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

[Johan Hovold]

On Mon, Apr 28, 2025 at 11:06:39AM +0200, Aleksandrs Vinarskis wrote:
> On Mon, 28 Apr 2025 at 09:45, Johan Hovold <johan at 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.

Right, I'm concerned about breaking working setups for users of machines
like the X13s.

> - 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.

Abel (or anyone else), do you have one of these docks that you could
test with the X13s to confirm whether this series fixes a regression or
not?

> > 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).

Indeed. If LTTPR support broke existing setups, then I think all should
be marked with a Fixes tag and merged for 6.15. If we can't get it into
6.15 we may consider just disabling LTTPR support in 6.15 to address the
regression and then enable it again once fixed in 6.16.

But if this series is just enabling support for docks (and USB-C ports)
that did not used to work, then I guess this can all wait for 6.16.

Johan