input: touchboost: boost less and for less time on thread migrations and load based syncs.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	drivers/cpufreq/cpu-boost.c

Change-Id: Ia2104a1ad7d73d992426da5359ec43c9a9ff1f9e
input: touchboost: shut up.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
3.4.84

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	Makefile
	drivers/ata/libata-core.c

Change-Id: Ief919b6749099e59c724264cc92416b5113037ea
3.4.85 and .86

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>

Conflicts:
	net/ceph/osd_client.c
	sound/core/compress_offload.c

Change-Id: I457cba9ad9f44d4795c39cacf10dfc076ec2e6ec
I/O Schedulers: add BFQ & VR
block/bfq-iosched.c: GCC 4.8.x compatibility fixup

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

Conflicts:
	block/bfq-iosched.c

Change-Id: Ibcdc5481e715b8a7bc689c1dbfe4a739e56cb52d
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/Makefile

Conflicts:
	block/Kconfig.iosched

Change-Id: I3d6ca28eed25b71a03cf292dc8b9a02d7b32ed17
block: add Kconfig & Makefile flags for VR iosched

Change-Id: Ib7eb15f62f9ec2c7b7fa055f147725e8cc8cfc70
block: add SIO iosched

Change-Id: I3d41ca5c944226a97b23952077bf83928e752ff0
defconfig: enable new I/O Schedulers (SIO, FIOPS, VR, BFQ)

Change-Id: I237b1986bb195ca31c986a754edc73341a5ec895

Conflicts:
	arch/arm/configs/cm_rhine_honami_row_defconfig
	arch/arm/configs/pimped_rhine_honami_defconfig
block: fix VR iosched

Change-Id: I1cb67c124048f09e60d9b8e52ec794858bcdd4f0
clock-krait/cpufreq: custom voltage control v1

* TODO: control only available frequencies
deadline: tweak generally recommended for SSDs
deadline: Allow 0ms deadline latency, increase the read speed

Change a timer compare from after to after-equals, thus allowing
0 timeout and making deadline schedule FIFO.

Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Add defconfig flag for the VDD Control

Change-Id: I357d023cd05e49eab6b883a1456a06449ac31275
defconfig: enable VDD Control

Change-Id: I0cc05d5324496ad082fd8dd1b7599dc72fcc25e2

Conflicts:
	arch/arm/configs/cm_rhine_honami_row_defconfig
	arch/arm/configs/pimped_rhine_honami_defconfig
mach-msm: forgot Kconfig flag for VDD Control

Change-Id: Ic93b3933ce30808e2cf9c7a3af4688392f098a4a

Conflicts:
	arch/arm/mach-msm/Kconfig

Conflicts:
	arch/arm/mach-msm/Kconfig
LCD_KCAL: Color Control driver for Moto G
LCD_KCAL: porting to Xperia Z1 (part 2)

Conflicts:
	arch/arm/mach-msm/board-8974.c

Change-Id: I6f7f1137fc3e274d5d60f0e5319ad3b7b813d79d

Conflicts:
	arch/arm/mach-msm/Makefile
	arch/arm/mach-msm/board-8974.c
	drivers/video/msm/mdss/Kconfig
defconfig: enable LCD_KCAL & 80211_WEXT

Change-Id: I8aac860c510e6d4867eefb81ca30ac6b1d520588