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

Mon Jul 27 08:54:02 PDT 2026

On 7/27/26 16:23, Thorsten Leemhuis wrote:
> 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

Thorsten,
I agree with you, and it's fine for me to get this commit reverted, for the sake
of following the rule (which is something I agree about: as a user, the last thing
that should happen is to be afraid of what breaks if I update my system!!!!),
even though reverting this actually breaks anything that is not PS8640.

......though......

Everyone, please, look at how fundamentally broken PS8640 is... Qualcomm people had
the same issue as what is currently happening here.

They had to fix their DSI driver, as it was kind-of broken in a vagualy similar way
compared to MediaTek - and then they found out that they needed (and upstreamed) a
*hack* that had to be done specifically for the PS8640 Bridge [1]: their issue was
never really resolved, as then the same bridge started casually working for unknown
reasons (is it still working?), so they removed the hack [2] and called it a day.

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/dsi/dsi_manager.c?h=next-20260726&id=ec7981e6c614254937b37ce0af9eac09901c05c5
[2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/dsi/dsi_manager.c?h=next-20260726&id=9e15123eca7942caa8a3e1f58ec0df7d088df149

Especially in [2], the assmption from Dmitry sadly isn't correct, because this is
happening now on MediaTek, and here Runtime PM makes sure that the PS8640 is also
being enabled "a wee bit" earlier than DSI... but that doesn't seem to be enough.


Now, here I'm kind of shotgunning at the driver, but I wonder if anyone can try
the following patch before reverting this commit in mtk_dsi? Adam?

---
  drivers/gpu/drm/bridge/parade-ps8640.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 96332721cb69..54ebf2fc8d1c 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -665,6 +665,7 @@ static int ps8640_probe(struct i2c_client *client)

  	ps_bridge->bridge.of_node = dev->of_node;
  	ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
+	ps_bridge->bridge.pre_enable_prev_first = true;

  	/*
  	 * Get MIPI DSI resources early. These can return -EPROBE_DEFER so
-- 
2.55.0

Cheers,
Angelo

