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

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
cpuquiet: create specific load calculation for load_stats
cpuquiet: remove mako_hotplug

Conflicts:
	arch/arm/configs/cyanogenmod_find5_defconfig
cpufreq: unified governor and scaling min and max switching use related_cpus to apply correctly to new online cpus
         this removes temp voltage control which will be implementade later again
Conflicts:
	arch/arm/mach-msm/cpufreq.c
	drivers/cpufreq/cpufreq.c

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

Fix store_powersave_bias() race with hotplug
switch to m7 ondemand

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>

Conflicts:
	drivers/cpufreq/cpufreq_ondemand.c
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: 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
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>
change scheduler params for input boost threads

Conflicts:
	drivers/cpufreq/cpufreq_smartmax.c

Conflicts:
	drivers/cpufreq/cpufreq_smartmax.c
cpuquiet: load_stats - use rq_depth to detect situations with lots of threads but low load
cpuquiet: always respect max cpus restriction
cpuquiet: load_stats - rq_depth fine tuning