Re: [PATCH RFC 0/4] DP: Read LTTPR caps followed by DPRX caps

["Murthy, Arun R" <arun.r.murthy@intel.com>]

I understand that with race conditions from user get_connector it still 
cannot guarantee that lttpr caps are read first, dropping this patch for 
now!

Thanks and Regards,
Arun R Murthy
-------------------

On 06-03-2026 15:16, Imre Deak wrote:
> 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 <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>
>>>>