[PATCH 2/4] drm/bridge: tc358767: Move hardware init to enable callback

[Dave Stevenson]

On Tue, 7 Dec 2021 at 13:59, Marek Vasut <marex at denx.de> wrote:
>
> 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.

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?

> >>> 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.