public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: ville.syrjala@linux.intel.com
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 06/14] drm/i915: Fix LP1+ watermark disabling ILK
Date: Thu,  5 Dec 2013 15:51:33 +0200	[thread overview]
Message-ID: <1386251501-10602-7-git-send-email-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <1386251501-10602-1-git-send-email-ville.syrjala@linux.intel.com>

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

On ILK disabling LP1+ watermarks must be done carefully to avoid
underruns. If we just write 0 to the register in the middle of the scan
cycle we often get an underrun. So instead we have to leave the actual
watermark levels in the register intact, and just toggle the enable bit.

Presumably the hardware takes a while to get out of low power mode, and
so the watermark level need to stay valid until that time.

We also have to be careful with the WM1S_LP_EN bit. It seems the
hardware more or less treats it like the actual watermarks numbers, and
so we must not toggle it too soon. Just leave it alone when disabling
the LP1+ watermarks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c | 33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index db7f3a6..1aa6ea9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2897,16 +2897,23 @@ static void hsw_write_wm_values(struct drm_i915_private *dev_priv,
 	if (!dirty)
 		return;
 
-	if (dirty & WM_DIRTY_LP(3) && previous->wm_lp[2] != 0)
-		I915_WRITE(WM3_LP_ILK, 0);
-	if (dirty & WM_DIRTY_LP(2) && previous->wm_lp[1] != 0)
-		I915_WRITE(WM2_LP_ILK, 0);
-	if (dirty & WM_DIRTY_LP(1) && previous->wm_lp[0] != 0)
-		I915_WRITE(WM1_LP_ILK, 0);
+	if (dirty & WM_DIRTY_LP(3) && previous->wm_lp[2] & WM1_LP_SR_EN) {
+		previous->wm_lp[2] &= ~WM1_LP_SR_EN;
+		I915_WRITE(WM3_LP_ILK, previous->wm_lp[2]);
+	}
+	if (dirty & WM_DIRTY_LP(2) && previous->wm_lp[1] & WM1_LP_SR_EN) {
+		previous->wm_lp[1] &= ~WM1_LP_SR_EN;
+		I915_WRITE(WM2_LP_ILK, previous->wm_lp[1]);
+	}
+	if (dirty & WM_DIRTY_LP(1) && previous->wm_lp[0] & WM1_LP_SR_EN) {
+		previous->wm_lp[0] &= ~WM1_LP_SR_EN;
+		I915_WRITE(WM1_LP_ILK, previous->wm_lp[0]);
+	}
 
-	if (INTEL_INFO(dev)->gen <= 6 &&
-	    dirty & WM_DIRTY_LP(1) && previous->wm_lp_spr[0] != 0)
-		I915_WRITE(WM1S_LP_ILK, 0);
+	/*
+	 * Don't touch WM1S_LP_EN here.
+	 * Doing so could cause underruns.
+	 */
 
 	if (dirty & WM_DIRTY_PIPE(PIPE_A))
 		I915_WRITE(WM0_PIPEA_ILK, results->wm_pipe[0]);
@@ -2950,7 +2957,7 @@ static void hsw_write_wm_values(struct drm_i915_private *dev_priv,
 	}
 
 	if (INTEL_INFO(dev)->gen <= 6) {
-		if (dirty & WM_DIRTY_LP(1) && results->wm_lp_spr[0] != 0)
+		if (dirty & WM_DIRTY_LP(1) && previous->wm_lp_spr[0] != results->wm_lp_spr[0])
 			I915_WRITE(WM1S_LP_ILK, results->wm_lp_spr[0]);
 	} else {
 		if (dirty & WM_DIRTY_LP(1) && previous->wm_lp_spr[0] != results->wm_lp_spr[0])
@@ -2961,11 +2968,11 @@ static void hsw_write_wm_values(struct drm_i915_private *dev_priv,
 			I915_WRITE(WM3S_LP_IVB, results->wm_lp_spr[2]);
 	}
 
-	if (dirty & WM_DIRTY_LP(1) && results->wm_lp[0] != 0)
+	if (dirty & WM_DIRTY_LP(1) && previous->wm_lp[0] != results->wm_lp[0])
 		I915_WRITE(WM1_LP_ILK, results->wm_lp[0]);
-	if (dirty & WM_DIRTY_LP(2) && results->wm_lp[1] != 0)
+	if (dirty & WM_DIRTY_LP(2) && previous->wm_lp[1] != results->wm_lp[1])
 		I915_WRITE(WM2_LP_ILK, results->wm_lp[1]);
-	if (dirty & WM_DIRTY_LP(3) && results->wm_lp[2] != 0)
+	if (dirty & WM_DIRTY_LP(3) && previous->wm_lp[2] != results->wm_lp[2])
 		I915_WRITE(WM3_LP_ILK, results->wm_lp[2]);
 
 	dev_priv->wm.hw = *results;
-- 
1.8.3.2

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2013-12-05 13:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05 13:51 [PATCH 00/14] drm/i915: Make ILK/SNB/IVB use HSW watermark code ville.syrjala
2013-12-05 13:51 ` [PATCH 01/14] drm/i915: Add IVB DDB partitioning control ville.syrjala
2013-12-05 13:51 ` [PATCH 02/14] drm/i915: Add ILK/SNB/IVB WM latency field support ville.syrjala
2013-12-05 13:51 ` [PATCH 03/14] drm/i915: Avoid computing invalid WM levels when sprites/scaling is enabled ville.syrjala
2013-12-05 13:51 ` [PATCH 04/14] Revert "drm/i915/sprite: Always enable the scaler on IronLake" ville.syrjala
2013-12-16 21:42   ` Imre Deak
2013-12-05 13:51 ` [PATCH 05/14] drm/i915: Fix LP1 sprite watermarks for ILK/SNB ville.syrjala
2013-12-05 13:51 ` ville.syrjala [this message]
2013-12-16 21:46   ` [PATCH 06/14] drm/i915: Fix LP1+ watermark disabling ILK Imre Deak
2013-12-05 13:51 ` [PATCH 07/14] drm/i915: Don't merge LP1+ watermarks on ILK/SNB/IVB when multiple pipes are enabled ville.syrjala
2013-12-05 13:51 ` [PATCH 08/14] drm/i915: Disable FBC WM on ILK, and disable LP2+ when FBC is enabled ville.syrjala
2013-12-05 13:51 ` [PATCH 09/14] drm/i915: Linetime watermarks are a HSW feature ville.syrjala
2013-12-05 13:51 ` [PATCH 10/14] drm/i915: Disable LP1+ watermarks safely in init ville.syrjala
2013-12-05 14:27   ` Chris Wilson
2013-12-05 14:41     ` Ville Syrjälä
2013-12-05 13:51 ` [PATCH 11/14] drm/i915: Move ILK/SNB/IVB over to the HSW WM code ville.syrjala
2013-12-16 22:16   ` Imre Deak
2013-12-05 13:51 ` [PATCH 12/14] drm/i915: Try to fix the messy IVB sprite scaling workaround ville.syrjala
2013-12-05 13:51 ` [PATCH 13/14] drm/i915: Don't disable primary when color keying is used ville.syrjala
2013-12-05 13:51 ` [PATCH 14/14] drm/i915: Avoid underruns when disabling sprites ville.syrjala
2013-12-05 14:30 ` [PATCH 00/14] drm/i915: Make ILK/SNB/IVB use HSW watermark code Daniel Vetter
2013-12-05 14:48   ` Ville Syrjälä
2013-12-16 21:38 ` Imre Deak
2013-12-17 10:13   ` Daniel Vetter

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=1386251501-10602-7-git-send-email-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox