On 13-07-17, 18:52, Saravana Kannan wrote:
> On 07/11/2017 10:24 PM, Viresh Kumar wrote:
> >On 11-07-17, 19:24, Saravana Kannan wrote:
> >>Currently, the governor calculates the next frequency, set the current CPU
> >>frequency (policy->cur). It also assumes the current CPU frequency doesn't
> >>ch
On 07/11/2017 10:24 PM, Viresh Kumar wrote:
On 11-07-17, 19:24, Saravana Kannan wrote:
Currently, the governor calculates the next frequency, set the current CPU
frequency (policy->cur). It also assumes the current CPU frequency doesn't
change if the next frequency isn't calculated again and hen
On 07/11/2017 10:24 PM, Viresh Kumar wrote:
On 11-07-17, 19:24, Saravana Kannan wrote:
Currently, the governor calculates the next frequency, set the current CPU
frequency (policy->cur). It also assumes the current CPU frequency doesn't
change if the next frequency isn't calculated again and hen
On 11-07-17, 19:24, Saravana Kannan wrote:
> Currently, the governor calculates the next frequency, set the current CPU
> frequency (policy->cur). It also assumes the current CPU frequency doesn't
> change if the next frequency isn't calculated again and hence caches the
> "current frequency".
>
>
Currently, the governor calculates the next frequency, set the current CPU
frequency (policy->cur). It also assumes the current CPU frequency doesn't
change if the next frequency isn't calculated again and hence caches the
"current frequency".
However, this isn't true when CPU min/max frequency li
5 matches
Mail list logo
