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
cpufreq: ondemand: set boostfreq to 700Mhz
cpufreq_ondemand.c: Tuning
cpufreq: interactiver governor: Add a time view concept

CPUFreq governors are always a tradeoff between power vs performance.
For low power UCs we want to have a less reponsive cpufreq governor that
does not respond or react to each load pick.
However when scrolling on the screen or during webbrowsing we need a more
responsive governor that interact or esponse to each load variation.

To detect which kind of application we have, we'll rely on the history of
the load. if the the average over the load history is high that means we
need to be more responsive so we change the governor paramters in that
direction.
if the average over the load history is low thatmeans we are in low power
UCs so we change the governor parameter to be less responsive

Change-Id: Ifd55ac4cfbc1bd9eded4ae603b158054c6169e8c
Signed-off-by: Nicole Chalhoub <n-chalhoub@ti.com>
Signed-off-by: Taras Kondratiuk <taras@ti.com>
(cherry picked from commit c9d2e290d40f629306ba4cd020be1d71ed5e1d23)

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive governor: Fix not uniform buf filling & memory corruption

Each CPU has it's own load history buffer, but all they use shared
<history_load_index> variable, this lead to not uniform filling
of the cpu's circular buffers. Only about half of buffer is updated
during each buffer rewriting cycle that obligate governor to use
outdated data during freq tuning.

Moreover access to <history_load_index> variable is not atomic, that
create race conditions. Simultaneous increment could cause situation
where such check:

        if (++history_load_index == sampling_periods)
                history_load_index = 0;

not safe and buffer overflow will not be prevented. That will lead
to memory corruption.

To avoid such problems this patch move buffer-index variable to
<cpufreq_interactive_cpuinfo> structure, which is separate for each CPU.
Also, buffer overflow checking will be paranoidly changed.

Change-Id: I333a4462be17816372a7a57529811d87930058c0
Signed-off-by: Leonid Iziumtsev <x0153368@ti.com>
(cherry picked from commit befb3fe3e38d88bc1872d99748c246c26406315d)

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: take idle notifications only when active - https://github.com/android/kernel_common/commit/22a51ab6e21de740c1b555f9a03626d28aaebdf3

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: keep freezer happy when not current governor - https://github.com/android/kernel_common/commit/5ff8407798f1d8c44f3165bc535676a2a897666b

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: handle speed up and down in the realtime task - https://github.com/android/kernel_common/commit/f8aa05d96a0d18416d2627c493f7dc9bc5324901

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: remove input_boost handling - https://github.com/android/kernel_common/commit/4e27eb56e819745a1b184f278d7f3dd3887a456c

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix compiling errors from the latest commits

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: separate Interactive governor into two, one with static settings and another one with dynamic settings (it adjusts itself according to load). The new governor is called Dynamic Interactive.
cpufreq: interactive: change frequency up/down kernel thread priority. Now it has more priority than any user thread which should boost interactivity.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: add input_boost_freq entry. This entry is the frequency which the CPU will be boosted when the screen is touched. It's user configurable from userspace and it needs to match the entries in the frequency table.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: always limit initial speed bump to hispeed

First bump speed up to hispeed_freq whenever the current speed is below
hispeed_freq, instead of only when the current speed is the minimum speed.
The previous code made it too difficult to use hispeed_freq as a common
intermediate speed on systems that frequently run at speeds between
minimum and hispeed_freq.

Change-Id: I04ec30bafabf5741e267ff289209b8c2d846824b
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
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>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix input_boost_freq type from u64 to unsigned int. Also get rid of boost option, its not needed and its mostly not used. Boostpulse calls cpufreq_interactive_boost when its activated (Tuna PowerHAL takes care of that).

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: decrease inpu_bost_freq to 537MHz.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: pin timers to associated CPU - original patch: https://github.com/android/kernel_common/commit/430d3d4539a0d441679ca32cc7c3876f97a07da6

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: use deferrable timer by default - original patch: https://github.com/android/kernel_common/commit/0697ab54cab34e099711ceb4b07b2dfc6b507f0d

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpufreq: interactive: kick timer on idle exit past expiry - original patch: https://github.com/android/kernel_common/commit/9b29a6d49becf8caf0550373d84a1068c716e891

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>