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>
(cherry picked from commit 56f5a6de7f2ab48ed0538da727ad52673fb801a2)

Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
msm: cpufreq: Remove cross-calling limitation

Remove cross-calling limitations imposed by cpufreq. Clock drivers
and SPM driver now allow changing of frequencies from any core. Using
cpus_allowed mask to check for core affinity works well with workqueues
but do not port so well when the core requesting frequency change is a
kthread with the flag PF_TASK_BOUND not set.

Change-Id: Iab664ce8657780814440a11dff77cc925df597f8
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
(cherry picked from commit be01a17afb6b6e85456217caa1ac11eb0b6674e1)
(cherry picked from commit bd97cdfeb87eda0373721baaea744b02a27822f5)
msm: cpufreq: Implement suspend/resume for cpufreq driver

Cpufreq suspend variable get's updated in kernel pm notifier
callback which gets called in process context. This will create
window where cpufreq governor may try to change the frequency
before suspend variable is updated while resume.

Define suspend/resume for cpufreq driver to update suspend variable
in atomic context.

Don't update the policy->cur upon cpufreq driver failure.

CRs-fixed: 423791
Change-Id: Id78705f5c3b8bf801c6253e9362299280903769f
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Revert "msm: cpufreq: Remove cross-calling limitation"

This reverts commit be01a17afb6b6e85456217caa1ac11eb0b6674e1.

Re-introduce cross calling in cpufreq to prevent race conditions in the
hardware when changing PLLs.

A core could be in retention, while another core, could try and set the
frequency of the core in retention, causing a change in PLL and when the
core exits retention, the PLL mismatch could hang the SPM state machine.

Change-Id: I99b454a0f146652f2d8a369f79f6d35748160dcb
Signed-off-by: Praveen Chidambaram <pchidamb@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
Revert "cpufreq: fix interactive bug during hotplug."

This reverts commit c5d82e843dc210898d67edc3362cfece50016c77.