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

[Thorsten Leemhuis]

On 7/27/26 14:48, Gary Bisson wrote:
> On Mon, Jul 27, 2026 at 02:28:56PM +0200, Thorsten Leemhuis wrote:
>> [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
> 
> Not much happened I'm afraid. The status as I see is:
> - this patch is necessary to have TI SN65DSI83 working
> - this patch also follows the DRM guidelines saying that HS clock must
>   be enabled during pre_enable (see previous answer / [1])
> - this patch has been successfully tested against MIPI-DSI panels (by
>   Angelo) and LVDS panels via TI bridge (by myself)
> - Adam reported an issue with another bridge (PS8640) where resume is
>   broken
> - Esben offered a patch to the TI bridge that would fix the issue we
>   were seeing in the first place.
> 
> But for the last two points, I'm not sure this calls for a revert yet:
> - enabling HS clock in pre_enable still is what should be done [1]
> - maybe the issue Adam is facing is due to the bridge driver instead as
>   it could not be reproduced with another setup
> - Esben patch would break the SN65DSI83 init sequence, suggesting that
>   the culprit really is the MIPI bridge for not following the HS clock
>   requirement in pre_enable instead [2]
It's tricky, yes, but I suspect the right time for a revert was weeks
ago. What Linus afaics basically wants in situations like this (espe.
with two reporters) boils down to "something broke recently, no fix was
found within a week or maybe two, so we go back to the previous state to
restart from there -- and this is nothing bad, that's just done to buy
us time."

If something is right by some hardware or DRM specs often doesn't matter
much. What makes this tricky is the fact that the revert might cause a
regression for those that relied on the functionally the change brought.
But I suspect even then Linus prefers a revert, as it's a recent change
that only went into 7.1. The quoted from Linus on this page cover this iirc:
https://www.kernel.org/doc/html/latest/process/handling-regressions.html#quotes-from-linus-about-regression

If we can't agree on this, we maybe should ask Simona or Airlied for advice.

Ciao, Thorsten