cpuquiet: initial

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c

Conflicts:
	arch/arm/configs/cyanogenmod_find5_defconfig
cpuquiet: fix correct bootup sequence
cpufreq: unified governor and scaling min and max switching
use related_cpus to apply correctly to new online cpus

Conflicts:
	arch/arm/mach-msm/cpufreq.c

Conflicts:
	arch/arm/mach-msm/cpufreq.c
	drivers/cpufreq/cpufreq.c
cpuquiet: governors: Configure WQ for higer priority
cpuquiet: added load based governors

Conflicts:
	arch/arm/configs/cyanogenmod_find5_defconfig
cpuquiet: cpufreq: added screen off core and freq limit support
msm_rq_stats: added support enable load calculation on demand

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
cpuquiet: load_stats: use on demand enabling of load calculation in msm_rq_stats
cpuquiet: added input boost support
cpuquiet: move input boost into kthread
cpuquiet: init input dev with late_initcall

Conflicts:
	drivers/cpuquiet/governor.c
cpuquiet: add some useful logging for governor handling
cpuquiet: fixed threshold sysfs for rq_stats and load_stats
cpuquiet: allow enabling of hotplugging log on runtime
cpuqiet: reset time counters on governor start
input: added input mediator for ordering of input events

Conflicts:
	arch/arm/configs/cyanogenmod_find5_defconfig
	drivers/cpufreq/cpufreq_smartmax.c
cpuquiet: create specific load calculation for load_stats
cpuquiet: remove mako_hotplug

Conflicts:
	arch/arm/configs/cyanogenmod_find5_defconfig
msm: cpufreq: Configure WQ for higer priority

When the workqueue runs at a lower priority, it gets starved by higher
priority threads. Bump the WQ priority to high to ensure cpufreq work
queue gets a fair scheduling chance

Change-Id: I9e994da94a347dceb884e72ec3dd3da468a4471d
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>

Let's try this again.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:
	arch/arm/mach-msm/cpufreq.c

Conflicts:
	arch/arm/mach-msm/cpufreq.c
msm: cpufreq: increase priority of thread that increases frequencies

When the cpufreq governors request for increase in frequency from kworker
threads, there is chance that the kworker thread is cpu starved due to
other high priority threads, leading to undesirable increase in frequency
ramp-up latency. Add the calling thread to SCHED_FIFO policy when
requesting for increase in frequency and restore back to original policy
after ramp-up is completed.

Change-Id: Ie4fa199b7f9087717cb94dfcc2eddea27cc0012b
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/cpufreq.c