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.
