Merge tag 'AU_LINUX_ANDROID_JB_2.5.04.02.02.040.252' of git://codeaurora.org/kernel/msm into cm-10.1

AU_LINUX_ANDROID_JB_2.5.04.02.02.040.252 based on quic/aosp/jb_2.5
arm: mm: Add VM_ARM_EMPTY_MAPPING flag to mark the PMD gaps

ioremap optimization to return the addresses from the static mapping
if already present added the feature to add the pmd empty gaps into
the VM area but don't map such gaps in this commit "19b52abe3c5d".

This introduces the problem when the pfn is 0x0 and ends up into the
empty section gap found by the fill_pmd_gaps. If the driver calls
the ioremap(0, PAGE_SIZE) then it will return the address which is never
mapped, and access to that address will result in the crash.

To resolve this mark the empty PMD gaps with new flag VM_ARM_EMPTY_MAPPING
instead of the VM_ARM_STATIC_MAPPING, so that ioremap only checks
the VM_ARM_STATIC_MAPPING flag and skips over the VM_ARM_EMPTY_MAPPING
sections.

CRs-Fixed: 385828
Change-Id: I71e053f05abd2f611a6f17e7c86635404c31751e
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Trilok Soni <tsoni@codeaurora.org>
ARM: gic: Refactor code for gic_configure_and_raise

Currently the offset and bit calculation in the function was
hardcoded for IPC1 interrupt. To support other secondary cores
we have to refactor the code to calculate the offset and bits
as per the cpu and interrupt number.

Change-Id: I33de8f185c219fb6a8e9d7f9676e958f27d54a12
Signed-off-by: Taniya Das <tdas@codeaurora.org>
ARM: gic: save/restore distributor ISR register values

Before going into power collapse we have to save/restore the ISR
registers in case we configure GIC to handle FIQ on apps side.
Otherwise we will end up in wrong ISR configurations after PC.

Change-Id: Ib58b701fc462c10ec88576feab3c8a9eb3027009
Signed-off-by: Taniya Das <tdas@codeaurora.org>
android: lowmemorykiller: add lmk parameters tunning code.

There are cases that LMK doesn't run, even when it must run.
It is due to LMK shrinker not considering memory status per zone.
So add LMK parameters(other_free, other_file) tunnig code to
consider target zone of LMK shrinker.

Change-Id: I6f1f8660d5da920a0e3af45a160499965032081d
Git-commit: 22d990a58fc17b3f0155e15eb2dc3efa037bea1c
Git-repo: https://android.googlesource.com/kernel/common/
[ohaugan@codeaurora.org: Fix compilation issues]
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
android/lowmemorykiller: Selectively count free CMA pages

In certain memory configurations there can be a large number of
CMA pages which are not suitable to satisfy certain memory
requests.

This large number of unsuitable pages can cause the
lowmemorykiller to not kill any tasks because the
lowmemorykiller counts all free pages.
In order to ensure the lowmemorykiller properly evaluates the
free memory only count the free CMA pages if they are suitable
for satisfying the memory request.

Change-Id: I7f06d53e2d8cfe7439e5561fe6e5209ce73b1c90
CRs-fixed: 437016
Signed-off-by: Liam Mark <lmark@codeaurora.org>
mmc: msm_sdcc: Check for unclocked register access in IRQ handler

After SDCC has been suspended and clocks turned off, an asynchronous
interrupt from an SDIO device will result in a call to the IRQ handler.
Since SDCC hardware registers are unclocked, a read of the status
register will result in an exception. Verify that clock to SDCC is on
before access in the IRQ handler.

CRs-Fixed: 424960
Change-Id: I81afd2dd5c5fa4785f11f2eec03e5b454b8f5dbe
Signed-off-by: Oluwafemi Adeyemi <aadeyemi@codeaurora.org>
msm: camera: Fix locking in msm_close

Change-Id: Id832a967f5f790a93102b7761285012d5231de7a
sec_debug: Forward-port SEC_DEBUG feature from Samsung

 * Forward port, fix warnings, fix ifdefs.
 * Very useful for debugging hard problems, no impact when disabled.
 * Also required to get correct ramdumps.

Change-Id: I375e0dcce83b717e5f1228925d7269c5197b2016
M2: sound: fix static on speaker enable/disable

Rapid speaker enable/disable is causing a loud static POP.
Can be replicated by enabling "Touch Sounds" and playing music through Apollo.

Speaker enable/disable delay sequence as in msm8960.c

Change-Id: If1772a80da8ac2d06bb39ad4766bf92089081338
d2: ifdefs for ramconsole

build will fail with ANDROID_RAM_CONSOLE disabled

Change-Id: Ie2b3585a0a9f402107c1316db570007cb969a02c
Merge tag 'AU_LINUX_ANDROID_JB_2.5.04.02.02.040.257' of git://codeaurora.org/kernel/msm into cm-10.1

AU_LINUX_ANDROID_JB_2.5.04.02.02.040.257 based on quic/aosp/jb_2.5

Change-Id: Ia0615c2dbe67b58640c8029efce0e6553b4ddd09
Linux 3.4.41

Signed-off-by: task650 <task650@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>
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>
mutex: dynamically disable mutex spinning at high load Date
blk: row: updated to latest and block: urgent request: Update dispatch_urgent in case of requeue
f_fs: ffs_func_free: cleanup requests allocated by autoconfig

functionfs was leaking request objects created by autoconfig.

Bug: 8659094

Change-Id: I641326cb5cb26e0a2ffa082cd2be2c21c66c38e5
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Goby <benoit@android.com>
USB: f_mass_storage: Added cdrom option to UMS-lun-devices

This patch allows programs to change the cdrom option at runtime
through sysfs.

Change-Id: Id2a02ab67062734793424c32c94024d6bbaccac6
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>