On Fri, Mar 06, 2026 at 09:59:10AM +0530, Murthy, Arun R wrote:
>
> 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.
No, it's not a deviation of the spec, because the spec does not forbid
reading the DPCD_REV or other DPCD registers before reading the LTTPR
capability registers and it cannot really forbid this as I explained.
What the spec requires is reading the DPRX capabilities after the LTTPR
capabilities were read out, which the driver does: after the above lines
there is also:
/*
* The DPTX shall read the DPRX caps after LTTPR detection, so re-read
* it here.
*/
if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd)) ...
> > 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).
The above does not prohibit reading non-LTTPR DPCD registers before
reading F0000h - F0009h, and it cannot forbid this as explained above.
> > > 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.
This is not forbidden by the specification.
> 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 pointed 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.
There is already a quirk in the driver - to read out the LTTPR
capabilities 1 byte at a time - and the quirk is applied based on the
DPCD_REV register value of the monitor.
> 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]>
> > >
