snd_soc_info_enum_ext() and snd_soc_info_enum_double() are almost identical. The
only difference is that snd_soc_info_enum_double() is also able to handle stereo
controls. Using snd_soc_info_enum double() instead of snd_soc_info_enum_ext()
for the SOC_ENUM_EXT control's info callback allows us to remove
snd_soc_info_enum_ext().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The SOC_SINGLE_EXT control has been using snd_soc_info_volsw() for its info
callback since commit 1c433fbd ("[ALSA] soc - 0.13 ASoC headers"). The
snd_soc_info_volsw_ext() function has been unused ever since then, so remove it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Some devices have the problem that if a internal audio signal source is disabled
the output of the source becomes undefined or goes to a undesired state (E.g.
DAC output goes to ground instead of VMID). In this case it is necessary, in
order to avoid unwanted clicks and pops, to disable any mixer input the signal
feeds into or to active a mute control along the path to the output. Often it is
still desirable to expose the same mixer input control to userspace, so cerain
paths can sill be disabled manually. This means we can not use conventional DAPM
to manage the mixer input control. This patch implements a method for letting
DAPM overwrite the state of a userspace visible control. I.e. DAPM will disable
the control if the path on which the control sits becomes inactive. Userspace
will then only see a cached copy of the controls state. Once DAPM powers the
path up again it will sync the userspace setting with the hardware and give
control back to userspace.

To implement this a new widget type is introduced. One widget of this type will
be created for each DAPM kcontrol which has the auto-disable feature enabled.
For each path that is controlled by the kcontrol the widget will be connected to
the source of that path. The new widget type behaves like a supply widget,
which means it will power up if one of its sinks are powered up and will only
power down if all of its sinks are powered down. In order to only have the mixer
input enabled when the source signal is valid the new widget type will be
disabled before all other widget types and only be enabled after all other
widget types.

E.g. consider the following simplified example. A DAC is connected to a mixer
and the mixer has a control to enable or disable the signal from the DAC.

                     +-------+
  +-----+            |       |
  | DAC |-----[Ctrl]-| Mixer |
  +-----+       :    |       |
     |          :    +-------+
     |          :
    +-------------+
    | Ctrl widget |
    +-------------+

If the control has the auto-disable feature enabled we'll create a widget for
the control. This widget is connected to the DAC as it is the source for the
mixer input. If the DAC powers up the control widget powers up and if the DAC
powers down the control widget is powered down. As long as the control widget
is powered down the hardware input control is kept disabled and if it is enabled
userspace can freely change the control's state.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently the DAPM code is limited to only setting or clearing a single bit in a
register to power a widget up or down. This patch extends the DAPM code to be
more flexible in that regard and allow widgets to use arbitrary values to be
used to put a widget in either on or off state.

Since the snd_soc_dapm_widget struct already contains a on_val and off_val field
no additional fields need to be added and in fact the invert field can even be
removed. Also the generated code is slightly smaller.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently we store for each path which control (if any at all) is associated
with that control. But we are only ever interested in the reverse relationship,
i.e. we want to know all the paths a certain control is associated with. This is
currently implemented by always iterating over all paths. This patch updates the
code to keep a list for each control which contains all the paths that are
associated with that control. This improves the run time of e.g.
soc_dapm_mixer_update_power() and soc_dapm_mux_update_power() from O(n) (with n
being the number of paths for the card) to O(1).
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The 'value' field is really per control and not per widget. Currently it is only
used for virtual MUXes, which only have one control per widget. So in that case
there is not so much of a difference between whether it is stored per widget or
per control. Moving the 'value' field from the widget to the control will allow
us to use it also for cases where we have more than one control per widget. E.g.
for mixers with multiple input controls.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

We use the same 3 lines to get the CODEC for a kcontrol in a quite a few places.
This patch puts them into a common helper function. Having this encapsulated in
a helper function will also make it more easier to eventually change the data
layout of the kcontrol's private data.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The update field of a DAPM context is only assigned while the card's dapm_mutex
is locked, the field is also cleared again while the mutex is stil locked. So
there will only ever be one DAPM context at a time with a non-NULL update field.
So it is safe to move the update field from the DAPM context struct to the card
struct. Doing so will allow further cleanups in this area.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

In order to avoid race conditions the assignment of dapm->update should happen
while card->dapm_mutex is being held. To allow CODEC drivers to run a register
update when using snd_soc_dapm_mux_update_power() or
snd_soc_dapm_mixer_update_power() add a update parameter to these two functions.
The update parameter will be assigned to dapm->update while card->dapm_mutex is
locked.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently when updating a control that is shared between multiple widgets the
whole power-up/power-down sequence is being run once for each widget. The
control register is updated during the first run, which means the CODEC internal
routing is also updated for all widgets during this first run. The input and
output paths for each widgets are only updated though during the respective run
for that widget. This leads to a slight inconsistency between the CODEC's
internal state and ASoC's state, which causes non optimal behavior in regard to
click and pop avoidance.

E.g. consider the following setup where two MUXs share the same control.

          +------+
 A1 ------|      |
          | MUX1 |----- C1
 B1 ------|      |
          +------+
             |
  control ---+
             |
          +------+
 A2 ------|      |
          | MUX2 |----- C2
 B2 ------|      |
          +------+

If the control is updated to switch the MUXs from input A to input B with the
current code the power-up/power-down sequence will look like this:

Run soc_dapm_mux_update_power for MUX1
  Power-down A1
  Update MUXing
  Power-up B1

Run soc_dapm_mux_update_power for MUX2
  Power-down A2
  (Update MUXing)
  Power-up B2

Note that the second 'Update Muxing' is a no-op, since the register was already
updated.

While the preferred order for avoiding pops and clicks should be:

Run soc_dapm_mux_update_power for control
  Power-down A1
  Power-down A2
  Update MUXing
  Power-up B1
  Power-up B2

This patch changes the behavior to the later by running the updates for all
widgets that the control is attached to at the same time.

The new code is also a bit simpler since callers of
soc_dapm_{mux,muxer}_update_power don't have to loop over each widget anymore
and neither do we need to keep track for which of the kcontrol's widgets the
current update is.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

soc_dpcm_runtime_update() operates on a ASoC card as a whole. Currently it takes
a snd_soc_dapm_widget as its only parameter though. The widget is then used to
look up the card and is otherwise unused. This patch changes the function to
take a pointer to the card directly. This makes it possible to to call
soc_dpcm_runtime_update() for updates which are not related to one specific
widget.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently we can only have a single platform built in with AC'97 support
due to the use of a global variable to provide the bus operations. Fix
this by making that variable a pointer and having the bus drivers set the
operations prior to registering.

This is not a particularly good or nice approach but it avoids blocking
multiplatform and a real fix involves fixing the fairly deep problems
with AC'97 support - we should be converting it to a real bus.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Introduce a new helper function, snd_ctl_sync_vmaster(), which updates
the slave put callbacks forcibly as well as calling the hook.  This
will be used in the upcoming patch in HD-audio codec driver for
toggling the mute in vmaster slaves.

Along with the new function, the old snd_ctl_sync_vmaster_hook() is
replaced as a macro calling with the argument hook_only=true.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Since commit 85762e71 ("ASoC: dapm: Implement mixer control sharing") the
long_name field of the snd_soc_dapm_path struct is unused. All of the name
handling now happens entirely in dapm_create_or_share_mixmux_kcontrol(). So we
can remove the long_name field from the snd_soc_dapm_path struct.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch adds the ALC5640 codec driver.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NBard Liao <bardliao@realtek.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Even though they are virtual widgets DAI widgets still get counted for the
DAPM context power management so we can't just use the active state to
check if they should be powered as they may not be part of a complete path.

Instead split them into input and output widgets and do the same power
checks as we perform on AIFs.
Reported-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently ALSA supports up to 32 card instances when the dynamic minor
is used.  While 32 cards are usually big enough for normal use cases,
there are sometimes weird requirements with more card support.

Actually, this limitation, 32, comes from the index option, where you
can pass the bit mask to assign the card.  Other than that, we can
actually give more cards up to the minor number limits (currently 256,
which can be extended more, too).

This patch adds a new Kconfig to specify the max card numbers, and
changes a few places to accept more than 32 cards.

The only incompatibility with high card numbers would be the handling
of index option.  The index option can be still used to pass the
bitmask for card assignments, but this works only up to 32 slots.
More than 32, no bitmask style option is available but only a single
slot can be specified via index option.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The ops field of the snd_pcm_substream struct is never modified inside the ALSA
core. Making it const allows drivers to declare their snd_pcm_ops struct as
const.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some devices may benefit from being able to start some parts of the widget
power up/down sequence earlier on in the sequence than the point at which
the final power state is committed. Support these by providing events which
are called before any power state changes are done.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>

Userspace is not meant to have to handle all strange dB ranges,
so add a specification comment.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Add a function to handle conversion from snd_pcm_format_t
to bitwise with proper typing.

Change such conversions to use this function and silence sparse
warnings.
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Fix typo in printk and comments within various drivers.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The commit [b209c4df: ALSA: emu10k1: cache emu1010 firmware] broke the
firmware loading of the dock, just (mistakenly) ignoring a different
firmware for docks on some models.  This patch revives them again.

Bugzilla: https://bugs.archlinux.org/task/34865Reported-and-tested-by: NTobias Powalowski <tobias.powalowski@googlemail.com>
Cc: <stable@vger.kernel.org> [v3.8+]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Some platforms which are half-duplex share the same DMA channel between the
playback and capture stream. Add support for this to the generic dmaengine PCM
driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch reworks the writes to use cumulative values thus making the
app_pointer unecessary and removing it.

Only tested as far as build.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Only tested as far as build.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The buffer passed to the copy callback should not be const because the
copy callback can be used for capture and playback.
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Use the generic dmaengine PCM driver instead of a custom implemention.  There is
a minor functional change, the ux500 PCM driver did not preallocate the audio
buffer, while the generic dmaengine PCM driver will do this.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch adds two formats for Direct Stream Digital (DSD), a
pulse-density encoding format which is described here:
https://en.wikipedia.org/wiki/Direct_Stream_Digital

DSD operates on 2.8, 5.6 or 11.2MHz sample rates and as a 1-bit
stream.

The two new types added by this patch describe streams that are capable
of handling DSD samples in DOP format as 8-bit or in 16-bit (or at a x8
or x16 data rate, respectively).

DSD itself specifies samples in *bit*, while DOP and ALSA handle them
as *bytes*. Hence, a factor of 8 or 16 has to be applied for the sample
rare configuration, according to the following table:

                                                  configured hardware
        176.4KHz   352.8kHz   705.6KHz     <----       sample rate

8-bit                2.8MHz     5.6MHz
16-bit    2.8Mhz     5.6MHz    11.2MHz

         `-----------------------------'
             actual DSD sample rates
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Unfortunately there are still quite a few platforms with a dmaengine driver
which do not support reporting the number of bytes left to transfer. If we want
to support these platforms in the generic dmaengine PCM driver we have.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Add support for platforms which don't use devicetree yet or have to optionally
support a non-devicetree way to request the DMA channel. The patch adds the
compat_request_channel and compat_filter_fn callbacks to the
snd_dmaengine_pcm_config struct. If the compat_request_channel is implemented it
will be used to request the DMA channel. If not dma_request_channel with
compat_filter_fn as the filter function will be used to request the channel.

The patch also exports the snd_dmaengine_pcm_request_chan() function, since
compat platforms will want to use it to request their DMA channel.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch adds a generic dmaengine PCM driver. It builds on top of the
dmaengine PCM library and adds the missing pieces like DMA channel management,
buffer management and channel configuration. It will be able to replace the
majority of the existing platform specific dmaengine based PCM drivers.
Devicetree is used to map the DMA channels to the PCM device.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

snd_soc_{add,remove}_platform are similar to snd_soc_register_platform and
snd_soc_unregister_platform with the difference that they won't allocate and
free the snd_soc_platform structure.

Also add snd_soc_lookup_platform which looks up a platform by the device it has
been registered for.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Refactor the dmaengine PCM library to allow the DMA channel to be requested
before opening a PCM substream. snd_dmaengine_pcm_open() now expects a DMA
channel instead of a filter function and filter parameter as its parameters.
snd_dmaengine_pcm_close() is updated to not release the DMA channel. This allows
a dmaengine based PCM driver to request its channels before the substream is
opened.

The patch also introduces two new functions, snd_dmaengine_pcm_open_request_chan()
and snd_dmaengine_pcm_close_release_chan(), which have the same signature and
behaviour of the old snd_dmaengine_pcm_{open,close}() and internally use the new
variants of these functions. All users of snd_dmaengine_pcm_{open,close}() are
updated to use snd_dmaengine_pcm_open_request_chan() and
snd_dmaengine_pcm_close_release_chan().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch adds a common DMA data struct which can be used by DAI drivers to
communicate their DMA configuration requirements to the DMA pcm driver.  Having
a common data structure for this allows us to implement common functions on top
of them, which can be used by multiple platforms.

This patch also introduces a new function to initialize certain fields of a
dma_slave_config struct from the common DAI DMA data struct.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The ASoC core does not modify a platform driver's compr_ops structure. Making it
const allows ASoC platform drivers to declare their snd_compr_ops struct as
const.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The ASoC core does not modify a platform driver's ops structure. Making it const
allows ASoC platform drivers to declare their snd_pcm_ops struct as const.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The ASoC core does no not modify the driver of a platform. Making it const
allows ASoC platform drivers to declare the snd_soc_platform_driver struct as
const.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

All drivers are using snd_soc_register_component()
instead of snd_soc_register_dai[s]()
snd_soc_[un]register_dai[s]() are no longer needed
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

These functions were initially added to be able to support some oddball dma
drivers, but all users have been updated to deal with the situation without the
help of snd_dmaengine_pcm_{set,get}_data, so these two functions can be removed.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>