summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/omap-cpufreq.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-03-21 17:45:24 +0300
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-03-23 01:13:36 +0300
commit0a300767e5882ad5b687966c80f9620aa0871be5 (patch)
tree9ef2f2783313800279988d99b08129303dae3ee5 /drivers/cpufreq/omap-cpufreq.c
parent1b0289848d5dcea74a6e5115d6c9892b0dbe9c8f (diff)
downloadlinux-0a300767e5882ad5b687966c80f9620aa0871be5.tar.xz
cpufreq: Introduce cpufreq_start_governor()
Starting a governor in cpufreq always follows the same pattern involving two calls to cpufreq_governor(), one with the event argument set to CPUFREQ_GOV_START and one with that argument set to CPUFREQ_GOV_LIMITS. Introduce cpufreq_start_governor() that will carry out those two operations and make all places where governors are started use it. That slightly modifies the behavior of cpufreq_set_policy() which now also will go back to the old governor if the second call to cpufreq_governor() (the one with event equal to CPUFREQ_GOV_LIMITS) fails, but that really is how it should work in the first place. Also cpufreq_resume() will now pring an error message if the CPUFREQ_GOV_LIMITS call to cpufreq_governor() fails, but that makes it follow cpufreq_add_policy_cpu() and cpufreq_offline() in that respect. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Diffstat (limited to 'drivers/cpufreq/omap-cpufreq.c')
0 files changed, 0 insertions, 0 deletions