tree cbeb60deff8d40c04ce669ba3afefeab67791fc4
parent 26fa2dd9c454687cde33672a2d7a8108b7ac0604
author Saravana Kannan <skannan@codeaurora.org> 1408066185 -0700
committer Stephen Boyd <sboyd@codeaurora.org> 1490037373 -0700

cpufreq: interactive: Compute target freq independent of policy min/max

When the existing code computes the target frequency, it limits the target
frequency to be within policy min/max. It does this to make sure the
governor doesn't set the CPU frequency to something outside the policy
min/max limits.

The problem with this is that when the limits are removed, the CPU
frequency takes time to catch up with the real load because the governor
needs to wait for the next recalculation and even when the recalculated
frequency is correct, hysteresis might be applied.

In reality, the load might have already been consistent enough to exceeded
the hysteresis criteria and cause a frequency change if it wasn't for the
policy limits. However, since the policy min/max limits the target
frequency from reflecting the increased need, the hysteresis criteria
doesn't get a chance to expire.

Since the CPUfreq framework already takes care of limiting the governor's
request to be within the policy min/max limits before it sets the CPU
frequency, there's no need to limit the computation of target frequency to
be within policy min/max.

That way, when limits are removed, we can use the current target frequency
as is and immediately jump to a CPU frequency that's appropriate for the
current load.

Change-Id: Idc02359f6ff91530ff69de8edd8a25c275642099
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>