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/20250226231436.16138-2-alex.vinarskis@xxxxxxxxx/ 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(-) -- 2.45.2
