public inbox for intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox