cpufreq [1]: unified governor and scaling min and max switching
governor scaling_min_freq and scaling_max_freq will be populated to all online cpus immediately

Conflicts:
	drivers/cpufreq/cpufreq.c
cpufreq [2]: 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
cpufreq: Retain only online cpus in managed_policy->cpus

cpufreq's handling of cpu online event can incorrectly initialize
managed_policy->cpus to include offline cpus. This causes cpufreq
governors to include offline cpus in their idle time computation, which
causes frequency to shoot up beyond normal levels (on systems where 2 or
more cpus need to be synchronized wrt frequency change).

This frequency shootup was not seen prior to commit 21111be8 which
changed idle time accounting for offline cpus. Prior to commit 21111be8,
idle time statistics for offline cpus would include their offline time
as well. Post commit 21111be8, offline time is not included in a cpu's
idle time statistics.

As a result, ondemand (or other cpufreq) governors would see unchanged
idle time for offline cpus, causing them to interpret those (offline)
cpus as 100% busy, which is wrong.

This patch fixes the issue by modifying cpufreq's hotplug handling to
retain only online cpus in managed_policy->cpus field. cpufreq governors
would then skip such offline cpus from idle time calculations.

Change-Id: Id2eba8c0ec3367609369b2e42a4e1386ff2e7ab5
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
cpufreq: block hotplugging during multi-cpu operations
cpufreq: dont apply multi-cpu values if not changed
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
change scheduler params for input boost threads

Conflicts:
	drivers/cpufreq/cpufreq_smartmax.c
msm: cpufreq: Always update frequency limits when core is online

Remove condition in msm_cpufreq_init() so that when cpu is set to
online, it will call set_cpu_freq() and update the frequency limits.

CRs-Fixed: 462816
Change-Id: I40ac33c9cb4b42590a83f9d61b74f23379f5642e
Signed-off-by: Jennifer Liu <chihning@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/cpufreq.c
msm: cpufreq: Break out early if target frequency is the same as the current

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
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: when breaking out early set return value to good