cpufreq: Add a boostpulse interface to ondemand

For applications that require a one-shot increase in frequency,
the boostpulse interface would help to scale to max for the time
specified in boostime. This helps applications that currently
increases scaling_min_freq and resets later after a fixed duration.
Instead of changing scaling_min_freq applications can directly write
to boostpulse and governer resets during regular timer after the time
expires.

Change-Id: Ie5f490ff06b41364aa76dd468573433495da28a4
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: boost the sampling rate on touch event

For better Ux responsiveness ondemand sampling rate
needs to be 20ms. But, a 20ms sampling rate increases power
consumption. So, boost the sampling rate to 20ms on every
touch event for 2.5 ms and later reset to default rate.
Also, change sampling down factor proportional to the
sampling rate.

Change-Id: I111b1cf3b8ed133347149afc34d329d0384ecfcb
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
cpufreq: ondemand: Fix the boostpulse interface

 * Boostpulse was not working because no default frequency was set.
 * We don't need an input handler to push the freq to max, userspace
   does a better job with the Power HAL.
 * Tweak boost time to 500ms

Change-Id: Ib377e22fb4fbe5f41e85ac16806fdad9537a3077
ARM: disable preemption in machine_shutdown

Since the smp call to stop the other cpus are handled in those
cpus in interrupt context, there's a potential for those smp
handlers to interrupt threads holding spin locks (such as the
one a mutex holds).  This prevents those threads from ever
releasing their spin lock, so if the cpu doing the shutdown
is allowed to switch to another thread that tries to grab the
same lock/mutex, we could get into a deadlock (the spin lock
call is called with preemption disabled in the mutex lock code).

To avoid that possibility, disable preemption before doing the
smp_send_stop().

Change-Id: I7976c5382d7173fcb3cd14da8cc5083d442b2544
Signed-off-by: Mike J. Chen <mjchen@google.com>
mmc: Make sure host is disabled on suspend

Change-Id: Ie0bf2004e173cef8dad66722a152658d7727ab65
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
panic: Fix a possible deadlock in panic()

panic_lock is meant to ensure that panic processing takes
place only on one cpu; if any of the other cpus encounter
a panic, they will spin waiting to be shut down.

However, this causes a regression in this scenario:

1. Cpu 0 encounters a panic and acquires the panic_lock
   and proceeds with the panic processing.
2. There is an interrupt on cpu 0 that also encounters
   an error condition and invokes panic.
3. This second invocation fails to acquire the panic_lock
   and enters the infinite while loop in panic_smp_self_stop.

Thus all panic processing is stopped, and the cpu is stuck
for eternity in the while(1) inside panic_smp_self_stop.
To address this, disable local interrupts with
local_irq_disable before acquiring the panic_lock. This will
prevent interrupt handlers from executing during the panic
processing, thus avoiding this particular problem.

Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
ARM: smp: Fix cpu_up() racing with sys_reboot

Nothing stops a process from hotplugging in a CPU concurrently
with a sys_reboot() call. In such a situation we could have
ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the
fact that the CPU is not really offline and call the
CPU_UP_PREPARE notifier. When this happens stop_machine code will
complain that the cpu thread already exists and BUG_ON().

CPU0                      CPU1

sys_reboot()
 kernel_restart()
  machine_restart()
   machine_shutdown()
    smp_send_stop()
    ...                   ipi_cpu_stop()
                           set_cpu_online(1, false)
                            local_irq_disable()
                             while(1)
    <PREEMPT>
cpu_up()
 _cpu_up()
   if (!cpu_online(1))
    __cpu_notify(CPU_UP_PREPARE...)
cpu_stop_cpu_callback()
  BUG_ON(stopper->thread)

This is easily reproducible by hotplugging in and out in a tight
loop while also rebooting.

Since the CPU is not really offline and hasn't gone through the
proper steps to be marked as such, let's mark the CPU as inactive.
This is just as easily testable as online and avoids any possibility
of _cpu_up() trying to bring the CPU back online when it never was
offline to begin with.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
modified for tuna kernel by faux123 from Linux 3.5+
Revert "cpufreq: boost the sampling rate on touch event"

This reverts commit b96ee01bac18bd29c22357b4d61d8891ca512357.
Revert "cpufreq: ondemand: Fix the boostpulse interface"

This reverts commit c39eb39b17e806a5b9ebf9c8756c167d24561a55.
cpufreq: boost the sampling rate on touch event

For better Ux responsiveness ondemand sampling rate
needs to be 20ms. But, a 20ms sampling rate increases power
consumption. So, boost the sampling rate to 20ms on every
touch event for 2.5 ms and later reset to default rate.
Also, change sampling down factor proportional to the
sampling rate.

Change-Id: I111b1cf3b8ed133347149afc34d329d0384ecfcb
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

Conflicts:

	drivers/cpufreq/cpufreq_ondemand.c
Revert "cpufreq: boost the sampling rate on touch event"

This reverts commit b96ee01bac18bd29c22357b4d61d8891ca512357.
add defconfig