Add schedulers and governors
User voltage control for msm-cpufreq device
Set scheduler to prefer battery life over Performance
Overclock the slimbus for better audio
Further optimize Slimbus clocks for optimal audio quality
media-device: fix infoleak in ioctl media_enum_entities()
2-way stereo call recording patch
Sound Control: WCD9320: expose additional controls

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
sound control 3.x: Initial GPL release for WCD9320 Audio Codec

This is first official GPL release based on my private implementation.

This release has been tested for xperia Z officially.  It may work
with other devices using the same WCD9320 Audio Codec as well, but not tested

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

Conflicts:
	sound/soc/codecs/Makefile
sound control: WCD9320: update speaker gain control for Z1

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
Sound Control: (Optional) work around for Nexus 4/5 audio issues

(Use this only for devices with audio reset issues)

Also bump version to 3.1

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

wcd9xxx-core: add register write without mutex protection

This is assuming the calling function will take care of the mutex.

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
Sound Control: (OPTIONAL) add power amp registers access control as well

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
sound control: add register cache

bump to version 3.2

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

Conflicts:
	sound/soc/codecs/wcd9320.c
Signed-off-by: flar2 <asegaert@gmail.com>
Sound Control 3.x: adaptation for HTC One (M8)

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
readahead: make context readahead more conservative

This helps performance on moderately dense random reads on SSD.

Transaction-Per-Second numbers provided by Taobao:

		QPS	case
		-------------------------------------------------------
		7536	disable context readahead totally
w/ patch:	7129	slower size rampup and start RA on the 3rd read
		6717	slower size rampup
w/o patch:	5581	unmodified context readahead

Before, readahead will be started whenever reading page N+1 when it happen
to read N recently.  After patch, we'll only start readahead when *three*
random reads happen to access pages N, N+1, N+2.  The probability of this
happening is extremely low for pure random reads, unless they are very
dense, which actually deserves some readahead.

Also start with a smaller readahead window.  The impact to interleaved
sequential reads should be small, because for a long run stream, the the
small readahead window rampup phase is negletable.

The context readahead actually benefits clustered random reads on HDD
whose seek cost is pretty high.  However as SSD is increasingly used for
random read workloads it's better for the context readahead to concentrate
on interleaved sequential reads.

Another SSD rand read test from Miao

        # file size:        2GB
        # read IO amount: 625MB
        sysbench --test=fileio          \
                --max-requests=10000    \
                --num-threads=1         \
                --file-num=1            \
                --file-block-size=64K   \
                --file-test-mode=rndrd  \
                --file-fsync-freq=0     \
                --file-fsync-end=off    run

shows the performance of btrfs grows up from 69MB/s to 121MB/s, ext4 from
104MB/s to 121MB/s.

Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Tested-by: Tao Ma <tm@tao.ma>
Tested-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: flar2 <asegaert@gmail.com>

Conflicts:
	mm/readahead.c
nohz: Reduce overhead under high-freq idling patterns

One testbox of mine (Intel Nehalem, 16-way) uses MWAIT for its idle routine,
which apparently can break out of its idle loop rather frequently, with
high frequency.

In that case NO_HZ_FULL=y kernels show high ksoftirqd overhead and constant
context switching, because tick_nohz_stop_sched_tick() will, if
delta_jiffies == 0, mis-identify this as a timer event - activating the
TIMER_SOFTIRQ, which wakes up ksoftirqd.

Fix this by treating delta_jiffies == 0 the same way we treat other short
wakeups, delta_jiffies == 1.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Geoff Levand <geoff@infradead.org>
Cc: Gilad Ben Yossef <gilad@benyossef.com>
Cc: Hakan Akkan <hakanakkan@gmail.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
mm: slub: Default slub_max_order to 0

To avoid locking and per-cpu overhead, SLUB optimisically uses
high-order allocations up to order-3 by default and falls back to
lower allocations if they fail. While care is taken that the caller
and kswapd take no unusual steps in response to this, there are
further consequences like shrinkers who have to free more objects to
release any memory. There is anecdotal evidence that significant time
is being spent looping in shrinkers with insufficient progress being
made (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.

SLUB is now the default allocator and some bug reports have been
pinned down to SLUB using high orders during operations like
copying large amounts of data. SLUBs use of high-orders benefits
applications that are sized to memory appropriately but this does not
necessarily apply to large file servers or desktops.  This patch
causes SLUB to use order-0 pages like SLAB does by default.
There is further evidence that this keeps kswapd's usage lower
(https://lkml.org/lkml/2011/5/10/383).

Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: flar2 <asegaert@gmail.com>
block: Reserve only one queue tag for sync IO if only 3 tags are available

In case a device has three tags available we still reserve two of them
for sync IO. That leaves only a single tag for async IO such as
writeback from flusher thread which results in poor performance.

Allow async IO to consume two tags in case queue has three tag availabe
to get a decent async write performance.

This patch improves streaming write performance on a machine with such disk
from ~21 MB/s to ~52 MB/s. Also postmark throughput in presence of
streaming writer improves from 8 to 12 transactions per second so sync
IO doesn't seem to be harmed in presence of heavy async writer.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: flar2 <asegaert@gmail.com>
msm: kgsl: Fix nice level for higher priority GPU start thread

Before, we were actually setting the lowest possible priority.

Change-Id: I3a52de949eee0faea8061dd91ed303fa8231f0d4

Signed-off-by: flar2 <asegaert@gmail.com>

Conflicts:
	drivers/gpu/msm/adreno.c
Add fsync option

Signed-off-by: flar2 <asegaert@gmail.com>

Conflicts:
	fs/sync.c