Use table based setup to register the controls and DAPM widgets and routes. This
on one hand makes the code a bit shorter and cleaner and on the other hand the
board level DAPM elements get registered in the card's DAPM context rather than
in the CODEC's DAPM context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Merge branch 'topic/dapm' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-pxa

snd_soc_dapm_mutex_unlock() wants a pointer to the DAPM context, not the CODEC.

Fixes: 03510ca0 ("ASoC: ams-delta: Update locking around use of DAPM pin API")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Try to spot locking issues by asserting that the DAPM mutex is held when
it should be. There's a bit of fun due to us not requiring the lock to be
held prior to the card being instantiated which mean we need to wrap the
assert in some paths and this isn't methodical by any stretch of the
imagination.
Signed-off-by: Mark Brown <broonie@linaro.org>

The function is not called outside soc-dapm.c so there is no need for it
to be exported.
Signed-off-by: Mark Brown <broonie@linaro.org>

The new sequence ensure that dapm_pre_sequence_async work on
the card before all codecs and dapm_post_sequence_async work
on the card after all codecs.
So the machine driver could utilize the determinate sequence
to do the gloabl setup and teardown in the right place.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The widgets generated by the machine driver need to power off too.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.

Also drop the two snd_soc_dapm_enable_pin() since pins are enabled by default
and there is no matching snd_soc_dapm_disable_pin() in the driver.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.

Also remove the snd_soc_dapm_enable_pin() calls, since pins are enabled by
default and there are no matching snd_soc_dapm_disable_pin() calls.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Use table based setup to register the DAPM widgets and routes. This on one hand
makes the code a bit cleaner and on the other hand the board level DAPM elements
get registered in the card's DAPM context rather than in the CODEC's DAPM
context.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

When calling {corgi,poodle,spitz}_ext_control() from the startup callback we
pass the CODEC's DAPM context instead of the card's DAPM context. This is not a
problem per se since all the DAPM functions in ext_control() fallback to widgets
from other DAPM contexts, but passing the card's context is more consistent.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

The locking here was added in commit 71a29560 ("ASoC: Lock the CODEC in PXA
external jack controls") to protect the DAPM changes that are made inside of
${board}_ext_control() against concurrent updates. The ASoC core was updated in
commit a73fb2df ("ASoC: dapm: Use DAPM mutex for DAPM ops instead of codec
mutex") to use a card wide lock rather the CODEC mutex to protect DAPM
operations. We now have proper locking inside ${board}_ext_control() itself, so
taking the CODEC lock can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so. It looks like these were originally locked
with the CODEC mutex and not updated since the patch "ASoC: dapm: Use
DAPM mutex for DAPM ops instead of codec mutex", so remove the original
CODEC mutex locking as well.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

The pin updates in this driver look like they are intended to be done
atomically, update to do so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

We will often call sync after several functions that require the DAPM
mutex to be held. Rather than release and immediately relock the mutex
provide an unlocked function for this situation.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Acquiring the DAPM mutex is necessary before using several DAPM
functions and dereference is quite ugly. This patch provides a helper
function to simplify this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Merge branch 'fix/dapm' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-dapm

The snd_soc_dapm_xxxx_pin all require the dapm_mutex to be held when
they are called as they edit the dirty list, however very few of the
callers do so.

This patch adds unlocked versions of all the functions replacing the
existing implementations with one that holds the lock internally. We
also fix up the places where the lock was actually held on the caller
side.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take
it externally as well. This patch fixes this.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org

The error messages for bypassing/unbypassing a regulator appear to be
swapped round, this patch corrects these.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

Commit f7d3c170 ("ASoC: dapm: Change prototype of soc_widget_read") changed the
signature of soc_widget_read() so that it, instead of return the register value
as a int, takes a pointer to a unsigned int and stores the register value in
that pointer. There are still a few places that pass a int type value to that
function though. Change these to unsigned int. For more consistency also change
the signature of soc_widget_write() to take a unsigned int instead of an int for
the register value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>

Pull parisc updates from Helge Deller:
 "The three major changes in this patchset is a implementation for
  flexible userspace memory maps, cache-flushing fixes (again), and a
  long-discussed ABI change to make EWOULDBLOCK the same value as
  EAGAIN.

  parisc has been the only platform where we had EWOULDBLOCK != EAGAIN
  to keep HP-UX compatibility.  Since we will probably never implement
  full HP-UX support, we prefer to drop this compatibility to make it
  easier for us with Linux userspace programs which mostly never checked
  for both values.  We don't expect major fall-outs because of this
  change, and if we face some, we will simply rebuild the necessary
  applications in the debian archives"

* 'parisc-3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: add flexible mmap memory layout support
  parisc: Make EWOULDBLOCK be equal to EAGAIN on parisc
  parisc: convert uapi/asm/stat.h to use native types only
  parisc: wire up sched_setattr and sched_getattr
  parisc: fix cache-flushing
  parisc/sti_console: prefer Linux fonts over built-in ROM fonts

HPFS needs to load 4 consecutive 512-byte sectors when accessing the
directory nodes or bitmaps.  We can't switch to 2048-byte block size
because files are allocated in the units of 512-byte sectors.

Previously, the driver would allocate a 2048-byte area using kmalloc,
copy the data from four buffers to this area and eventually copy them
back if they were modified.

In the current implementation of the buffer cache, buffers are allocated
in the pagecache.  That means that 4 consecutive 512-byte buffers are
stored in consecutive areas in the kernel address space.  So, we don't
need to allocate extra memory and copy the content of the buffers there.

This patch optimizes the code to avoid copying the buffers.  It checks
if the four buffers are stored in contiguous memory - if they are not,
it falls back to allocating a 2048-byte area and copying data there.
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Previously, hpfs scanned all bitmaps each time the user asked for free
space using statfs.  This patch changes it so that hpfs scans the
bitmaps only once, remembes the free space and on next invocation of
statfs it returns the value instantly.

New versions of wine are hammering on the statfs syscall very heavily,
making some games unplayable when they're stored on hpfs, with load
times in minutes.

This should be backported to the stable kernels because it fixes
user-visible problem (excessive level load times in wine).
Signed-off-by: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Add support for the flexible mmap memory layout (as described in
http://lwn.net/Articles/91829). This is especially very interesting on
parisc since we currently only support 32bit userspace (even with a
64bit Linux kernel).
Signed-off-by: Helge Deller <deller@gmx.de>

On Linux, only parisc uses a different value for EWOULDBLOCK which
causes a lot of troubles for applications not checking for both values.
Since the hpux compat is long dead, make EWOULDBLOCK behave the same as
all other architectures.
Signed-off-by: Guy Martin <gmsoft@tuxicoman.be>
Signed-off-by: Helge Deller <deller@gmx.de>