[PATCH v7 0/2] Adjust bandwidth limit for DP

[PATCH v7 0/2] Adjust bandwidth limit for DP

[Liankun Yang]

DP link training checks the current PHY link signal quality.
After DP detects an HPD connection, it should first determine
the current link signal quality in order to select the resolution.

Since the EDP is already fixed to use the EDP panel,
the current training information and resolution are basically fixed.
EDP exists and its process differs from DP. Therefore,
it is necessary to isolate the parsing capability,
panel power, training state and enable state.

For example, the platform support DP 4lane 5.4G,
but panel A support DP 2lane 5.4G.

This is a time sequence:

1. Plug in panel A. According to the platform, it can output 4K 60Hz.
2. Timing mode set 4K 60Hz.
3. Atomic enable(Based on panel A ability, training pass 2lane 5.4G).
4. Finally, due to 2lane 5.4G bandwidth limitation, the platform cannot
output 4K 60Hz, resulting in a black sreen.

If apply this patch.

1. Plug in panel A.
2. Training pass 2lane 5.4G
3. Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit).
4. Atomic enable for output screen.

Liankun Yang (2):
  drm/mediatek: Adjust bandwidth limit for DP
  drm/mediatek: Add isolation to edp

 drivers/gpu/drm/mediatek/mtk_dp.c | 57 ++++++++++++++++++++-----------
 1 file changed, 38 insertions(+), 19 deletions(-)

-- 
2.45.2

[PATCH v7 1/2] 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.

The `mtk_dp_aux_panel_poweron` function fails to align.
Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`,
causing a failure and thus preventing symmetry.

Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
---
Change in V7:
- Separate the edp part:
https://patchwork.kernel.org/project/linux-mediatek/patch/20250822120506.15486-1-liankun.yang@mediatek.com/

Change in V6:
- Fixed power on in atomic enable.
Per suggestion from the previous thread:
https://patchwork.kernel.org/project/linux-mediatek/patch/20250630080824.7107-1-liankun.yang@mediatek.com/

Change in V5:
- Fixed the issue that the 4th version of the patch caused DP to have no screen.
Per suggestion from the previous thread:
https://patchwork.kernel.org/project/linux-mediatek/patch/20250625095446.31726-1-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 | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
index bef6eeb30d3e..0ba2c208811c 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,28 @@ 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));
 
+			mtk_dp->enabled = false;
+			/* 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->enabled = true;
 		}
 	}
 
-- 
2.45.2

[PATCH v7 2/2] drm/mediatek: Add isolation to edp

[Liankun Yang]

Because edp doesn't expect any (un)plug events during runtime and
its process differs from DP. Therefore, it is necessary to isolate
the parsing capability, panel power, training state and enable state.

And DP related behaviors are adjusted to execute in the second half
of the interrupt.
For DP details, see drm/mediatek: Adjust bandwidth limit for DP

Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
---
 drivers/gpu/drm/mediatek/mtk_dp.c | 37 +++++++++++++++----------------
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
index 0ba2c208811c..efd4c45985ca 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2187,7 +2187,8 @@ static const struct drm_edid *mtk_dp_edid_read(struct drm_bridge *bridge,
 	 * 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)) {
+	if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP &&
+	    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;
@@ -2385,13 +2386,15 @@ static void mtk_dp_bridge_atomic_enable(struct drm_bridge *bridge,
 		return;
 	}
 
-	mtk_dp_aux_panel_poweron(mtk_dp, true);
+	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
+		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;
+		/* 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);
@@ -2411,7 +2414,9 @@ static void mtk_dp_bridge_atomic_enable(struct drm_bridge *bridge,
 		       sizeof(mtk_dp->info.audio_cur_cfg));
 	}
 
-	mtk_dp->enabled = true;
+	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP)
+		mtk_dp->enabled = true;
+
 	mtk_dp_update_plugged_status(mtk_dp);
 
 	return;
@@ -2426,21 +2431,15 @@ static void mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
 {
 	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
 
-	mtk_dp->enabled = false;
+	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
+		mtk_dp->enabled = false;
+		mtk_dp_aux_panel_poweron(mtk_dp, false);
+	}
+
 	mtk_dp_update_plugged_status(mtk_dp);
 	mtk_dp_video_enable(mtk_dp, false);
 	mtk_dp_audio_mute(mtk_dp, true);
 
-	if (mtk_dp->train_info.cable_plugged_in) {
-		drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
-		usleep_range(2000, 3000);
-	}
-
-	/* power off aux */
-	mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
-			   DP_PWR_STATE_BANDGAP_TPLL,
-			   DP_PWR_STATE_MASK);
-
 	/* SDP path reset sw*/
 	mtk_dp_sdp_path_reset(mtk_dp);
 
-- 
2.45.2

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

[CK Hu (胡俊光)]

On Tue, 2025-11-04 at 16:55 +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.
> 
> The `mtk_dp_aux_panel_poweron` function fails to align.
> Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
> the `mtk_dp_aux_panel_poweron` function will write from `aux` to `DPRX`,
> causing a failure and thus preventing symmetry.

I'm curious about another case.
In your description, when DP plug out and plug in, DRM core would not call mtk_dp_bridge_atomic_enable(), right?
If so, when I plug out DP, and plug in another DP panel which support smaller resolution,
then mtk_dp_bridge_atomic_enable() is not called and below call sequence would not happen:

mtk_dp_bridge_atomic_enable() -> mtk_dp_video_enable() -> mtk_dp_set_tx_out() -> mtk_dp_setup_tu()

In mtk_dp_setup_tu, it would set sram_read_start according to lane_count.
But the call sequence would not happen when new plug in, the sram_read_start would be old value which may incorrect.
If think that when plug in and plug out, it should disable DP and then enable DP again.
If DRM core does not do this, I think we should modify DRM core or you should reconfig the whole DP when plug in, not only training.

Regards,
CK


> 
> Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> ---
> Change in V7:
> - Separate the edp part:
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20250822120506.15486-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dixTD-P0$ 
> 
> Change in V6:
> - Fixed power on in atomic enable.
> Per suggestion from the previous thread:
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20250630080824.7107-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9d2uyXyOA$ 
> 
> Change in V5:
> - Fixed the issue that the 4th version of the patch caused DP to have no screen.
> Per suggestion from the previous thread:
> https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20250625095446.31726-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dptlx1kc$ 
> 
> 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!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dTyrYJLQ$ 
> 
> 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://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20241025083036.8829-4-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9drgc9X0o$ 
> 
> 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://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20240315015233.2023-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dYxjNtE8$ 
> ---
>  drivers/gpu/drm/mediatek/mtk_dp.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index bef6eeb30d3e..0ba2c208811c 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,28 @@ 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));
>  
> +			mtk_dp->enabled = false;
> +			/* 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->enabled = true;
>  		}
>  	}
>  

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

[LIANKUN YANG (杨连坤)]

On Wed, 2025-11-19 at 09:18 +0000, CK Hu (胡俊光) wrote:
> On Tue, 2025-11-04 at 16:55 +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.
> > 
> > The `mtk_dp_aux_panel_poweron` function fails to align.
> > Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
> > the `mtk_dp_aux_panel_poweron` function will write from `aux` to
> > `DPRX`,
> > causing a failure and thus preventing symmetry.
> 
> I'm curious about another case.
> In your description, when DP plug out and plug in, DRM core would not
> call mtk_dp_bridge_atomic_enable(), right?
> If so, when I plug out DP, and plug in another DP panel which support
> smaller resolution,
> then mtk_dp_bridge_atomic_enable() is not called and below call
> sequence would not happen:
> 
> mtk_dp_bridge_atomic_enable() -> mtk_dp_video_enable() ->
> mtk_dp_set_tx_out() -> mtk_dp_setup_tu()
> 
> In mtk_dp_setup_tu, it would set sram_read_start according to
> lane_count.
> But the call sequence would not happen when new plug in, the
> sram_read_start would be old value which may incorrect.
> If think that when plug in and plug out, it should disable DP and
> then enable DP again.
> If DRM core does not do this, I think we should modify DRM core or
> you should reconfig the whole DP when plug in, not only training.
> 
> Regards,
> CK
> 

Hi CK

When DP plug out, DRM core will call mtk_dp_bridge_atomic_disable().
When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable().

If DP plug in, sram_read_start will be recalculate based on the lane
count.

Regards
Liankun.

> 
> > 
> > Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> > ---
> > Change in V7:
> > - Separate the edp part:
> > 
https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20250822120506.15486-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dixTD-P0$
> >  
> > 
> > Change in V6:
> > - Fixed power on in atomic enable.
> > Per suggestion from the previous thread:
> > 
https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20250630080824.7107-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9d2uyXyOA$
> >  
> > 
> > Change in V5:
> > - Fixed the issue that the 4th version of the patch caused DP to
> > have no screen.
> > Per suggestion from the previous thread:
> > 
https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20250625095446.31726-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dptlx1kc$
> >  
> > 
> > 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!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dTyrYJLQ$
> >  
> > 
> > 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://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20241025083036.8829-4-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9drgc9X0o$
> >  
> > 
> > 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://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/patch/20240315015233.2023-1-liankun.yang@mediatek.com/__;!!CTRNKA9wMg0ARbw!k4Lf9UagGvqF5rzqpPtWReo4zF4UzBkmgcHZq0z6q3f7kyA-rtj8kV8uiKP2nryG0sTpORl1Y58Sum9dYxjNtE8$
> >  
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dp.c | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
> > b/drivers/gpu/drm/mediatek/mtk_dp.c
> > index bef6eeb30d3e..0ba2c208811c 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,28 @@ 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));
> >  
> > +			mtk_dp->enabled = false;
> > +			/* 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->enabled = true;
> >  		}
> >  	}
> >  
> 
> 

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

[CK Hu (胡俊光)]

On Mon, 2025-11-24 at 09:14 +0000, LIANKUN YANG (杨连坤) wrote:
> On Wed, 2025-11-19 at 09:18 +0000, CK Hu (胡俊光) wrote:
> > On Tue, 2025-11-04 at 16:55 +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.
> > > 
> > > The `mtk_dp_aux_panel_poweron` function fails to align.
> > > Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
> > > the `mtk_dp_aux_panel_poweron` function will write from `aux` to
> > > `DPRX`,
> > > causing a failure and thus preventing symmetry.
> > 
> > I'm curious about another case.
> > In your description, when DP plug out and plug in, DRM core would not
> > call mtk_dp_bridge_atomic_enable(), right?
> > If so, when I plug out DP, and plug in another DP panel which support
> > smaller resolution,
> > then mtk_dp_bridge_atomic_enable() is not called and below call
> > sequence would not happen:
> > 
> > mtk_dp_bridge_atomic_enable() -> mtk_dp_video_enable() ->
> > mtk_dp_set_tx_out() -> mtk_dp_setup_tu()
> > 
> > In mtk_dp_setup_tu, it would set sram_read_start according to
> > lane_count.
> > But the call sequence would not happen when new plug in, the
> > sram_read_start would be old value which may incorrect.
> > If think that when plug in and plug out, it should disable DP and
> > then enable DP again.
> > If DRM core does not do this, I think we should modify DRM core or
> > you should reconfig the whole DP when plug in, not only training.
> > 
> > Regards,
> > CK
> > 
> 
> Hi CK
> 
> When DP plug out, DRM core will call mtk_dp_bridge_atomic_disable().
> When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable().


When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable(), and mtk_dp_bridge_atomic_enable would call mtk_dp_training().
So it's not necessary to call mtk_dp_training() in mtk_dp_hpd_event_thread().

Regards,
CK

> 
> If DP plug in, sram_read_start will be recalculate based on the lane
> count.
> 
> Regards
> Liankun.
> 
> > 
> > > 
> > > Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> > > ---
> > > ---
> > >  drivers/gpu/drm/mediatek/mtk_dp.c | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
> > > b/drivers/gpu/drm/mediatek/mtk_dp.c
> > > index bef6eeb30d3e..0ba2c208811c 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,28 @@ 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));
> > >  
> > > +			mtk_dp->enabled = false;
> > > +			/* 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->enabled = true;
> > >  		}
> > >  	}
> > >  
> > 
> > 

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

[LIANKUN YANG (杨连坤)]

On Wed, 2025-11-26 at 03:11 +0000, CK Hu (胡俊光) wrote:
> On Mon, 2025-11-24 at 09:14 +0000, LIANKUN YANG (杨连坤) wrote:
> > On Wed, 2025-11-19 at 09:18 +0000, CK Hu (胡俊光) wrote:
> > > On Tue, 2025-11-04 at 16:55 +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.
> > > > 
> > > > The `mtk_dp_aux_panel_poweron` function fails to align.
> > > > Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
> > > > the `mtk_dp_aux_panel_poweron` function will write from `aux`
> > > > to
> > > > `DPRX`,
> > > > causing a failure and thus preventing symmetry.
> > > 
> > > I'm curious about another case.
> > > In your description, when DP plug out and plug in, DRM core would
> > > not
> > > call mtk_dp_bridge_atomic_enable(), right?
> > > If so, when I plug out DP, and plug in another DP panel which
> > > support
> > > smaller resolution,
> > > then mtk_dp_bridge_atomic_enable() is not called and below call
> > > sequence would not happen:
> > > 
> > > mtk_dp_bridge_atomic_enable() -> mtk_dp_video_enable() ->
> > > mtk_dp_set_tx_out() -> mtk_dp_setup_tu()
> > > 
> > > In mtk_dp_setup_tu, it would set sram_read_start according to
> > > lane_count.
> > > But the call sequence would not happen when new plug in, the
> > > sram_read_start would be old value which may incorrect.
> > > If think that when plug in and plug out, it should disable DP and
> > > then enable DP again.
> > > If DRM core does not do this, I think we should modify DRM core
> > > or
> > > you should reconfig the whole DP when plug in, not only training.
> > > 
> > > Regards,
> > > CK
> > > 
> > 
> > Hi CK
> > 
> > When DP plug out, DRM core will call
> > mtk_dp_bridge_atomic_disable().
> > When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable().
> 
> 
> When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable(),
> and mtk_dp_bridge_atomic_enable would call mtk_dp_training().
> So it's not necessary to call mtk_dp_training() in
> mtk_dp_hpd_event_thread().
> 
> Regards,
> CK
> 

Hi CK.

This shows the current timings after the DP cable is plugged in,
as well as the modified timings.

current timings:		Fix timings:

mtk_dp_hpd_event_thread()	mtk_dp_hpd_event_thread()
				(including DP link training) 
	|				|
       ...			       ...
mtk_dp_bridge_mode_valid()	mtk_dp_bridge_mode_valid()
	|
       ...			       ...
mtk_dp_bridge_atomic_check()	mtk_dp_bridge_atomic_check()
	|
       ...			       ...
mtk_dp_bridge_atomic_enable()	mtk_dp_bridge_atomic_enable()
(including DP link training)


PS:
1. "..." represents ommited steps;

2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the
current lane count and link rate, and then filters each mode to
determine if it supports returning a status.

3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode,
&mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()`
function, `adjusted_mode` sets the currently selected display mode for
the DRM.

4. DP link training tests the signal conditions of the link between
DPTX and DPRX, and selects the lane count and link rate that meet
the signal conditions.

5. For example, the platform support DP 4lane 5.4G,
but panel A support DP 2lane 5.4G.

   This is a time sequence:

   a).Plug in panel A. According to the platform, it can output 4K
   60Hz.
   b). Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check
   function).
   c). Atomic enable(Based on panel A ability, training pass 2lane
   5.4G).
   d). Finally, due to 2lane 5.4G bandwidth limitation, the platform
   cannot output 4K 60Hz, resulting in a black sreen.

   If apply this patch.

   a). Plug in panel A.
   b). Training pass 2lane 5.4G
   c). Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit
   and including in mtk_dp_bridge_atomic_check function).
   d). Atomic enable for output screen.

Best Regards
Liankun.

> > 
> > If DP plug in, sram_read_start will be recalculate based on the
> > lane
> > count.
> > 
> > Regards
> > Liankun.
> > 
> > > 
> > > > 
> > > > Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> > > > ---
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_dp.c | 20 ++++++++++++++++++++
> > > >  1 file changed, 20 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
> > > > b/drivers/gpu/drm/mediatek/mtk_dp.c
> > > > index bef6eeb30d3e..0ba2c208811c 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,28 @@ 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));
> > > >  
> > > > +			mtk_dp->enabled = false;
> > > > +			/* 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->enabled = true;
> > > >  		}
> > > >  	}
> > > >  
> > > 
> > > 
> 
> 

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

[CK Hu (胡俊光)]

On Mon, 2025-12-01 at 06:39 +0000, LIANKUN YANG (杨连坤) wrote:
> On Wed, 2025-11-26 at 03:11 +0000, CK Hu (胡俊光) wrote:
> > On Mon, 2025-11-24 at 09:14 +0000, LIANKUN YANG (杨连坤) wrote:
> > > On Wed, 2025-11-19 at 09:18 +0000, CK Hu (胡俊光) wrote:
> > > > On Tue, 2025-11-04 at 16:55 +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.
> > > > > 
> > > > > The `mtk_dp_aux_panel_poweron` function fails to align.
> > > > > Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
> > > > > the `mtk_dp_aux_panel_poweron` function will write from `aux`
> > > > > to
> > > > > `DPRX`,
> > > > > causing a failure and thus preventing symmetry.
> > > > 
> > > > I'm curious about another case.
> > > > In your description, when DP plug out and plug in, DRM core would
> > > > not
> > > > call mtk_dp_bridge_atomic_enable(), right?
> > > > If so, when I plug out DP, and plug in another DP panel which
> > > > support
> > > > smaller resolution,
> > > > then mtk_dp_bridge_atomic_enable() is not called and below call
> > > > sequence would not happen:
> > > > 
> > > > mtk_dp_bridge_atomic_enable() -> mtk_dp_video_enable() ->
> > > > mtk_dp_set_tx_out() -> mtk_dp_setup_tu()
> > > > 
> > > > In mtk_dp_setup_tu, it would set sram_read_start according to
> > > > lane_count.
> > > > But the call sequence would not happen when new plug in, the
> > > > sram_read_start would be old value which may incorrect.
> > > > If think that when plug in and plug out, it should disable DP and
> > > > then enable DP again.
> > > > If DRM core does not do this, I think we should modify DRM core
> > > > or
> > > > you should reconfig the whole DP when plug in, not only training.
> > > > 
> > > > Regards,
> > > > CK
> > > > 
> > > 
> > > Hi CK
> > > 
> > > When DP plug out, DRM core will call
> > > mtk_dp_bridge_atomic_disable().
> > > When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable().
> > 
> > 
> > When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable(),
> > and mtk_dp_bridge_atomic_enable would call mtk_dp_training().
> > So it's not necessary to call mtk_dp_training() in
> > mtk_dp_hpd_event_thread().
> > 
> > Regards,
> > CK
> > 
> 
> Hi CK.
> 
> This shows the current timings after the DP cable is plugged in,
> as well as the modified timings.
> 
> current timings:		Fix timings:
> 
> mtk_dp_hpd_event_thread()	mtk_dp_hpd_event_thread()
> 				(including DP link training) 
> 	|				|
>        ...			       ...
> mtk_dp_bridge_mode_valid()	mtk_dp_bridge_mode_valid()
> 	|
>        ...			       ...
> mtk_dp_bridge_atomic_check()	mtk_dp_bridge_atomic_check()
> 	|
>        ...			       ...
> mtk_dp_bridge_atomic_enable()	mtk_dp_bridge_atomic_enable()
> (including DP link training)
> 
> 
> PS:
> 1. "..." represents ommited steps;
> 
> 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the
> current lane count and link rate, and then filters each mode to
> determine if it supports returning a status.
> 
> 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode,
> &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()`
> function, `adjusted_mode` sets the currently selected display mode for
> the DRM.
> 
> 4. DP link training tests the signal conditions of the link between
> DPTX and DPRX, and selects the lane count and link rate that meet
> the signal conditions.
> 
> 5. For example, the platform support DP 4lane 5.4G,
> but panel A support DP 2lane 5.4G.
> 
>    This is a time sequence:
> 
>    a).Plug in panel A. According to the platform, it can output 4K
>    60Hz.
>    b). Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check
>    function).
>    c). Atomic enable(Based on panel A ability, training pass 2lane
>    5.4G).
>    d). Finally, due to 2lane 5.4G bandwidth limitation, the platform
>    cannot output 4K 60Hz, resulting in a black sreen.
> 
>    If apply this patch.
> 
>    a). Plug in panel A.
>    b). Training pass 2lane 5.4G
>    c). Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit
>    and including in mtk_dp_bridge_atomic_check function).
>    d). Atomic enable for output screen.

The original commit message does not show WHY need to training in hotplug thread.
This explain shows WHY need to training in hotplug thread.
So replace the commit message with this explain.

Regards,
CK

> 
> Best Regards
> Liankun.
> 
> > > 
> > > If DP plug in, sram_read_start will be recalculate based on the
> > > lane
> > > count.
> > > 
> > > Regards
> > > Liankun.
> > > 
> > > > 
> > > > > 
> > > > > Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> > > > > ---
> > > > > ---
> > > > >  drivers/gpu/drm/mediatek/mtk_dp.c | 20 ++++++++++++++++++++
> > > > >  1 file changed, 20 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
> > > > > b/drivers/gpu/drm/mediatek/mtk_dp.c
> > > > > index bef6eeb30d3e..0ba2c208811c 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,28 @@ 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));
> > > > >  
> > > > > +			mtk_dp->enabled = false;
> > > > > +			/* 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->enabled = true;
> > > > >  		}
> > > > >  	}
> > > > >  
> > > > 
> > > > 
> > 
> > 

Re: [PATCH v7 2/2] drm/mediatek: Add isolation to edp

[CK Hu (胡俊光)]

On Tue, 2025-11-04 at 16:55 +0800, Liankun Yang wrote:
> Because edp doesn't expect any (un)plug events during runtime and
> its process differs from DP. Therefore, it is necessary to isolate
> the parsing capability, panel power, training state and enable state.
> 
> And DP related behaviors are adjusted to execute in the second half
> of the interrupt.
> For DP details, see drm/mediatek: Adjust bandwidth limit for DP
> 
> Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> ---
>  drivers/gpu/drm/mediatek/mtk_dp.c | 37 +++++++++++++++----------------
>  1 file changed, 18 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
> index 0ba2c208811c..efd4c45985ca 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> @@ -2187,7 +2187,8 @@ static const struct drm_edid *mtk_dp_edid_read(struct drm_bridge *bridge,
>  	 * 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)) {
> +	if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP &&
> +	    mtk_dp_parse_capabilities(mtk_dp)) {

This is not related to dp training.
If dp does not need to parse edid, describe WHY and do not mix edid modification with dp training modification.

>  		drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n");
>  		drm_edid_free(drm_edid);
>  		drm_edid = NULL;
> @@ -2385,13 +2386,15 @@ static void mtk_dp_bridge_atomic_enable(struct drm_bridge *bridge,
>  		return;
>  	}
>  
> -	mtk_dp_aux_panel_poweron(mtk_dp, true);
> +	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
> +		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;
> +		/* Training */
> +		ret = mtk_dp_training(mtk_dp);
> +		if (ret) {
> +			drm_err(mtk_dp->drm_dev, "Training failed, %d\n", ret);
> +			goto power_off_aux;
> +		}

Merge this to previous patch.

>  	}
>  
>  	ret = mtk_dp_video_config(mtk_dp);
> @@ -2411,7 +2414,9 @@ static void mtk_dp_bridge_atomic_enable(struct drm_bridge *bridge,
>  		       sizeof(mtk_dp->info.audio_cur_cfg));
>  	}
>  
> -	mtk_dp->enabled = true;
> +	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP)
> +		mtk_dp->enabled = true;

Merge this to previous patch.

> +
>  	mtk_dp_update_plugged_status(mtk_dp);
>  
>  	return;
> @@ -2426,21 +2431,15 @@ static void mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
>  {
>  	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
>  
> -	mtk_dp->enabled = false;
> +	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
> +		mtk_dp->enabled = false;

Merge this to previous patch.

> +		mtk_dp_aux_panel_poweron(mtk_dp, false);

You change the code flow of DRM_MODE_CONNECTOR_eDP.
I think you should not change this.

> +	}
> +
>  	mtk_dp_update_plugged_status(mtk_dp);
>  	mtk_dp_video_enable(mtk_dp, false);
>  	mtk_dp_audio_mute(mtk_dp, true);
>  
> -	if (mtk_dp->train_info.cable_plugged_in) {
> -		drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
> -		usleep_range(2000, 3000);

For DRM_MODE_CONNECTOR_DP, you remove this usleep. This may cause side effect.
Doesn't it?

> -	}
> -
> -	/* power off aux */
> -	mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
> -			   DP_PWR_STATE_BANDGAP_TPLL,
> -			   DP_PWR_STATE_MASK);

if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
	/* power off aux */
	mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
			   DP_PWR_STATE_BANDGAP_TPLL,
			   DP_PWR_STATE_MASK);
}

Regards,
CK

> -
>  	/* SDP path reset sw*/
>  	mtk_dp_sdp_path_reset(mtk_dp);
>  

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

[CK Hu (胡俊光)]

On Mon, 2025-12-01 at 06:39 +0000, LIANKUN YANG (杨连坤) wrote:
> On Wed, 2025-11-26 at 03:11 +0000, CK Hu (胡俊光) wrote:
> > On Mon, 2025-11-24 at 09:14 +0000, LIANKUN YANG (杨连坤) wrote:
> > > On Wed, 2025-11-19 at 09:18 +0000, CK Hu (胡俊光) wrote:
> > > > On Tue, 2025-11-04 at 16:55 +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.
> > > > > 
> > > > > The `mtk_dp_aux_panel_poweron` function fails to align.
> > > > > Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
> > > > > the `mtk_dp_aux_panel_poweron` function will write from `aux`
> > > > > to
> > > > > `DPRX`,
> > > > > causing a failure and thus preventing symmetry.
> > > > 
> > > > I'm curious about another case.
> > > > In your description, when DP plug out and plug in, DRM core would
> > > > not
> > > > call mtk_dp_bridge_atomic_enable(), right?
> > > > If so, when I plug out DP, and plug in another DP panel which
> > > > support
> > > > smaller resolution,
> > > > then mtk_dp_bridge_atomic_enable() is not called and below call
> > > > sequence would not happen:
> > > > 
> > > > mtk_dp_bridge_atomic_enable() -> mtk_dp_video_enable() ->
> > > > mtk_dp_set_tx_out() -> mtk_dp_setup_tu()
> > > > 
> > > > In mtk_dp_setup_tu, it would set sram_read_start according to
> > > > lane_count.
> > > > But the call sequence would not happen when new plug in, the
> > > > sram_read_start would be old value which may incorrect.
> > > > If think that when plug in and plug out, it should disable DP and
> > > > then enable DP again.
> > > > If DRM core does not do this, I think we should modify DRM core
> > > > or
> > > > you should reconfig the whole DP when plug in, not only training.
> > > > 
> > > > Regards,
> > > > CK
> > > > 
> > > 
> > > Hi CK
> > > 
> > > When DP plug out, DRM core will call
> > > mtk_dp_bridge_atomic_disable().
> > > When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable().
> > 
> > 
> > When DP plug in, DRM core will call mtk_dp_bridge_atomic_enable(),
> > and mtk_dp_bridge_atomic_enable would call mtk_dp_training().
> > So it's not necessary to call mtk_dp_training() in
> > mtk_dp_hpd_event_thread().
> > 
> > Regards,
> > CK
> > 
> 
> Hi CK.
> 
> This shows the current timings after the DP cable is plugged in,
> as well as the modified timings.
> 
> current timings:		Fix timings:
> 
> mtk_dp_hpd_event_thread()	mtk_dp_hpd_event_thread()
> 				(including DP link training) 
> 	|				|
>        ...			       ...
> mtk_dp_bridge_mode_valid()	mtk_dp_bridge_mode_valid()
> 	|
>        ...			       ...
> mtk_dp_bridge_atomic_check()	mtk_dp_bridge_atomic_check()
> 	|
>        ...			       ...
> mtk_dp_bridge_atomic_enable()	mtk_dp_bridge_atomic_enable()
> (including DP link training)
> 
> 
> PS:
> 1. "..." represents ommited steps;
> 
> 2. `mtk_dp_bridge_mode_valid()` calculates the bandwidth using the
> current lane count and link rate, and then filters each mode to
> determine if it supports returning a status.
> 
> 3. In the `drm_display_mode_to_videomode(&crtc_state->adjusted_mode,
> &mtk_dp->info.vm);` function, within the `mtk_dp_bridge_atomic_check()`
> function, `adjusted_mode` sets the currently selected display mode for
> the DRM.
> 
> 4. DP link training tests the signal conditions of the link between
> DPTX and DPRX, and selects the lane count and link rate that meet
> the signal conditions.
> 
> 5. For example, the platform support DP 4lane 5.4G,
> but panel A support DP 2lane 5.4G.
> 
>    This is a time sequence:
> 
>    a).Plug in panel A. According to the platform, it can output 4K
>    60Hz.
>    b). Timing mode set 4K 60Hz(Including in mtk_dp_bridge_atomic_check
>    function).
>    c). Atomic enable(Based on panel A ability, training pass 2lane
>    5.4G).
>    d). Finally, due to 2lane 5.4G bandwidth limitation, the platform
>    cannot output 4K 60Hz, resulting in a black sreen.
> 
>    If apply this patch.
> 
>    a). Plug in panel A.
>    b). Training pass 2lane 5.4G
>    c). Timing mode set 2K 60Hz(Based on the 2lane 5.4G bandwidth limit
>    and including in mtk_dp_bridge_atomic_check function).
>    d). Atomic enable for output screen.

The original title does not show exactly what this patch do.
This patch does not only adjust bandwidth limit, it also fix some bugs.
I prefer the title to be "Move DP training to hotplug thread"

Regards,
CK

> 
> Best Regards
> Liankun.
> 
> > > 
> > > If DP plug in, sram_read_start will be recalculate based on the
> > > lane
> > > count.
> > > 
> > > Regards
> > > Liankun.
> > > 
> > > > 
> > > > > 
> > > > > Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> > > > > ---
> > > > > ---
> > > > >  drivers/gpu/drm/mediatek/mtk_dp.c | 20 ++++++++++++++++++++
> > > > >  1 file changed, 20 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
> > > > > b/drivers/gpu/drm/mediatek/mtk_dp.c
> > > > > index bef6eeb30d3e..0ba2c208811c 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,28 @@ 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));
> > > > >  
> > > > > +			mtk_dp->enabled = false;
> > > > > +			/* 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->enabled = true;
> > > > >  		}
> > > > >  	}
> > > > >  
> > > > 
> > > > 
> > 
> > 

Re: [PATCH v7 2/2] drm/mediatek: Add isolation to edp

[LIANKUN YANG (杨连坤)]

On Wed, 2025-12-17 at 10:08 +0000, CK Hu (胡俊光) wrote:
> On Tue, 2025-11-04 at 16:55 +0800, Liankun Yang wrote:
> > Because edp doesn't expect any (un)plug events during runtime and
> > its process differs from DP. Therefore, it is necessary to isolate
> > the parsing capability, panel power, training state and enable
> > state.
> > 
> > And DP related behaviors are adjusted to execute in the second half
> > of the interrupt.
> > For DP details, see drm/mediatek: Adjust bandwidth limit for DP
> > 
> > Signed-off-by: Liankun Yang <liankun.yang@mediatek.com>
> > ---
> >  drivers/gpu/drm/mediatek/mtk_dp.c | 37 +++++++++++++++----------
> > ------
> >  1 file changed, 18 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
> > b/drivers/gpu/drm/mediatek/mtk_dp.c
> > index 0ba2c208811c..efd4c45985ca 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> > @@ -2187,7 +2187,8 @@ static const struct drm_edid
> > *mtk_dp_edid_read(struct drm_bridge *bridge,
> >  	 * 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)) {
> > +	if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP &&
> > +	    mtk_dp_parse_capabilities(mtk_dp)) {
> 
> This is not related to dp training.
> If dp does not need to parse edid, describe WHY and do not mix edid
> modification with dp training modification.
> 

`mtk_dp_parse_capabilities` is related to DP training, it is
used in `mtk_dp_hpd_event_thread` before DP training, and then only
used by eDP when read edid.

Read edid continued according to its original logic and was unaffected.
	...
	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) {
	...

> >  		drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n");
> >  		drm_edid_free(drm_edid);
> >  		drm_edid = NULL;
> > @@ -2385,13 +2386,15 @@ static void
> > mtk_dp_bridge_atomic_enable(struct drm_bridge *bridge,
> >  		return;
> >  	}
> >  
> > -	mtk_dp_aux_panel_poweron(mtk_dp, true);
> > +	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
> > +		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;
> > +		/* Training */
> > +		ret = mtk_dp_training(mtk_dp);
> > +		if (ret) {
> > +			drm_err(mtk_dp->drm_dev, "Training failed,
> > %d\n", ret);
> > +			goto power_off_aux;
> > +		}
> 
> Merge this to previous patch.
> 
> >  	}
> >  
> >  	ret = mtk_dp_video_config(mtk_dp);
> > @@ -2411,7 +2414,9 @@ static void
> > mtk_dp_bridge_atomic_enable(struct drm_bridge *bridge,
> >  		       sizeof(mtk_dp->info.audio_cur_cfg));
> >  	}
> >  
> > -	mtk_dp->enabled = true;
> > +	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP)
> > +		mtk_dp->enabled = true;
> 
> Merge this to previous patch.
> 
> > +
> >  	mtk_dp_update_plugged_status(mtk_dp);
> >  
> >  	return;
> > @@ -2426,21 +2431,15 @@ static void
> > mtk_dp_bridge_atomic_disable(struct drm_bridge *bridge,
> >  {
> >  	struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
> >  
> > -	mtk_dp->enabled = false;
> > +	if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
> > +		mtk_dp->enabled = false;
> 
> Merge this to previous patch.
> 
> > +		mtk_dp_aux_panel_poweron(mtk_dp, false);
> 
> You change the code flow of DRM_MODE_CONNECTOR_eDP.
> I think you should not change this.
> 
> > +	}
> > +
> >  	mtk_dp_update_plugged_status(mtk_dp);
> >  	mtk_dp_video_enable(mtk_dp, false);
> >  	mtk_dp_audio_mute(mtk_dp, true);
> >  
> > -	if (mtk_dp->train_info.cable_plugged_in) {
> > -		drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER,
> > DP_SET_POWER_D3);
> > -		usleep_range(2000, 3000);
> 
> For DRM_MODE_CONNECTOR_DP, you remove this usleep. This may cause
> side effect.
> Doesn't it?
> 

The modification to `mtk_dp_bridge_atomic_disable` here is base on
the same logic as `mtk_dp_aux_panel_poweron(mtk_dp, false);`.

Modify part of in `mtk_dp_bridge_atomic_disable`
  if (mtk_dp->train_info.cable_plugged_in) {
    drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
    usleep_range(2000, 3000);
  }

  /* power off aux */
  mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
		DP_PWR_STATE_BANDGAP_TPLL,
		DP_PWR_STATE_MASK);

Modify part of in `mtk_dp_aux_panel_poweron(mtk_dp, false);`
  if (pwron) {
    ....
  } else {
    /* power off panel */
    drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
    usleep_range(2000, 3000);

    /* power off aux */
    mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
			DP_PWR_STATE_BANDGAP_TPLL,
			DP_PWR_STATE_MASK);
  }

The `mtk_dp_aux_panel_poweron` function fails to align.
Within the `mtk_dp_hpd_event_thread`, if DP is disconnected,
the `mtk_dp_aux_panel_poweron` function will write from `aux`
to `DPRX`, causing a failure and thus preventing symmetry.

> > -	}
> > -
> > -	/* power off aux */
> > -	mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
> > -			   DP_PWR_STATE_BANDGAP_TPLL,
> > -			   DP_PWR_STATE_MASK);
> 
> if (mtk_dp->data->bridge_type == DRM_MODE_CONNECTOR_eDP) {
> 	/* power off aux */
> 	mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
> 			   DP_PWR_STATE_BANDGAP_TPLL,
> 			   DP_PWR_STATE_MASK);
> }
> 
> Regards,
> CK
> 
> > -
> >  	/* SDP path reset sw*/
> >  	mtk_dp_sdp_path_reset(mtk_dp);
> >  
> 
>