config: Touch Control Support
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>
Revert "input: lge: use the old 100px finger movement code for CPU frequency boostpulse instead of using interactive's built in input_boost which didn't always work perfectly."

This reverts commit b71e45ddbd8483a6018d3fd64fbf4ae22a29b059.
Revert "drivers: input: disable onlining the second core on screen touch for now."

This reverts commit 13fe2889a354cb41cef2a7858f1d5587051859b2.
Revert "drivers: input: clean up the boospulse call detection funtion."

This reverts commit 3700c0d7c91961845a40933f12fbf497674db139.
Revert "drivers: input: instead of calling boostpulse every touch input now we only call it if our finger moves 100 pixels away from the original input."

This reverts commit ebbbd1e49d8b648eb3e3579d6bef7e5d3b96fc73.
lge_touch_core: Simpler method of boosting the cpu frequency on touch
intellidemand: Activate Touch Boost
ondemand: Set boosfreq to 1242mhz (for Touch Boost)
cpufreq: intellidemand: Change optimal_freq to 1242mhz
cpufreq: ondemand: Set optimal_freq to 864mhz and sync_freq to 1350mhz