summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
diff options
context:
space:
mode:
authorJunjie Wu <junjiew@codeaurora.org>2015-08-17 16:02:55 -0700
committerDavid Keitel <dkeitel@codeaurora.org>2016-03-23 20:03:26 -0700
commit2043c3df36a7743db4fefbd38ceac04a7e1e8df6 (patch)
tree3046876f4c670cd521d15a6d679ab9ab0f302780 /drivers/cpufreq
parent5e3baefe8ef7fe0cdf3a83c7ff7fe67863726a90 (diff)
cpufreq: interactive: Use target_freq for load calculation
With per-policy timer implemented, there is no need to use policy->cur in load calculation and delay enforcement. Each CPUs in policy will naturally get the cluster frequency in target_freq. Using policy->cur has side effects if second evaluation comes before frequency switch requested by first evaluation is finished. When that occurs, the second evalution could enforce delays incorrectly based on the stale policy->cur while the timestamps have been updated when target_freq is updated by earlier evaluation. For example, assume current frequency is 1.5GHz, hispeed_freq is 1GHz. First evaluation drops target_freq to 500MHz. It also resets hispeed_validate_time. While frequency switch is still underway and policy->cur is still 1.5GHz, a second evaluation happens, and the evaluation result is 1GHz. Current evaluation would enforce hispeed_delay for 1.5GHz using the updated hispeed_validate_time and thus incorrectly delaying the ramp up to 1GHz. Change from policy->cur to target_freq in load calculation and delay enforcement. Change-Id: I416e1d524e14b2c082944b88678eb3105bd70d88 Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Diffstat (limited to 'drivers/cpufreq')
-rw-r--r--drivers/cpufreq/cpufreq_interactive.c10
1 files changed, 5 insertions, 5 deletions
diff --git a/drivers/cpufreq/cpufreq_interactive.c b/drivers/cpufreq/cpufreq_interactive.c
index c18c20d5fe54..4d091383dbda 100644
--- a/drivers/cpufreq/cpufreq_interactive.c
+++ b/drivers/cpufreq/cpufreq_interactive.c
@@ -508,11 +508,11 @@ static void __cpufreq_interactive_timer(unsigned long data, bool is_notif)
}
spin_lock_irqsave(&ppol->target_freq_lock, flags);
- cpu_load = loadadjfreq / ppol->policy->cur;
+ cpu_load = loadadjfreq / ppol->target_freq;
tunables->boosted = tunables->boost_val || now < tunables->boostpulse_endtime;
if (cpu_load >= tunables->go_hispeed_load || tunables->boosted) {
- if (ppol->policy->cur < tunables->hispeed_freq &&
+ if (ppol->target_freq < tunables->hispeed_freq &&
(!tunables->fast_ramp_up || cpu_load <= MAX_LOCAL_LOAD)) {
new_freq = tunables->hispeed_freq;
} else {
@@ -529,10 +529,10 @@ static void __cpufreq_interactive_timer(unsigned long data, bool is_notif)
}
if ((!tunables->fast_ramp_up || cpu_load <= MAX_LOCAL_LOAD) &&
- ppol->policy->cur >= tunables->hispeed_freq &&
- new_freq > ppol->policy->cur &&
+ ppol->target_freq >= tunables->hispeed_freq &&
+ new_freq > ppol->target_freq &&
now - ppol->hispeed_validate_time <
- freq_to_above_hispeed_delay(tunables, ppol->policy->cur)) {
+ freq_to_above_hispeed_delay(tunables, ppol->target_freq)) {
trace_cpufreq_interactive_notyet(
max_cpu, cpu_load, ppol->target_freq,
ppol->policy->cur, new_freq);