tree 34002fa94251769b29737429eb8d62586c336f4d
parent 450c857d1d6cac6e94aa2b317cb0f13a8eb8efce
author Junjie Wu <junjiew@codeaurora.org> 1439852575 -0700
committer Stephen Boyd <sboyd@codeaurora.org> 1490037372 -0700

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>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>