cpu governor DevilQ, based off lulzactiveQ by gokhanmoral

Change-Id: I4381bdb0a964f9015e6b1e62e137dd5013b9da34

Conflicts:
	drivers/cpufreq/Kconfig
	drivers/cpufreq/Makefile
	include/linux/cpufreq.h

	modified:   drivers/cpufreq/Kconfig added devilq governor
	modified:   drivers/cpufreq/Makefile added devilq governor
	new file:   drivers/cpufreq/cpufreq_devilq.c added devilq governor
	modified:   include/linux/cpufreq.h added devilq governor
added devilq governor
devilQ: use atleast 2 cores, if touchscreen pressed, i9300 part

Change-Id: I58012684d367c11ee3178d779442588c9571ff5e

Conflicts:
	drivers/input/touchscreen/mms_ts.c

	modified:   drivers/cpufreq/Kconfig add devilq governor [thanks to DerTeufel]
	modified:   drivers/cpufreq/Makefile add devilq governor [thanks to DerTeufel]
	modified:   drivers/input/touchscreen/mms_ts.c devilQ: use at least 2 cores, if touchscreen pressed
	modified:   include/linux/cpufreq.h add devilq governor [thanks to DerTeufel]
devilq: screen_off parameters

Change-Id: I6bdd5afd18d8c7859c77908d3f1df0a0cc5277e7
devilq: fix a mistake with suspend_max_cpu + version 0.19.7

Change-Id: I480e549c0592426e781c5dffb75d2736b078cd95

Conflicts:
	build_combo.sh
	drivers/cpufreq/cpufreq_devilq.c

	new file:   build_combo.sh deleted because of deprecated and not needed
	deleted:    build_combo.sh deprecated and not needed
	modified:   drivers/cpufreq/cpufreq_devilq.c devilq changes
devilq: new tunable: max online cpus while screen off

Change-Id: I9876575a18809a47b3e21331440a4dacf5c81fda

Conflicts:
	build_combo.sh
	drivers/cpufreq/cpufreq_devilq.c

	modified:   drivers/cpufreq/cpufreq_devilq.c devilq: new tunable: max online cpus while screen off
cpufreq: pegasusq: Change the calculation of target frequency:
based off this commit by stratosk: https://github.com/torvalds/linux/commit/dfa5bb622555d9da0df21b50f46ebdeef390041b

Change-Id: I6207f61cc706a4d50863b3a32f69bf210812b8a9
pegasusq: Add core count load biasing, multiple freq-steps, and fast-down scaling logics.

Original implementations based on Samsung's new sources.

Conflicts:
	drivers/cpufreq/cpufreq_pegasusq.c

Change-Id: Iedd6d6cdcae30af848b4143ce202fb907289ddbf

Conflicts:
	drivers/cpufreq/cpufreq_pegasusq.c

	modified:   drivers/cpufreq/cpufreq_devilq.c added devilq governor with new tunables
	modified:   drivers/cpufreq/cpufreq_pegasusq.c add core count load biasing, multiple freq-steps, and fast-down scaling logics
Add core count load biasing, multiple freq-steps, and fast-down scaling logics
drivers/cpufreq/cpufreq_pegasusq.c: introduce fast down

Change-Id: I0e374002299d974fac11cc7d489cc3c6dec1adb1

Conflicts:
	drivers/cpufreq/cpufreq_pegasusq.c

	modified:   drivers/cpufreq/cpufreq_pegasusq.c introduce fast down
mali_control: gpu oc up to 800 mhz, display gpu volt as mV

Change-Id: I58d72be87176acfefdf2e03a63b4af21790858a3

Conflicts:
	drivers/misc/mali_control.c

	modified:   drivers/cpufreq/cpufreq_pegasusq.c introduce fast down
	new file:   drivers/misc/mali_control.c mali_control: gpu OC up to 800MHz; display gpu volt as mV
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
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>

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Change-Id: I618b36b51ce02e5b219e99e2e69157f746f57c41

Conflicts:
	block/Kconfig.iosched
	block/Makefile

	modified:   block/Kconfig.iosched block: fiops io sched core
	modified:   block/Makefile block: fiops io sched core
	new file:   block/fiops-iosched.c block: fiops io sched core
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>
lulzactiveq: small fixes

Change-Id: Ib211ca93bd434f4de0c137e4e8639193bf32d619

Conflicts:
	drivers/cpufreq/cpufreq_lulzactiveq.c

	modified:   block/Kconfig.iosched added fiops io sched tweaks
	modified:   block/Makefile added fiops io sched tweaks
	modified:   drivers/cpufreq/cpufreq_lulzactiveq.c small fixes/tweaks [DerTeufel]
lulzactiveq governor tweaks