Voodoo sound v10 - working port + minor fixes
wm8994: clean debug logs, and store headset volume
FM: fix to include directly the module in the kernel
mpu3050: allow user control of the factory mode switch
PM: Allow wakeup events to abort freezing of tasks

If there is a wakeup event during the freezing of tasks, suspend or
hibernation will fail anyway.  Since try_to_freeze_tasks() can take
up to 20 seconds to complete or fail, aborting it as soon as a wakeup
event is detected improves the worst case wakeup latency.

Based on a patch from Arve Hjønnevåg.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
PM: Fix potential issue with failing asynchronous suspend

There is a potential issue with the asynchronous suspend code that
a device driver suspending asynchronously may not notice that it
should back off.  There are two failing scenarions, (1) when the
driver is waiting for a driver suspending synchronously to complete
and that second driver returns error code, in which case async_error
won't be set and the waiting driver will continue suspending and (2)
after the driver has called device_pm_wait_for_dev() and the waited
for driver returns error code, in which case the caller of
device_pm_wait_for_dev() will not know that there was an error and
will continue suspending.

To fix this issue make __device_suspend() set async_error, so
async_suspend() doesn't need to set it any more, and make
device_pm_wait_for_dev() return async_error, so that its callers
can check whether or not they should continue suspending.

No more changes are necessary, since device_pm_wait_for_dev() is
not used by any drivers' suspend routines.

Reported-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
PM: Lock PM device list mutex in show_dev_hash()

Lock the PM device list mutex using device_pm_lock() and
device_pm_unlock() around the list iteration in show_dev_hash().

show_dev_hash() was reverse iterating dpm_list without first locking the
mutex that the functions in drivers/base/power/main.c lock. I assume
this was unintentional since there is no comment suggesting why the lock
might not be necessary.

Signed-off-by: James Hogan <james@albanarts.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
FM: cleanup and enable debugging
kpanic over mmc support, using the empty p10 partition (OTA)

CONFIG_APANIC_MMC and CONFIG_APANIC_PLABEL are required

Also require the mmcparts cmdline to define the partition names
sdhci: properly handle irq timeouts
n1: fix pll_a frequency and missing pll_p_out4
update ext config overrides

fbmem and lp0 vec are no more required (this cmdline is not used)

else: enable ksm, bluesleep and odm uart detection

put fm in kernel
tegra: cpufreq: Add adjustable MIN/MAX cpu frequencies
Overclocking tunable to 1.3Ghz, voltage control from TDR and ardadat

squashed/cleaned

Signed-off-by: Tanguy Pruvot <tanguy.pruvot@gmail.com>
cpufreq: fix overclock warnings
ext4: add missing save_error_info() to ext4_error()

The ext4_error() function is missing a call to save_error_info().
Since this is the function which marks the file system as containing
an error, this oversight (which was introduced in 2.6.36) is quite
significant, and should be backported to older stable kernels with
high urgency.

Change-Id: I21c5b80ab5685f731367f919ff0ce4248d865092
Reported-by: Ken Sumrall <ksumrall@google.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: ksumrall@google.com
Cc: stable@kernel.org
Signed-off-by: Ken Sumrall <ksumrall@android.com>
ARM: 6781/1: Thumb-2: Work around buggy Thumb-2 short branch relocations in gas

Various binutils versions can resolve Thumb-2 branches to
locally-defined, preemptible global symbols as short-range "b.n"
branch instructions.

This is a problem, because there's no guarantee the final
destination of the symbol, or any candidate locations for a
trampoline, are within range of the branch.  For this reason, the
kernel does not support fixing up the R_ARM_THM_JUMP11 (102)
relocation in modules at all, and it makes little sense to add
support.

The symptom is that the kernel fails with an "unsupported
relocation" error when loading some modules.

Until fixed tools are available, passing
-fno-optimize-sibling-calls to gcc should prevent gcc generating
code which hits this problem, at the cost of a bit of extra runtime
stack usage in some cases.

The problem is described in more detail at:
https://bugs.launchpad.net/binutils-linaro/+bug/725126

Only Thumb-2 kernels are affected.

This patch adds a new CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 config
option which adds -fno-optimize-sibling-calls to CFLAGS_MODULE
when building a Thumb-2 kernel.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 6659/1: Thumb-2: Make CONFIG_OABI_COMPAT depend on !CONFIG_THUMB2_KERNEL

rmk says: "You might as well make OABI_COMPAT depend on !THUMB2_KERNEL.
OABI userland is useless without FPA support."

nwfpe doesn't work with Thumb-2 anyway and will probably never get
ported, so I can't argue with that.

This patch implements the dependency change.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6534/1: Make CONFIG_FPE_NWFPE depend on !CONFIG_THUMB2_KERNEL

Because the nwfpe support is unlikely to be used on new platforms
and requires CONFIG_OABI_COMPAT, which is not generally used with
ARMv7+, we shouldn't expect to build nwfpe support into a Thumb-2
kernel.

At present, nwfpe contains assembly code which isn't Thumb-2
compatible, and for now it doesn't appear useful to port this
code.

All ARMv7-A/R platforms necessarily have VFPv3 hardware floating-
point natively, making emulation unnecessary.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: always use ARM_UNWIND for thumb2 kernels

Thumb2 kernels cannot be built with frame pointers, but can use the
ARM_UNWIND feature for unwinding instead. This makes sure that all
features that rely on unwinding includeing CONFIG_LATENCYTOP and
FAULT_INJECTION_STACKTRACE_FILTER do not enable frame pointers
when the unwinder is already selected, and we always build with
the unwinder when we want a thumb2 kernel, to make sure we do not
get the frame pointers instead.

A different option would be to redefine the CONFIG_FRAME_POINTERS
option on ARM to mean builing with either frame pointers or
the unwinder, and then select which one to use based on the
CPU architecture or another user option. That would still allow
building thumb2 kernels without the unwinder but would also be
more confusing.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM: tegra: uncompress.h: Implement TEGRA_DEBUG_UART_AUTO_ODMDATA

Tegra has 5 UARTS which could be used for low-level debug output. Commit
fe26398 "ARM: tegra: uncompress.h: Choose a UART at runtime" implemented
one method for the kernel to automatically determine which of these to
use at run-time, so that the same DEBUG_LL-enabled kernel image could be
used across multiple Tegra boards. The required bootloader-side setup for
that option is implemented in NVIDIA's various downstream U-Boot branches,
but the U-Boot maintainers have refused to accept it upstream.

This change implements an alternative automatic UART selection option
using ODMDATA. This is a 32-bit value programmed into Tegra's boot memory
which provides a few pieces of basic board-specific information, including
a field that indicates the console UART. Setting up this value is part of
the standard Tegra boot architecture, and so requires no Tegra-specific
hacks in the bootloader's UART driver.

Note that in theory, the format of ODMDATA is board-specific. However, in
practice all boards use the same location/size/values for the UART field.
ODMDATA[19:18] (which drive the type of debug console) is more problematic,
since some boards use value 2 for UART and others use 3. This patch just
accepts either value; if this doesn't work well for a given board, I'd
suggest simply not enabling this debug option when building for that board.

Note that the kernel assumes the bootloader has already set up any required
pinmux settings for the UART; there is no way the kernel can do this for
itself prior to knowing which board it's running on. In practice, people
using this feature are highly likely to be using bootloaders that have
indeed configured the pinmux. This assumption existed prior to this patch.

Signed-off-by: Stephen Warren <swarren@nvidia.com>

ARM: tegra: Pass uncompress.h UART selection to DEBUG_LL

    uncompress.h now saves the selected UART's physical address in Tegra's
    IRAM, along with a cookie to indicate validity.

    The first time it's run, macro addruart in debug-macro.S looks for this
    cookie, and if it's present, uses the UART address stored there. If not,
    the static value TEGRA_DEBUG_UART_BASE is used, as was previous behaviour.
    The static behaviour will thus be used when not booting using a zImage.

    This work was inspired by work by Doug Anderson <dianders@chromium.org>;
    see http://lkml.org/lkml/2011/9/26/284. However, this patch relies on
    the data passing describe above, rather than duplicating the UART
    selection logic in debug-macro.S; the latest selection logic is more
    complex due to the need to check reset/clock bits too.

    Signed-off-by: Stephen Warren <swarren@nvidia.com>
    Tested-by: Doug Anderson <dianders@chromium.org>
    Acked-by: Doug Anderson <dianders@chromium.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>

Signed-off-by: Tanguy Pruvot <tanguy.pruvot@gmail.com>
bluetooth: add more debug logs, turn off bt sleep flag