lowmemorykiller: make default lowmemorykiller debug message useful

lowmemorykiller debug messages are inscrutable and mostly useful
for debugging the lowmemorykiller, not explaining why a process
was killed.  Make the messages more useful by prefixing them
with "lowmemorykiller: " and explaining in more readable terms
what was killed, who it was killed for, and why it was killed.

The messages now look like:
[   76.997631] lowmemorykiller: Killing 'droid.gallery3d' (2172), adj 1000,
[   76.997635]    to free 27436kB on behalf of 'kswapd0' (29) because
[   76.997638]    cache 122624kB is below limit 122880kB for oom_score_adj 1000
[   76.997641]    Free memory is -53356kB above reserved

A negative number for free memory above reserved means some of the
reserved memory has been used and is being regenerated by kswapd,
which is likely what called the shrinkers.

Change-Id: I1fe983381e73e124b90aa5d91cb66e55eaca390f
Signed-off-by: Colin Cross <ccross@android.com>
Faux Sound: Sound Control: Added headphone poweramp controls
Merge tag 'AU_LINUX_ANDROID_JB_2.5.04.02.02.040.288' of git://codeaurora.org/kernel/msm into cm-10.1

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

Change-Id: Ic3ab6aae4cf933f1c1f70594581b22aa88c80866
drivers: video/gpu: minor patches
Revert "USB: android: Fix kernel panic during ACM enable"

This reverts commit d0f3d4386032e18168b1d2195fe355b783fd9fac.

Change-Id: I52d0826888fa4868770a9338fc82dde6d4608066
d2: Enable HW_AVS

 * We previously had an issue with HW_AVS when using the interactive
   cpufreq governor due to some derpiness in the way SPM changed the
   acpuclock.
 * This has been fixed by Qualcomm in commit
   8ad40ba6da84b27cebf87983fd230b77923d09ad so let's enable it.

Change-Id: I5f1e47074d76d2d14764042d5e474ed0edd9b6e0
sound: soc: msm: add VZW_VOLUME

Adds support for Verizon wireless 8 level volume

Change-Id: I222891c61c615c9f017d346e4be1308f9f849cf9
drivers: mfd: d2vzw needs hard reset at end of probe

This was normal behavior in 3.0

Change-Id: If730ac50409517c114ee94e8a58fff6451d92997
video: msm: Fix initial state of LCD backlight

 * For devices which use the LCD backlight (such as D2), we need
   to actually call the function which sets the brightness after
   initializing it in the probe.

Change-Id: Id6b7c0de3cd31181394c56c7f6061bca9defd861
Revert "Revert "msm_fb: display: allow backlight update after first update""

This reverts commit a07ba467cf89dddec2e168a5af00e26ced9219ba.
Merge tag 'AU_LINUX_ANDROID_JB_2.5.04.02.02.040.292' of git://codeaurora.org/kernel/msm into cm-10.1

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

Change-Id: Iaf790dce4acebe7b9177717c438694ba9665c789
sched: Fix SCHED_HRTICK bug leading to late preemption of tasks

SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot
(just when they would have exceeded their ideal_runtime). It makes use
of a a per-cpu hrtimer resource and hence alarming that hrtimer should
be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,
rather than being based on number of tasks in a particular cfs_rq (as
implemented currently). As a result, with current code, its possible for
a running task (which is the sole task in its cfs_rq) to be preempted
much after its ideal_runtime has elapsed, resulting in increased latency
for tasks in other cfs_rq on same cpu.

Fix this by alarming sched hrtimer based on total number of SCHED_FAIR
tasks a CPU has across its various cfs_rqs.

Change-Id: I1f23680a64872f8ce0f451ac4bcae28e8967918f
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
sched: Mark schedule_io_timeout() with EXPORT_SYMBOL

Make schedule_io_timeout() visible to modules.

Change-Id: Ic0dedbad8a591a9a721f0d2e8f6c372ec75bc4b2
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
kernel: Mark find_task_by_vpid with EXPORT_SYMBOL_GPL

make find_task_by_vpid() visible to modules.

Change-Id: Ic0dedbad21a0d908a08dd64479a7acc6b3197d5f
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
sched: Reset rq->next_interval before going idle

next_balance, the point in jiffy time scale when a cpu will next load
balance, could have been calculated when the cpu was busy. A busy cpu
will apply its sched domain's busy_factor (usually > 1) in computing
next_balance for that sched domain, which causes the (busy) cpu to load
balance less frequently in its sched domains. However when the same cpu
is going idle, its next_balance needs to be reset without consideration
of busy_factor. Failure to do so would not trigger nohz idle balancer on
that cpu for unnecessarily long time (introducing additional scheduling
latencies for tasks). Fix bug in scheduler which aims to reset
next_balance before a cpu goes idle (as per existing comment) but is
clearly not doing so.

Change-Id: I7e027a51686528c4092d770c7d33c874d38f5df4
Signed-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>
Revert "hrtimer: Prevent enqueue of hrtimer on dead CPU"

This reverts commit 878f1bd9ddd4b9734ad72d187b0266e640c99e08.

Based on upstream mailing list discussions, this patch is not
necessary since switch_hrtimer_base() is called with interrupts
disabled.

Change-Id: I53c64b1a4cea3a310ef53d1729a00baee6e4534a
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Revert "hrtimer: Consider preemption when migrating hrtimer cpu_bases"

This reverts commit f31b9b9f30f76847c94155f9da4da12f912b0885.

Based on upstream mailing list discussions, this patch is not
necessary since switch_hrtimer_base() is called with interrupts
disabled.

Change-Id: I0244a744516e1c289af25043ee8b866be54813e3
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
d2: Raise MDP bandwidth requirements

 * Bump up MDP bandwidth requirements to solve flickering issues.

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

AU_LINUX_ANDROID_JB_2.5.04.02.02.040.295 based on quic/aosp/jb_2.5
ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+
commit a76d7bd96d65fa5119adba97e1b58d95f2e78829 upstream.

The open-coded mutex implementation for ARMv6+ cores suffers from a
severe lack of barriers, so in the uncontended case we don't actually
protect any accesses performed during the critical section.

Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
code but optimised to remove a branch instruction, as the mutex fastpath
was previously inlined. Now that this is executed out-of-line, we can
reuse the atomic access code for the locking (in fact, we use the xchg
code as this produces shorter critical sections).

This patch uses the generic xchg based implementation for mutexes on
ARMv6+, which introduces barriers to the lock/unlock operations and also
has the benefit of removing a fair amount of inline assembly code.

Change-Id: Ie078d293204c562878c3a3e7cb567a8d9ca197fd
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reported-by: Shan Kang <kangshan0910@gmail.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@linuxfoundation.org>