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 1/3] drm/i915: Compute use_sagv_wm differently
Date: Tue, 19 Dec 2023 15:07:54 +0200	[thread overview]
Message-ID: <20231219130756.25986-2-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20231219130756.25986-1-ville.syrjala@linux.intel.com>

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

drm_atomic_check_only() gets upset if we try to add extra crtcs
to any commit that isn't flagged with DRM_MODE_ATOMIC_ALLOW_MODESET.
This conflicts with how SAGV watermarks work on pre-ADL as we
need to manually switch over the SAGV watermarks before we can
safely enable SAGV.

So in order to make SAGV usage possible we need to compute each
pipe's use of SAGV watermarks as if there aren't any other
active pipes. Ie. if the current pipe isn't the one blocking
SAGV then we make it use the SAGV watermarks, even if some
other pipe prevents SAGV from actually being used. Otherwise
we could end up with a pipes using the normal watermarks (but
not blocking SAGV), and some other pipe in parallel enabling
SAGV, which would likely cause underruns.

The alternative approach of preventing SAGV usage until all
pipes simultanously end up using SAGV watermarks would only
really work if userspace always adds all pipes to every
commits, which isn't the case typically.

The downside of this is that we will end up using the less
optimal SAGV watermarks even if some other pipe prevents
SAGV from actually being enabled. In which case the system
won't achieve the minimum possible power consumption.

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

diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c b/drivers/gpu/drm/i915/display/skl_watermark.c
index 56588d6e24ae..9cee19cbe253 100644
--- a/drivers/gpu/drm/i915/display/skl_watermark.c
+++ b/drivers/gpu/drm/i915/display/skl_watermark.c
@@ -443,12 +443,35 @@ static int intel_compute_sagv_mask(struct intel_atomic_state *state)
 
 	for_each_new_intel_crtc_in_state(state, crtc,
 					 new_crtc_state, i) {
+		struct skl_pipe_wm *pipe_wm = &new_crtc_state->wm.skl.optimal;
+
 		new_bw_state = intel_atomic_get_bw_state(state);
 		if (IS_ERR(new_bw_state))
 			return PTR_ERR(new_bw_state);
 
 		old_bw_state = intel_atomic_get_old_bw_state(state);
 
+		/*
+		 * We store use_sagv_wm in the crtc state rather than relying on
+		 * that bw state since we have no convenient way to get at the
+		 * latter from the plane commit hooks (especially in the legacy
+		 * cursor case).
+		 *
+		 * drm_atomic_check_only() gets upset if we pull more crtcs
+		 * into the state, so we have to calculate this based on the
+		 * individual intel_crtc_can_enable_sagv() rather than
+		 * the overall intel_crtc_can_enable_sagv(). Otherwise the
+		 * crtcs not included in the commit would not switch to the
+		 * SAGV watermarks when we are about to enable SAGV, and that
+		 * would lead to underruns. This does mean extra power draw
+		 * when only a subset of the crtcs are blocking SAGV as the
+		 * other crtcs can't be allowed to use the more optimal
+		 * normal (ie. non-SAGV) watermarks.
+		 */
+		pipe_wm->use_sagv_wm = !HAS_HW_SAGV_WM(i915) &&
+			DISPLAY_VER(i915) >= 12 &&
+			intel_crtc_can_enable_sagv(new_crtc_state);
+
 		if (intel_crtc_can_enable_sagv(new_crtc_state))
 			new_bw_state->pipe_sagv_reject &= ~BIT(crtc->pipe);
 		else
@@ -478,21 +501,6 @@ static int intel_compute_sagv_mask(struct intel_atomic_state *state)
 			return ret;
 	}
 
-	for_each_new_intel_crtc_in_state(state, crtc,
-					 new_crtc_state, i) {
-		struct skl_pipe_wm *pipe_wm = &new_crtc_state->wm.skl.optimal;
-
-		/*
-		 * We store use_sagv_wm in the crtc state rather than relying on
-		 * that bw state since we have no convenient way to get at the
-		 * latter from the plane commit hooks (especially in the legacy
-		 * cursor case)
-		 */
-		pipe_wm->use_sagv_wm = !HAS_HW_SAGV_WM(i915) &&
-			DISPLAY_VER(i915) >= 12 &&
-			intel_can_enable_sagv(i915, new_bw_state);
-	}
-
 	return 0;
 }
 
-- 
2.41.0


  reply	other threads:[~2023-12-19 13:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-19 13:07 [PATCH 0/3] drm/i915: Rework global state serialization Ville Syrjala
2023-12-19 13:07 ` Ville Syrjala [this message]
2024-02-01  8:17   ` [PATCH 1/3] drm/i915: Compute use_sagv_wm differently Lisovskiy, Stanislav
2023-12-19 13:07 ` [PATCH 2/3] drm/i915: Rework global state serializaiton Ville Syrjala
2024-02-01  8:48   ` Lisovskiy, Stanislav
2023-12-19 13:07 ` [PATCH 3/3] drm/i915: Extract intel_atomic_swap_state() Ville Syrjala
2024-01-15 11:10   ` Lisovskiy, Stanislav
2023-12-19 13:39 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Rework global state serialization Patchwork
2023-12-19 13:52 ` ✓ Fi.CI.BAT: success " Patchwork
2023-12-19 15:25 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-10 18:17 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Rework global state serialization (rev2) Patchwork
2024-01-10 18:30 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-10 22:20 ` ✗ Fi.CI.IGT: 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=20231219130756.25986-2-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.