Re: [PATCH 14/23] drm/i915/dp: Add member to intel_dp to store AS SDP v2 support

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Apr 07, 2026 at 07:05:51PM +0530, Nautiyal, Ankit K wrote:
> 
> On 4/7/2026 1:50 PM, Nautiyal, Ankit K wrote:
> >
> > On 4/2/2026 6:20 PM, Ville Syrjälä wrote:
> >> On Thu, Apr 02, 2026 at 02:04:28PM +0300, Ville Syrjälä wrote:
> >>> On Thu, Apr 02, 2026 at 01:34:14PM +0530, Ankit Nautiyal wrote:
> >>>> DP v2.1 SCR advertises support for FAVT payload fields parsing in DPCD
> >>>> 0x2214 Bit 2. This indicates the support for Adaptive-Sync SDP 
> >>>> version 2
> >>>> (AS SDP v2), which allows the source to set the version in HB2[4:0] 
> >>>> and the
> >>>> payload length in HB3[5:0] of the AS SDP header.
> >>>>
> >>>> DP v2.1 SCR also introduces ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR 
> >>>> in the
> >>>> Panel Replay Capability DPCD 0x00b1 (Bit 3). When this bit is set, 
> >>>> the sink
> >>>> does not support asynchronous video timing while in a Panel Replay 
> >>>> Active
> >>>> state and the source is required to keep transmitting Adaptive-Sync
> >>>> SDPs. The spec mandates that such sinks shall support AS SDP v2.
> >>>>
> >>>> Infer AS SDP v2 support from these capabilities and store it in
> >>>> struct intel_dp for use by subsequent feature enablement changes.
> >>> Hmm. After some more reading I think we might actually want to consult
> >>> the DisplayID for this. The presence of the new adaptive sync block
> >>> there might be a good indication for AS SDP v2 support. While the
> >>> DisplayID 2.1 spec itself doesn't say that AS SDP v2 must be supported
> >>> when the block is present, the DP 2.1 spec does at least say the 
> >>> converse.
> >>> Ie. adaptive sync capable DP 2.1 sink must have the DisplayID block. 
> >>> And
> >>> DP 2.1 seems to be all about the AS SDP v2 and not AS SDP v1 (that's 
> >>> a DP
> >>> 2.0 thing really).
> >> Hmm. But the EDID comes from the display, and we could have a PCON
> >> in between that doesn't understand AS SDP v2. Sigh. What a mess.
> >
> >
> > hmm yeah. Is it alright to have a #TODO something like:
> >
> > /*
> > * TODO: Check the Adaptive-Sync DisplayID 2.1 block once DisplayID 
> > parsing
> > * is available. This may help detect AS SDP v2 support for native DP 2.1
> > * sinks that do not expose FAVT or PR-based capability bits.
> > *
> > * In the presence of PCONs, check PCON support from DPCD and sink 
> > support from Display ID.
> > */
> >
> 
> Going throught the eDP spec, it seems for eDP,  if AS SDP is supported 
> it implicitly means AS SDP v2.
> 
>  From eDP spec 2.0

eDP 2.0 does not seem relevant for us. But IIRC eDP v1.5 also implies
AS SDP v2 support. And that we can actually check if necessary.

Though I suppose the only real concern is branch devices. Maybe we
should use the FAVT check only for those. For everything else it
should be sufficient to have either the DisplayID adaptive sync 
block or PR ALPM support.

> 
> Section 2.8 Adaptive-Sync
> 
> "eDP may optionally support the Adaptive-Sync operation to maintain 
> video timing
> synchronization between Source and Sink devices (see DP Standard, 
> “Adaptive-Sync Operation
> for VESA AdaptiveSync”). If supported, the Adaptive-Sync SDP version 
> shall be v2 or higher
> (HB2[4:0] = 02h or higher, and HB3[5:0] = 09h or higher)."
> 
> Also, the FAVT Payload fields parsing support is not used for eDP and 
> will always read 0.
> 
> This however doesn't mean that FAVT is not supported, the support is 
> implicit.
> 
> Section 8.7.1 Video Timing Synchronization while in a PR Active State
> with ALPM Enabled
> 
> ...Source-to-Sink device timing synchronization during a PR Active state 
> that uses the Adaptive-Sync SDP may be enabled in
> Adaptive-Sync (FAVT or AVT mode) operation (DPCD 00107h[7] = 1) –or– when
> DPCD 00107h[7] = 0..
> 
> 
> So, I will update the logic for eDP here.
> 
> Regards,
> 
> Ankit
> 
> 
> 
> >
> > Regards,
> >
> > Ankit
> >
> >>> I think there was a patch posted very recently on dri-devel, adding the
> >>> adaptive sync DisplayID block parsing. Or at least some DisplayID block
> >>> related to this.
> >>>
> >>> The intel_psr_pr_async_video_timing_supported() check I think we want
> >>> to keep regardless, because you could have a sink with PR but no
> >>> adaptive sync. But the FAVT check could perhaps be dropped if we add
> >>> the DisplayID check.
> >>>
> >>>> v2: Include parsing ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR bit to
> >>>>      determine AS SDP v2 support. (Ville)
> >>>> v3: Use helper to determine asynch video timing support.
> >>>>
> >>>> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> >>>> ---
> >>>>   .../drm/i915/display/intel_display_types.h    |  1 +
> >>>>   drivers/gpu/drm/i915/display/intel_dp.c       | 33 
> >>>> +++++++++++++++++++
> >>>>   2 files changed, 34 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> >>>> b/drivers/gpu/drm/i915/display/intel_display_types.h
> >>>> index e2496db1642a..efc609eef4f5 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> >>>> @@ -1870,6 +1870,7 @@ struct intel_dp {
> >>>>       /* connector directly attached - won't be use for modeset in 
> >>>> mst world */
> >>>>       struct intel_connector *attached_connector;
> >>>>       bool as_sdp_supported;
> >>>> +    bool as_sdp_v2_supported;
> >>>>         struct drm_dp_tunnel *tunnel;
> >>>>       bool tunnel_suspended:1;
> >>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> >>>> b/drivers/gpu/drm/i915/display/intel_dp.c
> >>>> index cec0f3d03c2f..9fd768447f28 100644
> >>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >>>> @@ -6306,6 +6306,36 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> >>>>                              false);
> >>>>   }
> >>>>   +static bool
> >>>> +intel_dp_sink_supports_as_sdp_v2(struct intel_dp *intel_dp)
> >>>> +{
> >>>> +    u8 rx_features;
> >>>> +
> >>>> +    /*
> >>>> +     * The DP spec does not explicitly provide the AS SDP v2 
> >>>> capability.
> >>>> +     * So based on the DP v2.1 SCR, we infer it from the following 
> >>>> bits:
> >>>> +     *
> >>>> +     * DP_AS_SDP_FAVT_PAYLOAD_FIELDS_PARSING_SUPPORTED indicates 
> >>>> support for
> >>>> +     * FAVT, which is explicitly defined to use AS SDP v2.
> >>>> +     *
> >>>> +     * DP_ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR indicates that 
> >>>> the sink
> >>>> +     * does not support asynchronous video timing while in PR Active,
> >>>> +     * requiring the source to keep transmitting Adaptive-Sync 
> >>>> SDPs. The
> >>>> +     * spec mandates that such sinks shall support AS SDP v2.
> >>>> +     */
> >>>> +    if (drm_dp_dpcd_read_byte(&intel_dp->aux,
> >>>> +                  DP_DPRX_FEATURE_ENUMERATION_LIST_CONT_1,
> >>>> +                  &rx_features) == 1) {
> >>>> +        if (rx_features & 
> >>>> DP_AS_SDP_FAVT_PAYLOAD_FIELDS_PARSING_SUPPORTED)
> >>>> +            return true;
> >>>> +    }
> >>>> +
> >>>> +    if (!intel_psr_pr_async_video_timing_supported(intel_dp))
> >>>> +        return true;
> >>>> +
> >>>> +    return false;
> >>>> +}
> >>>> +
> >>>>   static void
> >>>>   intel_dp_detect_sdp_caps(struct intel_dp *intel_dp)
> >>>>   {
> >>>> @@ -6313,6 +6343,9 @@ intel_dp_detect_sdp_caps(struct intel_dp 
> >>>> *intel_dp)
> >>>>         intel_dp->as_sdp_supported = HAS_AS_SDP(display) &&
> >>>>           drm_dp_as_sdp_supported(&intel_dp->aux, intel_dp->dpcd);
> >>>> +
> >>>> +    intel_dp->as_sdp_v2_supported = intel_dp->as_sdp_supported &&
> >>>> + intel_dp_sink_supports_as_sdp_v2(intel_dp);
> >>>>   }
> >>>>     static bool intel_dp_needs_dpcd_probe(struct intel_dp 
> >>>> *intel_dp, bool force_on_external)
> >>>> -- 
> >>>> 2.45.2
> >>> -- 
> >>> Ville Syrjälä
> >>> Intel

-- 
Ville Syrjälä
Intel