ondemand: cpuidle detection

I found a problem with the ondemand governor while in earlysuspend
suspend mode (ondemand keeping the freq close to the max at all times
despite near 0% load). The problem is that the cpu starts to go in
long cpuidle cycles, a sampling_rate of 10000 (usec) is applied only
once in a while and the real sampling_rate becomes 1 second (or more).

So when a wakeup happens we return to the 10000usec sampling rate. The
ondemand sees lots of activity after the wakeup but those "loads" must
be adjusted down if the previous wall_time delta was huge and the
current one is tiny. We're too close to long cpuidle to worry about
the cpu freq anyway and it may be just a jitter load that if we take
into account without adjusting it down, will lead to the next long
cpuidle to be entered at the max freq again, and this repeats forever.

So my solution is to tweak the ondemand to scale down the "load"
according to the decrease in the wall_time delta ratio
(deep_sleep_ratio variable). This allows the CPU to stay at the lowest
freq during the deep sleeps even when the ondemand governor is enabled
and the sampling_rate is set to 10000. (setting the sampling_rate to
values >100000 would also tend to hide the problem but it'd screw the
interactive behavior by running at the lowest frequency for too long
during interactive usage)

During interactive usage with the screen on (not in earlysuspend
mode), or during playback or voip with screen off the deep_sleep_rate
is set to 1 practically all the time so it won't alter the behavior of
the ondemand governor unless the system is very idle (and in turn when
we want it to stay at low freq).

Change-Id: If0391e6d6c41c1c8c9fa590502e88e681a800b04

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>
Voodoo Sound added for i9300, n7100, n8000, m8013, t0lte and t0ltecdma - Used The Glitch Kernel i9300 as a refrence - https://github.com/GlitchKernel/Glitch-i9300
Makefile:  Add LDFLAGS_MODULE  = --strip-debug

shrink the modules down to a respectable size
Signed-off-by: Curtis Menard <curtis.menard@gmail.com>

Change-Id: I7ce7aa4d9a8e6315983b87aa211af5db27d457e6
mach-exynos: cpufreq: undervolting and overclocking support
cpufreq: undervolting interfaces
Allow CPU Based Alignment Handling
Expand OC to 1920 and 2000MHz

Tweak deadline scheduler.
Raise max readahead.
Tune Ondemand for those who want to use it.
Try to get pegasusq to online cores sooner, it seems a little sleepy.
Push GPU to 600MHz as test.
Scaling needs attention for UI response. Credit Morfic
cpufreq: fix sticking OC clocks

Conflicts:
	arch/arm/mach-exynos/cpufreq.c
performance: Turn CPUs online while active

Since we don't have separate active hotplugging logic aside the in-governor one in pegasusq, switching to performance governor will always just remain with whatever cores were online before the switch. This activates all available cores on governor start, and turns additional cores off when stopped.
t0ltecdma: custom config

Change-Id: I1c83df564b39d20cb6628ba9cbfd9e586c7e80f8
t0ltecdma: savedefconfig

Change-Id: Ie9e3ba1af4e63b3503cc0866fe372b58cdd20d0e
Cleanup

Change-Id: I82b68d2e1af7b9d70e2cfa011986378b49268ca3
cpufreq: interactive: Add boostpulse duration

Taken from stingray.

Credit - Daniel Bateman (tuna patch), Narayanan Gopalakrishnan and
Steve Kondik.

Change-Id: I7de5b15fa74a5c67437f514c20a0ad63f997f565
cpufreq: interactive: limit boostpulse duration to MAX

For boostpulse requests for a duration above MAX,
limit them to MAX instead of to DEFAULT.

Change-Id: I03ed20ee3b7a47122361ec890962d8c7ed0dad81
cpufreq: Update interactive governor

Originally for crespo (Iba70ed3580dd04704b0d7b4acde178df7a843b5f)

This is a squashed commit of the following:

cpufreq: interactive: add show_boost sysfs entry
  Signed-off-by: jt1134 <jt1134@gmail.com>

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>

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>

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.
  Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: remove input_boost handling
Now handled in userspace Power HAL instead.
  Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: fix interactive bug during hotplug
When a new cpu is added and if does not enter idle
for long, the interactive timer is not started and hence
the cpu remains at lowest frequecny, despite the system
load. This impacts mainly benchmarks. Starting a timer
at governor start to handle low frequency.
  Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

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.
  Signed-off-by: Todd Poynor <toddpoynor@google.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).
  Signed-off-by: Todd Poynor <toddpoynor@google.com>

Change-Id: I11646ce80158bf198c0ced4e006f0f7f983904d3
Linux 3.0.65

Change-Id: I648fbd46a49e9242bf6da8348006882e61c73a48
Linux 3.0.66

Change-Id: I4c1c8455d9ac258749e75a140a4fbfd029575195
Linux 3.0.67

Change-Id: Iacf5a91b5cf039a01ab58501a5d6a1129c84a49e
Linux 3.0.68

Restore cgroup to mainline.

Change-Id: Ie5a56d75b162d3f0844fe82eae2962c0dec17b40