All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor updates
Date: Wed, 13 Dec 2023 12:25:18 +0200	[thread overview]
Message-ID: <20231213102519.13500-9-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20231213102519.13500-1-ville.syrjala@linux.intel.com>

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Our legacy cursor updates are actually mailbox updates.
Ie. the hardware latches things once per frame on start of
vblank, but we issue an number of updates per frame,
withough any attempt to synchronize against the vblank
in software. So in theory only the last update issued
during the frame will latch, and the previous ones are
discarded.

However this can lead to problems with maintaining the
ggtt/iommu mappings as we have no idea which updates
will actually latch.

The problem is exacerbated by the hardware's annoying disarming
behaviour; any non-arming register write will disarm an already
armed update, only to be rearmed later by the arming register
(CURBASE in case of cursors). If a disarming write happens
just before the start of vblank, and the arming write happens
after start of vblank we have effectively prevented the hardware
from latching anything. And if we manage to straddle multiple
sequential vblank starts in this manner we effectively prevent
the hardware from latching any new registers for an arbitrary
amount of time. This provides more time for the (potentially
still in use by the hardware) gtt/iommu mappings to be torn
down.

A partial solution, of course, is to use vblank evasion to
avoid the register writes from spreading on both sides of
the start of vblank.

I've previously highlighted this problem as a general issue
affecting mailbox updates. I even added some notes to the
{i9xx,skl}_crtc_planes_update_arm() to remind us that the noarm
and arm phases both need to pulled into the vblank evasion
critical section if we actually decided to implement mailbox
updates in general. But as I never impelemented the noarm+arm
split for cursors we don't have to worry about that for the
moment.

We've been lucky enough so far that this hasn't really caused
problems. One thing that does help is that Xorg generally
sticks to the same cursor BO. But igt seems pretty good at
hitting this on MTL now, so apparently we have to start
thinking about this.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_cursor.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c b/drivers/gpu/drm/i915/display/intel_cursor.c
index 926e2de00eb5..77531838001f 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -22,6 +22,7 @@
 #include "intel_frontbuffer.h"
 #include "intel_psr.h"
 #include "intel_psr_regs.h"
+#include "intel_vblank.h"
 #include "skl_watermark.h"
 
 #include "gem/i915_gem_object.h"
@@ -647,12 +648,14 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
 {
 	struct intel_plane *plane = to_intel_plane(_plane);
 	struct intel_crtc *crtc = to_intel_crtc(_crtc);
+	struct drm_i915_private *i915 = to_i915(plane->base.dev);
 	struct intel_plane_state *old_plane_state =
 		to_intel_plane_state(plane->base.state);
 	struct intel_plane_state *new_plane_state;
 	struct intel_crtc_state *crtc_state =
 		to_intel_crtc_state(crtc->base.state);
 	struct intel_crtc_state *new_crtc_state;
+	struct intel_vblank_evade_ctx evade;
 	int ret;
 
 	/*
@@ -745,14 +748,15 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
 	 */
 	crtc_state->active_planes = new_crtc_state->active_planes;
 
-	/*
-	 * Technically we should do a vblank evasion here to make
-	 * sure all the cursor registers update on the same frame.
-	 * For now just make sure the register writes happen as
-	 * quickly as possible to minimize the race window.
-	 */
+	intel_vblank_evade_init(crtc_state, crtc_state, &evade);
+
 	local_irq_disable();
 
+	if (!drm_WARN_ON(&i915->drm, drm_crtc_vblank_get(&crtc->base))) {
+		intel_vblank_evade(&evade);
+		drm_crtc_vblank_put(&crtc->base);
+	}
+
 	if (new_plane_state->uapi.visible) {
 		intel_plane_update_noarm(plane, crtc_state, new_plane_state);
 		intel_plane_update_arm(plane, crtc_state, new_plane_state);
-- 
2.41.0


  parent reply	other threads:[~2023-12-13 10:25 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 10:25 [PATCH 0/9] drm/i915: Cursor vblank evasion Ville Syrjala
2023-12-13 10:25 ` [PATCH 1/9] drm/i915: Decouple intel_crtc_vblank_evade_scanlines() from atomic commits Ville Syrjala
2023-12-20 11:11   ` Shankar, Uma
2023-12-13 10:25 ` [PATCH 2/9] drm/i915: Reorder drm_vblank_put() vs. need_vlv_dsi_wa Ville Syrjala
2023-12-20 11:20   ` Shankar, Uma
2023-12-13 10:25 ` [PATCH 3/9] drm/i915: Introduce struct intel_vblank_evade_ctx Ville Syrjala
2023-12-20 11:22   ` Shankar, Uma
2023-12-13 10:25 ` [PATCH 4/9] drm/i915: Include need_vlv_dsi_wa in intel_vblank_evade_ctx Ville Syrjala
2023-12-20 11:22   ` Shankar, Uma
2023-12-13 10:25 ` [PATCH 5/9] drm/i915: Extract intel_vblank_evade() Ville Syrjala
2023-12-20 11:26   ` Shankar, Uma
2023-12-13 10:25 ` [PATCH 6/9] drm/i915: Move the min/max scanline sanity check into intel_vblank_evade() Ville Syrjala
2023-12-20 11:27   ` Shankar, Uma
2023-12-13 10:25 ` [PATCH 7/9] drm/i915: Move intel_vblank_evade() & co. into intel_vblank.c Ville Syrjala
2023-12-20 11:28   ` Shankar, Uma
2023-12-13 10:25 ` Ville Syrjala [this message]
2023-12-20 11:41   ` [PATCH 8/9] drm/i915: Perform vblank evasion around legacy cursor updates Shankar, Uma
2023-12-20 11:45     ` Shankar, Uma
2023-12-20 14:48       ` Ville Syrjälä
2023-12-22  5:07         ` Shankar, Uma
2024-01-16 20:49   ` [PATCH v2 " Ville Syrjala
2024-01-17 13:16     ` Hogander, Jouni
2024-01-18  7:53     ` Hogander, Jouni
2024-01-18  9:03     ` Hogander, Jouni
2023-12-13 10:25 ` [PATCH 9/9] Revert "drm/i915/xe2lpd: Treat cursor plane as regular plane for DDB allocation" Ville Syrjala
2023-12-13 11:28   ` Lisovskiy, Stanislav
2023-12-13 15:15     ` Ville Syrjälä
2023-12-13 15:29       ` Ville Syrjälä
2023-12-15 11:15         ` Ville Syrjälä
2024-01-09 12:17           ` Lisovskiy, Stanislav
2023-12-13 20:51 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Cursor vblank evasion Patchwork
2023-12-13 21:08 ` ✗ Fi.CI.BAT: failure " Patchwork
2023-12-18 10:35   ` Saarinen, Jani
2024-01-18  8:04     ` Illipilli, TejasreeX
2024-01-19  8:11       ` Saarinen, Jani
2023-12-19 11:54 ` ✓ Fi.CI.BAT: success " Patchwork
2023-12-19 13:51 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-09 12:34 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Cursor vblank evasion (rev2) Patchwork
2024-01-09 12:48 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-09 15:10 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-16 21:22 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Cursor vblank evasion (rev3) Patchwork
2024-01-16 21:36 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-01-17  8:02 ` ✓ Fi.CI.IGT: success for drm/i915: Cursor vblank evasion (rev2) Patchwork
2024-01-17  8:07 ` ✓ Fi.CI.BAT: success for drm/i915: Cursor vblank evasion (rev3) Patchwork
2024-01-17 10:31 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-17 11:30 ` [PATCH 0/9] drm/i915: Cursor vblank evasion Shankar, Uma
2024-01-17 12:13   ` Ville Syrjälä
2024-01-18  7:57 ` ✓ Fi.CI.IGT: success for drm/i915: Cursor vblank evasion (rev3) Patchwork
2024-01-22 11:43 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Cursor vblank evasion (rev4) Patchwork
2024-01-22 11:56 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-22 15:03 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-22 16:59   ` Ville Syrjälä

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=20231213102519.13500-9-ville.syrjala@linux.intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.