diff options
author | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2016-03-21 17:45:24 +0300 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2016-03-23 01:13:36 +0300 |
commit | 0a300767e5882ad5b687966c80f9620aa0871be5 (patch) | |
tree | 9ef2f2783313800279988d99b08129303dae3ee5 /drivers/cpufreq/freq_table.c | |
parent | 1b0289848d5dcea74a6e5115d6c9892b0dbe9c8f (diff) | |
download | linux-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/freq_table.c')
0 files changed, 0 insertions, 0 deletions