From: <Hermes.Wu@ite.com.tw>
To: <dmitry.baryshkov@oss.qualcomm.com>
Cc: <andrzej.hajda@intel.com>, <neil.armstrong@linaro.org>,
<rfoss@kernel.org>, <Laurent.pinchart@ideasonboard.com>,
<jonas@kwiboo.se>, <jernej.skrabec@gmail.com>,
<maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>,
<tzimmermann@suse.de>, <airlied@gmail.com>, <simona@ffwll.ch>,
<Pet.Weng@ite.com.tw>, <Kenneth.Hung@ite.com.tw>,
<treapking@chromium.org>, <dri-devel@lists.freedesktop.org>,
<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH RESEND v3 3/5] drm/bridge: it6505: modify DP link auto training
Date: Thu, 18 Sep 2025 02:23:35 +0000 [thread overview]
Message-ID: <e25dfcb49f5949ab9952c46a2984bbf5@ite.com.tw> (raw)
In-Reply-To: <nh3mxefaqznbirhez4c5xtkvs756cjasmb5bdsxol7cai7u4da@3nmtq6figidw>
>
>
>-----Original Message-----
>From: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>Sent: Wednesday, September 17, 2025 9:47 PM
>To: Hermes Wu (吳佳宏) <Hermes.Wu@ite.com.tw>
>Cc: andrzej.hajda@intel.com; neil.armstrong@linaro.org; rfoss@kernel.org; Laurent.pinchart@ideasonboard.com; jonas@kwiboo.se; jernej.skrabec@gmail.com; maarten.lankhorst@linux.intel.com; mripard@kernel.org; tzimmermann@suse.de; airlied@gmail.com; simona@ffwll.ch; Pet Weng (翁玉芬) <Pet.Weng@ite.com.tw>; Kenneth Hung (洪家倫) <Kenneth.Hung@ite.com.tw>; treapking@chromium.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org
>Subject: Re: [PATCH RESEND v3 3/5] drm/bridge: it6505: modify DP link auto training
>
>On Wed, Sep 17, 2025 at 08:37:10AM +0000, Hermes.Wu@ite.com.tw wrote:
>>
>> >-----Original Message-----
>> >From: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> >Sent: Tuesday, September 16, 2025 6:49 PM
>> >To: Hermes Wu (吳佳宏) <Hermes.Wu@ite.com.tw>
>> >Cc: Andrzej Hajda <andrzej.hajda@intel.com>; Neil Armstrong <neil.armstrong@linaro.org>; Robert Foss <rfoss@kernel.org>; Laurent Pinchart <Laurent.pinchart@ideasonboard.com>; Jonas Karlman <jonas@kwiboo.se>; Jernej Skrabec <jernej.skrabec@gmail.com>; Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>; David Airlie <airlied@gmail.com>; Simona Vetter <simona@ffwll.ch>; Pet Weng (翁玉芬) <Pet.Weng@ite.com.tw>; Kenneth Hung (洪家倫) <Kenneth.Hung@ite.com.tw>; treapking@chromium.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org
>> >Subject: Re: [PATCH RESEND v3 3/5] drm/bridge: it6505: modify DP link auto training
>> >
>> >On Tue, Sep 16, 2025 at 12:47:43PM +0800, Hermes Wu via B4 Relay wrote:
>> >> From: Hermes Wu <Hermes.wu@ite.com.tw>
>> >>
>> >> IT6505 supports HW link training which will write DPCD and check
>> >> training status automatically.
>> >>
>> >> In the case that driver set link rate at 2.7G and HW fail to training,
>> >> it will change link configuration and try 1.65G. And this will cause
>> >> INT_VID_FIFO_ERROR triggered when link clock is changed.
>> >>
>> >> When video error occurs, video logic is reset and link training restart,
>> >> this will cause endless auto link training.
>> >>
>> >> Modify link auto training with disable INT_VID_FIFO_ERROR to avoid loop
>> >> and check INT_LINK_TRAIN_FAIL event to abort wait training done.
>> >>
>> >> Signed-off-by: Hermes Wu <Hermes.wu@ite.com.tw>
>> >> ---
>> >> drivers/gpu/drm/bridge/ite-it6505.c | 14 +++++++++++++-
>> >> 1 file changed, 13 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c
>> >> index 7f6227c278a51358c70a3de93454aafeef64f2bb..f9b99c70789eea6beb3c6513155c9a4ca103d219 100644
>> >> --- a/drivers/gpu/drm/bridge/ite-it6505.c
>> >> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
>> >> @@ -1806,6 +1806,13 @@ static bool it6505_link_start_auto_train(struct it6505 *it6505)
>> >> struct device *dev = it6505->dev;
>> >>
>> >> mutex_lock(&it6505->aux_lock);
>> >> +
>> >> + /* Disable FIFO error interrupt trigger */
>> >> + /* to prevent training fail loop issue */
>> >> + it6505_set_bits(it6505, INT_MASK_03, BIT(INT_VID_FIFO_ERROR), 0);
>> >> +
>> >> + it6505_write(it6505, INT_STATUS_03,
>> >> + BIT(INT_LINK_TRAIN_FAIL) | BIT(INT_VID_FIFO_ERROR));
>> >> it6505_set_bits(it6505, REG_TRAIN_CTRL0,
>> >> FORCE_CR_DONE | FORCE_EQ_DONE, 0x00);
>> >> /* reset link state machine and re start training*/
>> >> @@ -1818,8 +1825,10 @@ static bool it6505_link_start_auto_train(struct it6505 *it6505)
>> >> link_training_state = it6505_read(it6505, REG_LINK_TRAIN_STS);
>> >> int03 = it6505_read(it6505, INT_STATUS_03);
>> >> if (int03 & BIT(INT_LINK_TRAIN_FAIL)) {
>> >> + /* Ignore INT_VID_FIFO_ERROR when auto training fail*/
>> >> it6505_write(it6505, INT_STATUS_03,
>> >> - BIT(INT_LINK_TRAIN_FAIL));
>> >> + BIT(INT_LINK_TRAIN_FAIL) |
>> >> + BIT(INT_VID_FIFO_ERROR));
>> >
>> >I'm really unusure about this change. Judging by the description of the
>> >problem, it's fix for the issue, but the issue gets introduced in the
>> >previous patch.
>> In this patch serious?
>>
>> This patch serious fix this FIFO error issue, it change link training algorithm first then fix wrong FIFO error status.
>>
>> The link training process start after video status is stable, and when video FIFO error occurs,
>> video stable status will also lost, link training will reset to idle and wait until video stable again.
>>
>> IT6505 HW auto training will process link training automatically, which include CR/EQ DPCD setting, link status check,
>> and try lower link rate is the 2.7G cannot pass training.
>>
>> In some case, DP connect to a DP sink device which cannot pass IT6505 HW auto training.
>> when link auto training fail on 2.7G and IT6505 HW change link rate to 1.65G and retry training automatically,
>> at this time video FIFO error will occur because of the link rate change(chip issue), the video signal from SOC is not lost actually.
>
>We seems to be misunderstanding each other. I pointed out that your are
>fixing the code that was introduced in the previous patch. Would it make
>more sense to reoder or to squash the patches?
this patch can squash to previous one. they are part of auto link training fail check.
I will update in next patch serious
>>
>> >>
>> >> DRM_DEV_DEBUG_DRIVER(dev,
>> >> "INT_LINK_TRAIN_FAIL(%x)!",
>> >> @@ -1837,6 +1846,9 @@ static bool it6505_link_start_auto_train(struct it6505 *it6505)
>> >> timeout--;
>> >> }
>> >> unlock:
>> >> + /* recover interrupt trigger*/
>> >> + it6505_set_bits(it6505, INT_MASK_03,
>> >> + BIT(INT_VID_FIFO_ERROR), BIT(INT_VID_FIFO_ERROR));
>> >> mutex_unlock(&it6505->aux_lock);
>> >>
>> >> return state;
>> >>
>> >> --
>> >> 2.34.1
>> >>
>> >>
>> >
>> >--
>> >With best wishes
>> >Dmitry
>> >
>> BR.
>> Hermes Wu
>
>--
>With best wishes
>Dmitry
>
next prev parent reply other threads:[~2025-09-18 2:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 4:47 [PATCH RESEND v3 0/5] drm/bridge: it6505: fix DP link traning and improve compatibility Hermes Wu via B4 Relay
2025-09-16 4:47 ` [PATCH RESEND v3 1/5] drm/bridge: it6505: fix link training state HW register reset Hermes Wu via B4 Relay
2025-09-16 10:40 ` Dmitry Baryshkov
2025-09-16 4:47 ` [PATCH RESEND v3 2/5] drm/bridge: it6505: check INT_LINK_TRAIN_FAIL while link auto training Hermes Wu via B4 Relay
2025-09-16 10:41 ` Dmitry Baryshkov
2025-09-16 4:47 ` [PATCH RESEND v3 3/5] drm/bridge: it6505: modify DP " Hermes Wu via B4 Relay
2025-09-16 10:48 ` Dmitry Baryshkov
2025-09-17 8:37 ` Hermes.Wu
2025-09-17 13:47 ` Dmitry Baryshkov
2025-09-18 2:23 ` Hermes.Wu [this message]
2025-09-16 4:47 ` [PATCH RESEND v3 4/5] drm/bridge: it6505: modify DP link training work Hermes Wu via B4 Relay
2025-09-16 10:44 ` Dmitry Baryshkov
2025-09-16 4:47 ` [PATCH RESEND v3 5/5] drm/bridge: it6505: skip auto training when previous try fail Hermes Wu via B4 Relay
2025-09-16 10:47 ` Dmitry Baryshkov
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=e25dfcb49f5949ab9952c46a2984bbf5@ite.com.tw \
--to=hermes.wu@ite.com.tw \
--cc=Kenneth.Hung@ite.com.tw \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=Pet.Weng@ite.com.tw \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=simona@ffwll.ch \
--cc=treapking@chromium.org \
--cc=tzimmermann@suse.de \
/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