On Thu, 3 Jul 2014 16:59:17 +0100
Chris Wilson wrote:
> On Thu, Jul 03, 2014 at 08:49:22AM -0700, Jesse Barnes wrote:
> > On Thu, 3 Jul 2014 15:29:26 +0100
> > Chris Wilson wrote:
> >
> > > Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
> > > a very lax downclocking
On Thu, Jul 03, 2014 at 08:49:22AM -0700, Jesse Barnes wrote:
> On Thu, 3 Jul 2014 15:29:26 +0100
> Chris Wilson wrote:
>
> > Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
> > a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
> > downclock if
On Thu, 3 Jul 2014 15:29:26 +0100
Chris Wilson wrote:
> Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
> a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
> downclock if less than 70% busy over 450ms). This causes Baytrail to use
> maximum clo
Baytrail uses the RPS wait-boosting mechanism of Sandybridge+ but also has
a very lax downclocking strategy (upclock if more than 90% busy over 76ms,
downclock if less than 70% busy over 450ms). This causes Baytrail to use
maximum clocks, and for them to stay high, when doing simple tasks such as
s
