cpufreq: intellidemand: squashed governor from faux kernel

cpufreq/cpufreq_intellidemand: intellidemand cpufreq governor (version 4.0)

Intellidemand is inspired by ondemand governor. Its main features are:

 - auto cpu hotplugging based on runnable thread average calculations
 - detection of browsing mode (long screen on activities with moderate run
   queue depth =< 45 )
 - limit max frequencies when in browsing mode to conserve battery for long
   duration tasks

Browsing State Determination:
 1- Browsing state is enabled as power-on default. Browsing state is disabled
    when run queue depth is > 45 (very high instantaneous spikes)

Browsing State Limit Max Freq Logic (sliding window algorithm):
 1- While Screen is ON > 3 min, and average load of the CPU is < 35%, then
    CPU Max frequencies will remain power-on default
 2- While Screen is On, if average CPU load > 35%, both CPUs max frequencies
    will be limited to a lower user configurable max value
 3- While Screen is On, After both CPUs' Max is limited to lowered max, when
    the average CPU load has dropped down to less than < 25%, then both CPUs
    Max freq will be restored to back to power-on default

Runnable Thread Auto-hotplug (fast hotplug / slow unplug algorithm):
 1- When average number of running thread is < threshold, 2nd cpu will be
    unplugged.
 2- When > threshold, 2nd cpu will be hotplugged.
 3- The logic applies a fast hotplug and slow unplug algorithm so 2nd core
    will stay enabled longer to help deal with performance spikes

changes from Ver 2.0 -> Ver 3.0:
  - remove GPU Busy dependency for browsing state detection (this will make
    the governor more portable to other platforms without specific GPU
    architecture knowledge)

dependencies:
  -- Qualcomm's run queue average logic (SOC independent logic)
  -- TI's runnable thread average logic (SOC independent logic)

forward ported to Linux 3.4 for use on Mako

Signed-off-by: Paul Reioux <reioux@gmail.com>

intellidemand: Add boost pulse capability

Boost pulse increases UI performance by increasing CPU freq and
reduce sampling time.

forward ported for Linux 3.4 for use on Mako
Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: add bug fixes

 - Fix crash input event handler on governor switch
 - Fix panic when setting sampling rate

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: add a run queue persistence to determine browsing state

persistence will allow for better browsing state detection rather than just
purely based on run queue depth alone

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: add minimum cpu performance lock

a minimum cpu frequency performance lock is add to ensure smooth
operations when only 1 core is active

Signed-off-by: faux123 <reioux@gmail.com>

Intellidemand: update for quadcore operations. bump version to 4.0

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: code derps clean up!

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: increase boost duration to 2.5 seconds from 1.5

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: add eco mode (dual core operations) bump version to 4.1

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: tweak for not using min performance lock

Signed-off-by: faux123 <reioux@gmail.com>

Intellidemand: adjust the nr_run hysteresis for better UI response

Signed-off-by: faux123 <reioux@gmail.com>

cpufreq: Avoid using smp_processor_id() in preemptible context

Even though this work item runs on only one cpu at a time (due to
queue_work_on()) it is possible for the work item to be preempted
and so use of smp_processor_id() is illegal.

BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/3:1/4162 caller is dbs_refresh_callback+0xc/0x188
[<c00151b0>] (unwind_backtrace+0x0/0x120) from [<c0279058>]
(debug_smp_processor_id+0xbc/0xf0)
[<c0279058>] (debug_smp_processor_id+0xbc/0xf0) from [<c0454b54>]
(dbs_refresh_callback+0xc/0x188)
[<c0454b54>] (dbs_refresh_callback+0xc/0x188) from [<c0087290>]
(process_one_work+0x354/0x648)
[<c0087290>] (process_one_work+0x354/0x648) from [<c0089754>]
(worker_thread+0x1a8/0x2a8)
[<c0089754>] (worker_thread+0x1a8/0x2a8) from [<c008e480>]
(kthread+0x90/0xa0)
[<c008e480>] (kthread+0x90/0xa0) from [<c000f438>]
(kernel_thread_exit+0x0/0x8)

The intent of the code is to determine which CPU this work item
is running on, which we can easily do by passing that information
in a wrapper struct around the work struct. Do this so we avoid
this problem.

Change-Id: I05ca0ff2b3cbaa239930463ea0760e3e9d75145f
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
adapted for Intellidemand from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: Add support to consider other cpu load when scaling frequencies

Currently only current cpu load is considered when frequency scaling.
As a side effect of this when scheduler migrates a thread to a slower
core, the execution time increases unexpectedly.

The new algorithm not only considers current cpu load for frequency
scaling, but also takes into account load of other online cpus. The
treshold for this can be controlled using up_threshold_any_cpu_load.
When the up_threshold_any_cpu_load is crossed in any cpu then the
current cpu is set to sync_freq.

Also, when more than one cpu is online a two step ramp-up mechanism
is used. When the up_threshold_multi_core is crossed the cpu is ramped
up to optimal_freq which is less than policy->max and set to a power
friendly value.

Change-Id: I64bed1b142cde1f239e73aa1f78981c78aaf59ce
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

intellidemand: Fix kernel warning in cpufreq_governor_dbs

GOV_STOP event destroys the timer_mutex and is not initialized back
upon GOV_START event.
The Kernel complains at mutex_lock(during GOV_LIMITS event) after
mutex_destroy.

[<c0014918>] (unwind_backtrace+0x0/0x11c)
[<c007c004>] (warn_slowpath_common+0x4c/0x64)
[<c007c034>] (warn_slowpath_null+0x18/0x1c)
[<c079eef8>] (__mutex_lock_slowpath+0x130/0x3c4)
[<c079f1ac>] (mutex_lock+0x20/0x3c) from [<c0540900>]
[<c0540900>] (cpufreq_governor_dbs+0x3c8/0x468)
[<c053d500>] (__cpufreq_governor+0x90/0xe0)
[<c053d774>] (__cpufreq_set_policy+0x224/0x258)
[<c053da58>] (cpufreq_add_dev_interface+0x2b0/0x308)
[<c053e784>] (cpufreq_add_dev+0x500/0x56c)
[<c079247c>] (cpufreq_cpu_callback+0x88/0x9c)
[<c07a2ca8>] (notifier_call_chain+0x38/0x68)
[<c007ded0>] (__cpu_notify+0x28/0x40)
[<c0790024>] (_cpu_up+0xe4/0x118)
[<c0790024>] (cpu_up+0x64/0x80)
[<c0765840>] (store_online+0x48/0x78)
[<c038d0c8>] (dev_attr_store+0x18/0x24)
[<c017be40>] (sysfs_write_file+0x108/0x13c)
[<c012cdfc>] (vfs_write+0xb0/0x128)
[<c012d034>](sys_write+0x38/0x64)

Change-Id: Ie2a796b17209243de731ccf2ab04b7f9e7048df8
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>

Adapted for Intellidemand from CAF reference

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: give intellidemand's cpu_dbs_info its own name

Signed-off-by: Paul Reioux <reioux@gmail.com>

intellidemand: add default values for dbs sync and optimal tuneables

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: remove cpu cores autoplug capability (replaced by intelli_plug)

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: remove eco mode option (replaced by intelli_plug)

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: remove unused min performance lock defines

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: Don't update the policy->cur upon cpufreq driver failure

Signed-off-by: faux123 <reioux@gmail.com>

msm: cpufreq: make the gov stop part fully atomic

In the function cpufreq_governor_dbs, the case CPUFREQ_GOV_STOP
is not completely atomic. The removal of sysfs is outside the
critical path. If a START/STOP done frequently from user space
then there is chance of adding the sysfs interface before removal.
This creates a warning from sysfs saying creating an already
existing entry.

Also once it fails to create, cpufreq_governor_dbs returns with
error code. The dbs_enable value is incremented which is not
rolled back and cpufreq core tries to set the old
governor. This might create further problems.

Hence the removal of sysfs entry should happen in the critical
path.

CRs-fixed: 440969
Change-Id: I98891756caf2ce0b85e39e9b4f58034af1ed97ce
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
Signed-off-by: faux123 <reioux@gmail.com>

Remove deprecated logic. Based on http://tinyurl.com/kokpohm

Change-Id: I3c70fba9c2452fbdae1e1c14a2240fc73ae403a9
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>

intellidemand: allow clean compilation when LMF is disabled

bumped version to 4.2

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: change boost tunable scope from global to local

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: change permission for boostpulse from root to system

for use with Android PowerHAL

Signed-off-by: faux123 <reioux@gmail.com>

intellidemand: fix permission for sampling_rate as well

to work with Android's PowerHAL

Signed-off-by: faux123 <reioux@gmail.com>

cpufreq: intellidemand: Set MIN_LATENCY_MULTIPLIER to 20

Currently MIN_LATENCY_MULTIPLIER is set defined as 100 and so on a system with
transition latency of 1 ms, the minimum sampling time comes to be around 100 ms.
That is quite big if you want to get better performance for your system.

Redefine MIN_LATENCY_MULTIPLIER to 20 so that we can support 20ms sampling rate
for such platforms.

Signed-off-by: faux123 <reioux@gmail.com>

cpufreq: intellidemand: Fix optimal_freq logic on ramp down

When ondemand governor decides to ramp down the frequency, the missing
check for frequency being lower than optimal_freq was causing frequency
to be ramped down to optimal_freq even if the frequency decided by ondemand
governor was higher.

Change-Id: I00f9ae4c61ccda4039f3338dee2c29b8cb790be4
Signed-off-by: Veena Sambasivan <veenas@codeaurora.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>

intellidemand: re-enable performance lock option

with low freq enabled kernels, minimum performance lock will help music
playback to be smooth and glitch free

Signed-off-by: Paul Reioux <reioux@gmail.com>

Intellidemand: limit min cpu perflock to boot cpu only

Signed-off-by: Paul Reioux <reioux@gmail.com>

Add Intellidemand

Change-Id: I0fe516e656bf18e8d4ee6c34c8499c3cd4949e97
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>

Conflicts:
	arch/arm/configs/mako_defconfig

Conflicts:
	arch/arm/mach-msm/cpufreq.c
cyanogen_mako_defconfig: enable INTELLIDEMAND
block: cgroups, kconfig, build bits for BFQ-v6r2 for 3.4

Update Kconfig.iosched to include kernel configuration options
for BFQ. Add a Kconfig option and do the related Makefile changes
to compile the scheduler. Also let the cgroups subsystem know about
the BFQ I/O controller.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Makefile
block: introduce the BFQ-v6r2 I/O sched for 3.4

Add the BFQ-v6r2 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
associated to each task doing I/O on a device, and each time a scheduling
decision has to be made a queue is selected and served until it expires.

    - Slices are given in the service domain: tasks are assigned budgets,
      measured in number of sectors. Once got the disk, a task must
      however consume its assigned budget within a configurable maximum time
      (by default, the maximum possible value of the budgets is automatically
      computed to comply with this timeout). This allows the desired latency
      vs "throughput boosting" tradeoff to be set.

    - Budgets are scheduled according to a variant of WF2Q+, implemented
      using an augmented rb-tree to take eligibility into account while
      preserving an O(log N) overall complexity.

    - A low-latency tunable is provided; if enabled, both interactive and soft
      real-time applications are guaranteed very low latency.

    - Latency guarantees are preserved also in presence of NCQ.

    - Also with flash-based devices, a high throughput is achieved while
      still preserving latency guarantees.

    - Useful features borrowed from CFQ: cooperating-queues merging (with
      some additional optimizations with respect to the original CFQ version),
      static fallback queue for OOM.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Each node has a full scheduler, so each group can
      be assigned its own ioprio (mapped to a weight, see next point)
      and an ioprio_class.

    - If the cgroups interface is used, weights can be explictly assigned,
      otherwise ioprio values are mapped to weights using the relation
      weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order, i.e., lower
      priority queues are not served as long as there are higher priority
      queues.  Among queues in the same class the bandwidth is distributed
      in proportion to the weight of each queue. A very thin extra bandwidth
      is however guaranteed to the Idle class, to prevent it from starving.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block, bfq: add Early Queue Merge (EQM) to BFQ-v6r2 for 3.4

A set of processes may happen  to  perform interleaved reads, i.e., requests
whose union would give rise to a  sequential read  pattern.  There   are two
typical  cases: in the first  case,   processes  read  fixed-size  chunks of
data at a fixed distance from each other, while in the second case processes
may read variable-size chunks at  variable distances. The latter case occurs
for  example with  KVM, which  splits the  I/O generated  by the  guest into
multiple chunks,  and lets these chunks  be served by a  pool of cooperating
processes,  iteratively  assigning  the  next  chunk of  I/O  to  the  first
available  process. CFQ  uses actual  queue merging  for the  first type  of
processes, whereas it  uses preemption to get a sequential  read pattern out
of the read requests  performed by the second type of  processes. In the end
it uses  two different  mechanisms to  achieve the  same goal:  boosting the
throughput with interleaved I/O.

This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a
sequential  read pattern  with both  types of  processes. The  main idea  is
checking newly arrived requests against the next request of the active queue
both in case of actual request insert and in case of request merge. By doing
so, both the types of processes can be handled by just merging their queues.
EQM is  then simpler and  more compact than the  pair of mechanisms  used in
CFQ.

Finally, EQM  also preserves the  typical low-latency properties of  BFQ, by
properly restoring the weight-raising state of  a queue when it gets back to
a non-merged state.

Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Reviewed-by: Paolo Valente <paolo.valente@unimore.it>
bfq-iosched: Tuning for SSD
bfq-iosched: Set bfq_back_penalty = 1
cyanogen_mako_defconfig: enable BFQ
board-mako-display: update gamma values
makefile: optimize AK flags
cyanogen_mako_defconfig: enable ARCH_RANDOM
cyanogen_mako_defconfig: enable XCHGADD_ALGORITHM
Kernel Version: AK.016