defconfig: Regenerate

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

Change-Id: I6cc54461e91e46a1e76ae2a1fdb57dec3ecb4488
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>
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>
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>
Revert "rtc: alarm: Proper handling of spinlock"

Improper handling ultimately breaks reboot to recovery/download.

This reverts commit 537d9288198b49c04206981949ad875a3d3d9d91.

Change-Id: I603b463625d6a31a5ed3caaf219b0a36d180fdbe
rtc: alarm: Proper handling of spinlock

Real proper.

Change-Id: I58c01e5d307dfbafa8e8bdad71c4521212524bbb