Re: drm/msm/dp: Introduce link training per-segment for LTTPRs

Aleksandrs Vinarskis
2025-04-28T09:06:52Z

On Mon, 28 Apr 2025 at 09:45, Johan Hovold <johan@kernel.org> wrote:
>
> On Thu, Apr 17, 2025 at 04:10:31AM +0200, Aleksandrs Vinarskis 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).
>
> Does this mean that the incomplete LTTPR support in 6.15-rc1 broke
> adapters or docks with retimers in transparent mode?

I am actually not 100% sure.
- If without LTTPR initialization, they default to transparent mode,
then yes, incomplete LTTPR support sets them to non-transparent
without per-segment training and breaks docks with retimers, while it
would've worked if LTTPR(s) would've been left in default transparent
mode. Note that in this case, X1E devices with ps883x are somehow an
exception, because without LTTPR initialization at all the training
always fails.
- If LTTPR has to be initialized either way, and explicitly set to
transparent mode if we do not want non-transparent, then no,
incomplete LTTPR support in 6.15-rcX did not explicitly break docks
with retimers, as those never worked in the first place. As per my
understanding, this is the case, unless something (firmware?) has
already placed LTTPR to transparent mode before the driver takes over
- then 1st case would be applicable.

Docks with retimers do not work in 6.15-rcX, but I am unable to verify
if it did work before, as I do not have a Qualcomm based device
without LTTPR on the baseboard.

> You describe at least one of this patches as a fix but I'm not seeing
> any Fixes tags or indication that these need to go into 6.15-rc to fix
> a regression.

You are right, I will add Fixes tag to the 1st patch to make it clear:
Fixes 72d0af4accd (drm/msm/dp: Add support for LTTPR handling)

Or should I mark the entire series with Fixes, so that the docking
stations with retimers can be fixed in 6.15 already? Landing only the
1st patch will fix inconsistency with DP spec, but will not fix
docking stations with retimers. I guess this comes down to whether
existing LTTPR (but not multiple LTTPRs) support is considered a bug
(and patches 2,3,4 are a fix) or lack of functionality (and patches
2,3,4 are a new feature).

>
> > Changes in v3:
> > - Split 1st patch into 3
> > - Simplified handling of max_lttpr_lanes/max_lttpr_rate
> > - Moved lttpr_common_caps to msm_dp_link (not msm_dp_panel, as LTTPRs
> > are link related, not panel related)
> > - Picked Stefan's T-b tag (last patch only, as 1st one is getting split)
> > - Droped Abel's R-b tags from 1st patch that got split due to high diff
> > - Fixed alignment issues, initialization of variables, debug prints
> > - Moved lttpr_count to avoid ugly pointer
> > - Link to v2: https://lore.kernel.org/all/20250311234109.136510-1-alex.vinarskis@gmail.com/
>
> I tested v2 due to the dependencies in msm-next and DP altmode still
> works on my X13s and T14s (while not using any docks):
>
> Tested-by: Johan Hovold <johan+linaro@kernel.org>

Thanks,

Alex

>
> > Aleksandrs Vinarskis (4):
> > drm/msm/dp: Fix support of LTTPR initialization
> > drm/msm/dp: Account for LTTPRs capabilities
> > drm/msm/dp: Prepare for link training per-segment for LTTPRs
> > drm/msm/dp: Introduce link training per-segment for LTTPRs
>
> Johan