Revert "Update intellidemand to Faux's one.."

This reverts commit 00153ceb9cfa51cf9a6899be7031337b7aedbffe.
Revert "cpufreq_ondemand.c: Tuning"

This reverts commit 615e9fbd1e815a54acebb864fe3091cb3bbe78e6.
Revert "cpufreq: ondemand: set boostfreq to 700Mhz"

This reverts commit bf37d0aaea955c640418e19ddded18e735e94d01.
Revert "cpufreq: ondemand: add boostpulse interface"

This reverts commit 51a84c5fca9716de40574bf2fa0b329ba9474efe.
cpufreq: add ondemand two-phase scheduling

two phase scheduling will provide further power savings to ondemand
scheduler

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: tweak ondemand defaults
cpufreq/ondemand: add early suspend/late resume drivers and tune 2-phase

add early suspend/late resume drivers to hot plug/unplug 2nd cpu depending
screen on/off to further reduce power consumption during screen off.

tuned two-phase to use 80% of max freq.
cpufreq/ondemand: further tune two-phase ondemand governor

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
nohz: Fix update_ts_time_stat idle accounting

update_ts_time_stat currently updates idle time even if we are in
iowait loop at the moment. The only real users of the idle counter
(via get_cpu_idle_time_us) are CPU governors and they expect to get
cumulative time for both idle and iowait times.
The value (idle_sleeptime) is also printed to userspace by print_cpu
but it prints both idle and iowait times so the idle part is misleading.

Let's clean this up and fix update_ts_time_stat to account both counters
properly and update consumers of idle to consider iowait time as well.
If we do this we might use get_cpu_{idle,iowait}_time_us from other
contexts as well and we will get expected values.

Signed-off-by: Michal Hocko <mhocko@suse.cz>
Cc: Dave Jones <davej@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Link: http://lkml.kernel.org/r/e9c909c221a8da402c4da07e4cd968c3218f8eb1.1314172057.git.mhocko@suse.cz
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
cpufreq: update early suspend level to EARLY_SUSPEND_LEVEL_STOP_DRAWING

conservative, ondemand and interactive governors, update their early suspend
level from EARLY_SUSPEND_LEVEL_BLANK_SCREEN to
EARLY_SUSPEND_LEVEL_STOP_DRAWING to avoid race conditions with rapid screen
on/off via gpio

Conflicts:

	drivers/cpufreq/cpufreq_conservative.c
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: hotplugging via EARLY_SUSPEND_LEVEL_BLANK_SCREEN + 25

revert previous hotplug based on EARLY_SUSPEND_LEVEL_STOP_DRAWING which
lead to another race condition causing instability

Conflicts:

	drivers/cpufreq/cpufreq_interactive.c
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>
cpufreq: Ondemand - 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
Config: Add Ondemand2 phase again
derp