On 12/7/21 17:28, Dave Stevenson wrote:
Hi,
[...]
Secondly the datasheet states that the DSI Reference Clock Source Division Selection is done by the MODE1 pin, and switches between HSCKBY2 divided by 7 and HSCKBY2 divided by 9. There is a stated assumption that HSCK is either 364MHz or 468MHz, thereby ending up with 26MHz. To do this we have to be running DSI in burst mode, but the support for that in DRM is near zero.
Yes, you have to run the DSI clock lane at either of the two clock frequencies, that is rather limiting. The DSI has to be running in continuous clock mode, this has nothing to do with burst mode, the burst mode is a DSI host setting which is supported by most DSI hosts.
OK burst mode is technically dropping the lane to LP mode, and you don't need that state transition.
To quote the Toshiba datasheet: "As the clock derived from the DSICLK has to be fixed at 13, 26, 19.2 or 38.4 MHz, the DSI Host may need to run DSI clock lane at higher frequency than needed by frame rate and may have to send the DSI video mode transmissions in burst mode (explained in DSI section of this specification) "
So where are you configuring the DSI clock lane to be running at one of those frequencies? Or are you requiring your panel to be running with a matching pixel clock?
This is a preparatory patch, so nowhere yet. I forced the clock lane to the required clock frequency on the DSI host side thus far. You can still configure the chip to derive clock from Xtal, even with DSI as data input.
Ah, I'd read too much into the commit text and read it as already fully implemented with a DSI derived clock instead of refclk. Sorry.
Are you already working on the infrastructure changes, or are they just vaguely planned?
I plan to implement those changes, when I have time to do that.