From: "LIANKUN YANG (杨连坤)" <Liankun.Yang@mediatek.com>
To: "Peng Liu (刘鹏)" <Peng.Liu@mediatek.com>,
"Mac Shen (沈俊)" <Mac.Shen@mediatek.com>,
"chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
"simona@ffwll.ch" <simona@ffwll.ch>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"CK Hu (胡俊光)" <ck.hu@mediatek.com>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>,
"airlied@gmail.com" <airlied@gmail.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 1/2] drm/mediatek: Adjust bandwidth limit for DP
Date: Mon, 1 Dec 2025 06:39:15 +0000 [thread overview]
Message-ID: <f4e8ba2e9f9a8e5fd4b35afe25b9874c64c6ea17.camel@mediatek.com> (raw)
In-Reply-To: <54b075b4ff6b9aa7cd916bb65e34e5edae3642dc.camel@mediatek.com>
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;
> > > > }
> > > > }
> > > >
> > >
> > >
>
>
next prev parent reply other threads:[~2025-12-01 6:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 8:55 [PATCH v7 0/2] " Liankun Yang
2025-11-04 8:55 ` [PATCH v7 1/2] drm/mediatek: " Liankun Yang
2025-11-19 9:18 ` CK Hu (胡俊光)
2025-11-24 9:14 ` LIANKUN YANG (杨连坤)
2025-11-26 3:11 ` CK Hu (胡俊光)
2025-12-01 6:39 ` LIANKUN YANG (杨连坤) [this message]
2025-12-17 9:59 ` CK Hu (胡俊光)
2025-12-18 1:13 ` CK Hu (胡俊光)
2025-11-04 8:55 ` [PATCH v7 2/2] drm/mediatek: Add isolation to edp Liankun Yang
2025-12-17 10:08 ` CK Hu (胡俊光)
2025-12-23 6:34 ` LIANKUN YANG (杨连坤)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4e8ba2e9f9a8e5fd4b35afe25b9874c64c6ea17.camel@mediatek.com \
--to=liankun.yang@mediatek.com \
--cc=Mac.Shen@mediatek.com \
--cc=Peng.Liu@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=ck.hu@mediatek.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®