From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Subject: [PATCH v2 1/8] drm/i915/dsb: Move the +1 usec adjustment into dsb_wait_usec()
Date: Sat, 8 Feb 2025 00:31:52 +0200 [thread overview]
Message-ID: <20250207223159.14132-2-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20250207223159.14132-1-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The "wait usec" DSB command doesn't quite seem to able to
guarantee that it always waits at least the specified
amount of usecs. Some of that could be just because it
supposedly just does some kind of dumb timestamp comparison
internally. But I also see cases where two hardware timestamps
sampled on each side of the "wait usec" command come out one
less than expected. So it looks like we always need at least a
+1 to guarantee that we never wait less than specified. Always
apply that adjustment in dsb_wait_usec().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_dsb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c
index 2f2812c23972..f8bd6fad0c87 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -369,7 +369,8 @@ void intel_dsb_interrupt(struct intel_dsb *dsb)
void intel_dsb_wait_usec(struct intel_dsb *dsb, int count)
{
- intel_dsb_emit(dsb, count,
+ /* +1 to make sure we never wait less time than asked for */
+ intel_dsb_emit(dsb, count + 1,
DSB_OPCODE_WAIT_USEC << DSB_OPCODE_SHIFT);
}
@@ -622,7 +623,7 @@ void intel_dsb_wait_vblank_delay(struct intel_atomic_state *state,
const struct intel_crtc_state *crtc_state =
intel_pre_commit_crtc_state(state, crtc);
int usecs = intel_scanlines_to_usecs(&crtc_state->hw.adjusted_mode,
- dsb_vblank_delay(state, crtc)) + 1;
+ dsb_vblank_delay(state, crtc));
intel_dsb_wait_usec(dsb, usecs);
}
--
2.45.3
next prev parent reply other threads:[~2025-02-07 22:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 22:31 [PATCH v2 0/8] drm/i915/vrr: Fix DSB+VRR usage for PTL+ Ville Syrjala
2025-02-07 22:31 ` Ville Syrjala [this message]
2025-02-11 8:58 ` [PATCH v2 1/8] drm/i915/dsb: Move the +1 usec adjustment into dsb_wait_usec() Nautiyal, Ankit K
2025-02-07 22:31 ` [PATCH v2 2/8] drm/i915/vrr: Don't send push for legacy cursor updates Ville Syrjala
2025-02-11 9:01 ` Nautiyal, Ankit K
2025-02-07 22:31 ` [PATCH v2 3/8] drm/i915/vrr: Account for TRANS_PUSH delay Ville Syrjala
2025-02-11 9:03 ` Nautiyal, Ankit K
2025-02-07 22:31 ` [PATCH v2 4/8] drm/i915/dsb: Compute use_dsb earlier Ville Syrjala
2025-02-11 9:39 ` Nautiyal, Ankit K
2025-02-07 22:31 ` [PATCH v2 5/8] drm/i915/dsb: Introduce intel_dsb_poll() Ville Syrjala
2025-02-07 22:31 ` [PATCH v2 6/8] drm/i915/vrr: Reorder the DSB "wait for safe window" vs. TRANS_PUSH Ville Syrjala
2025-02-07 22:31 ` [PATCH v2 7/8] drm/i915/vrr: Check that the push send bit is clear after delayed vblank Ville Syrjala
2025-02-10 16:07 ` [PATCH v3 " Ville Syrjala
2025-02-11 7:08 ` Nautiyal, Ankit K
2025-02-11 17:38 ` Ville Syrjälä
2025-02-12 13:09 ` Nautiyal, Ankit K
2025-02-12 13:23 ` Nautiyal, Ankit K
2025-02-12 16:45 ` Ville Syrjälä
2025-02-07 22:31 ` [PATCH v2 8/8] drm/i915/dsb: Decode DSB error interrupts Ville Syrjala
2025-02-11 8:54 ` Nautiyal, Ankit K
2025-02-07 23:47 ` ✗ Fi.CI.SPARSE: warning for drm/i915/vrr: Fix DSB+VRR usage for PTL+ (rev3) Patchwork
2025-02-08 3:35 ` ✓ i915.CI.BAT: success " Patchwork
2025-02-08 18:46 ` ✗ i915.CI.Full: failure " Patchwork
2025-02-10 19:00 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vrr: Fix DSB+VRR usage for PTL+ (rev4) Patchwork
2025-02-10 19:00 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-02-10 21:10 ` ✗ i915.CI.BAT: failure " Patchwork
2025-02-12 1:41 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/vrr: Fix DSB+VRR usage for PTL+ (rev5) Patchwork
2025-02-12 1:41 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-02-12 2:08 ` ✗ i915.CI.BAT: failure " Patchwork
2025-02-12 8:19 ` Saarinen, Jani
2025-02-12 9:13 ` Ravali, JupallyX
2025-02-12 9:02 ` ✓ i915.CI.BAT: success " Patchwork
2025-02-12 11:54 ` ✗ i915.CI.Full: failure " Patchwork
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=20250207223159.14132-2-ville.syrjala@linux.intel.com \
--to=ville.syrjala@linux.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