drivers: cpufreq: Send a uevent when governor changes

 * Useful so userspace tools can reconfigure.

Change-Id: Ib423910b8b9ac791ebe81a75bf399f58272f64f2
cpufreq: ondemand: add boostpulse interface

Squashed commit consisting of the following:
--------
For applications that require a one-shot increase in frequency,
the boostpulse interface would help to scale to max for the time
specified in boostime. This helps applications that currently
increases scaling_min_freq and resets later after a fixed duration.
Instead of changing scaling_min_freq applications can directly write
to boostpulse and governer resets during regular timer after the time
expires.

Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
--------
cpufreq: ondemand: Fix the boostpulse interface

* Boostpulse was not working because no default frequency was set.
 * We don't need an input handler to push the freq to max, userspace
   does a better job with the Power HAL.
 * Tweak boost time to 500ms

cpufreq: ondemand: Add duration for boosting

* Keep default behavior of 500ms boost if "1" is given, otherwise use
   the value (microseconds) as the boost duration.

drivers: cpufreq: Add max duration for boosting

* Don't allow boosting for more than 5 seconds.

From: Steve Kondik<shade@chemlab.org>
--------
cpufreq: ondemand: Default to max

From: Daniel Bateman<jetison.24@gmail.com>
--------
Change-Id: Ib272703616b9dabc9ab54221f6e2c84c9e9c6dda
net: wireless: bcmdhd: Avoid suspend on watchdog

Change-Id: Ic41a8f369a2ee8b2a0084e6a1cbf6b454ff53353
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Merge branch 'tinykernel-exp' into tinykernel
cpufreq: ondemand: set boostfreq to 700Mhz
cpufreq: interactive: take idle notifications only when active

Register an idle notifier only when the governor is active.  Also
short-circuit work of idle end if the governor is not enabled.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: I4cae36dd2e7389540d337d74745ffbaa0131870f
cpufreq: interactive: keep freezer happy when not current governor

Fix a problem where the hung task mechanism was deeming the interactive
clock boost thread as hung.  This was because the thread is created at
module init but never run/woken up until needed.  If the governor is not
being used this can be forever.  To workaround this explicitly wake up
the thread once all the necessary data structures are initialized.  The
latter required some minor code shuffle.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: Ie2c058dd75dcb6460ea10e7ac997e46baf66b1fe
cpufreq: interactive: handle speed up and down in the realtime task

Not useful to have a separate, non-realtime workqueue for speed down
events, avoid priority inversion for speed up events.

Change-Id: Iddcd05545245c847aa1bbe0b8790092914c813d2
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive: remove input_boost handling

Now handled in userspace Power HAL instead.

Change-Id: I78a4a2fd471308bfcd785bbefcc65fede27314cf
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive: add boostpulse duration

This makes up for the portions missing that would've been written
by Narayanan Gopalakrishnan but they were missing (duration, and boost
time) and also adds the ability to set duration (which was originally
created by cyanogen)

Change-Id: I5428d4edb9e7c903435c368d3539f353234b083a
cpufreq: interactive: if boost duration greater than max use max instead of default

Change-Id: Ib1b206da6ebafc78740f3610c3583052175aff3d
cpufreq: interactive: dont boost for less than default duration

Change-Id: I8a4294b59da883130d4434e44b52d74391b7bb70
cpufreq: interactive: run at fraction of hispeed_freq when load is low

When load is below go_hispeed_load, apply the percentage of CPU load to
a max frequency of hispeed_freq instead of the max speed.  This avoids
jumping too quickly to hispeed_freq when it is a relatively low
percentage of max speed.  This also allows go_hispeed_load to be set to
a high percentage relative to hispeed_freq (as a percentage of max speed,
again useful when hispeed_freq is a low fraction of max speed), to cap
larger loads at hispeed_freq.  For example, a load of 60% will typically
move to 60% of hispeed_freq, not 60% of max speed.  This causes the
governor to apply two different speed caps, depending on whether load is
below or above go_hispeed_load.

Also fix the type of hispeed_freq, which was u64, to match other
speed data types (and avoid overhead and allow division).

Change-Id: Ie2d0668be161c074aaad77db2037505431457b3a
Signed-off-by: Todd Poynor <toddpoynor@google.com>
bump to version 1.7