Message-ID:
 <CY5PR19MB6147B4E21D67D2E2A1913E6FBAD32@CY5PR19MB6147.namprd19.prod.outlook.com>
Date: Thu, 13 Mar 2025 16:34:14 +0000
From: "Tudor, Laurentiu" <Laurentiu.Tudor1@...l.com>
To: Aleksandrs Vinarskis <alex.vinarskis@...il.com>,
        Dmitry Baryshkov
	<dmitry.baryshkov@...aro.org>,
        "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>,
        "freedreno@...ts.freedesktop.org"
	<freedreno@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: Rob Clark <robdclark@...il.com>,
        Abhinav Kumar
	<quic_abhinavk@...cinc.com>,
        Sean Paul <sean@...rly.run>,
        Marijn Suijten
	<marijn.suijten@...ainline.org>,
        David Airlie <airlied@...il.com>, Simona
 Vetter <simona@...ll.ch>,
        "abel.vesa@...aro.org" <abel.vesa@...aro.org>,
        "johan@...nel.org" <johan@...nel.org>
Subject: RE: [PATCH v2 0/2] drm/msm/dp: Introduce link training per-segment
 for LTTPRs



> -----Original Message-----
> From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
> Sent: Wednesday, March 12, 2025 1:38 AM
> Subject: [PATCH v2 0/2] drm/msm/dp: Introduce link training per-segment for
> LTTPRs
> 
> 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)
> 
> 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@...hz and 4k@...z 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.
> 
> Due to lack of access to the official DisplayPort specfication, changes were
> primarily inspired by/reverse engineered from Intel's i915 driver.
> 
> [1]
> https://urldefense.com/v3/__https://lore.kernel.org/all/20250226231436.161
> 38-2-
> alex.vinarskis@...il.com/__;!!LpKI!hlok7KSBKQntrFMYAFr0mFGIjXmlwtqOD
> mQuO_6YwQ1pNJWCY9KqVJjzRZFzLv9fDgYOinq0MkYpccsMJFtXiQWvlNs2$ [lo
> re[.]kernel[.]org]
> 
> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@...il.com>

Tested-by: Laurentiu Tudor <Laurentiu.Tudor1@...l.com>

---
Thanks & Best Regards, Laurentiu

> ---
> 
> Changes in v2:
> - Picked up Abel's R-b tags
> - Fixed typo as per Abel, fixed readability as per Johan
> - Updated cover and commit message on mailink issue which appears to be
>   specific to Gnome+Wayland. No problems on Xorg.
> - Link to v1:
> https://urldefense.com/v3/__https://lore.kernel.org/all/20250310211039.298
> 43-1-
> alex.vinarskis@...il.com/__;!!LpKI!hlok7KSBKQntrFMYAFr0mFGIjXmlwtqOD
> mQuO_6YwQ1pNJWCY9KqVJjzRZFzLv9fDgYOinq0MkYpccsMJFtXiW5uR0d1$ [l
> ore[.]kernel[.]org]
> 
> ---
> 
> Aleksandrs Vinarskis (2):
>   drm/msm/dp: Fix support of LTTPR handling
>   drm/msm/dp: Introduce link training per-segment for LTTPRs
> 
>  drivers/gpu/drm/msm/dp/dp_ctrl.c    | 137 +++++++++++++++++++---------
>  drivers/gpu/drm/msm/dp/dp_ctrl.h    |   2 +-
>  drivers/gpu/drm/msm/dp/dp_display.c |  31 +++++--
>  drivers/gpu/drm/msm/dp/dp_panel.c   |  30 ++++--
>  drivers/gpu/drm/msm/dp/dp_panel.h   |   2 +
>  5 files changed, 141 insertions(+), 61 deletions(-)
> 
> --
> 2.45.2

Powered by blists - more mailing lists