umbrella_core: always abide by the user settings
raccoon_city: initial skeleton of future governor

This governor is a WIP. The aim is to provide a performance governor
that does not run the phone at max during suspend to prevent
unnecessary drain.
ramdisk: move secure storage to custom, disabled
build: update kernel identification for new design
intelli_plug: add performance boost option

also fixed dependency on __cpuinit

bumped to version 3.9

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

Ported from arm64 by LoungeKatt
build: update configuration for new kernel governor
block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For
example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the
dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives
in
the tree. The key into the tree is called vios (virtual I/O). Every
request
has vios, which is calculated according to its ioprio, request size and
so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the
task
dispatch request. The dispatched request's vios is then added to the
task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with
I/O
less writeback, usually a task can only dispatch either sync or async
requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

Signed-off-by: Paul Reioux <reioux@gmail.com>
block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority
A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly,
we preserve its vios key, so it will not lost its share. This should work
for task driving big queue depth. For single depth task, there is no approach
to preserve its vios key.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops bias sync workload

If there are async requests running, delay async workload. Otherwise
async workload (usually very deep iodepth) will use all queue iodepth
and later sync requests will get long delayed. The idea is from CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add some trace information

Add some trace information, which is helpful when I do debugging.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
FIOPS: forward port for use on 3.10 Linux

Signed-off-by: Paul Reioux <reioux@gmail.com>
build: update configuration and fix stray settings
Tap2Unlock - a new screen wake feature similar to d2w and s2w

Divide your screen vertically and horizontally
They are numbered as
          1 | 2
          -----
          3 | 4
The pattern is stored in sysfs file sys/android_touch/tap2unlock_pattern
You tap the right combination to open your screen
Pressing the power button will turn your display on but not the touch
sensor.

version 1.0
-Ability - 4 number pattern (will be improved)
-Currently the pattern gets rstored to 1234 after every boot
(This can only be fixed if a kernel mod app provides support for it in
the future.)

All copyrights of t2u is reserved with goutamniwas
<goutamniwas@gmail.com>
Many credits to showp-1984 for his D2w which made this possible.

Note: This was ported from the original commits listed at
http://forum.xda-developers.com/android/software-hacking/kernel-tap2unlo
ck-tap2wake-feature-t2965344 but is poorly written and will most likely
break. This is only an attempt to salvage the concept
t2u : fix screen freeze after wakeup during call
t2u : Improve t2u detect algorithm much much better
The bad algorithm due to import from dt2w and some bad implementations by me
Improve it to the best possible , by simplifying the algorithm
removing unwanted stuffs

fix loopback problem
touch count : 1 2 3 4
input value : 2 3 4 1

now its more accurate and works after a single pattern input after deepsleep

enable check time gap between every two touches
if long then clear previous touch and consider the 2nd as the first
t2u : Make t2u secure
this means that you will need to know the old pattern , to change the new pattern
also the sysfs file tap2unlock_pattern will not show the pattern

It is now used to authenticate pattern change for the t2u app

inputdata for tap2unlock_pattern = xxxxyyyy (x=old pin y = new pin)
if success output : 1 or else 0
t2u : Fix previous commit - make t2u secure