When we reach the user's RPS limits, stop requesting an adjustment. Even
though we will clamp the requested frequency later, we rely on interrupt
masking to disable further adjustments in the same direction. Even
though it is unlikely (one scenario is a bug in the driver, another is
careful manipulation through the uAPI) if we keep exponentially
increasing the adjustment value, it will wrap and cause a negative
adjustment.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484884104-28134-2-git-send-email-sagar.a.kamble@intel.com
adj *= 2;
else /* CHV needs even encode values */
adj = IS_CHERRYVIEW(dev_priv) ? 2 : 1;
+
+ if (new_delay >= dev_priv->rps.max_freq_softlimit)
+ adj = 0;
/*
* For better performance, jump directly
* to RPe if we're below it.
adj *= 2;
else /* CHV needs even encode values */
adj = IS_CHERRYVIEW(dev_priv) ? -2 : -1;
+
+ if (new_delay <= dev_priv->rps.min_freq_softlimit)
+ adj = 0;
} else { /* unknown event */
adj = 0;
}