[msm] audio boost
[mm] various memory bugfixes and tweaks

ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area

    commit a248b13b21ae00b97638b4f435c8df3075808b5d upstream.

    The v6 and v7 implementations of flush_kern_dcache_area do not align
    the passed MVA to the size of a cacheline in the data cache. If a
    misaligned address is used, only a subset of the requested area will
    be flushed. This has been observed to cause failures in SMP boot where
    the secondary_data initialised by the primary CPU is not cacheline
    aligned, causing the secondary CPUs to read incorrect values for their
    pgd and stack pointers.

    This patch ensures that the base address is cacheline aligned before
    flushing the d-cache.

    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath()

    commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream.

    I believe I found a problem in __alloc_pages_slowpath, which allows a
    process to get stuck endlessly looping, even when lots of memory is
    available.

    Running an I/O and memory intensive stress-test I see a 0-order page
    allocation with __GFP_IO and __GFP_WAIT, running on a system with very
    little free memory.  Right about the same time that the stress-test gets
    killed by the OOM-killer, the utility trying to allocate memory gets stuck
    in __alloc_pages_slowpath even though most of the systems memory was freed
    by the oom-kill of the stress-test.

    The utility ends up looping from the rebalance label down through the
    wait_iff_congested continiously.  Because order=0,
    __alloc_pages_direct_compact skips the call to get_page_from_freelist.
    Because all of the reclaimable memory on the system has already been
    reclaimed, __alloc_pages_direct_reclaim skips the call to
    get_page_from_freelist.  Since there is no __GFP_FS flag, the block with
    __alloc_pages_may_oom is skipped.  The loop hits the wait_iff_congested,
    then jumps back to rebalance without ever trying to
    get_page_from_freelist.  This loop repeats infinitely.

    The test case is pretty pathological.  Running a mix of I/O stress-tests
    that do a lot of fork() and consume all of the system memory, I can pretty
    reliably hit this on 600 nodes, in about 12 hours.  32GB/node.

    Signed-off-by: Andrew Barry <abarry@cray.com>
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Reviewed-by: Rik van Riel<riel@redhat.com>
    Acked-by: Mel Gorman <mgorman@suse.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

vmalloc: remove redundant unlikely()

    IS_ERR() already implies unlikely(), so it can be omitted here.

    Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
    Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove likely() from mapping_unevictable()

    The mapping_unevictable() has a likely() around the mapping parameter.
    This mapping parameter comes from page_mapping() which has an unlikely()
    that the page will be set as PAGE_MAPPING_ANON, and if so, it will return
    NULL.  One would think that this unlikely() means that the mapping
    returned by page_mapping() would not be NULL, but where page_mapping() is
    used just above mapping_unevictable(), that unlikely() is incorrect most
    of the time.  This means that the "likely(mapping)" in
    mapping_unevictable() is incorrect most of the time.

    Running the annotated branch profiler on my main box which runs firefox,
    evolution, xchat and is part of my distcc farm, I had this:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    12872836 1269443893  98 mapping_unevictable            pagemap.h            51
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659

    The page_mapping() is a static inline, which is why it shows up multiple
    times.  The mapping_unevictable() is also a static inline but seems to be
    used only once in my setup.

    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  Perhaps this is
    enough to remove the unlikely from page_mapping() as well.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Acked-by: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove unlikely() from page_mapping()

    page_mapping() has a unlikely that the mapping has PAGE_MAPPING_ANON set.
    But running the annotated branch profiler on a normal desktop system doing
    vairous tasks (xchat, evolution, firefox, distcc), it is not really that
    unlikely that the mapping here will have the PAGE_MAPPING_ANON flag set:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
    35935762 1270265395  97 page_mapping                   mm.h                 659
    1306198001   143659   0 page_mapping                   mm.h                 657
    203131478   121586   0 page_mapping                   mm.h                 657
     5415491     1116   0 page_mapping                   mm.h                 657
    74899487     1116   0 page_mapping                   mm.h                 657
    203132845      224   0 page_mapping                   mm.h                 659
     5415464       27   0 page_mapping                   mm.h                 659
       13552        0   0 page_mapping                   mm.h                 657
       13552        0   0 page_mapping                   mm.h                 659
      242630        0   0 page_mapping                   mm.h                 657
      242630        0   0 page_mapping                   mm.h                 659
    74899487        0   0 page_mapping                   mm.h                 659

    The page_mapping() is a static inline, which is why it shows up multiple
    times.

    The unlikely in page_mapping() was correct a total of 1909540379 times and
    incorrect 1270533123 times, with a 39% being incorrect.  With this much of
    an error, it's best to simply remove the unlikely and have the compiler
    and branch prediction figure this out.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: remove likely() from grab_cache_page_write_begin()

    Running the annotated branch profiler on a box doing average work
    (firefox, evolution, xchat, distcc farm), the likely() used in
    grab_cache_page_write_begin() was incorrect most of the time:

     correct incorrect  %        Function                  File              Line
     ------- ---------  -        --------                  ----              ----
     1924262 71332401  97 grab_cache_page_write_begin    filemap.c           2206

    Adding a trace_printk() and running the function tracer limited to
    just this function I can see:

            gconfd-2-2696  [000]  4467.268935: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=7
            gconfd-2-2696  [000]  4467.268946: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268947: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=8
            gconfd-2-2696  [000]  4467.268959: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268960: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=9
            gconfd-2-2696  [000]  4467.268972: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268973: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=10
            gconfd-2-2696  [000]  4467.268991: grab_cache_page_write_begin <-ext3_write_begin
            gconfd-2-2696  [000]  4467.268992: grab_cache_page_write_begin: page=          (null) mapping=ffff8800676a9460 index=11
            gconfd-2-2696  [000]  4467.269005: grab_cache_page_write_begin <-ext3_write_begin

    Which shows that a lot of calls from ext3_write_begin will result in the
    page returned by "find_lock_page" will be NULL.

    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Acked-by: Nick Piggin <npiggin@kernel.dk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

writeback: avoid unnecessary determine_dirtyable_memory call

    I think determine_dirtyable_memory() is a rather costly function since it
    need many atomic reads for gathering zone/global page state.  But when we
    use vm_dirty_bytes && dirty_background_bytes, we don't need that costly
    calculation.

    This patch eliminates such unnecessary overhead.

    NOTE : newly added if condition might add overhead in normal path.
           But it should be _really_ small because anyway we need the
           access both vm_dirty_bytes and dirty_background_bytes so it is
           likely to hit the cache.

    [akpm@linux-foundation.org: fix used-uninitialised warning]
    Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

brk: fix min_brk lower bound computation for COMPAT_BRK

    Even if CONFIG_COMPAT_BRK is set in the kernel configuration, it can still
    be overriden by randomize_va_space sysctl.

    If this is the case, the min_brk computation in sys_brk() implementation
    is wrong, as it solely takes into account COMPAT_BRK setting, assuming
    that brk start is not randomized.  But that might not be the case if
    randomize_va_space sysctl has been set to '2' at the time the binary has
    been loaded from disk.

    In such case, the check has to be done in a same way as in
    !CONFIG_COMPAT_BRK case.

    In addition to that, the check for the COMPAT_BRK case introduced back in
    a5b4592c ("brk: make sys_brk() honor COMPAT_BRK when computing lower
    bound") is slightly wrong -- the lower bound shouldn't be mm->end_code,
    but mm->end_data instead, as that's where the legacy applications expect
    brk section to start (i.e.  immediately after last global variable).

    [akpm@linux-foundation.org: fix comment]
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Cc: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/page_alloc.c: simplify calculation of combined index of adjacent buddy lists

    The previous approach of calucation of combined index was

    	page_idx & ~(1 << order))

    but we have same result with

    	page_idx & buddy_idx

    This reduces instructions slightly as well as enhances readability.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: fix used-unintialised warning]
    Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/dmapool.c: take lock only once in dma_pool_free()

    dma_pool_free() scans for the page to free in the pool list holding the
    pool lock.  Then it releases the lock basically to acquire it immediately
    again.  Modify the code to only take the lock once.

    This will do some additional loops and computations with the lock held in
    if memory debugging is activated.  If it is not activated the only new
    operations with this lock is one if and one substraction.

    Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/dmapool.c: use TASK_UNINTERRUPTIBLE in dma_pool_alloc()

    As it stands this code will degenerate into a busy-wait if the calling task
    has signal_pending().

    Cc: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[msm] various bug fixes and tweaks

msm: rpc: free the buffer if read fails.

    In do_read_data(), while reading a data fragment, if
    read() fails to read all the required bytes, free the fragment
    buffer.  Also correct the allocation size for fragment buffer.

    Signed-off-by: Niranjana Vishwanathapura <nvishwan@codeaurora.org>

msm: timer: remove set_next_event late print

    This case is properly handled in the generic code, and there is no need
    for us to print this ourselves.

    Change-Id: I80cd1fdbd2927f703d8902ff414cb5351f6fff70
    Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>

msm: timer: Increase write delay on dg_timer

    Sometimes set_next_event on the dg_timer takes longer than the minimum
    timer delta, causing debug prints to fire. Increase this timeout to
    suppress these.

    CRs-Fixed: 279340
    Change-Id: I04d22b04ffe7353f44c599369852b96faf9e45a5
    Signed-off-by: Jeff Ohlstein <johlstei@codeaurora.org>

msm: smd_tty: limit buffer size requested from tty framework

    tty_prepare_flip_string() might throw an error if requested
    size of continuous chunk of memory is not available due to
    memory fragmentation. Limit the size for each request to a
    default value of 2k.

    Change-Id: If35be0589f85a03ed684826a36def7c8323e2155
    Signed-off-by: Niranjana Vishwanathapura <nvishwan@codeaurora.org>

msm: smd: remove extra outgoing interrupts

    Remove interrupts which are sent by default in response to an event on an
    open SMD channel.  An interrupt is already sent if necessary according to
    the SMD protocol, so the default interrupts serve no purpose and can cause
    performance degradation.

    Change-Id: I4bbaf6cd12ef504b2452ece570af120c96dc0bc5
    Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>

msm: Increase the DMA consistent memory zone to 14MB

    Increase the zone for mapping DMA memory on most platforms from 2MB
    to the maximum 14MB. The actual memory comes from the normal pool, this
    change just increases the virtual range where the memory can be mappped
    (at the cost of 7 more 2MB pagetables).

    Change-Id: Ibc8067be1fbb92775b3c5e59277b5767e01706ea
    Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>

msm: sirc: fix out of bounds error

    The irq_handler function may exceed sirc_reg_table while checking for
    the correct cascaded interrupt causing out of bound accesses.

    Return after printing an error if this happens.

    Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
[USB] performance enhancement and other fixes

USB: android gadget: mass_storage: read/write performance enhancement

    Implementing the csw hack feature & increasing the number of
    buffers used in mass storage to 4.

    As per the mass storage protocol, csw is sent from the device
    after successfully writing the data on to storage media, where
    there is a time factor involved. With this csw hack, csw is sent
    just after receiving the data & before writing the data on the
    storage media. By, any chance, if the write fails, the corresponding
    lun is removed to indicate the user of write failure.

    Buffers has been increased to 4, so that there is enough space for
    the incoming data, which is usually 64KB per CBW.

    User has the option of selecting/deselecting this feature from
    the kernel config.

    Signed-off-by: Velempati Chiranjeevi <c_cvelem@qualcomm.com>

USB: gadget: g_mass_storage: static data instead of dynamic allocation

    This patch changes msg_do_config() function so that it uses
    a static object for a fsg_common structure instead of dynamically
    allocated.  This is a micro-optimisation.

    Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: gadget: f_fs: use usb_string_ids_n()

    Use usb_string_ids_n() function to simplify string ids
    registeration.

    Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: gadget: f_mass_storage: dead code removed

    The ep0req_name was never used in f_mass_storage hence it may
    be safely removed from the code.  It was a leftover from File
    Storage Gadget which used it for debug messages.

    Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com>
    Cc: David Brownell <dbrownell@users.sourceforge.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: gadget: f_mass_storage: added eject callback

    Added pre_eject() and post_eject() callbacks which are
    called before and after removable logical unit is ejected.
    The first can prevent logical unit from being ejected.

    This commit also changes the way callbacks are passed to
    the function from gadget.  A fsg_operations structure has
    been created which lists all callbacks -- this is passed
    to the fsg_config.

    This is important because it changes the way thread_exits()
    callback is passed.

    Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com>
    Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
various cpu tweaks

ashmem: fix deadlock when system is low on memory

    When system is low on memory, allocating memory while holding the
    ashmem_mutex may try to directly reclaim memory. Then ashmem_shrink()
    is called in same thread. It will deadlock at acquiring ashmem_mutex.
    This change lets ashmem_shrink() return failure if ashmem_mutex is not
    available. Memory will be reclaimed from others.

    Change-Id: I3b6024d5477d37245f4ebde6d7069fb77af789ee
    Signed-off-by: Yuanyuan Zhong <yuanyuan.zhong@gmail.com>

cgroup: fix cpuset permission check

    The permission check code added by "cgroup: Add generic cgroup subsystem
    permission checks" does not build and also leaves a variable uninitialized.
    Fix it.

    Change-Id: I8009d6315527725d45b20792b7cd74aedc9bff44
    Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
    Signed-off-by: Christian Bejram <christian.bejram@stericsson.com>

cpuidle: menu: fixed wrapping timers at 4.294 seconds

    commit 7467571f4480b273007517b26297c07154c73924 upstream.

    Cpuidle menu governor is using u32 as a temporary datatype for storing
    nanosecond values which wrap around at 4.294 seconds. This causes errors
    in predicted sleep times resulting in higher than should be C state
    selection and increased power consumption. This also breaks cpuidle
    state residency statistics.

    Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

percpu: Generic support for this_cpu_add, sub, dec, inc_return

    Introduce generic support for this_cpu_add_return etc.

    The fallback is to realize these operations with simpler __this_cpu_ops.

    tj: - Reformatted __cpu_size_call_return2() to make it more consistent
          with its neighbors.
        - Dropped unnecessary temp variable ret__ from
          __this_cpu_generic_add_return().

    Reviewed-by: Tejun Heo <tj@kernel.org>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Acked-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
ARM: msm: fast charging while connected via USB
ARM: msm: enable fast charging via USB by default
sched: Improve latencies under load by decreasing minimum scheduling granularity

Mathieu reported bad latencies with make -j10 kind of kbuild
workloads - which is mostly caused by us scheduling with a
too coarse granularity.

Reduce the minimum granularity some more, to make sure we
can meet the latency target.

I got the following results (make -j10 kbuild load, average of 3
runs):

 vanilla:

  maximum latency: 38278.9 µs
  average latency:  7730.1 µs

 patched:

  maximum latency: 22702.1 µs
  average latency:  6684.8 µs

Mathieu also measured it:

|
| * wakeup-latency.c (SIGEV_THREAD) with make -j10
|
| - Mainline 2.6.35.2 kernel
|
| maximum latency: 45762.1 µs
| average latency: 7348.6 µs
|
| - With only Peter's smaller min_gran (shown below):
|
| maximum latency: 29100.6 µs
| average latency: 6684.1 µs
|

Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Suggested-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <AANLkTi=8m4g01wZPacySoF7U0PevTNVgJoZZrHiUD-pN@mail.gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ARM: prevent multiple syscall restarts

Al Viro reports that calling "sys_sigsuspend(-ERESTARTNOHAND, 0, 0)"
with two signals coming and being handled in kernel space results
in the syscall restart being done twice.

Avoid this by clearing the 'why' flag when we call the signal handling
code to prevent further syscall restarts after the first.

Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[msm] USB fast charging fix

devices not using BATTERY_DS2746 (everything but msm7230) need additional headers
Add SLQB slab allocator
Drop swap cache more aggressively via ck1 patch
Enable swaptoken only when swap is full via ck3 patch

The swap token is only useful in conditions of swap thrash, and actually
worsens the common case by causing more swapping. Make it only have an effect
when swap is more than half full.
backport 2.6.39 bcm4329 driver
bcm4329: backport latest wifi driver from google's 3.0_rc7 kernel
backport 3.0 block code