On 11-02-16, 10:48, Rafael J. Wysocki wrote:
> On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar wrote:
> > Also note that cpufreq_driver->stop_cpu() and ->exit() can get called
> > while policy->rwsem is held. That shouldn't have any side effects
> > though.
>
> The last paragraph is unclear.
>
>
On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar wrote:
> This isn't followed properly by all parts of the core code, some follow
> it, whereas others don't.
"The cpufreq core code is not consistent with respect to invoking
__cpufreq_governor() under policy->rwsem."
> Enforcing it will also enable
On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar wrote:
> This isn't followed properly by all parts of the core code, some follow
> it, whereas others don't.
"The cpufreq core code is not consistent with respect to invoking
__cpufreq_governor() under policy->rwsem."
>
On 11-02-16, 10:48, Rafael J. Wysocki wrote:
> On Tue, Feb 9, 2016 at 4:46 AM, Viresh Kumar wrote:
> > Also note that cpufreq_driver->stop_cpu() and ->exit() can get called
> > while policy->rwsem is held. That shouldn't have any side effects
> > though.
>
> The last
This isn't followed properly by all parts of the core code, some follow
it, whereas others don't.
Enforcing it will also enable us to remove cpufreq_governor_lock, that
is used today because we can't guarantee that __cpufreq_governor() isn't
executed in parallel.
We should also ensure that the
This isn't followed properly by all parts of the core code, some follow
it, whereas others don't.
Enforcing it will also enable us to remove cpufreq_governor_lock, that
is used today because we can't guarantee that __cpufreq_governor() isn't
executed in parallel.
We should also ensure that the
6 matches
Mail list logo