[v1,0/2] drm/msm/dp: Introduce link training per-segment for LTTPRs

Message

Aleksandrs Vinarskis March 10, 2025, 9:05 p.m. UTC

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 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 works when increasing
  bandwith (eg. change framerate from 60hz to 100hz), but in all other
  cases the setting again does not stick.

These appear to be mainlink initialization related, as in all cases LT
passes successfully.

Test matrix:
* Dell XPS 9345
	* Left USB Type-C, Right USB Type-C
	* Direct monitor connection, Dell WD19TB, Dell WD22TB4
	* Dell AW3423DWF, Samsung LS24A600, dual Samsung LS24A600 (one
	  monitor per USB Type-C connector)
* Dell XPS 9345
	* Left USB Type-C, Right USB Type-C
	* Direct monitor connection
	* Dell U2725QE (universal Thunderbolt/DP Alt mode, probes with
	  LTTPR when in DP Alt mode)

In both cases, "Thunderbot Support"/"USB4 PCIE Tunneling" was disabled
in UEFI to force universal Thunderbolt/DP Alt mode devices to work in
DP Alt mode.
In both cases laptops had HBR3 patches applied [1], resulting in
maximum successful link with 3440x1440@100hz and 4k@60hz respectively.
When using 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, mainlink parameters changing is not stable, but
  appears to be unrelated to this series, and works better than before.
* In a very particular combination of Dell XPS 9345 + Dell AW3423DWF at
  max resolution, right USB Type-C connector does not always work:
  following successful link training, mainlink is not starting. When
  switching monitor to PIP/PBP mode, the issue is gone. I am unable to
  reproduce this issue in any other combination of devices/modes, so
  perhaps its an edge case of either the monitor (Dell AW3423DWF) or
  the docking station (Dell WD19TB/WD22TB4) specifically.


Due to lack of access to official DisplayPort specfication, changes
were primarily inspired by/reverse engineered from Intel's i915 driver.

[1] https://lore.kernel.org/all/[e-mail]/

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    | 136 +++++++++++++++++++---------
 drivers/gpu/drm/msm/dp/dp_ctrl.h    |   2 +-
 drivers/gpu/drm/msm/dp/dp_display.c |  33 +++++--
 drivers/gpu/drm/msm/dp/dp_panel.c   |  30 ++++--
 drivers/gpu/drm/msm/dp/dp_panel.h   |   2 +
 5 files changed, 141 insertions(+), 62 deletions(-)