Add my Hotplug driver.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: we can live with 80% threshold.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: we can now cap max freq to 1GHz on screen off.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: without updating the policy nothing actually happened.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: make sure the notifier does not go through for every damn CPUFREQ_ADJUST otherwise it's a mess.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: lets try this fix for the crippling sound when changing networks.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: minor code optimisations.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: small fix to make sure we don't try to cpu_up(x) if x is alread online.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: clean-up

* clean up the store functions using proper and modern kstrtoul

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
mako_hotplug: bugfixing

* fix a bug where cpu_smash()->cpus_cpufreq_work()->cpus_offline_work()
was being called every 100ms

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
zram use 4 block devices insteaad of one
vfp: hardfloat

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>

Conflicts:
	arch/arm/vfp/Makefile
import logger changes from Cl3kener

Conflicts:
	drivers/staging/android/logger.c
Enable pipe flag.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: Add cpu-boost driver

When certain bursty and important events take place, it might take a while
for the current cpufreq governor to notice the new load and react to it.
That would result in poor user experience. To alleviate this, the cpu-boost
driver boosts the frequency of a CPU for a short duration to maintain good
user experience while the governor catches up.

Specifically, this commit deals with ensuring that when "important" tasks
migrate from a fast CPU to a slow CPU, the frequency of the slow CPU is
boosted to be at least as high as the fast CPU for a short duration.

Since this driver enforces the boost by hooking into standard cpufreq
ADJUST notifiers, it has several advantages:
- More portable across kernel versions where the cpufreq internals might
  have been rewritten.
- Governor agnostic and hence works with multiple governors like
  conservative, ondemand, interactive, etc.
- Does not affect the sampling period/logic of existing governors.
- Can have the boost period adjusted independent of governor sampling
  period.

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

Conflicts:
	drivers/cpufreq/cpu-boost.c

Conflicts:
	drivers/cpufreq/cpu-boost.c
cpufreq: Add a sync limit to cpu-boost

Perform frequency synchronization only when source CPU's frequency
is less than sync_threshold, else sync to the sync_threshold.

Change-Id: I544c414568d4e015b80ce5891dd215275bac95da
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: Add Input Boost feature to the cpu-boost driver

On incoming input events boost the frequency of all online cpus
for at least input_boost_ms ms. This is accomplished by changing
the policy->min of all the online cpus to input_boost_freq.

Change-Id: Idb0ab75d68ae4ceff259cbbaaec1a9bb3bc871d3
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: cpu-boost: Fix deadlock in wake_up of sync threads

If wake_up() is called on the current task on a CPU, the call will wait
until the current task is switched out before it wakes it up again and
returns.

The sync notifier for a CPU always runs on that CPU.

These two together can result in a deadlock if the sync notifier on CPU A
tries to wake up the sync thread of CPU A as it goes to sleep (is the
current task). A previous commit fixed this by adding a check to the sync
notifier to not wake up the sync thread of CPU A if it's the current task.

But this is still not sufficient to prevent deadlocks.

Sync thread of CPU A could be the current task on CPU B and sync thread of
CPU B could be the current task on CPU A.  At this point, if sync notifier
of CPU A and B try to wake up the sync threads of CPU A and B, it will
result in CPU A waiting for the current task in CPU B to get switched out
and CPU B waiting for the current task in CPU A to get switched out.  This
will result in a deadlock.

Prevent this scenario from happening by pinning the sync threads of each
CPU to run on that CPU. By doing this, we guarantee that sync notifiers
will only try to wake up sync threads running on that CPU. The fix added by
"cpufreq: cpu-boost: Resolve deadlock when waking up sync thread" ensures a
deadlock doesn't happen when a sync notifier tries to wake up a sync thread
running on that CPU.

Change-Id: I864e545529722a23886dd5a82f66089155d2d193
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
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>
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).

Change-Id: I4fa1f3a6d6b2b68ecb6e751678584f24abd85992