cpuquiet: fix correct bootup sequence
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: added input boost support
fix conflicts

Change-Id: I866832b0f253a11bee1ee3d247c4744d5351079e
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
fix conflicts

Change-Id: I1f6ef0bc8be358e9276a418ff25e2abc2b0b418e
cpuquiet: remove mako_hotplug

Conflicts:
	arch/arm/configs/cyanogenmod_find5_defconfig
fix conflicts

Change-Id: I15429c5edb5ada0cdea32e5ca1d2275c48ddb736
cpufreq: ondemand: Fix store_powersave_bias() race with hotplug

store_powersave_bias() assumes that CPUs will not be taken offline or
brought online while executing its for_each_online_cpu() loops. Fix
this race by blocking hotplug while executing in these loop.

CRs-Fixed: 494407
Change-Id: I0d5520444ec21a8d9b12fb73c06ac8442449fa85
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
cpufreq: ondemand: Fix locking in store_powersave_bias

store_powersave_bias() assumes that dbs_info->cur_policy will
not change while it is executing. If it does, memory corruption
can potentially result. Fix this by acquiring the dbs_lock.

Most noticeably, this resolves timer-related list corruptions
encountered when queue_delayed_work_on() is called from within
store_powersave_bias() while a CPU is being hotplugged in and
out.

CRs-Fixed: 494407
Change-Id: I0fd5cbef6834545274cad9481e574ec50b37b871
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
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>
fix conflicts

Change-Id: I253181e897ded8c5ad07ce4236b805398e61b698
cpuquiet: load_stats - use rq_depth to detect situations with lots of threads but low load