support for gcc 4.9
msm: acpuclock: Fix acpuclk_get_rate

acpuclk_get_rate() is broken, quick fix it by returning msm_cpufreq_get_freq
to avoid regressions.
msm: cpufreq: Don't try to call acpuclk_get_rate()

acpuclk_get_rate() is broken, so don't even try to call it as it will
invoke clk_get_rate() anyway.
msm: cpufreq: Avoid NULL clock pointer references

The MSM CPUfreq driver defines a mapping from cpu number to clock
pointer. On SOCs with synchronous cpus, only the mapping for cpu#0
is defined, even though there may be more than 1 cpu. Handle this
case by skipping certain unnecessary initialization steps for SOCs
with synchronous cpus.

Conflicts:
	arch/arm/mach-msm/cpufreq.c

Change-Id: Iaeba7a8615e3cb7da2c725250db92595450bfa46
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
msm: cpufreq: Correct synchronous cpu logic

Fix an incorrect patch conflict resolution which results in failing to
initialize the cpufreq policy correctly when using an old acpuclock driver
version.

Change-Id: If8743a2608e720258ebc710718c3041144c00f10
CRs-fixed: 612226
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
msm: cpufreq: Fix msm_cpufreq_get_freq() for sync CPUs

When CPUs are in sync, only CPU0 has a non-NULL cpu_clk. clk_get_rate()
on other cpu_clk will return 0. msm_cpufreq_get_freq() is used in multiple
places in cpufreq framework to determine current hardware frequency.

Fix msm_cpufreq_get_freq() to return the right hardware frequency for
systems with synchronous CPUs.

Change-Id: I6a880764ad51fa9a257a328798b38d574750686a
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
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>
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>

Conflicts:
	arch/arm/mach-msm/cpufreq.c
cpufreq: cpu-boost: Use hotplug thread infrastructure

Before this patch, thread migration ran in uninterruptible threads.
Use the relatively new hotplug thread infrastructure with parked
threads to reduce cpu load (x4).
cpufreq: cpu-boost: Fix queue_delayed_work_on() race with hotplug

Calling queue_delayed_work_on() on a CPU that's in the process of getting
hotplugged out can result in that CPU infinitely looping in
msm_pm_wait_cpu_shutdown(). If queue_delayed_work_on() is called after the
CPU is hotplugged out, it could wake up the CPU without going through the
hotplug path and cause instability. To avoid this, make sure the CPU is and
stays online while queuing a work on it.

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

Conflicts:
	drivers/cpufreq/cpu-boost.c
cpufreq: cpu-boost: Remove unused waitqueue
cpufreq: cpu-boost: Don't register for cpufreq notifiers too early

The cpufreq notifiers should be registered only after all the data
structures used in the notifier callbacks have been initialized. So, move
the cpufreq notifier registration to a later point in the init function.

Change-Id: I043ab5bc0ebb98164c40549fe151a8d801c8c186
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
cpufreq: Sync on thread migration optimizations

When threads migrate between CPUs the destination CPU will temporarily
have a boosted frequency and the source CPU will have a residual higher
frequency even though the load could have just been reduced. To avoid
leaving CPUs at a high frequencies notify the source CPU after a thread
migration and make the interactive governor's timer reschedule
conditionally.

Change-Id: Id55055f2a116ca7ffd2a34dc3d0ec519c888a111
Signed-off-by: Patrick Cain <pcain@codeaurora.org>
cpufreq: cpu-boost: Re-issue boosts above minimum frequency

Frequency boosts where the source CPU frequency is greater than CPU's
minimum frequency should always go through regardless of the destination
CPU's current frequency. This fixes a performance issue where the governor
lowers the CPU frequency shortly after a thread is migrated to it because
the boost wasn't re-issued.

Change-Id: I449545a688d84b0a6e834f5a51dcb499caa84d29
Signed-off-by: Patrick Cain <pcain@codeaurora.org>
cpufreq: Optimize cpufreq_frequency_table_verify()

cpufreq_frequency_table_verify() is rewritten here to make it more logical
and efficient.
 - merge multiple lines for variable declarations together.
 - quit early if any frequency between min/max is found.
 - don't call cpufreq_verify_within_limits() in case any valid freq is
   found as it is of no use.
 - rename the count variable as found and change its type to boolean.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Linux 3.4.88

Signed-off-by: LaboDJ <jacopolabardi@gmail.com>
smp: Add generic smpboot facility

Start a new file, which will hold SMP and CPU hotplug related generic
infrastructure.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Hirokazu Takata <takata@linux-m32r.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Howells <dhowells@redhat.com>
Cc: James E.J. Bottomley <jejb@parisc-linux.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/20120420124557.035417523@linutronix.de
smp: Provide generic idle thread allocation

All SMP architectures have magic to fork the idle task and to store it
for reusage when cpu hotplug is enabled. Provide a generic
infrastructure for it.

Create/reinit the idle thread for the cpu which is brought up in the
generic code and hand the thread pointer to the architecture code via
__cpu_up().

Note, that fork_idle() is called via a workqueue, because this
guarantees that the idle thread does not get a reference to a user
space VM. This can happen when the boot process did not bring up all
possible cpus and a later cpu_up() is initiated via the sysfs
interface. In that case fork_idle() would be called in the context of
the user space task and take a reference on the user space VM.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Hirokazu Takata <takata@linux-m32r.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Howells <dhowells@redhat.com>
Cc: James E.J. Bottomley <jejb@parisc-linux.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: x86@kernel.org
Acked-by: Venkatesh Pallipadi <venki@google.com>
Link: http://lkml.kernel.org/r/20120420124557.102478630@linutronix.de
smp, idle: Allocate idle thread for each possible cpu during boot

percpu areas are already allocated during boot for each possible cpu.
percpu idle threads can be considered as an extension of the percpu areas,
and allocate them for each possible cpu during boot.

This will eliminate the need for workqueue based idle thread allocation.
In future we can move the idle thread area into the percpu area too.

[ tglx: Moved the loop into smpboot.c and added an error check when
  the init code failed to allocate an idle thread for a cpu which
  should be onlined ]

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: venki@google.com
Link: http://lkml.kernel.org/r/1334966930.28674.245.camel@sbsiddha-desk.sc.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>