From: Abel Vesa <abel.vesa@linaro.org>
To: Johan Hovold <johan@kernel.org>
Cc: Aleksandrs Vinarskis <alex.vinarskis@gmail.com>,
Dmitry Baryshkov <lumag@kernel.org>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dmitry.baryshkov@oss.qualcomm.com,
Rob Clark <robdclark@gmail.com>,
Abhinav Kumar <quic_abhinavk@quicinc.com>,
Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
laurentiu.tudor1@dell.com
Subject: Re: drm/msm/dp: Introduce link training per-segment for LTTPRs
Date: Tue, 29 Apr 2025 10:50:55 +0300 [thread overview]
Message-ID: <aBCE3wSG2g5pp7jg@linaro.org> (raw)
In-Reply-To: <aBB-gl150GVaZPn5@hovoldconsulting.com>
On 25-04-29 09:23:46, Johan Hovold wrote:
> On Mon, Apr 28, 2025 at 05:17:21PM +0300, Abel Vesa 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 <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?
>
> > > > 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.
>
> Ok, but my concern is if they may have worked in a default transparent
> mode.
But if they are by default in transparent mode, doing the setup to
transparent mode will not break it in any way. At least that is my
understanding of the standard. Also, I tested multiple writes to
transparent mode on CRD back when I wrote the LTTPR msm/dp patches and
doing multiple writes doesn't affect the link training that happens
after in any way.
I do not own such dock though to confirm 100%.
>
> > 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.
>
> But this is the crux; does any off-board LTTPRs in transparent mode add
> to the count or not? If they don't, how would you ever learn that there
> are any LTTPRs? If they do, it seems we may have a problem here.
Count gets increased either way. It doesn't matter if they are in
transparent mode or not.
If they are in transparent mode by default, link training will succeed.
No matter how many times the transparent mode is requested.
>
> Johan
next prev parent reply other threads:[~2025-04-29 7:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 2:10 drm/msm/dp: Introduce link training per-segment for LTTPRs Aleksandrs Vinarskis
2025-04-17 2:10 ` [PATCH v3 1/4] drm/msm/dp: Fix support of LTTPR initialization Aleksandrs Vinarskis
2025-04-24 21:48 ` Dmitry Baryshkov
2025-04-17 2:10 ` [PATCH v3 2/4] drm/msm/dp: Account for LTTPRs capabilities Aleksandrs Vinarskis
2025-04-25 6:53 ` Abel Vesa
2025-04-25 9:20 ` Dmitry Baryshkov
2025-04-17 2:10 ` [PATCH v3 3/4] drm/msm/dp: Prepare for link training per-segment for LTTPRs Aleksandrs Vinarskis
2025-04-25 6:53 ` Abel Vesa
2025-04-25 19:05 ` Dmitry Baryshkov
2025-04-17 2:10 ` [PATCH v3 4/4] drm/msm/dp: Introduce " Aleksandrs Vinarskis
2025-04-25 19:07 ` Dmitry Baryshkov
2025-04-28 20:07 ` Rob Clark
2025-04-24 21:12 ` Rob Clark
2025-04-24 22:14 ` Dmitry Baryshkov
2025-04-28 7:45 ` Johan Hovold
2025-04-28 9:06 ` Aleksandrs Vinarskis
2025-04-28 12:47 ` Johan Hovold
2025-04-28 14:17 ` Abel Vesa
2025-04-28 18:23 ` Aleksandrs Vinarskis
2025-04-29 6:52 ` Abel Vesa
2025-04-29 7:29 ` Aleksandrs Vinarskis
2025-04-29 7:23 ` Johan Hovold
2025-04-29 7:50 ` Abel Vesa [this message]
2025-04-29 8:03 ` Johan Hovold
2025-04-29 10:57 ` Aleksandrs Vinarskis
2025-04-29 11:31 ` Johan Hovold
2025-04-29 13:07 ` Dmitry Baryshkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBCE3wSG2g5pp7jg@linaro.org \
--to=abel.vesa@linaro.org \
--cc=airlied@gmail.com \
--cc=alex.vinarskis@gmail.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=johan@kernel.org \
--cc=laurentiu.tudor1@dell.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).