summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/cpufreq_governor.h
diff options
context:
space:
mode:
authorViresh Kumar <viresh.kumar@linaro.org>2016-02-11 15:01:12 +0300
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-03-09 16:41:00 +0300
commit49f18560f8bac5315047edfb673dd13d56cbcbc9 (patch)
tree994561aa9879b8392b460bbf4cd969dacbd7ffe5 /drivers/cpufreq/cpufreq_governor.h
parent69cee7147b4a4ea02085d571cd2d9974d4a4d8d5 (diff)
downloadlinux-49f18560f8bac5315047edfb673dd13d56cbcbc9.tar.xz
cpufreq: Call __cpufreq_governor() with policy->rwsem held
The cpufreq core code is not consistent with respect to invoking __cpufreq_governor() under policy->rwsem. Changing all code to always hold policy->rwsem around __cpufreq_governor() invocations will allow us to remove cpufreq_governor_lock that is used today because we can't guarantee that __cpufreq_governor() isn't executed twice in parallel for the same policy. We should also ensure that policy->rwsem is held across governor state changes. For example, while adding a CPU to the policy in the CPU online path, we need to stop the governor, change policy->cpus, start the governor and then refresh its limits. The complete sequence must be guaranteed to complete without interruptions by concurrent governor state updates. That can be achieved by holding policy->rwsem around those sequences of operations. Also note that after this patch cpufreq_driver->stop_cpu() and ->exit() will get called under policy->rwsem which wasn't the case earlier. That shouldn't have any side effects, though. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Juri Lelli <juri.lelli@arm.com> Tested-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/cpufreq/cpufreq_governor.h')
0 files changed, 0 insertions, 0 deletions