linux-kernel - Re: [PATCH v4 1/1] drm/mediatek: Adjust bandwidth limit for DP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f3135961b2fe2c2b5cb3c29d76eb3d818d7a766a.camel@collabora.com>
Date: Wed, 25 Jun 2025 14:49:53 -0400
From: Nícolas "F. R. A. Prado" <nfraprado@...labora.com>
To: Liankun Yang <liankun.yang@...iatek.com>, chunkuang.hu@...nel.org, 
 p.zabel@...gutronix.de, airlied@...il.com, simona@...ll.ch,
 matthias.bgg@...il.com,  angelogioacchino.delregno@...labora.com,
 mac.shen@...iatek.com,  peng.liu@...iatek.com,
 Project_Global_Chrome_Upstream_Group@...iatek.com
Cc: dri-devel@...ts.freedesktop.org, linux-mediatek@...ts.infradead.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/1] drm/mediatek: Adjust bandwidth limit for DP

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@...iatek.com>
> ---
> Change in V4:
> - Tested the internal eDP display on MT8195 Tomato and it is fine.
> Per suggestion from the previous thread:
> https://patchwork.kernel.org/project/linux-mediatek/patch/20250318140236.13650-2-liankun.yang@mediatek.com/

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.

-- 
Thanks,

Nícolas