cpuboost: Add hotplug boosting

If we decide to hotplug a core then we are making a strong
statement that we think that the system load is high.  Let's
have faith in our hotplug driver(s) and boost the cpufreq
when we are hotplugging cores.

[myfluxi: shorter boost, minor style changes]

[temasek: plug_boost_freq 1190400]

Change-Id: Id35bae6c27c39097c7aca70eebf1498ed0c3dfdc
cpufreq: cpu-boost: Introduce scheduler assisted load based syncs

Previously, on getting a migration notification cpu-boost changed
the scaling min of the destination frequency to match that of the
source frequency or sync_threshold whichever was minimum.

If the scheduler migration notification is extended with task load
(cpu demand) information, the cpu boost driver can use this load to
compute a suitable frequency for the migrating task. The required
frequency for the task is calculated by taking the load percentage
of the max frequency and no sync is performed if the load is less
than a particular value (migration_load_threshold).This change is
beneficial for both perf and power as demand of a task is taken into
consideration while making cpufreq decisions and unnecessary syncs
for lightweight tasks are avoided.

The task load information provided by scheduler comes from a
window-based load collection mechanism which also normalizes the
load collected by the scheduler to the max possible frequency
across all CPUs.

Change-Id: Id2ba91cc4139c90602557f9b3801fb06b3c38992
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>

Conflicts:
	drivers/cpufreq/cpu-boost.c
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>
cpufreq: cpuboost: Always consider current policy max

We fixed calculations in the scheduler in 58cd101c69c508a448a03fc480ceb35f0da12386.
Now repeat this in the cpu-boost driver.
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: Fix cores getting stuck. Finally.

* In exclusive hotplug system, if a core is not taken down
  explicitly, it is observed that it gets stuck at input
  boost frequency.
* This issue maybe particular to only this kernel but this
  fix resolves it completely.
* Root cause seems to be removal work is lost if queued on
  sibling cores. So simply fix this by queuing on boot CPU.

* Finally, I can use min_cpus_online > 1 without any issue.

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>