cpufreq: cpu-boost: Handle wakeup hints received for foreground tasks

A previous change modifies the notification conditions in the scheduler
to call the notifier chain even on foreground_thread wakeups for tasks
having load more than a threshold value.

If load_based_syncs is turned OFF then we do not need to perform
cpu boost for wakeup hints for foreground tasks from scheduler

Change-Id: Ifbdd3eccac5c9892dfc3a3c3edbfc0df766478ed
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
cpufreq: cpu-boost: Consider only task load to decide on sync frequency

Currently we take the maximum between the source CPU frequency and
the calculated frequency based on the migrating task load to decide on
the frequency to sync the destination CPU to. This was done to handle
short bursts in workloads of tasks which migrated immediately after
causing a ramp up on the source CPU. Since their load history wasn't
high enough, the destination CPU synced to a lower frequency which
wasn't sufficient for the spike in workload.

But as such cases are rare, taking the higher of source and calculated
frequency can lead to destination CPU unnecessarily spending a
considerable amount of time at higher frequencies which in turn can
hurt power.

With this change we make sure only the migrating task load is used
to calculate the sync frequency for destination CPU when load based
syncing is enabled.

Change-Id: Ib1489d256c42ea7712aad2179aebffc87c549836
Signed-off-by: Girish Ghongdemath <girishsg@codeaurora.org>
ramdisk: Re-tune interactive governor and cpu-boost

* Timer rate at 20K is too short and is harsh on battery
* Timer slack at 80K is too long and causes delays in frequency scaling
* Add intelligent migration boosts to preserve smoothness

Signed-off-by: Zhao Wei Liew <zhaoweiliew@gmail.com>
msm: hotplug: Add MSM Hotplug driver
msm: hotplug: Max 1036MHz during screen off
msm: hotplug: Remove spinlock in load stats

It's too expensive and not nessecary.
msm: hotplug: Stop hotplug work a tad later
msm: hotplug: Schedule suspend/resume work

Dennis is right, this is the proper way to suspend and resume.
hammerhead: touch: Remove touch boost

Revert "cpufreq: conservative: Boost all online cpus"

This reverts commit 3d2675da0500e4e9cd94de66f657790ca5e26467.

Revert "hammerhead: touch: Simple method of boosting cpu frequency on touch"

This reverts commit 2f25573cc2924e62d222f4fbd7a976121858dce2.

Conflicts:
	drivers/cpufreq/cpufreq_conservative.c
	drivers/cpufreq/cpufreq_interactive.c
	drivers/input/touchscreen/touch_synaptics_ds5.c
	include/linux/input/touch_synaptics.h
msm: hotplug: Increase down lock duration and janitize
msm: hotplug: Use high-priority workqueue
msm: hotplug: Add input boost handler

Add an input handler to hotplug additional cpus. Down lock will
take care of keeping the cpu boosted.
msm: hotplug: Add minimum interval for input boost
msm: hotplug: Remove deprecated msm_cpufreq_set_freq_limits
msm: hotplug: Cleanup hotplugging routines

Remove paroid atomic operations that were causing issues.
cpufreq: add new routine cpufreq_verify_within_cpu_limits()

Most of the users of cpufreq_verify_within_limits() calls it for
limiting with min/max from policy->cpuinfo. We can make that code
simple by introducing another routine which will do this for them
automatically.

This patch adds another routine cpufreq_verify_within_cpu_limits()
and updates others to use it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
msm: hotplug: Optimize hotplugging routines

- Power down the slowest cpu
- Move checks from callback to calling function
- Clean it up a bit
msm: hotplug: Add pm ops
msm: hotplug: Fix symbol export
msm: hotplug: Fixup sysfs interface

* Use proper return values
* Fix store_down_lock_duration()
* Add some more checks
* Cleanup some mess