| Message ID | 20250311234109.136510-1-alex.vinarskis@gmail.com |
|---|---|
| Headers | show |
| Series | drm/msm/dp: Introduce link training per-segment for LTTPRs | expand |
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 > 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. > 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
> -----Original Message----- > From: Aleksandrs Vinarskis <alex.vinarskis@gmail.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@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://urldefense.com/v3/__https://lore.kernel.org/all/20250226231436.161 > 38-2- > alex.vinarskis@gmail.com/__;!!LpKI!hlok7KSBKQntrFMYAFr0mFGIjXmlwtqOD > mQuO_6YwQ1pNJWCY9KqVJjzRZFzLv9fDgYOinq0MkYpccsMJFtXiQWvlNs2$ [lo > re[.]kernel[.]org] > > Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Tested-by: Laurentiu Tudor <Laurentiu.Tudor1@dell.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@gmail.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
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
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(-)