From: "Murthy, Arun R" <arun.r.murthy@intel.com>
To: <imre.deak@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH RFC 0/4] DP: Read LTTPR caps followed by DPRX caps
Date: Fri, 6 Mar 2026 09:59:25 +0530 [thread overview]
Message-ID: <51779f46-e806-4a82-84a7-82b2a166402c@intel.com> (raw)
In-Reply-To: <aamrRxXwBxzt6s4F@ideak-desk.lan>
On 05-03-2026 21:41, Imre Deak wrote:
> On Thu, Mar 05, 2026 at 01:48:10PM +0530, Arun R Murthy wrote:
>> As per the spec DP2.1 section 3.6.8.6.1, section 2.12.1,
>> section 2.12.3 (Link Policy) the LTTPR caps is to be read first
>> followed by the DPRX capability.
> Not exactly. The Standard requires reading the DPRX capabilities after
> the LTTPR caps are read.
I also mean the same, sorry if my wordings were complex.
> The driver does read the DPRX caps after
> reading the LTTPR caps.
In intel_dp_link_training.c function intel_dp_init_lttpr_and_dprx_caps()
int err = intel_dp_read_dprx_caps()
if (err != 0)
return err;
lttpr_count = intel_dp_init_lttpr()
Here we are reading dprx caps and then passing this dprx caps to the the
func intel_dp_init_lttpr(). I think this will be a deviation of the spec.
> The DP Standard does not mandate that the first
> read after a sink is connected (i.e. after the HPD signal of the sink is
> asserted) must be an LTTPR capability read and cannot be any other DPCD
> register read. In fact this would be impossible to guarantee, a DPRX
> capability read - or any DPCD register read for that matter - could
> happen at any point and so it could happen right after the HPD signal
> got asserted.
Spec DP2.1 Section 3.6.8.6.1 LTTPR Recognition
After HPD is propagated from the DPRX to the DPTX, a DP Source device
with a DPTX shall
read specific registers within the DPCD LTTPR Capability and ID Field
(DPCD F0000h through
F0009h; see Section 3.6.5)
After LTTPR recognition, a DP Source device with a DPTX shall read the
DP Sink device with
a DPRX’s capability by reading the DisplayID or legacy EDID and the
DPRX’s Receiver
Capability field (DPCD 00000h through 000FFh; see Table 2-232).
>> Git log shows that initially drm dp helper exposed function to read
>> lttpr caps. Driver reads the lttpr caps and then the dprx caps.
>> For a particular issue
>> https://gitlab.freedesktop.org/drm/intel/-/issues/3415
>> as a workaround reading dprx caps was done first to know if the panel is
>> < DP1.4 and then read 1 block at a time for lttpr caps.
>>
>> This can be handled in a better way and two such ways is what I see.
>> 1. Read LTTPR caps followed by DPRX caps as per the spec. Then on
>> reading dprx caps if revision < 1.4 then re-read the lttpr caps one
>> block at a time.
>>
>> 2. Read LTTPR caps and if 8b/10b check for correctness of the link rate
>> supported(lttpr caps 0xf0001), if some corrupted value is read then read
>> one block at a time.
> The driver does read the DPRX capabilities after reading the LTTPR
> capabilities. This is what the standard mandates.
Yes but before reading the LTTPR capabilities also DPRX capabilities is
read. Have added ref to the code snipped above.
Please let me know if my understanding is wrong.
>
> The workaround for issues/3415 depends on the DPCD_REV value, so this is
> read separately before reading the LTTPR caps. I don't see a better way
> to implement the workaround and such read is not prohibited by the DP
> Standard either. So I don't see the point of the changes in this
> patchset.
As Jani commented this can be added as a quirk for that particular panel
instead of mandating this kind of reading dprx caps first and then
reading the lttpr caps for all the monitors.
Thanks and Regards,
Arun R Murthy
-------------------
>
>> I am open for either of the two or you have any other options as well I
>> am open.
>>
>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>> ---
>> Arun R Murthy (4):
>> drm/display/dp: Read LTTPR caps without DPRX caps
>> drm/i915/dp: Read LTTPR caps followed by DPRX caps
>> drm/i915/dp: On HPD read LTTPR caps followed by DPRX caps
>> drm/i915/dp: DPRX/LTTPR caps for DP should be read once
>>
>> drivers/gpu/drm/display/drm_dp_helper.c | 63 ++++++++++++++++++++++
>> drivers/gpu/drm/i915/display/intel_dp.c | 3 +-
>> .../gpu/drm/i915/display/intel_dp_link_training.c | 40 +++++++-------
>> .../gpu/drm/i915/display/intel_dp_link_training.h | 1 -
>> drivers/gpu/drm/i915/display/intel_dp_tunnel.c | 3 +-
>> include/drm/display/drm_dp_helper.h | 2 +
>> 6 files changed, 86 insertions(+), 26 deletions(-)
>> ---
>> base-commit: cfc20c776480fda8c1b0517b187bb71ec0781cd4
>> change-id: 20260305-dp_aux-1e27599e06c8
>>
>> Best regards,
>> --
>> Arun R Murthy <arun.r.murthy@intel.com>
>>
next prev parent reply other threads:[~2026-03-06 4:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 8:18 [PATCH RFC 0/4] DP: Read LTTPR caps followed by DPRX caps Arun R Murthy
2026-03-05 8:18 ` [PATCH RFC 1/4] drm/display/dp: Read LTTPR caps without " Arun R Murthy
2026-03-05 9:18 ` Jani Nikula
2026-03-06 4:08 ` Murthy, Arun R
2026-03-05 16:29 ` Imre Deak
2026-03-06 4:10 ` Murthy, Arun R
2026-03-05 8:18 ` [PATCH RFC 2/4] drm/i915/dp: Read LTTPR caps followed by " Arun R Murthy
2026-03-05 8:18 ` [PATCH RFC 3/4] drm/i915/dp: On HPD read " Arun R Murthy
2026-03-05 8:18 ` [PATCH RFC 4/4] drm/i915/dp: DPRX/LTTPR caps for DP should be read once Arun R Murthy
2026-03-05 16:11 ` [PATCH RFC 0/4] DP: Read LTTPR caps followed by DPRX caps Imre Deak
2026-03-06 4:29 ` Murthy, Arun R
2026-03-06 9:46 ` Imre Deak
2026-03-10 8:58 ` Murthy, Arun R
2026-03-06 4:29 ` Murthy, Arun R [this message]
2026-03-06 3:42 ` ✗ CI.checkpatch: warning for " Patchwork
2026-03-06 3:44 ` ✓ CI.KUnit: success " Patchwork
2026-03-06 4:33 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-03-07 1:55 ` ✗ Xe.CI.FULL: " Patchwork
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=51779f46-e806-4a82-84a7-82b2a166402c@intel.com \
--to=arun.r.murthy@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=ville.syrjala@linux.intel.com \
/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