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

[Marek Vasut]

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.