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 <[email protected]>
---
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 <[email protected]>
