All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Michał Winiarski" <michal.winiarski@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/i915: Set softmin frequency on idle->busy transition
Date: Thu, 16 Jun 2016 19:00:12 +0300	[thread overview]
Message-ID: <20160616160012.GI4329@intel.com> (raw)
In-Reply-To: <1466090389-17469-1-git-send-email-michal.winiarski@intel.com>

On Thu, Jun 16, 2016 at 05:19:49PM +0200, Michał Winiarski wrote:
> If the GPU load is low enough, it's possible that we'll be stuck at idle
> frequency rather than transition into softmin frequency requested by
> userspace.
> Since we assume that idle_freq <= min_freq_softlimit and
> valleyview_set_rps is already skipping write when
> requested_freq == cur_freq we can also remove vlv_set_idle function.
> 
> v2: Use intel_set_rps, drop vlv_set_idle
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=89728
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 33 +++++++--------------------------
>  1 file changed, 7 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 658a756..41c5d25 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4798,6 +4798,7 @@ static void valleyview_set_rps(struct drm_i915_private *dev_priv, u8 val)
>  	WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
>  	WARN_ON(val > dev_priv->rps.max_freq);
>  	WARN_ON(val < dev_priv->rps.min_freq);
> +	WARN_ON(val < dev_priv->rps.idle_freq);
>  
>  	if (WARN_ONCE(IS_CHERRYVIEW(dev_priv) && (val & 1),
>  		      "Odd GPU freq value\n"))
> @@ -4815,31 +4816,11 @@ static void valleyview_set_rps(struct drm_i915_private *dev_priv, u8 val)
>  	trace_intel_gpu_freq_change(intel_gpu_freq(dev_priv, val));
>  }
>  
> -/* vlv_set_rps_idle: Set the frequency to idle, if Gfx clocks are down
> - *
> - * * If Gfx is Idle, then
> - * 1. Forcewake Media well.
> - * 2. Request idle freq.
> - * 3. Release Forcewake of Media well.
> -*/
> -static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
> -{
> -	u32 val = dev_priv->rps.idle_freq;
> -
> -	if (dev_priv->rps.cur_freq <= val)
> -		return;
> -
> -	/* Wake up the media well, as that takes a lot less
> -	 * power than the Render well. */
> -	intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);
> -	valleyview_set_rps(dev_priv, val);
> -	intel_uncore_forcewake_put(dev_priv, FORCEWAKE_MEDIA);
> -}
> -
>  void gen6_rps_busy(struct drm_i915_private *dev_priv)
>  {
>  	mutex_lock(&dev_priv->rps.hw_lock);
>  	if (dev_priv->rps.enabled) {
> +		intel_set_rps(dev_priv, dev_priv->rps.min_freq_softlimit);
>  		if (dev_priv->pm_rps_events & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED))
>  			gen6_rps_reset_ei(dev_priv);
>  		I915_WRITE(GEN6_PMINTRMSK,
> @@ -4852,10 +4833,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
>  {
>  	mutex_lock(&dev_priv->rps.hw_lock);
>  	if (dev_priv->rps.enabled) {
> -		if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> -			vlv_set_rps_idle(dev_priv);
> -		else
> -			gen6_set_rps(dev_priv, dev_priv->rps.idle_freq);
> +		intel_set_rps(dev_priv, dev_priv->rps.idle_freq);
>  		dev_priv->rps.last_adj = 0;
>  		I915_WRITE(GEN6_PMINTRMSK, 0xffffffff);
>  	}
> @@ -4905,8 +4883,11 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
>  
>  void intel_set_rps(struct drm_i915_private *dev_priv, u8 val)
>  {
> -	if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> +	if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> +		intel_uncore_forcewake_get(dev_priv, FORCEWAKE_MEDIA);
>  		valleyview_set_rps(dev_priv, val);
> +		intel_uncore_forcewake_put(dev_priv, FORCEWAKE_MEDIA);

Why should we take the extra hit from waking the media well for every
RPS changes?

> +	}
>  	else
>  		gen6_set_rps(dev_priv, val);
>  }
> -- 
> 2.8.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-06-16 16:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-16 15:19 [PATCH v2] drm/i915: Set softmin frequency on idle->busy transition Michał Winiarski
2016-06-16 15:42 ` Chris Wilson
2016-06-16 21:04   ` Chris Wilson
2016-06-16 15:46 ` ✓ Ro.CI.BAT: success for " Patchwork
2016-06-16 16:00 ` Ville Syrjälä [this message]
2016-06-20  7:51 ` [PATCH v3] " Michał Winiarski
2016-06-20  8:16   ` Chris Wilson
2016-06-20 10:00     ` Winiarski, Michal
2016-06-20  9:58   ` [PATCH v4] " Michał Winiarski
2016-06-20 16:55     ` Chris Wilson
2016-06-21 10:41       ` Chris Wilson
2016-06-20  8:11 ` ✓ Ro.CI.BAT: success for drm/i915: Set softmin frequency on idle->busy transition (rev2) Patchwork
2016-06-20 10:21 ` ✓ Ro.CI.BAT: success for drm/i915: Set softmin frequency on idle->busy transition (rev3) 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=20160616160012.GI4329@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.winiarski@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 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.