* [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay()
@ 2013-11-07 17:57 ville.syrjala
2013-11-07 17:57 ` [PATCH 2/2] drm/i915: Use clamp_t() when limiting cur_delay ville.syrjala
2013-11-07 18:55 ` [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay() Jesse Barnes
0 siblings, 2 replies; 5+ messages in thread
From: ville.syrjala @ 2013-11-07 17:57 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Polling to make sure the current GPU frequency matches the last
requested frequency should not be necessay, and if there's some
throttling involved, the two might not match anyway.
Since we're still seeing this trigger occasionally, and it just
introduces a rather pointless 10 ms delay, it seems like better
to kill it off.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_pm.c | 27 ---------------------------
1 file changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0a07d7c..f6f9dfe 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3606,31 +3606,6 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv)
mutex_unlock(&dev_priv->rps.hw_lock);
}
-/*
- * Wait until the previous freq change has completed,
- * or the timeout elapsed, and then update our notion
- * of the current GPU frequency.
- */
-static void vlv_update_rps_cur_delay(struct drm_i915_private *dev_priv)
-{
- u32 pval;
-
- WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
-
- if (wait_for(((pval = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS)) & GENFREQSTATUS) == 0, 10))
- DRM_DEBUG_DRIVER("timed out waiting for Punit\n");
-
- pval >>= 8;
-
- if (pval != dev_priv->rps.cur_delay)
- DRM_DEBUG_DRIVER("Punit overrode GPU freq: %d MHz (%u) requested, but got %d Mhz (%u)\n",
- vlv_gpu_freq(dev_priv->mem_freq, dev_priv->rps.cur_delay),
- dev_priv->rps.cur_delay,
- vlv_gpu_freq(dev_priv->mem_freq, pval), pval);
-
- dev_priv->rps.cur_delay = pval;
-}
-
void valleyview_set_rps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3641,8 +3616,6 @@ void valleyview_set_rps(struct drm_device *dev, u8 val)
WARN_ON(val > dev_priv->rps.max_delay);
WARN_ON(val < dev_priv->rps.min_delay);
- vlv_update_rps_cur_delay(dev_priv);
-
DRM_DEBUG_DRIVER("GPU freq request from %d MHz (%u) to %d MHz (%u)\n",
vlv_gpu_freq(dev_priv->mem_freq,
dev_priv->rps.cur_delay),
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 5+ messages in thread* [PATCH 2/2] drm/i915: Use clamp_t() when limiting cur_delay
2013-11-07 17:57 [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay() ville.syrjala
@ 2013-11-07 17:57 ` ville.syrjala
2013-11-07 18:56 ` Jesse Barnes
2013-11-07 18:55 ` [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay() Jesse Barnes
1 sibling, 1 reply; 5+ messages in thread
From: ville.syrjala @ 2013-11-07 17:57 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Make the cur_delay limiting code a bit less prone to typo errors
by using clamp_t().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/i915_irq.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 54338cf..b940ebe 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -966,10 +966,8 @@ static void gen6_pm_rps_work(struct work_struct *work)
/* sysfs frequency interfaces may have snuck in while servicing the
* interrupt
*/
- if (new_delay < (int)dev_priv->rps.min_delay)
- new_delay = dev_priv->rps.min_delay;
- if (new_delay > (int)dev_priv->rps.max_delay)
- new_delay = dev_priv->rps.max_delay;
+ new_delay = clamp_t(int, new_delay,
+ dev_priv->rps.min_delay, dev_priv->rps.max_delay);
dev_priv->rps.last_adj = new_delay - dev_priv->rps.cur_delay;
if (IS_VALLEYVIEW(dev_priv->dev))
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] drm/i915: Use clamp_t() when limiting cur_delay
2013-11-07 17:57 ` [PATCH 2/2] drm/i915: Use clamp_t() when limiting cur_delay ville.syrjala
@ 2013-11-07 18:56 ` Jesse Barnes
2013-11-07 19:05 ` Daniel Vetter
0 siblings, 1 reply; 5+ messages in thread
From: Jesse Barnes @ 2013-11-07 18:56 UTC (permalink / raw)
To: ville.syrjala; +Cc: intel-gfx
On Thu, 7 Nov 2013 19:57:49 +0200
ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Make the cur_delay limiting code a bit less prone to typo errors
> by using clamp_t().
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 54338cf..b940ebe 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -966,10 +966,8 @@ static void gen6_pm_rps_work(struct work_struct *work)
> /* sysfs frequency interfaces may have snuck in while servicing the
> * interrupt
> */
> - if (new_delay < (int)dev_priv->rps.min_delay)
> - new_delay = dev_priv->rps.min_delay;
> - if (new_delay > (int)dev_priv->rps.max_delay)
> - new_delay = dev_priv->rps.max_delay;
> + new_delay = clamp_t(int, new_delay,
> + dev_priv->rps.min_delay, dev_priv->rps.max_delay);
> dev_priv->rps.last_adj = new_delay - dev_priv->rps.cur_delay;
>
> if (IS_VALLEYVIEW(dev_priv->dev))
What a nice little helper.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] drm/i915: Use clamp_t() when limiting cur_delay
2013-11-07 18:56 ` Jesse Barnes
@ 2013-11-07 19:05 ` Daniel Vetter
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Vetter @ 2013-11-07 19:05 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx
On Thu, Nov 07, 2013 at 10:56:52AM -0800, Jesse Barnes wrote:
> On Thu, 7 Nov 2013 19:57:49 +0200
> ville.syrjala@linux.intel.com wrote:
>
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Make the cur_delay limiting code a bit less prone to typo errors
> > by using clamp_t().
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > index 54338cf..b940ebe 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -966,10 +966,8 @@ static void gen6_pm_rps_work(struct work_struct *work)
> > /* sysfs frequency interfaces may have snuck in while servicing the
> > * interrupt
> > */
> > - if (new_delay < (int)dev_priv->rps.min_delay)
> > - new_delay = dev_priv->rps.min_delay;
> > - if (new_delay > (int)dev_priv->rps.max_delay)
> > - new_delay = dev_priv->rps.max_delay;
> > + new_delay = clamp_t(int, new_delay,
> > + dev_priv->rps.min_delay, dev_priv->rps.max_delay);
> > dev_priv->rps.last_adj = new_delay - dev_priv->rps.cur_delay;
> >
> > if (IS_VALLEYVIEW(dev_priv->dev))
>
> What a nice little helper.
Indeed.
>
> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Both patches merged to dinq, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay()
2013-11-07 17:57 [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay() ville.syrjala
2013-11-07 17:57 ` [PATCH 2/2] drm/i915: Use clamp_t() when limiting cur_delay ville.syrjala
@ 2013-11-07 18:55 ` Jesse Barnes
1 sibling, 0 replies; 5+ messages in thread
From: Jesse Barnes @ 2013-11-07 18:55 UTC (permalink / raw)
To: ville.syrjala; +Cc: intel-gfx
On Thu, 7 Nov 2013 19:57:48 +0200
ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Polling to make sure the current GPU frequency matches the last
> requested frequency should not be necessay, and if there's some
> throttling involved, the two might not match anyway.
>
> Since we're still seeing this trigger occasionally, and it just
> introduces a rather pointless 10 ms delay, it seems like better
> to kill it off.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_pm.c | 27 ---------------------------
> 1 file changed, 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0a07d7c..f6f9dfe 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3606,31 +3606,6 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv)
> mutex_unlock(&dev_priv->rps.hw_lock);
> }
>
> -/*
> - * Wait until the previous freq change has completed,
> - * or the timeout elapsed, and then update our notion
> - * of the current GPU frequency.
> - */
> -static void vlv_update_rps_cur_delay(struct drm_i915_private *dev_priv)
> -{
> - u32 pval;
> -
> - WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
> -
> - if (wait_for(((pval = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS)) & GENFREQSTATUS) == 0, 10))
> - DRM_DEBUG_DRIVER("timed out waiting for Punit\n");
> -
> - pval >>= 8;
> -
> - if (pval != dev_priv->rps.cur_delay)
> - DRM_DEBUG_DRIVER("Punit overrode GPU freq: %d MHz (%u) requested, but got %d Mhz (%u)\n",
> - vlv_gpu_freq(dev_priv->mem_freq, dev_priv->rps.cur_delay),
> - dev_priv->rps.cur_delay,
> - vlv_gpu_freq(dev_priv->mem_freq, pval), pval);
> -
> - dev_priv->rps.cur_delay = pval;
> -}
> -
> void valleyview_set_rps(struct drm_device *dev, u8 val)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -3641,8 +3616,6 @@ void valleyview_set_rps(struct drm_device *dev, u8 val)
> WARN_ON(val > dev_priv->rps.max_delay);
> WARN_ON(val < dev_priv->rps.min_delay);
>
> - vlv_update_rps_cur_delay(dev_priv);
> -
> DRM_DEBUG_DRIVER("GPU freq request from %d MHz (%u) to %d MHz (%u)\n",
> vlv_gpu_freq(dev_priv->mem_freq,
> dev_priv->rps.cur_delay),
Yeah, this was just debug code to make sure turbo was working early
on. No longer needed.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-11-07 19:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-07 17:57 [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay() ville.syrjala
2013-11-07 17:57 ` [PATCH 2/2] drm/i915: Use clamp_t() when limiting cur_delay ville.syrjala
2013-11-07 18:56 ` Jesse Barnes
2013-11-07 19:05 ` Daniel Vetter
2013-11-07 18:55 ` [PATCH 1/2] drm/i915: Kill vlv_update_rps_cur_delay() Jesse Barnes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox