thermal: cpu_cooling: Update always cpufreq policy with thermal constraints
authorYadwinder Singh Brar <yadi.brar@samsung.com>
Fri, 7 Nov 2014 13:42:29 +0000 (19:12 +0530)
committerEduardo Valentin <edubezval@gmail.com>
Thu, 20 Nov 2014 22:17:11 +0000 (18:17 -0400)
commit2dcd851fe4b4fe60c2f8520bf7668d7e9b2dd76b
treee420c0d47716705eb3c76663f524938918fbb2d3
parentfc14f9c1272f62c3e8d01300f52467c0d9af50f9
thermal: cpu_cooling: Update always cpufreq policy with thermal constraints

Existing code updates cupfreq policy only while executing
cpufreq_apply_cooling() function (i.e. when notify_device != NOTIFY_INVALID).
It doesn't apply constraints when cpufreq policy update happens from any other
place but it should update the cpufreq policy with thermal constraints every
time when there is a cpufreq policy update, to keep state of
cpufreq_cooling_device and max_feq of cpufreq policy in sync. For instance
while resuming cpufreq updates cpufreq_policy and it restores default
policy->usr_policy values irrespective of cooling device's cpufreq_state since
notification gets missed because (notify_device == NOTIFY_INVALID).
Another problem, is that userspace is able to change max_freq irrespective of
cooling device's state, as notification gets missed.

This patch modifies code to maintain a global cpufreq_dev_list and applies
constraints of all matching cooling devices for policy's cpu when there is any
policy update(ends up applying the lowest max_freq among the matching cpu
cooling devices).

This patch also removes redundant check (max_freq > policy->user_policy.max),
as cpufreq framework takes care of user_policy constraints already where ever
required, otherwise its causing an issue while increasing max_freq in normal
scenerio as it restores max_freq with policy->user_policy.max which is old
(smaller) value.

Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
drivers/thermal/cpu_cooling.c