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