msm: cpufreq: Ensure cpufreq change happens on corresponding CPU

Checking the cpus_allowed mask of the current thread before changing the
frequency doesn't guarantee that the rest of the execution will continue on
the same CPU. The only way to guarantee this is to schedule a work on the
specific CPU and also prevent hotplug  of that CPU (already done by
existing code).

Change-Id: I51a02fcc777a47d3c16f2d83c47e96f2c59f7ae6
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/cpufreq.c
msm: cpufreq: Relax constraints on "msm-cpufreq" workqueue

This workqueue is not used in memory reclaim paths, so the
WQ_MEM_RECLAIM flag is not needed. Additionally, there is no
need to restrict the queue to having one in-flight work item.
Remove these constraints.

Change-Id: I9edde40917d3ec885ce061133de20680634321d0
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/cpufreq.c
msm: cpufreq: Add support for CPU clocks and msm-cpufreq device

Add support for using clock APIs to do CPU/L2 frequency scaling. When clock
APIs are used to control CPU/L2 frequencies, the cpufreq driver must handle
the CPU -> L2 -> DDR bandwidth voting. Use a msm-cpufreq device to provide
the per SoC list of CPU frequencies and their L2/DDR bandwidth mapping
information.

If CPU/L2 clocks are not available, fallback to using acpuclock APIs. We
eventually want to remove the use of non-standard acpuclock APIs.

Change-Id: I2c4e2c3967d73e8cdbd9833f3cb36f3d75e27b4a
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/cpufreq.c
msm: cpufreq: Initialize cpufreq driver early at boot

MSM cpufreq driver registering with the CPUFreq framework during
late_initcall() may cause the device to be available a few seconds after
the clock driver is ready for changing frequency. This could be bad for
boot and/or thermal performance, since the cpu will continue to boot at
whatever frequency the bootloaders set it to.

Initialize cpufreq driver as part of device_initcalL() but only after
all the clock drivers have had a chance to initialize their devices.

Change-Id: Iaa4867108f59a368ee5b511d35ea2e8e219d39d3
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/Makefile
msm: cpufreq: Update frequency index

A deprecated api can be used to limit the minimum and maximum cpu speeds.
Another driver temporarily needs to switch back to this api, instead of
using the new version. Make this api functional again by ensuring a stale
value is updated properly.

Change-Id: Ia63772e43ec534cf2bb58e7627a87315dae5d891
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>

Conflicts:

	arch/arm/mach-msm/cpufreq.c
msm: acpuclock-krait: Enable HFPLL for init only if switching to it

The existing code left the HFPLL enabled in hfpll_init(), even if
the CPU was detected to be at a non-HFPLL rate. Correct this for
power savings between when hfpll_init() and the first runtime CPU
frequency switch happen. This also ensure votes for HFPLL
regulators are not left unnecessarily asserted.

Change-Id: Iaca5dc7e4769bdbd494d669726ba9b500256f793
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
more CPU freq changes from AOSP'