cpufreq: interactive: import from zwliew kernel

until https://github.com/zwliew/Samsung_STE_Kernel/commit/e009503b4b4ddae2f8e0b1dbce4b7cdc6cdef5d4

Change-Id: I8df94bdc8cfb66aab5f01c2c6dce66de1fd78413
cpufreq: interactive: backport changes to linux 3.0

Change-Id: I627d80ff368a6b0503f7ccecb24044de0f98f41a
cpufreq: interactive: add early suspend hotplugging

Change-Id: I03032f6ead0e7b8b022d7d730752e076adc51050
Revert "cpufreq: interactive: remove input_boost handling"
since we removed powerhal, which is a pretty big part of google's so-called project butter, it's time to bring this back.

This reverts commit android/kernel_common@4e27eb5.

Change-Id: I438a7694852b40566891975054f4095ea8f09680
cpufreq: interactive: boost to 400mhz on input event

Change-Id: I852f004de570b532d81f88ec8a28ff68f9989a78
cpufreq: interactive: enable input boost

Change-Id: Ibe529411517654e67538200140e6b9af1f30f52a
cpufreq: interactive: allow configuration of input boost frequency

Change-Id: I50ce60fb186e6caa63c8575b5fea84a319c7db16
cpufreq: interactive: tune for better performance

these tunables provide good performance while battery is not lacking too much either.

Change-Id: I4c4489fbe9511709c6bdc95407e59c5900096be6
cpufreq: interactive: boost to input_boost_freq instead of hispeed

Change-Id: I98a5e721e6dcbb890c41c12982d7d32a6a9a2e36
cpufreq: interactive: specify input boost duration using boost_duration_val

Change-Id: I7fefa49ac21553c959de7eefbc9774aa55fddea3
cpufreq: interactive: cap max freq to 400mhz on screen off

Change-Id: Id314693b182c28caa051beff971e3f583b2de972
cpufreq: interactive: allow configuration of screen_off_max_freq
cpufreq: interactive: Initialize spinlocks

These were missing in commit 8fbac318173082918312d6a4ceacf63376797c52,
"cpufreq: interactive: Use frequency dependent per cpu timings".
cpufreq: interactive: prevents the frequency to directly raise above the hispeed_freq from a lower frequency.

When the load was below go_hispeed_load, there is a possibility that
choose_freq() would return a frequency which would be higher than the
hispeed_freq. According to the policy we should first jump to the
hispeed_freq, stay there for above_hispeed_delay and then be allowed to
raise higher than that.

Added a check to prevent the frequency to be directly raised to
something higher than the hispeed_freq.

Change-Id: Icda5d848dd9beadcc18835082ddf269732c75bd0
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>

[modified to fit linux 3.0 and previous driver changes]