Never append '+' symbol to kernel version string.
Added optimized ARM RWSEM algorithm.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
squashed: add intelli_plug by faux123

==========================================================================

intelli_plug: intelligent hotplug cpu driver with eco mode

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

==========================================================================

intelli_plug: tweak for faster wakeup from suspend

bump version to 1.1

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

==========================================================================

intelli_plug: increase cores on persistence

also replace hardcoded values with Macros for ease of updating later

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

==========================================================================

intelli_plug: make it gcc-4.6.x eabi compatible :p

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

==========================================================================

intelli_plug: use rq_stats to help detect artificial or constant loads

benchmarks often create fake / artificial loads at a constant rate.  These
type of loads are not detected corectly by run average algorithms. Use
the run queue stats to help detect these cases and bring up the cores in
correspondence.

bump version to 1.2

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

==========================================================================

intelli_plug: use mp_decision() algorithm for core 3 and 4

This replaces the simplistic check for run queue thresholds with a more
sophisticate algorithm with time awareness

bump version to 1.3

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

==========================================================================

intelli_plug: tweak mp_decsion parameters and remove unused logic

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

==========================================================================

intelli_plug: bump threshold slightly for better response

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

==========================================================================

intelli_plug: change logic for better benchmark performance

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

==========================================================================

intelli_plug: use mp_decision to reduce online persistence count for cores

this should bring down the cores faster when run queue is low
also optimized code a bit using local vars

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

==========================================================================

intelli_plug: slow down hotplug activity from 50ms to 200ms

this will reduce the hotplug chaos which may in turn save more power

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

==========================================================================

intelli_plug: code clean up and minor bug fixes

bump to version 1.6

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

==========================================================================

intelli_plug: add dynamic load sampling rate logic

Add dynamic sampling logic based on load. If load is high and required more
than 2 cores, increase the sampling rate for a duration of 3 seconds to help
manage the load better during this time.  Once duration expires, revert back
to lazier sampling rate for better batter performance.

bump to version 1.8

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

==========================================================================

intelli_plug: add touch input logic

changed intelli_plug sampling rates and bump to version 2.0

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

==========================================================================

intelli_plug: use a context safe function call instead

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

Change-Id: I6881f628cb59c53c0bd7f92fa4bdf77cd501386c
Signed-off-by: Willi Ye <williye97@gmail.com>

Conflicts:
	arch/arm/mach-msm/Kconfig
	arch/arm/mach-msm/Makefile

Conflicts:
	arch/arm/mach-msm/Makefile
intelli_plug: performance tune-up continued...

Change-Id: I59f6ccdbe9ce97f7247bc510d1cfff6b79565c42
Signed-off-by: Paul Reioux <reioux@gmail.com>
writeback: fix writeback cache thrashing

Consider Process A: huge I/O on sda
        doing heavy write operation - dirty memory becomes more
        than dirty_background_ratio
        on HDD - flusher thread flush-8:0

Consider Process B: small I/O on sdb
        doing while [1]; read 1024K + rewrite 1024K + sleep 2sec
        on Flash device - flusher thread flush-8:16

As Process A is a heavy dirtier, dirty memory becomes more
than dirty_background_thresh. Due to this, below check becomes
true(checking global_page_state in over_bground_thresh)
for all bdi devices(even for very small dirtied bdi - sdb):

In this case, even small cached data on 'sdb' is forced to flush
and writeback cache thrashing happens.

When we added debug prints inside above 'if' condition and ran
above Process A(heavy dirtier on bdi with flush-8:0) and
Process B(1024K frequent read/rewrite on bdi with flush-8:16)
we got below prints:

[Test setup: ARM dual core CPU, 512 MB RAM]

[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   384 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   960 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   768 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   320 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =  1024 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   576 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   512 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB

As mentioned in above log, when global dirty memory > global background_thresh
small cached data is also forced to flush by flush-8:16.
If removing global background_thresh checking code, we can reduce cache
thrashing of frequently used small data.
And It will be great if we can reserve a portion of writeback cache using
min_ratio.

After applying patch:
$ echo 5 > /sys/block/sdb/bdi/min_ratio
$ cat /sys/block/sdb/bdi/min_ratio
5
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  84160 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  96960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  94080 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  91520 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  89600 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  72960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90688 KB

As mentioned in the above logs, once cache is reserved for Process B,
and patch is applied there is less writeback cache thrashing on sdb
by frequent forced writeback by flush-8:16 in over_bground_thresh.

After all, small cached data will be flushed by periodic writeback
once every dirty_writeback_interval.

Suggested-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Vivek Trivedi <t.vivek@samsung.com>
 staging: Add Snappy compression library (v3)

Google's Snappy data compression library is a faster alternative to LZO,
optimized for x86-64. On compressible input it compresses ~2.5x faster than LZO
and decompresses ~1.5-2x faster than LZO. On incompressible input, it skips the
input at 100x faster than LZO and decompresses ~4x faster than LZO.
It is released under BSD license.
This is a kernel port from user space C++ code.
The current intended use is with zram (see next patch in series).

Signed-off-by: Zeev Tarantov <zeev.tarantov@gmail.com>
Signed-off-by: Willi Ye <williye97@gmail.com>

Conflicts:
	drivers/staging/Makefile
csnappy: Update to newest version

Pulled on 18/04/2013
enable snappy in cmdline

Signed-off-by: Willi Ye <williye97@gmail.com>

Conflicts:
	ramdisk/build.sh
intelli_plug: move to its own directory. It's been cross platform for a while

intelli_plug driver has been working on OMAP44xx, TEGRA 3, Exynos and
MSM Krait/Cortex multi-core SOCs.  So it doesn't make sense to patch on a per
SOC basis, move it to its own ARM platform independent folder so patches can
apply to all supported ARM platforms

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

Conflicts:
	arch/arm/mach-msm/Kconfig
	arch/arm/mach-msm/Makefile

Conflicts:
	arch/arm/mach-msm/Kconfig
	arch/arm/mach-msm/Makefile
keep intelli plug up to date

Signed-off-by: Willi Ye <williye97@gmail.com>
block: cgroups, kconfig, build bits for BFQ-v6r2-3.4

Update Kconfig.iosched and do the related Makefile changes to include
kernel configuration options for BFQ. Also add the bfqio controller
to the cgroups subsystem.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
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.0

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>
intelli_plug: refactor stats calculation code to be less intrusive

this is done for those kernels which do not have 100% source code available
and must use existing closed source modules such as wifi drivers

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

Conflicts:
	kernel/sched/core.c

Conflicts:
	arch/arm/mach-msm/intelli_plug.c
	kernel/sched/core.c
Intelli_plug: kernel sched/core: add per cpu nr_running stats

Signed-off-by: Paul Reioux <reioux@gmail.com>
ramdisk: remove wp module insmod

Signed-off-by: Willi Ye <williye97@gmail.com>
config dump

Signed-off-by: Willi Ye <williye97@gmail.com>
synapse: add intelli plug checkbox

Signed-off-by: Willi Ye <williye97@gmail.com>
use a different version of prima

Signed-off-by: Willi Ye <williye97@gmail.com>
add Battery Control

Signed-off-by: Willi Ye <williye97@gmail.com>