cpufreq: ondemand: Remove input boost

A probably imperfect extermination of ondemand's input boost.
We rely on the universal cpu boost input handler now.

Change-Id: If4e0669920c6f2ce25f088a2e88adfb89858856b
Signed-off-by: Dan Trifan <jimsth@gmail.com>
cpufreq: ondemand: Remove sync thread feature

Syncing threads in the cpu-boost driver is sufficient.

Change-Id: I6b3f17b01b0ef6765f7de952aff329c77c781735
Signed-off-by: Dan Trifan <jimsth@gmail.com>
cpufreq: interactive: Add max_freq_hysteresis feature

Previously known as sampling down factor, max_freq_hysteresis
extends the period that interactive governor will stay at policy->max.
This feature is to accomodate short idle periods in an otherwise very
intensive workload.

When the feature is enabled, it ensures that once a CPU goes to max
frequency, it doesn't reduce the frequency for max_freq_hysteresis
microseconds from the time it first goes to idle.

Change-Id: Ia54985cb554f63f8c22d0b554a0a0f2ed2be038f
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
cpufreq: interactive: Make window alignment optional

Make sampling window alignment optional when scheduler inputs
are not enabled.

Change-Id: If69c111a3efe219cdd1e38c1f46f03404789c0bb
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
cpufreq: interactive: Exercise hispeed settings at a policy level

If a heavy task migrates between otherwise idle CPUs in a policy during
every sample window, the above hispeed delay window for the CPUs would get
restarted for every sample window. Due to the continuous restart of above
hispeed delay window, none of the CPUs would ever pick a target frequency
higher than hispeed frequency. This causes the policy's frequency to be
stuck at hispeed freq even if the load justifies a higher frequency.

To fix this, the above high speed delay window is restarted only when the
policy frequency changes. This ensures that tasks migrating between CPUs in
a policy are handled correctly.

Also, the hispeed load/frequency heuristic is only necessary when the
information is insufficient to determine if the load on the CPU needs at
least hispeed frequency. When the policy frequency is already at or above
hispeed frequency, if the CPU load% based on policy frequency is not above
hispeed load, then the information is clearly sufficient to determine that
the load on the CPU does not need hispeed frequency.

Therefore, compute CPU load% (which is used only to compare against hispeed
load) based on policy frequency instead of CPU target frequency.

Change-Id: I1749d663949e34753ecb5c426a16563796f8b0b2
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Dan Trifan <jimsth@gmail.com>
Revert "rtc: alarm: Proper handling of spinlock"

Improper handling ultimately breaks reboot to recovery/download.

This reverts commit 537d9288198b49c04206981949ad875a3d3d9d91.

Change-Id: I603b463625d6a31a5ed3caaf219b0a36d180fdbe
Signed-off-by: Dan Trifan <jimsth@gmail.com>
rtc: alarm: Proper handling of spinlock

Real proper.

Change-Id: I58c01e5d307dfbafa8e8bdad71c4521212524bbb
Signed-off-by: Dan Trifan <jimsth@gmail.com>
defconfig: updates

* Disable unused stuff
* Enable HIDRAW for wiimote pairing support
* Significantly improve latencies while leaving debug
  and logging intact

Signed-off-by: Dan Trifan <jimsth@gmail.com>
version 2.0.2

Signed-off-by: Dan Trifan <jimsth@gmail.com>