asoc: msm: Enable spammy MBHC debugging

 * Accidentally got removed from previous patch. Enable spammy debugging
   so we can collect data about more types of headsets.

Change-Id: If65168e2fbb470562433f9738886025c51096ff6
asoc: msm: More MBHC tunings!

 * All day every day!
 * It seems that certain OEM handset makers who are also in the
   accessory biz have chosen resistence values which lie directly
   on the threshold of the reference design. I can only think of
   a few reasons why someone would do this.
 * Nice trolling, Xiaomi :)

Change-Id: I0ff08b0f2253f10422f16f00ef5a8911455c5348
asoc: msm: MBHC tunings forever!

 * Franco's Apple headset is right on the boundary for HIGH_HPH.
 * Move the threshold down to 180.

Change-Id: I487af13663cb74d55ff8a270bda917537284966f
sched: Rollback upstream backport

 * There are some stability issues under certain loads with this
   patchset. Rollback until we can revisit.

Revert "[backport] sched_rt: Upstream fixes"

This reverts commit 3aef4fdd36c3db6f5df88629ab0a9d6c42bae26c.

Revert "[backport] sched: Misc upstream scheduler improvements"

This reverts commit fa16d20f1c90bb0d7955b194d450891de680494e.

Revert "[backport]: sched: Load-based CPU boosting"

This reverts commit 54d5731ffe5a109691de3f61eeda14bd42942325.

Revert "sched: Remove get_online_cpus() usage"

This reverts commit 86b047357013e1d5c5547fd6d466dd75b90afc81.

Change-Id: I8bb638023a95df7ae7a44b06017c0190985e3f22
sched: fix race between try_to_wake_up() and move_task()

Until a task's state has been seen as interruptible/uninterruptible
and it is no longer on_cpu, it is possible that the task may move
to another CPU (load balancing may cause this). Here is an example
where the race condition results in incorrect operation:

- cpu 0 calls put_prev_task on task A, task A's state is TASK_RUNNING
- cpu 0 runs task B, which attempts to wake up A
- cpu 0 begins try_to_wake_up(), recording src_cpu for task A as cpu 0
- cpu 1 then pulls task A (perhaps due to idle balance)
- cpu 1 runs task A, which then sleeps, becoming INTERRUPTIBLE
- cpu 0 continues in try_to_wake_up(), thinking task A's previous
  cpu is 0, where it is actually 1
- if select_task_rq returns cpu 0, task A will be woken up on cpu 0
  without properly updating its cpu to 0 in set_task_cpu()

Change-Id: I870f7ffefe30ba2aae1114fd5e66d1a73e6a54fb
CRs-Fixed: 665958
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
video: mdss: Sunlight readability enhancement support

 * This hardware supports a postprocessing mode which improves
   readbility in bright sunlight. Add support for enabling
   this mode when the backlight value crosses a threshold.
 * Enable the feature using /sys/class/graphics/fb0/sre
 * Also add a max backlight level for using CABC. It's not
   effective at full brightness and causes too much visible
   distortion with many images.

Change-Id: I213eb5d91e526c80a0dc88e6e05e6d6f35841fdf
fs: sync: added fsync on/off support

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

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.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
fs: sync: Make sync() satisfy many requests with one invocation

Dave Jones reported RCU stalls, overly long hrtimer interrupts, and
amazingly long NMI handlers from a trinity-induced workload involving
lots of concurrent sync() calls (https://lkml.org/lkml/2013/7/23/369).
There are any number of things that one might do to make sync() behave
better under high levels of contention, but it is also the case that
multiple concurrent sync() system calls can be satisfied by a single
sys_sync() invocation.

Given that this situation is reminiscent of rcu_barrier(), this commit
applies the rcu_barrier() approach to sys_sync().  This approach uses
a global mutex and a sequence counter.  The mutex is held across the
sync() operation, which eliminates contention between concurrent sync()
operations.  The counter is incremented at the beginning and end of
each sync() operation, so that it is odd while a sync() operation is in
progress and even otherwise, just like sequence locks.

The code that used to be in sys_sync() is now in do_sync(), and sys_sync()
now handles the concurrency.  The sys_sync() function first takes a
snapshot of the counter, then acquires the mutex, and then takes another
snapshot of the counter.  If the values of the two snapshots indicate that
a full do_sync() executed during the mutex acquisition, the sys_sync()
function releases the mutex and returns ("Our work is done!").  Otherwise,
sys_sync() increments the counter, invokes do_sync(), and increments
the counter again.

This approach allows a single call to do_sync() to satisfy an arbitrarily
large number of sync() system calls, which should eliminate issues due
to large numbers of concurrent invocations of the sync() system call.

Changes since v1 (https://lkml.org/lkml/2013/7/24/683):

o	Add a pair of memory barriers to keep the increments from
	bleeding into the do_sync() code.  (The failure probability
	is insanely low, but when you have several hundred million
	devices running Linux, you can expect several hundred instances
	of one-in-a-million failures.)

o	Actually CC some people who have experience in this area.

Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Curt Wohlgemuth <curtw@google.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: linux-fsdevel@vger.kernel.org

Signed-off-by: Paul Reioux <reioux@gmail.com>
block: cgroups, kconfig, build bits for BFQ-v6r2 for 3.4

Update Kconfig.iosched to include kernel configuration options
for BFQ. Add a Kconfig option and do the related Makefile changes
to compile the scheduler. Also let the cgroups subsystem know about
the BFQ I/O controller.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Kconfig.iosched
	block/Makefile

Conflicts:
	block/Makefile
block: introduce the BFQ-v7r4 I/O sched for 3.4
block, bfq: add Early Queue Merge (EQM) to BFQ-v7r4 for 3.4.0"
block: bfq: Squashed update from BFQ-v7r4 to BFQ-v7r5

Change-Id: I749ef141246db7020cec0b10d980ec854a572603
ak_bacon_defconfig: enable BFQ
sched/debug: disable sched debug sysrq by default - increase performance
cfq-iosched: update tunables with mainline
bfq-iosched: Tuning for SSD
bfq-iosched: Set bfq_back_penalty = 1
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>