linux-kernel - Re: [PATCH v7 1/2] 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: <18cd9c74699b5afe4d0bff9a6c325389d2881e29.camel@mediatek.com>
Date: Wed, 19 Nov 2025 09:18:05 +0000
From: CK Hu (胡俊光) <ck.hu@...iatek.com>
To: "simona@...ll.ch" <simona@...ll.ch>, Mac Shen (沈俊)
	<Mac.Shen@...iatek.com>, AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>, "chunkuang.hu@...nel.org"
	<chunkuang.hu@...nel.org>, "airlied@...il.com" <airlied@...il.com>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@...iatek.com>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>, "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	Peng Liu (刘鹏) <Peng.Liu@...iatek.com>,
	LIANKUN YANG (杨连坤) <Liankun.Yang@...iatek.com>
CC: "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 1/2] drm/mediatek: Adjust bandwidth limit for DP

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@...iatek.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;
>  		}
>  	}
>