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>

The snd_pcm_hardware structs for playback and capture in the ux500 PCM are
identical, so remove one of them and use the same snd_pcm_hardware struct for
both playback and capture. Also move the defines used to initialize the
snd_pcm_hardware fields from ux500_pcm.h to ux500_pcm.c since that's the only
place where they are used.

Also drop the assignment of the snd_pcm_hardware struct to runtime->hw since
that is what the call to snd_soc_set_runtime_hwparams() right above it already
does, so the second assignment is redundant.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Commit 453807f3 ("ASoC: ep93xx: Use ep93xx_dma_params instead of
ep93xx_pcm_dma_params") introduced a small compile error by not updating the
name of the 'dma_port' field to 'port'. This patch fixes it.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Use the common DAI DMA data struct for fsl/imx, this allows us to use the common
helper function to configure the DMA slave config based on the DAI DMA data.
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>

Use the common DAI DMA data struct for tegra, this allows us to use the common
helper function to configure the DMA slave config based on the DAI DMA data.
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>

Use the common DAI DMA data struct for omap, this allows us to use the common
helper function to configure the DMA slave config based on the DAI DMA data.

For omap-dmic and omap-mcpdm also move the DMA data from a global variable to
the driver state struct.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
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>

Usually device_fc should be set to false for audio DMAs. Initialize it in a
common place so drivers don't have to do this manually.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The Kconfig symbol SND_SOC_OF_SIMPLE got removed in commit
f0fba2ad ("ASoC: multi-component - ASoC
Multi-Component Support"). But that commit missed one instance. Remove
it now, together with the prompt it has effectively hidden ever since.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
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>

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>

Currently the mxs_dma_data struct, which gets passed to the dmaengine driver, is
allocated in the pcm driver's open callback. The mxs_dma_data struct has exactly
one field which is initialized from the the same field in the mxs_pcm_dma_params
struct. The mxs_pcm_dma_params struct gets passed to the pcm driver from the dai
driver. Instead of taking this indirection embed the mxs_dma_data struct
directly in the mxs_pcm_dma_params struct. This allows us to simplify the pcm
driver quite a bit, since we don't have to care about memory managing the
mxs_dma_data struct anymore.
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>

Currently the imx_dma_data struct, which gets passed to the dmaengine driver, is
allocated and constructed in the pcm driver from the data stored in the
dma_params struct. The dma_params struct gets passed to the pcm driver from the
dai driver. Instead of going this route of indirection embed the dma_data struct
directly into the dma_params struct and let the dai driver fill it in. This
allows us to simplify the imx-pcm-dma driver quite a bit, since it doesn't have
care about memory managing the imx_dma_data struct anymore.
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>

The dma filter parameters are only used within filter callback, so there is no
need to allocate them on the heap and keep them around until the PCM has been
closed.
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>

Currently the ep93xx_dma_params struct which is passed to the dmaengine driver
is constructed at runtime from the ep93xx_pcm_dma_params that gets passed to the
ep93xx PCM driver from one of the ep93xx DAI drivers. The ep93xx_pcm_dma_params
struct is almost identical to the ep93xx_dma_params struct. The only missing
field is the 'direction' field, which is computed at runtime in the PCM driver
based on the current substream. Since we know in advance which
ep93xx_pcm_dma_params struct is being used for which substream at compile time,
we also already know which direction to use at compile time. So we can easily
replace all instances of ep93xx_pcm_dma_params with their ep93xx_dma_params
counterpart. This allows us to simplify the code in the ep93xx pcm driver quite
a bit.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NRyan Mallon <rmallon@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

We want to get rid of snd_dmaengine_pcm_{set,get}_data(). All instances of
snd_dmaengine_pcm_get_data() in the atmel pcm driver can easily be replaced with
snd_soc_dai_get_dma_data().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NBo Shen <voice.shen@atmel.com>
Acked-by: NBo Shen <voice.shen@atmel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The driver never uses snd_dmaengine_pcm_get_data(), so there is no need to use
snd_dmaengine_pcm_set_data().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NRajeev Kumar <rajeev-dlh.kumar@st.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The driver never uses snd_dmaengine_pcm_get_data(), so there is no need to use
snd_dmaengine_pcm_set_data().
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NOla Lilja <ola.o.lilja@stericsson.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If a PCM driver using the dmaengine PCM helper functions doesn't need to do
anything special in its pcm_close callback, snd_dmaengine_pcm_close can be used
directly for as the pcm_close callback and there is no need to wrap it in a
custom function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NBo Shen <voice.shen@atmel.com>
Acked-by: NBo Shen <voice.shen@atmel.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If a PCM driver using the dmaengine PCM helper functions doesn't need to do
anything special in its pcm_close callback, snd_dmaengine_pcm_close can be used
directly for as the pcm_close callback and there is no need to wrap it in a
custom function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NOla Lilja <ola.o.lilja@stericsson.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If a PCM driver using the dmaengine PCM helper functions doesn't need to do
anything special in its pcm_close callback, snd_dmaengine_pcm_close can be used
directly for as the pcm_close callback and there is no need to wrap it in a
custom function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If a PCM driver using the dmaengine PCM helper functions doesn't need to do
anything special in its pcm_close callback, snd_dmaengine_pcm_close can be used
directly for as the pcm_close callback and there is no need to wrap it in a
custom function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

If a PCM driver using the dmaengine PCM helper functions doesn't need to do
anything special in its pcm_close callback, snd_dmaengine_pcm_close can be used
directly for as the pcm_close callback and there is no need to wrap it in a
custom function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NRajeev Kumar <rajeev-dlh.kumar@st.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The generic dmaengine based PCM driver code takes care of setting this
constraint, there is no need of doing it manually in the ux500 driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NOla Lilja <ola.o.lilja@stericsson.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Used PTR_RET function instead of IS_ERR and PTR_ERR.
Patch found using coccinelle.
Signed-off-by: NAlexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The omap PCM driver provides a set_threshold callback which gets called by the
PCM driver when either playback or capture is started. The only DAI driver which
sets this callback is the mcbsp driver. This patch removes the callback from the
PCM driver and moves the invocation of the omap_mcbsp_set_threshold() function
to the mcbsp hw_params callback since this is the only place where the threshold
size can change. Doing so allows us to use the default dmaengine PCM trigger
callback in the omap PCM driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The generic parser should evaluate the availability of the independent
HP when specified.  Otherwise a DAC without the direct connection to
the corresponding pin may be assigned for the HP, but the driver
doesn't check it at all.  The problem was actually seen on some
machines with VT1708s or equivalent codec, where DAC0 is assigned to
HP although it can be connected only via aamix.

This patch adds the badness evaluation for the independent HP to make
it working properly.
Reported-by: NLydia Wang <LydiaWang@viatech.com.cn>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The current DSP loader code abuses snd_hda_lock_devices() for ensuring
the DSP loader not conflicting with the other normal operations.  But
this trick obviously doesn't work for the PM resume since the streams
are kept opened there where snd_hda_lock_devices() returns -EBUSY.
That means we need another lock mechanism instead of abuse.

This patch provides the new lock state to azx_dev.  Theoretically it's
possible that the DSP loader conflicts with the stream that has been
already assigned for another PCM.  If it's running, the DSP loader
should simply fail.  If not -- it's the case for PM resume --, we
should assign this stream temporarily to the DSP loader, and take it
back to the PCM after finishing DSP loading.  If the PCM is operated
during the DSP loading, it should get an error, too.
Reported-and-tested-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There is a typo in convert_to_spdif_status() about checking the
emphasis IEC958 status bit.  It should check the given value instead
of the resultant value.
Reported-by: NMartin Weishart <martin.weishart@telosalliance.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The IO address is no longer hardwired into the driver.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Due to HW limitation within OMAP McPDM IP uplink and downlink need to be
started at the same time. This causes issues when we have two streams
running, for example:
arecord | aplay

In this case the playback stream would have no channels enabled since at the
capture start we are not aware that a playback is going to start.

The workaround is to configure the other direction to stereo when the first
stream is started. When the second stream is coming we check the new stream's
number of channels against the pre-configured channels. If it does not match
we stop and restart McPDM to update the configuration. This might result a
small pop. If the coming stream is a match we do nothing in the McPDM driver.

This workaround can handle most use cases without the need to restart McPDM.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

mcpdm_link_config will collect the link direction related configurations like
channel masks, FIFO threshold.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Creation of individual mixer controls may fail, but that shouldn't cause
the entire mixer creation to fail. Even worse, if the mixer creation
fails, that will error out the entire device probing.

All the functions called by parse_audio_unit() should return -EINVAL if
they find descriptors that are unsupported or believed to be malformed,
so we can safely handle this error code as a non-fatal condition in
snd_usb_mixer_controls().

That fixes a long standing bug which is commonly worked around by
adding quirks which make the driver ignore entire interfaces. Some of
them might now be unnecessary.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Reported-and-tested-by: NRodolfo Thomazelli <pe.soberbo@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In check_input_term() and parse_audio_feature_unit(), propagate the
error value that has been returned by a failing function instead of
-EINVAL. That helps cleaning up the error pathes in the mixer.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

UAC2_EXTENSION_UNIT_V2 differs from UAC1_EXTENSION_UNIT, but can be handled in
the same way when parsing the unit. Otherwise parse_audio_unit() fails when it
sees an extension unit on a UAC2 device.

UAC2_EXTENSION_UNIT_V2 is outside the range allocated by UAC1.
Signed-off-by: NTorstein Hegge <hegge@resisty.net>
Acked-by: NDaniel Mack <zonque@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

I forgot to update spec->gpio_data in the automute hook, so it will be
overridden at the init sequence, thus the machine is still silent when
no headphone jack is plugged at boot time.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The argument passed to snd_hda_attach_beep_device() is a widget NID
while spec->beep_amp holds the composed value for amp controls.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This leaks the beep input device after module unload, which leads to
Oops.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55321Signed-off-by: NTakashi Iwai <tiwai@suse.de>

During the transition to the generic parser, the hook to the codec
specific automute function was forgotten.  This resulted in the silent
output on some MacBooks.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>