From: Imre Deak <imre.deak@intel.com>
To: ville.syrjala@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 06/14] drm/i915: Fix LP1+ watermark disabling ILK
Date: Mon, 16 Dec 2013 23:46:35 +0200 [thread overview]
Message-ID: <1387230395.2529.11.camel@ideak-mobl> (raw)
In-Reply-To: <1386251501-10602-7-git-send-email-ville.syrjala@linux.intel.com>
On Thu, 2013-12-05 at 15:51 +0200, ville.syrjala@linux.intel.com wrote:
> 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]);
This and the below "else" version are the same now, so it could be moved
before the if.
--Imre
> } 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;
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2013-12-16 21:46 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 ` [PATCH 06/14] drm/i915: Fix LP1+ watermark disabling ILK ville.syrjala
2013-12-16 21:46 ` Imre Deak [this message]
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=1387230395.2529.11.camel@ideak-mobl \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/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