On 12/7/21 14:34, Dave Stevenson wrote:
Hi,
The TC358767/TC358867/TC9595 are all capable of operating either from
attached Xtal or from DSI clock lane clock. In case the later is used,
all I2C accesses will fail until the DSI clock lane is running and
supplying clock to the chip.
Move all hardware initialization to enable callback to guarantee the
DSI clock lane is running before accessing the hardware. In case Xtal
is attached to the chip, this change has no effect.
This puzzles me as there seem to be a couple of ambiguities over how
it would be used.
Firstly the DT binding lists the clock as a required property, but
there isn't one present if deriving the clock from the DSI clock lane.
That's correct, the clock for the internal PLLs are derived from the DSI
clock lane.
Does that mean you're creating a dummy clock device?
If it's a required property then presumably yes, but it seems a little
odd as that reflck does not exist.
No. The refclk will become optional, but for that I need some more
infrastructure work, i.e. some way to communicate the requirements of
the DSI clock lane to the DSI host.
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.
Can I ask how the chip has actually been configured and run in this mode?
REFCLK Xtal disconnected and HSCKBY2/7 MODE0=H MODE1=L , that should be
all you need. Do you plan to develop a board with this bridge ?
Yes, I have a board with this chip in DSI to DPI mode that I'm trying
to get to work. The intent was to configure it via DSI LP commands
rather than I2C, but currently it's refusing to do anything.
I see.
