summaryrefslogtreecommitdiff
path: root/drivers/cpufreq/cpufreq-dt-platdev.c
diff options
context:
space:
mode:
authorSai Gurrappadi <sgurrappadi@nvidia.com>2016-04-29 21:44:37 (GMT)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-05-04 23:30:38 (GMT)
commite43e94c1eda76dabd686ddf6f7825f54d747b310 (patch)
tree9668779f7f97f3fbd76e3e9a9876be69bfc74fe8 /drivers/cpufreq/cpufreq-dt-platdev.c
parent9f123def55d3fd0d76d49e0009419bcb994f6f1f (diff)
downloadlinux-e43e94c1eda76dabd686ddf6f7825f54d747b310.tar.xz
cpufreq: Fix GOV_LIMITS handling for the userspace governor
Currently, the userspace governor only updates frequency on GOV_LIMITS if policy->cur falls outside policy->{min/max}. However, it is also necessary to update current frequency on GOV_LIMITS to match the user requested value if it can be achieved within the new policy->{max/min}. This was previously the behaviour in the governor until commit d1922f0 ("cpufreq: Simplify userspace governor") which incorrectly assumed that policy->cur == user requested frequency via scaling_setspeed. This won't be true if the user requested frequency falls outside policy->{min/max}. Ex: a temporary thermal cap throttled the user requested frequency. Fix this by storing the user requested frequency in a seperate variable. The governor will then try to achieve this request on every GOV_LIMITS change. Fixes: d1922f02562f (cpufreq: Simplify userspace governor) Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers/cpufreq/cpufreq-dt-platdev.c')
0 files changed, 0 insertions, 0 deletions