qcom-cpufreq: Move the enabling of the CPU/L2 clocks to CPU_STARTING

It is a requirement of PLLs in MSM SoCs that the PLL power
supplies be enabled while the PLL is running. If the PLL is
locked and outputs enabled, turning off the regulator(s)
supplying the PLL will cause the PLL to enter an unpredictable
state.

Now in the CPU_UP_PREPARE notifier, the CPU clocks are prepared
and enabled, causing the source HFPLLs to also turn on. Note
that the CPU isn't clocked yet. It is possible that execution is
pre-empted and the CPU running the notifier enters power
collapse. If all other CPUs also enter power collapse, then it
is possible for an RPM notification to go out, allowing the RPM
to transition the Apps processor to its sleep set. This can
result in the HFPLL supplies being turned off while the HFPLL is
running, violating the requirement mentioned above. Once the CPU
is unclamped, the CPU is effectively unclocked, due to the HFPLL
being in an unknown state.

There is a check that is enabled in the PM code's CPU_UP_PREPARE
notifier callback. This check ensures that the problematic RPM
notification cannot occur until the core that is being brought
online also enters power collapse. However, there is no ordering
guarantee between that PM's hotplug notifier callback's execution
and the cpufreq hotplug notifier callback's execution. This
ordering depends on program link order, which is unreliable.

It is necessary to ensure that once the HFPLL is enabled, the
RPM cannot transition apps to its sleep set. Move the enabling
of the CPU clocks to the CPU_STARTING notifier, which runs on
the CPU bring brought online. The CPU_STARTING notifier is
guaranteed to run after the CPU_UP_PREPARE notifier, which
implies that the aforementioned do-not-notify-rpm check is
executed *before* the HFPLL is enabled. Therefore even if all
cores enter power collapse after the HFPLL is enabled, the
HFPLL supplies are guaranteed to stay on, or the CPU clock
is switched to the safe source and the HFPLL is turned off.

CRs-Fixed: 622738
Change-Id: I136841405806c07e755919859e649ded0c719abb
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>

michael1900: fix a cherry-pick error

Conflicts:
	arch/arm/mach-msm/cpufreq.c
qcom-cpufreq: Block hotplug until cpufreq is ready

Hotplug before qcom-cpufreq is ready could lead to inconsistent CPU
clock state. Block hotplug by returning NOTIFY_BAD in hotplug callback
until qcom-cpufreq is probed.

Change-Id: I72a2f98c083c9b21b95ecafdb5a5be7a7682e842
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
qcom-cpufreq: Fix hotplug blocking logic

Change 2b63b10 qcom-cpufreq: Block hotplug until cpufreq is ready
intended to block hotplug until qcom-cpufreq driver has got all
clocks. However, its implementation still leaves a small window when
CPU 0 has got its clock but others haven't. If a hotplug happens on
another CPU that doesn't have its clock pointer, refcount of that CPU
clock will again be wrong.

Fix the issue by introducing a ready flag.

Change-Id: I1e05b063b0584088f717b82709a3f1d55bc6561b
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
qcom-cpufreq: Fix frequency table registration

CPUfreq device is the provider of CPU frequency table, and
it should always keep track of freq tables for every CPU itself.
cpufreq_frequency_get_table() is an API for frequency table user.
qcom-cpufreq should not use this API to obtain CPU freq table in
the init function. Otherwise, the following sequence will lead to init
failure.

Assume CPU 0 and 1 are under control of same policy and online. Say
policy->cpu is CPU 0.

1) Hot unplug CPU0
   update_policy_cpu() will transfer ownership of policy to CPU1
   cpufreq_frequency_table_update_policy_cpu() is called during
   the process to set CPU1's freq table to be the same as CPU0's freq
   table. CPU0's freq table is now NULL.
2) Hot unplug CPU1
   All CPUs in policy are now offline.
3) Hot plug in CPU0
   cpufreq_driver->init() is called for initialization. If this init
   function calls cpufreq_frequency_get_table() on CPU0, the result
   will be NULL.

Current qcom-cpufreq checks return value of cpufreq_frequency_get_table()
and returns an error in init.

Remove the usage of cpufreq_frequency_get_table() and fill in frequency
table for policy->cpu in msm_cpufreq_init().

Change-Id: I2d41af776938c31b4444c9f280a341dd1bed1548
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
msm: pm: Fix cpu collapse timeout

Looks like caf mismerged. This may fix the following warning:

<4>[  124.983957] ------------[ cut here ]------------
<4>[  124.984381] WARNING: at arch/arm/mach-msm/msm-pm.c:837 msm_pm_wait_cpu_shu
tdown+0x9c/0xb0()
<4>[  124.984661] CPU2 didn't collapse in 2 ms
<4>[  124.984869] [<c010e10c>] (unwind_backtrace+0x0/0x144) from [<c0a1c68c>] (d
ump_stack+0x20/0x24)
<4>[  124.985170] [<c0a1c68c>] (dump_stack+0x20/0x24) from [<c019ab44>] (warn_sl
owpath_common+0x58/0x70)
<4>[  124.985464] [<c019ab44>] (warn_slowpath_common+0x58/0x70) from [<c019abd8>
] (warn_slowpath_fmt+0x40/0x48)
<4>[  124.985943] [<c019abd8>] (warn_slowpath_fmt+0x40/0x48) from [<c0179d30>] (
msm_pm_wait_cpu_shutdown+0x9c/0xb0)
<4>[  124.986287] [<c0179d30>] (msm_pm_wait_cpu_shutdown+0x9c/0xb0) from [<c0126
750>] (platform_cpu_kill+0x38/0x48)
<4>[  124.986591] [<c0126750>] (platform_cpu_kill+0x38/0x48) from [<c010c6fc>] (
__cpu_die+0x4c/0x98)
<4>[  124.986778] [<c010c6fc>] (__cpu_die+0x4c/0x98) from [<c09ee9cc>] (_cpu_dow
n+0xf8/0x2e0)
<4>[  124.987074] [<c09ee9cc>] (_cpu_down+0xf8/0x2e0) from [<c09eec58>] (cpu_dow
n+0x34/0x50)
<4>[  124.987383] [<c09eec58>] (cpu_down+0x34/0x50) from [<c0194250>] (cpu_down_
work+0xc4/0xd8)
<4>[  124.987564] [<c0194250>] (cpu_down_work+0xc4/0xd8) from [<c01b4e44>] (proc
ess_one_work+0x178/0x4f4)
<4>[  124.987861] [<c01b4e44>] (process_one_work+0x178/0x4f4) from [<c01b5540>]
(worker_thread+0x174/0x448)
<4>[  124.988152] [<c01b5540>] (worker_thread+0x174/0x448) from [<c01bb8ac>] (kt
hread+0xb4/0xc0)
<4>[  124.988450] [<c01bb8ac>] (kthread+0xb4/0xc0) from [<c0108060>] (kernel_thr
ead_exit+0x0/0x8)
<4>[  124.988725] ---[ end trace 77427e632785e345 ]---