cpufreq: add intellidemand governor
cpufreq/kgsl: activate and adjust intellidemand for new kernel
cpufreq/kgsl/config: add intellidemand governor
cpufreq: Intellidemand - enable smart core management while screen on

Conflicts:
	arch/arm/mach-msm/cpufreq.c
intellidemand: adjust browsing state detection to be smarter

lower active state time from 5 mins to 3 mins
bump max frequency limit from 1.08GHz to 1.13GHz
cpufreq: intellidemand - make active/inactive max freqs tunable via sysfs
cpufreq: intellidemand - make debug message to reflect actual frequencies
CPUfreq ondemand: update sampling rate without waiting for next sampling

When a new sampling rate is shorter than the current one, (e.g., 1 sec
--> 10 ms) regardless how short the new one is, the current ondemand
mechanism wait for the previously set timer to be expired.

For example, if the user has just expressed that the sampling rate
should be 10 ms from now and the previous was 1000 ms, the new rate may
become effective 999 ms later, which could be not acceptable for the
user if the user has intended to speed up sampling because the system is
expected to react to CPU load fluctuation quickly from __now__.

In order to address this issue, we need to cancel the previously set
timer (schedule_delayed_work) and reset the timer if resetting timer is
expected to trigger the delayed_work ealier.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
intellidemand: tuning - increase browsing detection threshold
intellidemand: dynamic change of sampling rate based on screen on/off

using early_suspend/late_resume drivers to 2x min_sampling rate while screen
is off to reduce frequency transitions in hope to reduce power consumption
further
CPUfreq: update sampling rate without waiting for next sampling

When a new sampling rate is shorter than the current one, (e.g., 1 sec
--> 10 ms) regardless how short the new one is, the current ondemand
mechanism wait for the previously set timer to be expired.

For example, if the user has just expressed that the sampling rate
should be 10 ms from now and the previous was 1000 ms, the new rate may
become effective 999 ms later, which could be not acceptable for the
user if the user has intended to speed up sampling because the system is
expected to react to CPU load fluctuation quickly from __now__.

In order to address this issue, we need to cancel the previously set
timer (schedule_delayed_work) and reset the timer if resetting timer is
expected to trigger the delayed_work ealier.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
modified for intellidemand by faux123
intellidemand: add mutex protection around sampling rate change
msm: cpufreq: Fix store_powersave_bias to account for sync' CPUs.

Current code assumes that all online CPUs runs their own timers to
collect CPU samples for demand based switching (dbs). But in case of
synchronous CPUs ondemand governor registers only one timer at init
time because both CPUs are accounted in the same timer call. Hence
trying to restart/cancel dbs timers for all online CPUs is not legal
for these CPUs. This change fixes above function to restart/cancel
timers only once for group of synchronous CPUs.

CRs-Fixed: 348502
Signed-off-by: Krishna Vanka <kvanka@codeaurora.org>
(cherry picked from commit 3d5b6bd91f28ecbc90f233f3a2854e4496d619bc)

Change-Id: Ia69841655929f5e5306ca7e1865d7b0125cd8ead
Signed-off-by: Sunil Joseph <sunilj@codeaurora.org>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
msm/cpufreq/intellidemand: Fix store_powersave_bias to account for sync' CPUs.

Current code assumes that all online CPUs runs their own timers to
collect CPU samples for demand based switching (dbs). But in case of
synchronous CPUs ondemand governor registers only one timer at init
time because both CPUs are accounted in the same timer call. Hence
trying to restart/cancel dbs timers for all online CPUs is not legal
for these CPUs. This change fixes above function to restart/cancel
timers only once for group of synchronous CPUs.

modified from CAF refrerence for intellidemand by faux123
cpufreq/ondemand: add and enable dbs_input_event

this allows for more responsive UI based on touch inputs similar to
interactive boosts from Google
cpufreq/intellidemand: add and enable dbs_input_event

this allows for more responsive UI based on touch inputs similar to
interactive boosts from Google
cpufreq: fix compilation warnings
board/msm-cpufreq: add compile time CPU min / max adjustments (faux123)
board/cpufreq: add early suspend/late resume drivers

-- cap max screen off freq
-- hotplug 2nd core when screen is off
inspired by Colin Cross's code for Galaxy Nexus kernel and Ricardo Cerqueira
for being first to port to MSM platform

Conflicts:
	arch/arm/mach-msm/cpufreq.c
intellidemand: cherry-pick clean up...