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_xiang...@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
