From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/display: use set_context_latency for DSB W2-line waits
Date: Mon, 18 May 2026 17:52:41 +0300 [thread overview]
Message-ID: <agsnuYVMWNSJwf4F@intel.com> (raw)
In-Reply-To: <20260518060522.2945720-1-ankit.k.nautiyal@intel.com>
On Mon, May 18, 2026 at 11:35:22AM +0530, Ankit Nautiyal wrote:
> set_context_latency represents W2 window/latency lines.
> Earlier, delayed and undelayed vblank coincided, so this matched the
> distance from vactive end to undelayed vblank start.
>
> After guardband optimization changes, delayed vblank start can move
> away from undelayed vblank. In DSB non-VRR paths, the older
> intel_mode_vblank_delay() is still used in some code paths.
>
> Fix this by using set_context_latency directly for W2-line waits.
>
> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c
> index fec8a56e21ea..8521f5969aca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -745,6 +745,7 @@ void intel_dsb_vblank_evade(struct intel_atomic_state *state,
> intel_pre_commit_crtc_state(state, crtc);
> int latency = intel_usecs_to_scanlines(&crtc_state->hw.adjusted_mode,
> intel_dsb_arm_exec_time_us());
> + int vblank_delay = crtc_state->set_context_latency;
> int start, end;
>
> /*
> @@ -760,7 +761,6 @@ void intel_dsb_vblank_evade(struct intel_atomic_state *state,
> intel_dsb_emit_wait_dsl(dsb, DSB_OPCODE_WAIT_DSL_OUT, 0, 0);
>
> if (pre_commit_is_vrr_active(state, crtc) && crtc_state->vrr.dc_balance.enable) {
> - int vblank_delay = crtc_state->set_context_latency;
> int vmin_vblank_start, vmax_vblank_start;
>
> vmin_vblank_start = intel_vrr_dcb_vmin_vblank_start_next(crtc_state);
> @@ -789,8 +789,6 @@ void intel_dsb_vblank_evade(struct intel_atomic_state *state,
> start = end - vblank_delay - latency;
> intel_dsb_wait_scanline_out(state, dsb, start, end);
> } else if (pre_commit_is_vrr_active(state, crtc)) {
> - int vblank_delay = crtc_state->set_context_latency;
> -
> end = intel_vrr_vmin_vblank_start(crtc_state);
> start = end - vblank_delay - latency;
> intel_dsb_wait_scanline_out(state, dsb, start, end);
> @@ -799,8 +797,6 @@ void intel_dsb_vblank_evade(struct intel_atomic_state *state,
> start = end - vblank_delay - latency;
> intel_dsb_wait_scanline_out(state, dsb, start, end);
> } else {
> - int vblank_delay = intel_mode_vblank_delay(&crtc_state->hw.adjusted_mode);
> -
> end = intel_mode_vblank_start(&crtc_state->hw.adjusted_mode);
> start = end - vblank_delay - latency;
> intel_dsb_wait_scanline_out(state, dsb, start, end);
> @@ -889,7 +885,7 @@ void intel_dsb_wait_for_delayed_vblank(struct intel_atomic_state *state,
> intel_pre_commit_crtc_state(state, crtc);
> const struct drm_display_mode *adjusted_mode =
> &crtc_state->hw.adjusted_mode;
> - int wait_scanlines;
> + int wait_scanlines = crtc_state->set_context_latency + 1;
>
> if (pre_commit_is_vrr_active(state, crtc)) {
> /*
> @@ -912,9 +908,6 @@ void intel_dsb_wait_for_delayed_vblank(struct intel_atomic_state *state,
> * scanline until the delayed vblank occurs after
> * TRANS_PUSH has been written.
> */
> - wait_scanlines = crtc_state->set_context_latency + 1;
> - } else {
> - wait_scanlines = intel_mode_vblank_delay(adjusted_mode);
After further consideration I think the current code is in fact correct.
intel_dsb_wait_vblanks()/DSB_WAIT_FOR_VBLANK will wait for the undelayed
vblank when VRR is disabled, so this does need the full wait.
So I think the actual issue is more of a userspace bug in that they
assume the event fires at vblank_start and guesstimate the deadline
based on the time when the event was received. What they need to do
is calculate the deadline based on the event timestamp.
Another option might be to switch to using the safe window even for
the '!vrr && always_use_vrr_tg()' case. But that probably needs some
actual thought...
> }
>
> intel_dsb_wait_usec(dsb, intel_scanlines_to_usecs(adjusted_mode, wait_scanlines));
> --
> 2.45.2
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-05-18 14:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 6:05 [PATCH] drm/i915/display: use set_context_latency for DSB W2-line waits Ankit Nautiyal
2026-05-18 6:27 ` ✓ CI.KUnit: success for " Patchwork
2026-05-18 7:35 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-18 11:05 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-05-18 14:52 ` Ville Syrjälä [this message]
2026-05-21 11:46 ` [PATCH] " Nautiyal, Ankit K
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=agsnuYVMWNSJwf4F@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 \
/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