backport mach-msm/cpufreq.c updates from codeaurora msm-3.4
____________
msm: cpufreq: Check cpufreq_frequency_table NULL

This is required during single kernel binary support where one target
supports cpufreq and other target is at the initial stages of bringup.
Since we cannot remove CONFIG_CPU_FREQ_MSM from the config file, but
still support the boot on both of them adding a check for targets where
table is not initialized by the acpu clock driver.

Change-Id: I5f52c246586f0c0378a1b2873a064ef69601e3c6
Signed-off-by: Taniya Das <tdas@codeaurora.org>
_____________
msm: cpufreq: Release cpumask_var_t on all cases

Release cpufreq 'mask' variable when it fails to qualify for changing
cpu frequency.

CRs-fixed: 348827
Change-Id: I90b13aef01f39ee37ae2693fad494c50cb083e27
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
______________
msm: cpufreq: fix a race between hotplug and cpufreq

When msm_cpufreq_target() is called without holding the policy
semaphore, there is a rare chance that the cpu gets hotplugged in
the acpuclk_set_rate. The probability of this issue increases
when cross-calling is used or using interactive governor which
tries to set all cpu frequencies from a single thread.

Add a hotplug notifier and set the device_suspended flag holding
the suspend mutex, when cpu is going down. This mutex is always
held when frequency changes are done.

Change-Id: Ide3aa6927ad60d2512d63761c51bb15117461250
Signed-off-by: Narayanan Gopalakrishnan <nargop@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>

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