On Mon, 28 Apr 2025 at 16:17, Abel Vesa <abel.v...@linaro.org> wrote: > > On 25-04-28 14:47:04, Johan Hovold wrote: > > On Mon, Apr 28, 2025 at 11:06:39AM +0200, Aleksandrs Vinarskis wrote: > > > On Mon, 28 Apr 2025 at 09:45, Johan Hovold <jo...@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? > > Before the support for LTTPRs has been merged, if you would have one of > those docks (I do not own one) with LTTPRs, link training would've just > failed if the LTTPRs were not by default in transparent mode, which IIRC > is what the standard dictates. > > X13s doesn't have LTTPRs on-board so when reading the caps, LTTPRs count > would return 0 and none of the of the transparent/non-transparent setup > would happen. Now, as already mentioned, DP would be considered already > broken (or rather not supported) if you would connect a dock with LTTPRs in > it. > > With the support in, if one such dock is used, the training should be > successful as all LTTPRs are set in transparent mode. This I was not > able to test myself as I do not own such a dock. > > > > > > > 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. > > The LTTPR support did not break existing (working) setups because on these > setups, LTTPR count would read 0 and would be basically a no-op. > > > > > 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. > > I'm not sure about what this actually fixes. It might be that is > specific to a dock or something. But as far as X Elite boards go, even > without this "fix" display has been working fine. > > The change itself makes sense though and I think makes sense to be marked as > a fix.
Just to confirm, you mean to mark as fix only the 1st patch, correct? Since it's obvious now that the currently present partial LTTPR support did not break anything that used to work. Thanks, Alex > > > > > Johan > > Abel
