Re: [PATCH v2 0/2] drm/msm/dp: Introduce link training per-segment for LTTPRs

[Aleksandrs Vinarskis <alex.vinarskis@gmail.com>]

On 3/12/25 22:16, Stefan Schmidt wrote:
> Hello Aleksandrs,
> 
> On Wed, 12 Mar 2025 at 00:41, Aleksandrs Vinarskis
> <alex.vinarskis@gmail.com> wrote:
>>
>> Recently added Initial LTTPR support in msm/dp has configured LTTPR(s)
>> to non-transparent mode to enable video output on X1E-based devices
>> that come with LTTPR on the motherboards. However, video would not work
>> if additional LTTPR(s) are present between sink and source, which is
>> the case for USB Type-C docks (eg. Dell WD19TB/WD22TB4), and at least
>> some universal Thunderbolt/USB Type-C monitors (eg. Dell U2725QE).
>>
>> First, take into account LTTPR capabilities when computing max link
>> rate, number of lanes. Take into account previous discussion on the
>> lists - exit early if reading DPCD caps failed. This also fixes
>> "*ERROR* panel edid read failed" on some monitors which seems to be
>> caused by msm_dp_panel_read_sink_caps running before LTTPR(s) are
>> initialized.
>>
>> Finally, implement link training per-segment. Pass lttpr_count to all
>> required helpers.
>> This seems to also partially improve UI (Wayland) hanging when
>> changing external display's link parameters (resolution, framerate):
>> * Prior to this series, via direct USB Type-C to display connection,
>>    attempt to change resolution or framerate hangs the UI, setting does
>>    not stick. Some back and forth replugging finally sets desired
>>    parameters.
>> * With this series, via direct USB Type-C to display connection,
>>    changing parameters works most of the time, without UI freezing. Via
>>    docking station/multiple LTTPRs the setting again does not stick.
>> * On Xorg changing link paramaters works in all combinations.
>>
>> These appear to be mainlink initialization related, as in all cases LT
>> passes successfully.
>>
>> Test matrix:
>> * Dell XPS 9345, Ubuntu 24.10, Gnome 47, Wayland
>>          * Left USB Type-C, Right USB Type-C
>>          * Direct monitor connection, Dell WD19TB, Dell WD22TB4, USB
>>            Type-C to HDMI dongle, USB Type-C to DP dongle
>>          * Dell AW3423DWF, Samsung LS24A600, dual Samsung LS24A600 (one
>>            monitor per USB Type-C connector)
>> * Dell XPS 9345, Ubuntu 24.10, Gnome 47, Wayland
>>          * Left USB Type-C, Right USB Type-C
>>          * Direct monitor connection
>>          * Samsung S34BG85 (USB Type-C), Dell U2725QE (universal
>>            Thunderbolt/USB Type-C, probes with an LTTPR when in USB
>>            Type-C/DP Alt mode)
> 
> You can  add the following:
> * Dell XPS 9345, Debian trixie/sid, Gnome 48, Wayland
>          * Left USB Type-C, Right USB Type-C
>          * Dell WD15 Dock with DisplayPort connected
>          * Dell HD22Q dock with HDMI connected
>          * USB Type-C to HDMI dongle
>          * Dell U3417W

Hi,

Thanks for testing, will add on next re-spin.

> 
>> In both cases, "Thunderbot Support"/"USB4 PCIE Tunneling" was disabled
>> in UEFI to force universal Thunderbolt/USB Type-C devices to work in
>> DP Alt mode.
>> In both cases laptops had HBR3 patches applied [1], resulting in
>> maximum successful link at 3440x1440@100hz and 4k@60hz respectively.
>> When using Dell WD22TB4/U2725QE, USB Type-C pin assigment D got enabled
>> and USB3.0 devices were working in parallel to video ouput.
>>
>> Known issues:
>> * As mentioned above, it appears that on Gnome+Wayland framerate and
>>    resolution parameter adjustment is not stable.
> 
> I can confirm this on Gnome 48 + Wayland as well. Sometimes the resolution
> change from gnome settings gets stuck and does not apply. It normally works
> here around every third try or so when using a dock.

Good to know that it isn't issue only on my side :)

Alex

> 
>> Due to lack of access to the official DisplayPort specfication, changes
>> were primarily inspired by/reverse engineered from Intel's i915 driver.
>>
>> [1] https://lore.kernel.org/all/20250226231436.16138-2-alex.vinarskis@gmail.com/
>>
>> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
> 
> Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org>
> 
> regards
> Stefan Schmidt