Add a mechanism to retry Link Training 2 by lowering the pattern level
when the link training #2 first attempt fails. This approach enhances
compatibility, particularly addressing issues caused by certain hub
configurations.
Signed-off-by: Xiangxu Yin <quic_xiangxuy@quicinc.com>
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 49c8ce9b2d0e57a613e50865be3fe98e814d425a..b1862294cb98c9f756b0108b7670cb42de37bae4 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1220,7 +1220,7 @@ static void msm_dp_ctrl_clear_training_pattern(struct msm_dp_ctrl_private *ctrl)
}
static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
- int *training_step)
+ int *training_step, bool downgrade)
{
int tries = 0, ret = 0;
u8 pattern;
@@ -1243,6 +1243,28 @@ static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
state_ctrl_bit = 2;
}
+ /*
+ * DP link training uses the highest allowed pattern by default.
+ * If it fails, the pattern is downgraded to improve cable and monitor compatibility.
+ */
+ if (downgrade) {
+ switch (pattern) {
+ case DP_TRAINING_PATTERN_4:
+ pattern = DP_TRAINING_PATTERN_3;
+ state_ctrl_bit = 3;
+ break;
+ case DP_TRAINING_PATTERN_3:
+ pattern = DP_TRAINING_PATTERN_2;
+ state_ctrl_bit = 2;
+ break;
+ default:
+ break;
+ }
+ }
+
+ drm_dbg_dp(ctrl->drm_dev, "pattern(%d) state_ctrl_bit(%d) downgrade(%d)\n",
+ pattern, state_ctrl_bit, downgrade);
+
ret = msm_dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
if (ret)
return ret;
@@ -1311,10 +1333,14 @@ static int msm_dp_ctrl_link_train(struct msm_dp_ctrl_private *ctrl,
/* print success info as this is a result of user initiated action */
drm_dbg_dp(ctrl->drm_dev, "link training #1 successful\n");
- ret = msm_dp_ctrl_link_train_2(ctrl, training_step);
+ ret = msm_dp_ctrl_link_train_2(ctrl, training_step, false);
if (ret) {
- DRM_ERROR("link training #2 failed. ret=%d\n", ret);
- goto end;
+ drm_dbg_dp(ctrl->drm_dev, "link training #2 failed, retry downgrade.\n");
+ ret = msm_dp_ctrl_link_train_2(ctrl, training_step, true);
+ if (ret) {
+ DRM_ERROR("link training #2 failed. ret=%d\n", ret);
+ goto end;
+ }
}
/* print success info as this is a result of user initiated action */
--
2.25.1On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@quicinc.com> wrote:
>
> Add a mechanism to retry Link Training 2 by lowering the pattern level
> when the link training #2 first attempt fails. This approach enhances
> compatibility, particularly addressing issues caused by certain hub
> configurations.
Please reference corresponding part of the standard, describing this lowering.
>
> Signed-off-by: Xiangxu Yin <quic_xiangxuy@quicinc.com>
> ---
> drivers/gpu/drm/msm/dp/dp_ctrl.c | 34 ++++++++++++++++++++++++++++++----
> 1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 49c8ce9b2d0e57a613e50865be3fe98e814d425a..b1862294cb98c9f756b0108b7670cb42de37bae4 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1220,7 +1220,7 @@ static void msm_dp_ctrl_clear_training_pattern(struct msm_dp_ctrl_private *ctrl)
> }
>
> static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
> - int *training_step)
> + int *training_step, bool downgrade)
> {
> int tries = 0, ret = 0;
> u8 pattern;
> @@ -1243,6 +1243,28 @@ static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
> state_ctrl_bit = 2;
> }
>
> + /*
> + * DP link training uses the highest allowed pattern by default.
> + * If it fails, the pattern is downgraded to improve cable and monitor compatibility.
> + */
> + if (downgrade) {
> + switch (pattern) {
> + case DP_TRAINING_PATTERN_4:
> + pattern = DP_TRAINING_PATTERN_3;
> + state_ctrl_bit = 3;
> + break;
> + case DP_TRAINING_PATTERN_3:
> + pattern = DP_TRAINING_PATTERN_2;
> + state_ctrl_bit = 2;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + drm_dbg_dp(ctrl->drm_dev, "pattern(%d) state_ctrl_bit(%d) downgrade(%d)\n",
> + pattern, state_ctrl_bit, downgrade);
> +
> ret = msm_dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
> if (ret)
> return ret;
> @@ -1311,10 +1333,14 @@ static int msm_dp_ctrl_link_train(struct msm_dp_ctrl_private *ctrl,
> /* print success info as this is a result of user initiated action */
> drm_dbg_dp(ctrl->drm_dev, "link training #1 successful\n");
>
> - ret = msm_dp_ctrl_link_train_2(ctrl, training_step);
> + ret = msm_dp_ctrl_link_train_2(ctrl, training_step, false);
> if (ret) {
> - DRM_ERROR("link training #2 failed. ret=%d\n", ret);
> - goto end;
> + drm_dbg_dp(ctrl->drm_dev, "link training #2 failed, retry downgrade.\n");
> + ret = msm_dp_ctrl_link_train_2(ctrl, training_step, true);
> + if (ret) {
> + DRM_ERROR("link training #2 failed. ret=%d\n", ret);
> + goto end;
> + }
> }
>
> /* print success info as this is a result of user initiated action */
>
> --
> 2.25.1
>
--
With best wishes
Dmitry
On 11/29/2024 9:53 PM, Dmitry Baryshkov wrote:
> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@quicinc.com> wrote:
>>
>> Add a mechanism to retry Link Training 2 by lowering the pattern level
>> when the link training #2 first attempt fails. This approach enhances
>> compatibility, particularly addressing issues caused by certain hub
>> configurations.
>
> Please reference corresponding part of the standard, describing this lowering.
>
Per DisplayPort 1.4a specification Section 3.5.1.2 and Table 3-10, while the standard doesn't explicitly define a TPS downgrade mechanism, it does specify:
- All devices shall support TPS1 and TPS2
- HDR2-capable devices shall support TPS3
- HDR3-capable devices shall support TPS4
While these capabilities are explicitly defined DPCD for sink devices, source device capabilities are less strictly defined, with the minimum requirement being support for TPS1 and TPS2.
In QCS615 DP phy is only supporting to HBR2, we observed a critical interoperability scenario with a DP->HDMI bridge. When link training at TPS4 consistently failed, downgrading to the next lower training pattern successfully established the link and display output successfully.
This experience suggests that implementing a flexible link training pattern downgrade mechanism can significantly improve compatibility with third-party, non-standard hubs and displays,
especially in scenarios where strict adherence to the highest training pattern might prevent successful connection.
>>
>> Signed-off-by: Xiangxu Yin <quic_xiangxuy@quicinc.com>
>> ---
>> drivers/gpu/drm/msm/dp/dp_ctrl.c | 34 ++++++++++++++++++++++++++++++----
>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> index 49c8ce9b2d0e57a613e50865be3fe98e814d425a..b1862294cb98c9f756b0108b7670cb42de37bae4 100644
>> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
>> @@ -1220,7 +1220,7 @@ static void msm_dp_ctrl_clear_training_pattern(struct msm_dp_ctrl_private *ctrl)
>> }
>>
>> static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
>> - int *training_step)
>> + int *training_step, bool downgrade)
>> {
>> int tries = 0, ret = 0;
>> u8 pattern;
>> @@ -1243,6 +1243,28 @@ static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
>> state_ctrl_bit = 2;
>> }
>>
>> + /*
>> + * DP link training uses the highest allowed pattern by default.
>> + * If it fails, the pattern is downgraded to improve cable and monitor compatibility.
>> + */
>> + if (downgrade) {
>> + switch (pattern) {
>> + case DP_TRAINING_PATTERN_4:
>> + pattern = DP_TRAINING_PATTERN_3;
>> + state_ctrl_bit = 3;
>> + break;
>> + case DP_TRAINING_PATTERN_3:
>> + pattern = DP_TRAINING_PATTERN_2;
>> + state_ctrl_bit = 2;
>> + break;
>> + default:
>> + break;
>> + }
>> + }
>> +
>> + drm_dbg_dp(ctrl->drm_dev, "pattern(%d) state_ctrl_bit(%d) downgrade(%d)\n",
>> + pattern, state_ctrl_bit, downgrade);
>> +
>> ret = msm_dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
>> if (ret)
>> return ret;
>> @@ -1311,10 +1333,14 @@ static int msm_dp_ctrl_link_train(struct msm_dp_ctrl_private *ctrl,
>> /* print success info as this is a result of user initiated action */
>> drm_dbg_dp(ctrl->drm_dev, "link training #1 successful\n");
>>
>> - ret = msm_dp_ctrl_link_train_2(ctrl, training_step);
>> + ret = msm_dp_ctrl_link_train_2(ctrl, training_step, false);
>> if (ret) {
>> - DRM_ERROR("link training #2 failed. ret=%d\n", ret);
>> - goto end;
>> + drm_dbg_dp(ctrl->drm_dev, "link training #2 failed, retry downgrade.\n");
>> + ret = msm_dp_ctrl_link_train_2(ctrl, training_step, true);
>> + if (ret) {
>> + DRM_ERROR("link training #2 failed. ret=%d\n", ret);
>> + goto end;
>> + }
>> }
>>
>> /* print success info as this is a result of user initiated action */
>>
>> --
>> 2.25.1
>>
>
>
On Tue, Dec 03, 2024 at 04:13:22PM +0800, Xiangxu Yin wrote:
>
>
> On 11/29/2024 9:53 PM, Dmitry Baryshkov wrote:
> > On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@quicinc.com> wrote:
> >>
> >> Add a mechanism to retry Link Training 2 by lowering the pattern level
> >> when the link training #2 first attempt fails. This approach enhances
> >> compatibility, particularly addressing issues caused by certain hub
> >> configurations.
> >
> > Please reference corresponding part of the standard, describing this lowering.
> >
> Per DisplayPort 1.4a specification Section 3.5.1.2 and Table 3-10, while the standard doesn't explicitly define a TPS downgrade mechanism, it does specify:
Anything in DP 2.1?
> - All devices shall support TPS1 and TPS2
> - HDR2-capable devices shall support TPS3
> - HDR3-capable devices shall support TPS4
> While these capabilities are explicitly defined DPCD for sink devices, source device capabilities are less strictly defined, with the minimum requirement being support for TPS1 and TPS2.
> In QCS615 DP phy is only supporting to HBR2, we observed a critical interoperability scenario with a DP->HDMI bridge. When link training at TPS4 consistently failed, downgrading to the next lower training pattern successfully established the link and display output successfully.
Any other driver doing such TPS lowering? Or maybe we should be
selecting TPS3 for HBR2-only devices?
>
> This experience suggests that implementing a flexible link training pattern downgrade mechanism can significantly improve compatibility with third-party, non-standard hubs and displays,
> especially in scenarios where strict adherence to the highest training pattern might prevent successful connection.
> >>
> >> Signed-off-by: Xiangxu Yin <quic_xiangxuy@quicinc.com>
> >> ---
> >> drivers/gpu/drm/msm/dp/dp_ctrl.c | 34 ++++++++++++++++++++++++++++++----
> >> 1 file changed, 30 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> >> index 49c8ce9b2d0e57a613e50865be3fe98e814d425a..b1862294cb98c9f756b0108b7670cb42de37bae4 100644
> >> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> >> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> >> @@ -1220,7 +1220,7 @@ static void msm_dp_ctrl_clear_training_pattern(struct msm_dp_ctrl_private *ctrl)
> >> }
> >>
> >> static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
> >> - int *training_step)
> >> + int *training_step, bool downgrade)
> >> {
> >> int tries = 0, ret = 0;
> >> u8 pattern;
> >> @@ -1243,6 +1243,28 @@ static int msm_dp_ctrl_link_train_2(struct msm_dp_ctrl_private *ctrl,
> >> state_ctrl_bit = 2;
> >> }
> >>
> >> + /*
> >> + * DP link training uses the highest allowed pattern by default.
> >> + * If it fails, the pattern is downgraded to improve cable and monitor compatibility.
> >> + */
> >> + if (downgrade) {
> >> + switch (pattern) {
> >> + case DP_TRAINING_PATTERN_4:
> >> + pattern = DP_TRAINING_PATTERN_3;
> >> + state_ctrl_bit = 3;
> >> + break;
> >> + case DP_TRAINING_PATTERN_3:
> >> + pattern = DP_TRAINING_PATTERN_2;
> >> + state_ctrl_bit = 2;
> >> + break;
> >> + default:
> >> + break;
> >> + }
> >> + }
> >> +
> >> + drm_dbg_dp(ctrl->drm_dev, "pattern(%d) state_ctrl_bit(%d) downgrade(%d)\n",
> >> + pattern, state_ctrl_bit, downgrade);
> >> +
> >> ret = msm_dp_catalog_ctrl_set_pattern_state_bit(ctrl->catalog, state_ctrl_bit);
> >> if (ret)
> >> return ret;
> >> @@ -1311,10 +1333,14 @@ static int msm_dp_ctrl_link_train(struct msm_dp_ctrl_private *ctrl,
> >> /* print success info as this is a result of user initiated action */
> >> drm_dbg_dp(ctrl->drm_dev, "link training #1 successful\n");
> >>
> >> - ret = msm_dp_ctrl_link_train_2(ctrl, training_step);
> >> + ret = msm_dp_ctrl_link_train_2(ctrl, training_step, false);
> >> if (ret) {
> >> - DRM_ERROR("link training #2 failed. ret=%d\n", ret);
> >> - goto end;
> >> + drm_dbg_dp(ctrl->drm_dev, "link training #2 failed, retry downgrade.\n");
> >> + ret = msm_dp_ctrl_link_train_2(ctrl, training_step, true);
> >> + if (ret) {
> >> + DRM_ERROR("link training #2 failed. ret=%d\n", ret);
> >> + goto end;
> >> + }
> >> }
> >>
> >> /* print success info as this is a result of user initiated action */
> >>
> >> --
> >> 2.25.1
> >>
> >
> >
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
With best wishes
Dmitry
On 12/3/24 3:07 PM, Dmitry Baryshkov wrote: > On Tue, Dec 03, 2024 at 04:13:22PM +0800, Xiangxu Yin wrote: >> >> >> On 11/29/2024 9:53 PM, Dmitry Baryshkov wrote: >>> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@quicinc.com> wrote: >>>> >>>> Add a mechanism to retry Link Training 2 by lowering the pattern level >>>> when the link training #2 first attempt fails. This approach enhances >>>> compatibility, particularly addressing issues caused by certain hub >>>> configurations. >>> >>> Please reference corresponding part of the standard, describing this lowering. >>> >> Per DisplayPort 1.4a specification Section 3.5.1.2 and Table 3-10, while the standard doesn't explicitly define a TPS downgrade mechanism, it does specify: > > Anything in DP 2.1? > >> - All devices shall support TPS1 and TPS2 >> - HDR2-capable devices shall support TPS3 >> - HDR3-capable devices shall support TPS4 >> While these capabilities are explicitly defined DPCD for sink devices, source device capabilities are less strictly defined, with the minimum requirement being support for TPS1 and TPS2. >> In QCS615 DP phy is only supporting to HBR2, we observed a critical interoperability scenario with a DP->HDMI bridge. When link training at TPS4 consistently failed, downgrading to the next lower training pattern successfully established the link and display output successfully. > > Any other driver doing such TPS lowering? Or maybe we should be > selecting TPS3 for HBR2-only devices? Bump, this patch looks interesting and I'd like to see it revisited if it's correct Konrad
On 5/28/2025 4:49 AM, Konrad Dybcio wrote: > On 12/3/24 3:07 PM, Dmitry Baryshkov wrote: >> On Tue, Dec 03, 2024 at 04:13:22PM +0800, Xiangxu Yin wrote: >>> >>> >>> On 11/29/2024 9:53 PM, Dmitry Baryshkov wrote: >>>> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@quicinc.com> wrote: >>>>> >>>>> Add a mechanism to retry Link Training 2 by lowering the pattern level >>>>> when the link training #2 first attempt fails. This approach enhances >>>>> compatibility, particularly addressing issues caused by certain hub >>>>> configurations. >>>> >>>> Please reference corresponding part of the standard, describing this lowering. >>>> >>> Per DisplayPort 1.4a specification Section 3.5.1.2 and Table 3-10, while the standard doesn't explicitly define a TPS downgrade mechanism, it does specify: >> >> Anything in DP 2.1? >> In the DP 2.1 spec, mainly on section '3.6.7.2 8b/10b DP Link Layer LTTPR Link Training Mandates', defined 'LTTPR shall support TPS4'. The other parts seems similar to the 1.4 spec. >>> - All devices shall support TPS1 and TPS2 >>> - HDR2-capable devices shall support TPS3 >>> - HDR3-capable devices shall support TPS4 >>> While these capabilities are explicitly defined DPCD for sink devices, source device capabilities are less strictly defined, with the minimum requirement being support for TPS1 and TPS2. >>> In QCS615 DP phy is only supporting to HBR2, we observed a critical interoperability scenario with a DP->HDMI bridge. When link training at TPS4 consistently failed, downgrading to the next lower training pattern successfully established the link and display output successfully. >> >> Any other driver doing such TPS lowering? Or maybe we should be >> selecting TPS3 for HBR2-only devices? > This logic is porting from qualcomm downstream, For other device, only found in some older Tx chips like i915（intel_dp_training_pattern) used the maximum hardware-supported patterns, but not lowering. According to the description in DPCD table 2-232 003h, From the DP spec perspective, it appears that all supported cases should preferably adopt TPS4, as it is more robust. 'DPRXs should support TPS4 and set this bit, regardless of whether the DPRX supports HBR3 because TPS4 is more conducive to robust link establishment than TPS2 and TPS3. 0 = TPS4 is not supported. 1 = TPS4 is supported (shall be supported for downstream devices with DPCD r1.4, except for eDPRXs).' Although maximum capability of QCS615 is HBR2, but the actual pattern supports TPS4. From pure design perspective, it would be cleaner to drop this lowering in next patch. > Bump, this patch looks interesting and I'd like to see it revisited if > it's correct > > Konrad
On Wed, Jul 09, 2025 at 05:16:02PM +0800, Xiangxu Yin wrote: > > > On 5/28/2025 4:49 AM, Konrad Dybcio wrote: > > On 12/3/24 3:07 PM, Dmitry Baryshkov wrote: > >> On Tue, Dec 03, 2024 at 04:13:22PM +0800, Xiangxu Yin wrote: > >>> > >>> > >>> On 11/29/2024 9:53 PM, Dmitry Baryshkov wrote: > >>>> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@quicinc.com> wrote: > >>>>> > >>>>> Add a mechanism to retry Link Training 2 by lowering the pattern level > >>>>> when the link training #2 first attempt fails. This approach enhances > >>>>> compatibility, particularly addressing issues caused by certain hub > >>>>> configurations. > >>>> > >>>> Please reference corresponding part of the standard, describing this lowering. > >>>> > >>> Per DisplayPort 1.4a specification Section 3.5.1.2 and Table 3-10, while the standard doesn't explicitly define a TPS downgrade mechanism, it does specify: > >> > >> Anything in DP 2.1? > >> > In the DP 2.1 spec, mainly on section '3.6.7.2 8b/10b DP Link Layer LTTPR Link Training Mandates', defined 'LTTPR shall support TPS4'. > The other parts seems similar to the 1.4 spec. > >>> - All devices shall support TPS1 and TPS2 > >>> - HDR2-capable devices shall support TPS3 > >>> - HDR3-capable devices shall support TPS4 > >>> While these capabilities are explicitly defined DPCD for sink devices, source device capabilities are less strictly defined, with the minimum requirement being support for TPS1 and TPS2. > >>> In QCS615 DP phy is only supporting to HBR2, we observed a critical interoperability scenario with a DP->HDMI bridge. When link training at TPS4 consistently failed, downgrading to the next lower training pattern successfully established the link and display output successfully. > >> > >> Any other driver doing such TPS lowering? Or maybe we should be > >> selecting TPS3 for HBR2-only devices? > > > This logic is porting from qualcomm downstream, Hopefully a downstream has some sensible commit message which describes the issue and the configuration to reproduce it? > For other device, only found in some older Tx chips like i915（intel_dp_training_pattern) used the maximum hardware-supported patterns, but not lowering. > > According to the description in DPCD table 2-232 003h, From the DP spec perspective, it appears that all supported cases should preferably adopt TPS4, as it is more robust. If other drivers don't perform this kind of lowering, I'd prefer if we don't perform it too. > 'DPRXs should support TPS4 and set this bit, regardless of whether the DPRX supports HBR3 because TPS4 is more conducive to robust link establishment than TPS2 and TPS3. > 0 = TPS4 is not supported. > 1 = TPS4 is supported (shall be supported for downstream devices with DPCD r1.4, except for eDPRXs).' > > Although maximum capability of QCS615 is HBR2, but the actual pattern supports TPS4. > From pure design perspective, it would be cleaner to drop this lowering in next patch. > > Bump, this patch looks interesting and I'd like to see it revisited if > > it's correct > > > > Konrad > > -- With best wishes Dmitry
On 7/19/2025 5:43 PM, Dmitry Baryshkov wrote: > On Wed, Jul 09, 2025 at 05:16:02PM +0800, Xiangxu Yin wrote: >> >> On 5/28/2025 4:49 AM, Konrad Dybcio wrote: >>> On 12/3/24 3:07 PM, Dmitry Baryshkov wrote: >>>> On Tue, Dec 03, 2024 at 04:13:22PM +0800, Xiangxu Yin wrote: >>>>> >>>>> On 11/29/2024 9:53 PM, Dmitry Baryshkov wrote: >>>>>> On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@quicinc.com> wrote: >>>>>>> Add a mechanism to retry Link Training 2 by lowering the pattern level >>>>>>> when the link training #2 first attempt fails. This approach enhances >>>>>>> compatibility, particularly addressing issues caused by certain hub >>>>>>> configurations. >>>>>> Please reference corresponding part of the standard, describing this lowering. >>>>>> >>>>> Per DisplayPort 1.4a specification Section 3.5.1.2 and Table 3-10, while the standard doesn't explicitly define a TPS downgrade mechanism, it does specify: >>>> Anything in DP 2.1? >>>> >> In the DP 2.1 spec, mainly on section '3.6.7.2 8b/10b DP Link Layer LTTPR Link Training Mandates', defined 'LTTPR shall support TPS4'. >> The other parts seems similar to the 1.4 spec. >>>>> - All devices shall support TPS1 and TPS2 >>>>> - HDR2-capable devices shall support TPS3 >>>>> - HDR3-capable devices shall support TPS4 >>>>> While these capabilities are explicitly defined DPCD for sink devices, source device capabilities are less strictly defined, with the minimum requirement being support for TPS1 and TPS2. >>>>> In QCS615 DP phy is only supporting to HBR2, we observed a critical interoperability scenario with a DP->HDMI bridge. When link training at TPS4 consistently failed, downgrading to the next lower training pattern successfully established the link and display output successfully. >>>> Any other driver doing such TPS lowering? Or maybe we should be >>>> selecting TPS3 for HBR2-only devices? >> This logic is porting from qualcomm downstream, > Hopefully a downstream has some sensible commit message which describes > the issue and the configuration to reproduce it? The downstream commit log shows in 2019/08, SM8250 (kernel 4.19) type-c DP meet LT2 failures on Samsung HDR curved monitor, the pattern lowering fix was adopted. On QCS615, an mDP-to-HDMI adapter cable exhibited similar LT failure pattern, and it's works with this solution. However, It's rare compatibility case with special device and lowering seems violates protocol standards, maybe not suitable for general deployment. >> For other device, only found in some older Tx chips like i915（intel_dp_training_pattern) used the maximum hardware-supported patterns, but not lowering. >> >> According to the description in DPCD table 2-232 003h, From the DP spec perspective, it appears that all supported cases should preferably adopt TPS4, as it is more robust. > If other drivers don't perform this kind of lowering, I'd prefer if we > don't perform it too. Agree, I'll remove this patch in an upcoming version soon. > >> 'DPRXs should support TPS4 and set this bit, regardless of whether the DPRX supports HBR3 because TPS4 is more conducive to robust link establishment than TPS2 and TPS3. >> 0 = TPS4 is not supported. >> 1 = TPS4 is supported (shall be supported for downstream devices with DPCD r1.4, except for eDPRXs).' >> >> Although maximum capability of QCS615 is HBR2, but the actual pattern supports TPS4. >> From pure design perspective, it would be cleaner to drop this lowering in next patch. >>> Bump, this patch looks interesting and I'd like to see it revisited if >>> it's correct >>> >>> Konrad >>
© 2016 - 2026 Red Hat, Inc.