From: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org
Cc: Rob Clark <robdclark@gmail.com>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
laurentiu.tudor1@dell.com, abel.vesa@linaro.org,
johan@kernel.org, Aleksandrs Vinarskis <alex.vinarskis@gmail.com>
Subject: [PATCH v2 0/2] drm/msm/dp: Introduce link training per-segment for LTTPRs
Date: Wed, 12 Mar 2025 00:38:02 +0100 [thread overview]
Message-ID: <20250311234109.136510-1-alex.vinarskis@gmail.com> (raw)
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@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.
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>
---
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://lore.kernel.org/all/20250310211039.29843-1-alex.vinarskis@gmail.com/
---
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
next reply other threads:[~2025-03-11 23:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 23:38 Aleksandrs Vinarskis [this message]
2025-03-11 23:38 ` [PATCH v2 1/2] drm/msm/dp: Fix support of LTTPR handling Aleksandrs Vinarskis
2025-04-01 0:35 ` Dmitry Baryshkov
2025-03-11 23:38 ` [PATCH v2 2/2] drm/msm/dp: Introduce link training per-segment for LTTPRs Aleksandrs Vinarskis
2025-04-01 0:55 ` Dmitry Baryshkov
2025-04-08 22:29 ` Aleksandrs Vinarskis
2025-04-10 1:48 ` Dmitry Baryshkov
2025-03-12 21:16 ` [PATCH v2 0/2] " Stefan Schmidt
2025-03-13 22:59 ` Aleksandrs Vinarskis
2025-03-13 16:34 ` Tudor, Laurentiu
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=20250311234109.136510-1-alex.vinarskis@gmail.com \
--to=alex.vinarskis@gmail.com \
--cc=abel.vesa@linaro.org \
--cc=airlied@gmail.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=johan@kernel.org \
--cc=laurentiu.tudor1@dell.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
/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