[PATCH v4 1/1] drm/mediatek: Adjust bandwidth limit for DP

[Nícolas F. R. A. Prado]

On Fri, 2025-06-27 at 01:32 +0000, CK Hu (胡俊光) wrote:
> On Wed, 2025-06-25 at 14:49 -0400, Nícolas F. R. A. Prado wrote:
> > External email : Please do not click links or open attachments
> > until you have verified the sender or the content.
> > 
> > 
> > On Wed, 2025-06-25 at 17:54 +0800, Liankun Yang wrote:
> > > By adjusting the order of link training and relocating it to HPD,
> > > link training can identify the usability of each lane in the
> > > current
> > > link.
> > > 
> > > It also supports handling signal instability and weakness due to
> > > environmental issues, enabling the acquisition of a stable
> > > bandwidth
> > > for the current link. Subsequently, DP work can proceed based on
> > > the actual maximum bandwidth.
> > > 
> > > It should training in the hpd event thread.
> > > Check the mode with lane count and link rate of training.
> > > 
> > > If we're eDP and capabilities were already parsed we can skip
> > > reading again because eDP panels aren't hotpluggable hence the
> > > caps and training information won't ever change in a boot life
> > > 
> > > Therefore, bridge typec judgment is required for edp training in
> > > atomic_enable function.
> > > 
> > > Signed-off-by: Liankun Yang <liankun.yang at mediatek.com>
> > > ---
> > > Change in V4:
> > > - Tested the internal eDP display on MT8195 Tomato and it is
> > > fine.
> > > Per suggestion from the previous thread:
> > > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20250318140236.13650-2-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!g0Ii2UaT9Wu1FktoGneG4gHV_zwIAwcqEihEA0W4XHKOW2vv7i5MLlekFB9AbbBJvWKvbyaiQFkF-JpPcq0$
> > 
> > Hi,
> > 
> > I tested this patch on MT8195 Tomato, on top of next-20250625.
> > Indeed
> > the internal eDP display is unaffected by this commit: it still
> > works
> > fine.
> > 
> > The external displays though not so much. I tested 3 different
> > displays, using 2 different USBC-to-HDMI adapters, and in all cases
> > the
> > behavior was the same:
> > - Before the patch, the image on the display is completely
> > corrupted
> > and unusable. The only discernible element on the display is the
> > mouse
> > cursor, which shows perfectly fine. Occasionally no image will be
> > shown
> > at all, but most of the times, the behavior is as described.
> > - After the patch, nothing ever shows at all on the display. It is
> > always black.
> > 
> > So while the external display support on Tomato is basically broken
> > as
> > of the latest next, this patch seems to regress the support even
> > further.
> 
> Hi, Nicolas:
> 
> Have external display worked normally in previous version?
> If no, I think this patch just let external display change from one
> bad state to another bad state.
> If yes, I think we should fix this problem first, and then apply this
> patch to test.

Hi,

I do remember the external display working on Tomato before, but it's
been a long time since I'd last tested.

In any case, as I've described it is currently basically broken (just
the mouse cursor renders fine), so indeed this patch is bringing the
display from one bad state to another bad state. The bad state after
the patch is even worse than before, since nothing even shows, so
personally I think it'd make more sense to fix this issue before
merging this patch, so we can actually make sure the patch works well,
but I'll leave it for you to decide the best way forward.


-- 
Thanks,

Nícolas