On Tue, Jun 25, 2013 at 11:54:39AM -0700, Jesse Barnes wrote: > On Tue, 25 Jun 2013 21:38:11 +0300 > ville.syrjala at linux.intel.com wrote: > > > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > > > If the current GPU frquency is below RPe, and we're asked to increase > > it, just go directly to RPe. This should provide better performance > > faster than letting the frequency trickle up in response to the up > > threshold interrupts. > > > > For now just do it for VLV, since that matches quite closely how VLV > > used to operate when the rps delayed timer kept things at RPe always. > > > > Signed-off-by: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > --- > > drivers/gpu/drm/i915/i915_irq.c | 12 ++++++++++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > > index 62f8b2d..d6bd0d7 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > @@ -699,9 +699,17 @@ static void gen6_pm_rps_work(struct work_struct *work) > > > > mutex_lock(&dev_priv->rps.hw_lock); > > > > - if (pm_iir & GEN6_PM_RP_UP_THRESHOLD) > > + if (pm_iir & GEN6_PM_RP_UP_THRESHOLD) { > > new_delay = dev_priv->rps.cur_delay + 1; > > - else > > + > > + /* > > + * For better performance, jump directly > > + * to RPe if we're below it. > > + */ > > + if (IS_VALLEYVIEW(dev_priv->dev) && > > + dev_priv->rps.cur_delay < dev_priv->rps.rpe_delay) > > + new_delay = dev_priv->rps.rpe_delay; > > + } else > > new_delay = dev_priv->rps.cur_delay - 1; > > > > /* sysfs frequency interfaces may have snuck in while servicing the > > Yeah, seems reasonable. Going to RP1 on other platforms might be a > good approximation of this. > > Reviewed-by: Jesse Barnes <jbarnes at virtuousgeek.org> Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch