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>

Use the generic dmaengine PCM driver instead of a custom implementation.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
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>

Reported-by: NRyo Tsutsui <Ryo.Tsutsui@wolfsonmicro.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

The Charge Pump needs the DSP clock to work properly, without it the
bypass to HP/LINEOUT is not working properly. This requirement is not
mentioned in the datasheet but has been confirmed by Mark Brown from
Wolfson.
Signed-off-by: NAlban Bedel <alban.bedel@avionic-design.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

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>

The usb_control_msg() function expects __u16 types and performs
the endianness conversions by itself.
However, in three places, a conversion is performed before it is
handed over to usb_control_msg(), which leads to a double conversion
(= no conversion):
* snd_usb_nativeinstruments_boot_quirk()
* snd_nativeinstruments_control_get()
* snd_nativeinstruments_control_put()

Caught by sparse:

sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types)
sound/usb/mixer_quirks.c:512:38:    expected unsigned short [unsigned] [usertype] index
sound/usb/mixer_quirks.c:512:38:    got restricted __le16 [usertype] <noident>
sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types)
sound/usb/mixer_quirks.c:543:35:    expected unsigned short [unsigned] [usertype] value
sound/usb/mixer_quirks.c:543:35:    got restricted __le16 [usertype] <noident>
sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types)
sound/usb/mixer_quirks.c:543:56:    expected unsigned short [unsigned] [usertype] index
sound/usb/mixer_quirks.c:543:56:    got restricted __le16 [usertype] <noident>
sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types)
sound/usb/quirks.c:502:35:    expected unsigned short [unsigned] [usertype] value
sound/usb/quirks.c:502:35:    got restricted __le16 [usertype] <noident>
Signed-off-by: NEldad Zack <eldad@fogrefinery.com>
Acked-by: NDaniel Mack <zonque@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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>

changed is not initialized in path_power_down_sync, but it is expected
to be false in case no change happened in the loop. So set it to
false.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This reverts commit 6ab31741.

The commit [6ab31741: ALSA: hda - Allow power_save_controller option
override DCAPS] changed the behavior of power_save_controller so that
it can override the driver capability.  This assumed that this option
is rarely changed dynamically unlike power_save option.  Too naive.

It turned out that the user-space power-management tool tries to set
power_save_controller option to 1 together with power_save option
without knowing what's actually doing.  This enabled forcibly the
runtime PM of the controller,  which is known to be broken om many
chips thus disabled as default.

So, the only sane fix is to revert this commit again.  It was intended
to ease debugging/testing for runtime PM enablement, but obviously we
need another way for it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=56171Reported-and-tested-by: NNikita Tsukanov <keks9n@gmail.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Rename "Digitial In" to "Digital In". This function is only used for
proc output, so should not cause any problems to change.
Signed-off-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

* Added the device ID to the modalias list and assinged ALC662 patches
for it
* Added 4 port support for the device ID 0671 in alc662_parse_auto_config
Signed-off-by: NRainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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 tegra dmaengine driver does not support pausing and resuming a DMA stream.
The tegra PCM driver still claims to support pause and resume though and
implements them by stopping and restarting the stream. This is not what an
application using pause/resume would expect. Usually applications have support
for working around PCMs which do not support suspend and resume, so don't set
the SNDRV_PCM_INFO_PAUSE and SNDRV_PCM_INFO_RESUME flags for the tegra PCM and
use the default snd_dmaengine_pcm_trigger callback.
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>

Currently, a new platform device is created for secondary device
by calling platform_device_register_resndata and then the drvdata
is set for this device.

The following patch has been added to driver core:
"driver core: fix possible missing of device probe".

This results in the added device getting probed immediately but
the drvdata for the secondary device is not yet set.
This patch removes the platform_device_register_resndata call and
instead calls platform_device_alloc, platform_set_drvdata and
platform_device_add which fixes the above issue.
Signed-off-by: NPrathyush K <prathyush.k@samsung.com>
Signed-off-by: NPadmavathi Venna <padma.v@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This patch fixes a possible crash in case drvdata for the secondary
device is not set.
Signed-off-by: NPrathyush K <prathyush.k@samsung.com>
Signed-off-by: NPadmavathi Venna <padma.v@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The C-Media CM6631 USB receiver doesn't respond to changes in sample rate
while the interface is active. The same behavior is observed in other UAC2
hardware like the VIA VT1731.

Reset the interface after setting the sampling frequency on sample rate
changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is
used. Otherwise, the device will try to use the sample rate of the previous
stream, causing distorted sound on sample rate changes.

The reset is performed for all UAC2 devices, as it should not affect a
standards compliant device, but it is only necessary for C-Media CM6631,
VIA VT1731 and possibly others.

Failure to read sample rate from the device is not handled as an error in
set_sample_rate_v2(), as (permanent or intermittent) failure to read sample
rate isn't essential for a successful sample rate set.
Signed-off-by: NTorstein Hegge <hegge@resisty.net>
Acked-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

This patch let ELD debug message show 'pin_eld->monitor_present' which reflects
the real pin response to verb GET_PIN_SENSE.

'eld->monitor_present' should not be used here because 'eld' is a temp
structure now and so its "monitor_present" is not set.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Acked-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0.
Otherwise it will be returned uninitialized as non-zero after ELD info is got
successfully. Thus hdmi_present_sense() will always assume ELD info is invalid
by mistake, and /proc file system cannot show the proper ELD info.
Signed-off-by: NMengdong Lin <mengdong.lin@intel.com>
Cc: stable@vger.kernel.org
Acked-by: NDavid Henningsson <david.henningsson@canonical.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

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>

When a new stream is being opened it is necessary to cancel any delayed
power down of the audio.

[Fixed unused variable -- broonie]
Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
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>