mako_hotplug: default screen_off_max_freq changed to 1512MHz. Left the tunable there in case someone wants to play with it.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix wrong var type... thank you compiler for not warning me about it.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
input: touchboost: add back keypad filtering. I removed it earlier because I didn't know what it was for, so it seems it is, in this device's case, volume up/down and power button.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
input: touchboost: remove keypad filter, it seems that some idiot decided to bundle Bluetooth disconnect event through the keypad filter so users were having kernel_panics in that scenario. Also no need to call cpufreq_driver_target because interactive's speedtask thread will push do it for us in the next timer_rate. Since timer_rate is 30ms by default we adjust the minimum frequency for 40ms up to input_boost_freq, then the governor will catch up.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
input: touchboost: I misinterpretaded the panic log when a BT device was disconnected and what was actually causing the crash was destroying the WQ. Also fix a small bug where if the user underclocked below input_boost_freq after a touch input max/min freqs would be changed to wrong frequencies.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Correcting CM11 patches
Merge branch 'cm11' of https://github.com/raden/mako into cm11
Revert "alarmtimer: Use hrtimer per-alarm instead of per-base"

This reverts commit 4bbe5c679c99e8016e05f42e3466d26946111ff3.
Revert "alarmtimer: implement minimum alarm interval for allowing suspend"

This reverts commit b664e858d6a5ebce11ea38eb2789f7cb34d7ecb6.
cpufreq: interactive: decrease timer_slack to 70ms

4 * timer_rate could lead to enourmous defferable timer and sometimes,
even during screen off we might need cpufreq to react fast so lowered
timer_slack will help with that. This is specific to interactive, other
governors handle their routines differently.
sched: remove redundant update_runtime notifier

migration_call() will do all the things that update_runtime() does.
So it seems update_runtime() is a redundant notifier, remove it.

Furthermore, there is potential risk that the current code will catch
BUG_ON at line 687 of rt.c when do cpu hotplug while there are realtime
threads running because of enable runtime twice.

Change-Id: I0fdad8d5a1cebb845d3f308b205dbd6517c3e4de
Cc: bitbucket@online.de
Signed-off-by: Neil Zhang <zhangwm@marvell.com>
Reviewed-on: http://git-master/r/215596
(cherry picked from commit 8f646de983f24361814d9a6ca679845fb2265807)
Reviewed-on: http://git-master/r/223067
Reviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
Tested-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
Reviewed-by: Paul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
sched: reinitialize rq->next_balance when a CPU is hot-added

Reinitialize rq->next_balance when a CPU is hot-added.  Otherwise,
scheduler domain rebalancing may be skipped if rq->next_balance was
set to a future time when the CPU was last active, and the
newly-re-added CPU is in idle_balance().  As a result, the
newly-re-added CPU will remain idle with no tasks scheduled until the
softlockup watchdog runs - potentially 4 seconds later.  This can
waste energy and reduce performance.

This behavior can be observed in some SoC kernels, which use CPU
hotplug to dynamically remove and add CPUs in response to load.  In
one case that triggered this behavior,

0. the system started with all cores enabled, running multi-threaded
   CPU-bound code;

1. the system entered some single-threaded code;

2. a CPU went idle and was hot-removed;

3. the system started executing a multi-threaded CPU-bound task;

4. the CPU from event 2 was re-added, to respond to the load.

The time interval between events 2 and 4 was approximately 300
milliseconds.

Of course, ideally CPU hotplug would not be used in this manner,
but this patch does appear to fix a real bug.

Nvidia folks: this patch is submitted as at least a partial fix for
bug 1243368 ("[sched] Load-balancing not happening correctly after
cores brought online")

Change-Id: Iabac21e110402bb581b7db40c42babc951d378d0
Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Peter Boonstoppel <pboonstoppel@nvidia.com>
Reviewed-on: http://git-master/r/208927
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Peter Zu <pzu@nvidia.com>
Reviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
GVS: Gerrit_Virtual_Submit
Tested-by: Peter Zu <pzu@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Merge branch 'nightlies-4.4' of https://github.com/franciscofranco/mako into cm11