msm-sleeper: save previous max freq, add ex_max_freq interface, loosen permissions

Change-Id: Ic7d37089adc091f56929b3d9d81150881df73904
Added fsync on/off support.

Change-Id: I60d9533981fdb81538f606e6f6b2f3c3ab7dac70
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
fs: sync: enable fsync by default.

Change-Id: I3e4159f80683fbb785c9e24ee3e400e4108717af
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
fs: sync: add missing return if fsync is disabled from userspace.

Change-Id: I16e2f70e2033222b559e97726dad69e1c57beca1
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
switch do_fsync() to fget_light()

Change-Id: If13af3de7bf31949af4e2a6c6b9728ca23a23621
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: flar2 <asegaert@gmail.com>
backlight: enable backlight dimmer by default, update min value of auto & manual level

Conflicts:

	arch/arm/boot/dts/msm8974-hammerhead/msm8974-hammerhead-misc.dtsi

Change-Id: I9ae3db350acac63efa6c00ffc80ad2a93a55e732
backlight dimmer: change back min level to 5, so it's safe for everyone

Change-Id: Id94e740d9fc8451de8bf34140f31d0329f266d47
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>

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Change-Id: I984ac3fe74d090613636ef8f8a27d46faf00f97e
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 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.

Change-Id: I55cbbeafec52d4ec4873f4fcf1974e24ea8f3668
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
GPU: optimize build with -Ofast

Change-Id: I6c7ee3b3b03adcf16da193f668a43186d52976c3