Re: [PATCH] drm/mediatek: mtk_dsi: enable hs clock during pre-enable

[top-posting to facilitate]

Gary, Angelo, what's the status here? It looks like this fell through
the cracks -- or was this issue fixed in between somehow? If yes: great!
If not: Would be good to finally resolve this, as we are long past "fix
within a week" rule of thumb from Linus:
https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed

And also nearing -rc6, which is when Linus would like to see all known
regressions fixed.

Ciao, Thorsten

On 7/17/26 18:06, Gary Bisson wrote:
> On Wed, Jul 15, 2026 at 03:52:05PM +0200, Esben Haabendal wrote:
>> "AngeloGioacchino Del Regno" <[email protected]>
>> writes:
>>> On 7/15/26 15:36, Gary Bisson wrote:
>>>> On Wed, Jul 15, 2026 at 03:25:11PM +0200, AngeloGioacchino Del Regno wrote:
>>>>> On 7/15/26 14:53, Esben Haabendal wrote:
>>>>>> Gary Bisson <[email protected]> writes:
>>>>>>
>>>>>>> Some bridges, such as the TI SN65DSI83, require the HS clock to be
>>>>>>> running in order to lock its PLL during its own pre-enable function.
>>>>>>>
>>>>>>> Without this change, the bridge gives the following error:
>>>>>>> sn65dsi83 14-002c: failed to lock PLL, ret=-110
>>>>>>> sn65dsi83 14-002c: Unexpected link status 0x01
>>>>>>> sn65dsi83 14-002c: reset the pipe
>>>>>>>
>>>>>>> Move the necessary functions from enable to pre-enable.
>>>>>>>>>>>> I have run into the same problem, but in combination with
another
>>>>>> pipeline. I am seeing same problem with an i.MX8 using the nwl-dsi
>>>>>> bridge and the dcss driver.
>>>>>>
>>>>>> I have submitted a fix that adresses the problem in the ti-sn65dsi83
>>>>>> driver instead. With a bit of luck, it can replace the fix proposed in
>>>>>> this thread.
>>>>>>
>>>>>> See https://lore.kernel.org/all/[email protected]/
>>>>
>>>> Thanks, just tried it on 7.2-rc3 with my patch reverted and confirm that
>>>> it works too. My assumption was that the SN65DSI83 was locking the PLL
>>>> earlier for some specific reason and therefore was reluctant to change
>>>> it.
>>>>
>>>>> That clarifies a lot of things.
>>>>>
>>>>> The patch on mtk_dsi shall be reverted then.
>>>>
>>>> Angelo, do you want me to offer the revert patch? Should I wait to see
>>>> how the other thread goes?
>>>
>>> Gary, yes please, send a revert and make sure to explain the reason why
>>> we're reverting this in the commit description :-)
>>
>> Maybe test if my fix actually solves the problem with the mtk_dsi driver
>> also ;)
> 
> As mentioned in the other thread, your patch works but it might break
> the init sequence recommended by the bridge datasheet.
> 
> Moreover, the drm_bridge.c doc [1] does mention that the clock lane
> should be initialized during pre_enable. If we agree on this assumption
> I believe my patch should not be reverted.
> 
> Maybe Adam's bridge driver must be patched instead, just like the
> nwl-dsi driver should be updated to follow the drm recommendation.
> 
> Let me know your thoughts.