misc: fsa9485: convert to use themodule_i2c_driver() macro

* Bring in line with caf&korg 3.4.y fsa9480 driver

MISC: convert drivers/misc/* to use module_i2c_driver()

This patch converts the drivers in drivers/misc/* to use the
module_i2c_driver() macro which makes the code smaller and a bit
simpler.

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Michael Hennerich <hennerich@blackfin.uclinux.org>
Cc: Anantha Narayanan <Anantha.Narayanan@intel.com>
Cc: Hemanth V <hemanthv@ti.com>
Cc: Christoph Mair <christoph.mair@gmail.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Ben Gardner <bgardner@wabtec.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Kalhan Trisal <kalhan.trisal@intel.com>
Cc: Darrick J. Wong <djwong@us.ibm.com>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

misc: fsa9480: Remove obsolete cleanup for clientdata

A few new i2c-drivers came into the kernel which clear the clientdata-pointer
on exit or error. This is obsolete meanwhile, the core will do it.

Change-Id: Ie172160e0b9241beca7bd22f38087070d15e6ec9
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
d2: Remove board-m2-regulator. We use board-8960-regulator.

Change-Id: I9d10a8a3e1c3071af078f49c635182383e9bd5fa
msm: Forward-port Samsung's ramdump extensions

 * Port forward from the stock kernel source.
 * Necessary for debugging, no impact if disabled.

Change-Id: Iddad6c08a182f3207e4579712eb24cffc34ee898
block: row: Fix starvation tolerance values

The current starvation tolerance values increase the boot time
since high priority SW requests are delayed by regular priority requests.
In order to overcome this, increase the starvation tolerance values.

Change-Id: I9947fca9927cbd39a1d41d4bd87069df679d3103
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Maya Erez <merez@codeaurora.org>
msm: Move video firmware base down to the right location

Change-Id: Id80f07b2f07cf8387d9fe5ef14fde955393e827d
d2: Update defconfigs

 * Set ROW as default I/O scheduler, as it now provides a faster boot.
 * Raise default loglevel to 7 for better last_kmsg logs.

Change-Id: I8b1cb3da3f42f2aa4dedd13db7e3658c98744ef7
Revert "msm: pm-8x60: Do not default to WFI when not enabled"

This reverts commit 10bc53532071915f3a19091b8c3db39bfe404263.
msm: hotplug: wait for hotplug completion event from secondary core

Primary core has to wait for hotplug completion event from secondary
core to avoid race between ongoing hotplug and already queued online
event. This also prevent CPU_DEAD notifiers from executing before the
SPM has completed the collapse of the CPU. CPU DEAD notifiers executing
early have been attributed to MDD hardware block for the CPU being
turned off prematurely, resulting in crashes.

The patch also adds support for probing with device tree for 8974
targets.

Change-Id: I8c155324adfee35825181bbf7b28a52b87ca2938
CRs-fixed: 438314,457541
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: pm: Add support to query cpu status

During hotplug operation primary core is required to query
cpu registers to determine whether secondary core has
successfully shutdown.

Change-Id: I9dc359e2af20f79127a74f2c087fa39614f18957
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
d2: Add sleep status device

Change-Id: Ie0a3eb1376eff7fa48c28841c47d997a54f62943
cpufreq: interactive: when input_boost is enabled lets just boost to 702MHz instead of 1512MHz (hispeed_freq).

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

Conflicts:

	drivers/cpufreq/cpufreq_interactive.c

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
cpufreq: interactive: boost cpufreq to 1GHz on input, instead of 702MHz.

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

Conflicts:

	drivers/cpufreq/cpufreq_interactive.c

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
cpufreq: interactive: add input_boost_freq userspace tunable.

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

Conflicts:

	drivers/cpufreq/cpufreq_interactive.c

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
cpufreq: interactive: set input_boost perms to 666
we've set the other sysfs files to universal permissions for easy implementation through powerHAL and apps
really only too keep things in uniform for now
Signed-off-by: Luis Cruz <ljc2491@gmail.com>
arm: mutex: merge Will Deacon's patch for including a different implementationfor mutexes for ARM6+ chips. Didn't cherry pick original patches because they conflicted for some reason and I felt too lazy to fix the conflict.

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

Conflicts:

	arch/arm/include/asm/mutex.h

Signed-off-by: Luis Cruz <ljc2491@gmail.com>
mutex: Make more scalable by doing less atomic operations

Date	Thu, 4 Apr 2013 10:54:16 -0400

In the __mutex_lock_common() function, an initial entry into
the lock slow path will cause two atomic_xchg instructions to be
issued. Together with the atomic decrement in the fast path, a total
of three atomic read-modify-write instructions will be issued in
rapid succession. This can cause a lot of cache bouncing when many
tasks are trying to acquire the mutex at the same time.

This patch will reduce the number of atomic_xchg instructions used by
checking the counter value first before issuing the instruction. The
atomic_read() function is just a simple memory read. The atomic_xchg()
function, on the other hand, can be up to 2 order of magnitude or even
more in cost when compared with atomic_read(). By using atomic_read()
to check the value first before calling atomic_xchg(), we can avoid a
lot of unnecessary cache coherency traffic. The only downside with this
change is that a task on the slow path will have a tiny bit
less chance of getting the mutex when competing with another task
in the fast path.

The same is true for the atomic_cmpxchg() function in the
mutex-spin-on-owner loop. So an atomic_read() is also performed before
calling atomic_cmpxchg().

The mutex locking and unlocking code for the x86 architecture can allow
any negative number to be used in the mutex count to indicate that some
tasks are waiting for the mutex. I am not so sure if that is the case
for the other architectures. So the default is to avoid atomic_xchg()
if the count has already been set to -1. For x86, the check is modified
to include all negative numbers to cover a larger case.

The following table shows the scalability data on an 8-node 80-core
Westmere box with a 3.7.10 kernel. The numactl command is used to
restrict the running of the high_systime workloads to 1/2/4/8 nodes
with hyperthreading on and off.

+-----------------+------------------+------------------+----------+
|  Configuration  | Mean Transaction | Mean Transaction | % Change |
|		  |  Rate w/o patch  | Rate with patch  |	   |
+-----------------+------------------------------------------------+
|		  |              User Range 1100 - 2000		   |
+-----------------+------------------------------------------------+
| 8 nodes, HT on  |      36980       |      148590      | +301.8%  |
| 8 nodes, HT off |      42799       |      145011      | +238.8%  |
| 4 nodes, HT on  |	 61318       |      118445      |  +51.1%  |
| 4 nodes, HT off |     158481       |      158592      |   +0.1%  |
| 2 nodes, HT on  |     180602       |      173967      |   -3.7%  |
| 2 nodes, HT off |     198409       |      198073      |   -0.2%  |
| 1 node , HT on  |     149042       |      147671      |   -0.9%  |
| 1 node , HT off |     126036       |      126533      |   +0.4%  |
+-----------------+------------------------------------------------+
|		  |              User Range 200 - 1000		   |
+-----------------+------------------------------------------------+
| 8 nodes, HT on  |      41525       |      122349      | +194.6%  |
| 8 nodes, HT off |      49866       |      124032      | +148.7%  |
| 4 nodes, HT on  |	 66409       |      106984      |  +61.1%  |
| 4 nodes, HT off |     119880       |      130508      |   +8.9%  |
| 2 nodes, HT on  |     138003       |      133948      |   -2.9%  |
| 2 nodes, HT off |     132792       |      131997      |   -0.6%  |
| 1 node , HT on  |     116593       |      115859      |   -0.6%  |
| 1 node , HT off |     104499       |      104597      |   +0.1%  |
+-----------------+------------------+------------------+----------+
AIM7 benchmark run has a pretty large run-to-run variance due to random
nature of the subtests executed. So a difference of less than +-5%
may not be really significant.

This patch improves high_systime workload performance at 4 nodes
and up by maintaining transaction rates without significant drop-off
at high node count.  The patch has practically no impact on 1 and 2
nodes system.

The table below shows the percentage time (as reported by perf
record -a -s -g) spent on the __mutex_lock_slowpath() function by
the high_systime workload at 1500 users for 2/4/8-node configurations
with hyperthreading off.

+---------------+-----------------+------------------+---------+
| Configuration | %Time w/o patch | %Time with patch | %Change |
+---------------+-----------------+------------------+---------+
|    8 nodes    |      65.34%     |      0.69%       |  -99%   |
|    4 nodes    |       8.70%	  |      1.02%	     |  -88%   |
|    2 nodes    |       0.41%     |      0.32%       |  -22%   |
+---------------+-----------------+------------------+---------+
It is obvious that the dramatic performance improvement at 8
nodes was due to the drastic cut in the time spent within the
__mutex_lock_slowpath() function.

The table below show the improvements in other AIM7 workloads (at 8
nodes, hyperthreading off).

+--------------+---------------+----------------+-----------------+
|   Workload   | mean % change | mean % change  | mean % change   |
|              | 10-100 users  | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests     |     +0.6%     |   +104.2%      |   +185.9%       |
| five_sec     |     +1.9%     |     +0.9%      |     +0.9%       |
| fserver      |     +1.4%     |     -7.7%      |     +5.1%       |
| new_fserver  |     -0.5%     |     +3.2%      |     +3.1%       |
| shared       |    +13.1%     |   +146.1%      |   +181.5%       |
| short        |     +7.4%     |     +5.0%      |     +4.2%       |
+--------------+---------------+----------------+-----------------+
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mutex: restrict mutex spinning to only one task per mutex

Date	Thu, 4 Apr 2013 10:54:17 -0400

The current mutex spinning code allow multiple tasks to spin on a
single mutex concurrently. There are two major problems with this
approach:

 1. This is not very energy efficient as the spinning tasks are not
    doing useful work. The spinning tasks may also block other more
    important or useful tasks from running as preemption is disabled.
    Only one of the spinners will get the mutex at any time. The
    other spinners will have to wait for much longer to get it.

 2. The mutex data structure on x86-64 should be 32 bytes. The spinning
    code spin on lock->owner which, in most cases, should be in the same
    64-byte cache line as the lock->wait_lock spinlock. As a result,
    the mutex spinners are contending the same cacheline with other
    CPUs trying to get the spinlock leading to increased time spent
    on the spinlock as well as on the mutex spinning.

These problems are worse on system with large number of CPUs. One way
to reduce the effect of these two problems is to allow only one task
to be spinning on a mutex at any time.

This patch adds a new spinner field in the mutex.h to limit the
number of spinner to only one task. That will increase the size of
the mutex by 8 bytes in a 64-bit environment (4 bytes in a 32-bit
environment).

The AIM7 benchmarks were run on 3.7.10 derived kernels to show the
performance changes with this patch on a 8-socket 80-core system
with hyperthreading off.  The table below shows the mean % change
in performance over a range of users for some AIM7 workloads with
just the less atomic operation patch (patch 1) vs the less atomic
operation patch plus this one (patches 1+2).

+--------------+-----------------+-----------------+-----------------+
|   Workload   | mean % change   | mean % change   | mean % change   |
|              | 10-100 users    | 200-1000 users  | 1100-2000 users |
+--------------+-----------------+-----------------+-----------------+
| alltests     |     -0.2%       |     -3.8%       |    -4.2%        |
| five_sec     |     -0.6%       |     -2.0%       |    -2.4%        |
| fserver      |     +2.2%       |    +16.2%       |    +2.2%        |
| high_systime |     -0.3%       |     -4.3%       |    -3.0%        |
| new_fserver  |     +3.9%       |    +16.0%       |    +9.5%        |
| shared       |     -1.7%       |     -5.0%       |    -4.0%        |
| short        |     -7.7%       |     +0.2%       |    +1.3%        |
+--------------+-----------------+-----------------+-----------------+
It can be seen that this patch improves performance for the fserver and
new_fserver workloads while suffering some slight drop in performance
for the other workloads.

Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mutex: dynamically disable mutex spinning at high load

Date	Thu, 4 Apr 2013 10:54:18 -0400

The Linux mutex code has a MUTEX_SPIN_ON_OWNER configuration
option that was enabled by default in major distributions like Red
Hat. Allowing threads waiting on mutex to spin while the mutex owner
is running will theoretically reduce latency on the acquisition of
mutex at the expense of energy efficiency as the spinning threads
are doing no useful work.

This is not a problem on a lightly loaded system where the CPU may
be idle anyway. On a highly loaded system, the spinning tasks may be
blocking other tasks from running even if they have higher priority
because the spinning was done with preemption disabled.

This patch will disable mutex spinning if the current load is high
enough. The load is considered high if there are 2 or more active tasks
waiting to run on the current CPU. If there is only one task waiting,
it will check the average load at the past minute (calc_load_tasks).
If it is more than double the number of active CPUs, the load is
considered high too.  This is a rather simple metric that does not
incur that much additional overhead.

The AIM7 benchmarks were run on 3.7.10 derived kernels to show the
performance changes with this patch on a 8-socket 80-core system
with hyperthreading off.  The table below shows the mean % change
in performance over a range of users for some AIM7 workloads with
just the less atomic operation patch (patch 1) vs the less atomic
operation patch plus this one (patches 1+3).

+--------------+-----------------+-----------------+-----------------+
|   Workload   | mean % change   | mean % change   | mean % change   |
|              | 10-100 users    | 200-1000 users  | 1100-2000 users |
+--------------+-----------------+-----------------+-----------------+
| alltests     |      0.0%       |     -0.1%       |    +5.0%        |
| five_sec     |     +1.5%       |     +1.3%       |    +1.3%        |
| fserver      |     +1.5%       |    +25.4%       |    +9.6%        |
| high_systime |     +0.1%       |      0.0%       |    +0.8%        |
| new_fserver  |     +0.2%       |    +11.9%       |   +14.1%        |
| shared       |     -1.2%       |     +0.3%       |    +1.8%        |
| short        |     +6.4%       |     +2.5%       |    +3.0%        |
+--------------+-----------------+-----------------+-----------------+
It can be seen that this patch provides some big performance
improvement for the fserver and new_fserver workloads while is still
generally positive for the other AIM7 workloads.

Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Merge branch 'cm-10.1' of github.com:CyanogenMod/android_kernel_samsung_d2 into jb-mr1