From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org,
Xizhe Tang <xizheTang2005@163.com>,
Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Subject: [PATCH 1/3] drm/i915/vrr: Use vrr.in_range to determine if we need the AS SDP
Date: Wed, 23 Sep 2026 19:43:19 +0300 [thread overview]
Message-ID: <20260923164321.9230-1-ville.syrjala@linux.intel.com> (raw)
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
intel_vrr_possible() is seriously misnamed now. In the past it
used to tell us whether VRR might get enabled (now or later),
but now all it tell us whether we have something to program into
the VRR timing generator registers (which we pretty much always
do, even when we don't have a VRR monitor). Thus the use of
intel_vrr_possible() in intel_dp_needs_as_sdp() is nonsense.
Switch over the checking crtc_state->vrr.in_range instead, which
actually tells us whether actual VRR timings might get used
at some point. This is also what we use to program the DPCD
DP_MSA_TIMING_PAR_IGNORE_EN bit. Thus we shall only transmit the
AS SDP on VRR capable sinks, and only when the refresh rate is
in the VRR range.
The one slight snag with crtc_state->vrr.in_range is that we
don't have readout for it since it is derived from DPCD/EDID
which aren't part of readout. Thus the potential issue
highlighted in the comment in intel_dp_update_downspread_ctrl()
may now extend to the AS SDP bits as well. In particular if we
end up taking the full modeset path during during initial_commit(),
we may end up calculating the guardband differently than during
a later proper userspace commit (which will have access to
DPCD/EDID derived information). But the proper way to fix those
issues might be to eliminate all reasons for a full modeset
computation during initial_commit()...
Cc: Xizhe Tang <xizheTang2005@163.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/9252
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index ffddf4b33728..98349aedd855 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3113,7 +3113,7 @@ static bool intel_dp_needs_as_sdp(struct intel_dp *intel_dp,
!intel_psr_pr_async_video_timing_supported(intel_dp))
return true;
- return intel_vrr_possible(crtc_state);
+ return crtc_state->vrr.in_range;
}
static void intel_dp_compute_as_sdp(struct intel_dp *intel_dp,
--
2.54.0
next reply other threads:[~2026-09-23 16:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 16:43 Ville Syrjala [this message]
2026-09-23 16:43 ` [PATCH 2/3] drm/i915/vrr: Introduce intel_vrr_can_use_vrr_tg() Ville Syrjala
2026-09-23 16:43 ` [PATCH 3/3] drm/i915/vrr: s/intel_vrr_possible()/has_vrr_tg_timings()/ Ville Syrjala
2026-09-23 16:50 ` ✗ CI.checkpatch: warning for series starting with [1/3] drm/i915/vrr: Use vrr.in_range to determine if we need the AS SDP Patchwork
2026-09-23 16:52 ` ✓ CI.KUnit: success " Patchwork
2026-09-23 18:46 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-24 6:35 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-25 19:23 ` [PATCH 1/3] " xizheTang2005
2026-09-28 8:46 ` Jani Nikula
2026-09-28 18:50 ` xizheTang2005
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260923164321.9230-1-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ankit.k.nautiyal@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=xizheTang2005@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox