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

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

[Liankun Yang]

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@mediatek.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/

Change in V3:
- Remove 'mtk_dp->enabled = false" in atomic disable.
- Remove 'mtk_dp->enabled = true" in atomic enable.
Per suggestion from the previous thread:
https://patchwork.kernel.org/project/linux-mediatek/patch/20241025083036.8829-4-liankun.yang@mediatek.com/

Change in V2:
- Adjust DP training timing.
- Adjust parse capabilities timing.
- Add power on/off for connect/disconnect.
Per suggestion from the previous thread:
https://patchwork.kernel.org/project/linux-mediatek/patch/20240315015233.2023-1-liankun.yang@mediatek.com/
---
 drivers/gpu/drm/mediatek/mtk_dp.c | 42 +++++++++++++++++++------------
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
index a5b10b2545dc..36e07954965b 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -1976,6 +1976,7 @@ static irqreturn_t mtk_dp_hpd_event_thread(int hpd, void *dev)
 	struct mtk_dp *mtk_dp = dev;
 	unsigned long flags;
 	u32 status;
+	int ret;
 
 	if (mtk_dp->need_debounce && mtk_dp->train_info.cable_plugged_in)
 		msleep(100);
@@ -1994,9 +1995,27 @@ static irqreturn_t mtk_dp_hpd_event_thread(int hpd, void *dev)
 			memset(&mtk_dp->info.audio_cur_cfg, 0,
 			       sizeof(mtk_dp->info.audio_cur_cfg));
 
+			/* power off aux */
+			mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
+					   DP_PWR_STATE_BANDGAP_TPLL,
+					   DP_PWR_STATE_MASK);
+
 			mtk_dp->need_debounce = false;
 			mod_timer(&mtk_dp->debounce_timer,
 				  jiffies + msecs_to_jiffies(100) - 1);
+		} else {
+			mtk_dp_aux_panel_poweron(mtk_dp, true);
+
+			ret = mtk_dp_parse_capabilities(mtk_dp);
+			if (ret)
+				drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n");
+
+			/* Training */
+			ret = mtk_dp_training(mtk_dp);
+			if (ret)
+				drm_err(mtk_dp->drm_dev, "Training failed, %d\n", ret);
+
+			mtk_dp_aux_panel_poweron(mtk_dp, false);
 		}
 	}
 
@@ -2161,17 +2180,6 @@ static const struct drm_edid *mtk_dp_edid_read(struct drm_bridge *bridge,
 	}
 
 	drm_edid = drm_edid_read_ddc(connector, &mtk_dp->aux.ddc);
-
-	/*
-	 * Parse capability here to let atomic_get_input_bus_fmts and
-	 * mode_valid use the capability to calculate sink bitrates.
-	 */
-	if (mtk_dp_parse_capabilities(mtk_dp)) {
-		drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n");
-		drm_edid_free(drm_edid);
-		drm_edid = NULL;
-	}
-
 	if (drm_edid) {
 		/*
 		 * FIXME: get rid of drm_edid_raw()
@@ -2366,11 +2374,13 @@ static void mtk_dp_bridge_atomic_enable(struct drm_bridge *bridge,
 
 	mtk_dp_aux_panel_poweron(mtk_dp, true);
 
-	/* Training */
-	ret = mtk_dp_training(mtk_dp);
-	if (ret) {
-		drm_err(mtk_dp->drm_dev, "Training failed, %d\n", ret);
-		goto power_off_aux;
+	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
+		/* Training */
+		ret = mtk_dp_training(mtk_dp);
+		if (ret) {
+			drm_err(mtk_dp->drm_dev, "Training failed, %d\n", ret);
+			goto power_off_aux;
+		}
 	}
 
 	ret = mtk_dp_video_config(mtk_dp);
-- 
2.45.2

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

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

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@mediatek.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

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

[CK Hu (胡俊光)]

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

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@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.

Regards,
CK

> 
> --
> Thanks,
> 
> Nícolas


[-- Attachment #2: Type: text/html, Size: 5624 bytes --]

Re: [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@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