msm: cpufreq: boost freq of online cpu(s) to max on resume
Resume events cause several tasks to initiate such as WiFi connect,
data sync, etc. that require cpu cycles. Instead of waiting for the cpu
governor to increase the cpu frequency which occur after an unpleasant delay,
start at the max frequency and the cpu governor will scale the frequency
back as soon as possible. This shouldn't have any noticeable impact on battery
life.
--mrg666
ARM: 7133/1: SMP: fix per cpu timer setup before the cpu is marked online
The problem is related to the early enabling of interrupts and the
per cpu timer setup before the cpu is marked online. This doesn't
need to be done in order to call calibrate_delay().

calibrate_delay() monitors jiffies, which are updated from the CPU
which is waiting for the new CPU to set the online bit.

So simply calibrate_delay() can be called on the new CPU just from
the interrupt disabled region and move the local timer setup after
stored the cpu data and before enabling interrupts.

This solves both the cpu_online vs. cpu_active problem and the
affinity setting of the per cpu timers.

Signed-off-by: Thomas Gleinxer <tglx@linutronix.de>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
sched: Cleanup cpu_active madness
Stepan found:

CPU0		CPUn

_cpu_up()
  __cpu_up()

		boostrap()
		  notify_cpu_starting()
		  set_cpu_online()
		  while (!cpu_active())
		    cpu_relax()

<PREEMPT-out>

smp_call_function(.wait=1)
  /* we find cpu_online() is true */
  arch_send_call_function_ipi_mask()

  /* wait-forever-more */

<PREEMPT-in>
		  local_irq_enable()

  cpu_notify(CPU_ONLINE)
    sched_cpu_active()
      set_cpu_active()

Now the purpose of cpu_active is mostly with bringing down a cpu, where
we mark it !active to avoid the load-balancer from moving tasks to it
while we tear down the cpu. This is required because we only update the
sched_domain tree after we brought the cpu-down. And this is needed so
that some tasks can still run while we bring it down, we just don't want
new tasks to appear.

On cpu-up however the sched_domain tree doesn't yet include the new cpu,
so its invisible to the load-balancer, regardless of the active state.
So instead of setting the active state after we boot the new cpu (and
consequently having to wait for it before enabling interrupts) set the
cpu active before we set it online and avoid the whole mess.

Reported-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1323965362.18942.71.camel@twins
Signed-off-by: Ingo Molnar <mingo@elte.hu>

adapted for 3.0 by mrg666 (only for arm)
mmc: core: Fix NULL pointer dereference

mmc_signal_sdio_irq() should only be called when the function
driver registers for IRQ notification. In case, if any host
driver recieves a spurious interrupt and call mmc_signal_sdio_irq(),
ignore waking up uninitialized sdio irq thread.

CRs-Fixed: 472609
Change-Id: I831717fe80918538a18cc1f2300fe7fe2817c70f
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
ARM: Fix negative idle stats for offline cpu

We see negative idle stats because of cpu dying without
cleaning up idle entry statistics. When a cpu is offline,
the most immediate thing you'd want to do is just call
into cpu_die() and not waste time calling notifier(IDLE_START).

CRs-Fixed: 414554
Change-Id: Iadc6a3ca39997e0ccf65d2a29b004e24b1b211a1
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
msm cpufreq: Squash a few WildKernel Tweaks

msm: cpufreq: boost freq of online cpu(s) to max on resume
Resume events cause several tasks to initiate such as WiFi connect,
data sync, etc. that require cpu cycles. Instead of waiting for the cpu
governor to increase the cpu frequency which occur after an unpleasant delay,
start at the max frequency and the cpu governor will scale the frequency
back as soon as possible. This shouldn't have any noticeable impact on battery
life.
--mrg666