cpufreq: interactive: Re-add cpu_online() check on governor start

I believe cpufreq still calls this for all cpus, not just online cpus.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: interactive: Uninitialise sync freq feature

This is too aggressive and will cause CPUs to increase frequencies prematurely.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
Revert "cpufreq: interactive: Allow 1 ms error in above_hispeed_delay comparisons"

This reverts commit ff6af80775231f1dfab8353d0b665718222218bf.

Commit ff6af807 tries to avoid a corner case where frequency is stuck in
hispeed_freq for one additional window. For example, if timer_rate is
20ms, and go_hispeed_delay is 40ms, frequency might be stuck at
hispeed_freq for 60ms due to imprecision in jiffies. Same problem can be
easily solved by making go_hispeed_delay 1ms smaller instead of changing
the code.

Change-Id: Idab7c29ed28374df219210e444454068864d144d
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: Reset to latest CAF 3.10 branch

Between 3.4 branch and 3.10 branch, there were many changes.
Most of which, conflict with my previous changes. Thus, to
simplify things, I've decided to reset changes to 3.10 branch
with appropriate commits reverted to compile with 3.4. I will
probably re-add my changes afterwards.

The new 3.10 changes should make the governor more intelligent
in terms of scaling frequencies and CPU scheduling.

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
cpufreq: interactive: Re-add io_is_busy interface

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
u8500_hotplug: Fix max freq not capped on suspend bug (maybe)

Use a function to update cpufreq policy in order to prevent max freq from being overwritten during rapid suspend and resume.
Merge pull request #4 from TeamCanjica/3.0.101

Update