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 ]---
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>