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>
mako_hotplug: make a separate delayed work for when the device is sleeping, but wakelocked, and the device needs extra work that only one core can't withstand, for example listening to music and the GSM network changes from 2G to 3G or vice-versa, or Wi-Fi going up/down. Previous of this patch it would stutter the audio. With this separate work it will online cpu1 if the load justifies and so audio stutters are no more.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Revert "mako_hotplug: make a separate delayed work for when the device is sleeping, but wakelocked, and the device needs extra work that only one core can't withstand, for example listening to music and the GSM network changes from 2G to 3G or vice-versa, or Wi-Fi going up/down. Previous of this patch it would stutter the audio. With this separate work it will online cpu1 if the load justifies and so audio stutters are no more."

 * This caused the watchdog to bark because the msm pm driver doesn't particulary enjoy when I online a core during power collapse.

This reverts commit bde7929ff1c692dd494e3cbce6b97aadfdf05d12.
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.