On Tue, 25 Jun 2013 21:38:11 +0300 [email protected] wrote: > From: Ville Syrjälä <[email protected]> > > 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ä <[email protected]> > --- > 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 <[email protected]> -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
