[Samsung Galaxy Nexus] aosp:
[MENTION=4443334]Grarak[/MENTION]

Could you please add these cpufreq boost patches for the next GraKernel?

pm: cpufreq: boost cpu frequency API support

This patch introduces boost sysfs interface which would enable the

govenor to ack any request for running the system at max freq just before

the system is going to be loaded. The next sample time would be decided

based on the user configured timeout value or the default (0) usec.

To set boost timeout:

echo <in usec> > /sys/devices/system/cpu/cpufreq/interactive/boost_timeout

To enable boost:

echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/boost_cpufreq

http://goo.gl/n78dwP

cpufreq: interactive governor: Delete boost timer on CPUFREQ_GOV_STOP.

Concurrent execution of CPUFREQ_GOV_STOP and interactive_boost_timer()

should be avoided.

Also, interactive_boost() should follow CPUFREQ_GOV_STOP on

flush_work().

http://goo.gl/FkEoXA

cpufreq: interactive governor: Delete boost timer on CPUFREQ_GOV_STOP.

Concurrent execution of CPUFREQ_GOV_STOP and interactive_boost_timer()

should be avoided.

Also, interactive_boost() should follow CPUFREQ_GOV_STOP on

flush_work().

http://goo.gl/mSBt1o

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

http://goo.gl/27AOQD

OMAP4: DPLL cascading: Tune cpufreq interactive governor

During DPLL cascading timer_rate of interactive timer should be

increased, otherwise interactive governor will try to put system

out of DPLL cascading very frequently

http://goo.gl/f3Yyqw

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.

http://goo.gl/7hnndj

blaze_tablet: Enabling cpu boost during boot

Added cpu boost for boot time improvement.

http://goo.gl/BCTZ3Z

# Boost the CPU for 30 secs during boot

write /sys/devices/system/cpu/cpufreq/interactive/boost_timeout 30000000

write /sys/devices/system/cpu/cpu0/cpufreq/boost_cpufreq 1