On Tue, Mar 31, 2026 at 05:12:14PM +0530, Nautiyal, Ankit K wrote:
> 
> On 3/30/2026 11:51 PM, Ville Syrjälä wrote:
> > On Mon, Mar 30, 2026 at 09:36:45AM +0530, Ankit Nautiyal wrote:
> >> Add a helper that determines whether AS SDP can be used for the
> >> current DP configuration. For now this is true only when the sink
> >> supports AS SDP and VRR is enabled, but more conditions may be added
> >> later.
> >>
> >> Signed-off-by: Ankit Nautiyal <[email protected]>
> >> ---
> >>   drivers/gpu/drm/i915/display/intel_dp.c | 11 ++++++++++-
> >>   1 file changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 499850c2abcf..7ca3f9d583db 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -3124,6 +3124,15 @@ static void intel_dp_compute_vsc_colorimetry(const 
> >> struct intel_crtc_state *crtc
> >>    vsc->content_type = DP_CONTENT_TYPE_NOT_DEFINED;
> >>   }
> >>   
> >> +static bool intel_dp_can_use_as_sdp(struct intel_dp *intel_dp,
> >> +                              struct intel_crtc_state *crtc_state)
> >> +{
> >> +  if (!intel_dp->as_sdp_supported)
> >> +          return false;
> >> +
> > Could have a FIXME here about fastset being borked with this. Didn't
> > read far enough in the series yet to see if you did anything about that.
> 
> Hmm... let me check if I understand your concern correctly.
> 
> When VRR state changes through the fastset path, 
> intel_dp_as_sdp_compute_config_late() will compute different AS SDP fields.
> 
> We do write the new values to the SDP DIP registers during update_pipe, 
> but since AS SDP comparison is skipped during fastset,

Oh, I thought we didn't have that. If it's there then I guess it's
fine-ish. Although we don't do the infoframe/SDP updates in the
truly proper atomic fashion, nor do we handle the new cdclk->tc clock
crossing thing correctly. So I suspect we might end up sending
a corrupted packet if the update happens to straddle the transmission
line.

> we have no way to verify through state readback that the hardware 
> actually latched the new values correctly.
> 
> Is that what you had in mind?
> 
> I'll add a FIXME about this.
> 
> Thanks,
> 
> Ankit
> 
> 
> >
> > Either way
> > Reviewed-by: Ville Syrjälä <[email protected]>
> >
> >> +  return crtc_state->vrr.enable;
> >> +}
> >> +
> >>   static void intel_dp_compute_as_sdp(struct intel_dp *intel_dp,
> >>                                struct intel_crtc_state *crtc_state)
> >>   {
> >> @@ -3131,7 +3140,7 @@ static void intel_dp_compute_as_sdp(struct intel_dp 
> >> *intel_dp,
> >>    const struct drm_display_mode *adjusted_mode =
> >>            &crtc_state->hw.adjusted_mode;
> >>   
> >> -  if (!crtc_state->vrr.enable || !intel_dp->as_sdp_supported)
> >> +  if (!intel_dp_can_use_as_sdp(intel_dp, crtc_state))
> >>            return;
> >>   
> >>    crtc_state->infoframes.enable |= 
> >> intel_hdmi_infoframe_enable(DP_SDP_ADAPTIVE_SYNC);
> >> -- 
> >> 2.45.2

-- 
Ville Syrjälä
Intel

Reply via email to