arch/arm/configs: rin defconfigs added
Voltage Control: generic voltage control for DTS based kernels

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

Conflicts:
	arch/arm/mach-msm/clock-krait-8974.c
	drivers/cpufreq/cpufreq.c

Conflicts:
	arch/arm/mach-msm/Kconfig
Add schedulers and governors
firmware/synaptics: Add g3_global_com variant firmware
Ad Intelliactive/lagfree/lionheart/smartassv2 Governors
drivers/cpufreq: Remove interactivex
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: (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>
Sound Control: (OPTIONAL) add power amp registers access control as well

Signed-off-by: Paul Reioux <reioux@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
sound control: Samsung Microphone compatibility fixup

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: expose direct register manipulations to userspace

bump driver version to 3.3

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: Misc clean up for newer WCD9xxx SOCs

Bump driver version to 3.4

Change-Id: Idaf374634368e61ba1fc9e24d0c5e1a994271400
Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: let register lock be dependent on different HW revisions

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: separate locking mechanism for recording and playback

with newer hardware revisions coming from Qualcomm, single register lock
control isn't sufficient to cover both playback and recording usage scenarios

bump to version 3.5

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: add line gain to cached and register lock

bump version to 3.6

Signed-off-by: Paul Reioux <reioux@gmail.com>
drivers/usb/gadget: Changes for DriveDroid support
arch/arm/configs: Enable DriveDroid support for rin builds
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>

Conflicts:
	fs/sync.c

Conflicts:
	fs/sync.c
2-way stereo call recording patch