[ Upstream commit 2ec42f3147e1610716f184b02e65d7f493eed925 ]

Some tools use the snd_pcm_info_get_name() to try to identify PCMs or for
other purposes.

Currently it is left empty with the dmaengine-pcm, in this case copy the
pcm->id string as pcm->name.

For example IGT is using this to find the HDMI PCM for testing audio on it.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reported-by: NArthur She <arthur.she@linaro.org>
Link: https://lore.kernel.org/r/20190906055524.7393-1-peter.ujfalusi@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>

The conversion from PCM format type to bits needs an explicit cast,
and it'll be uglier.  Since we have a standard macro for that, let's
use it instead.

This patch fixes the sparse warning:
  sound/soc/soc-generic-dmaengine-pcm.c:200:63: warning: restricted snd_pcm_format_t degrades to integer
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

It seems that __user prefix was forgotten to be added to
dmaengine_copy_user callback while we refactored the user-copy PCM
core.

This patch adds the missing prefix, remove the superfluous cast, and
add the needed cast (__force is needed for downgrading from user
pointer to kernel pointer), too.

Spotted by a sparse warning like:
  sound/soc/soc-generic-dmaengine-pcm.c:397:27: warning: incorrect type in initializer (incompatible argument 4 (different address spaces))
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

'cmd_pause' DMA channel capability means that respective DMA engine
supports both pausing and resuming given DMA channel. However, in some
cases it is important to know if DMA channel can be paused without the
need to resume it. This is a typical requirement for proper residue
reading on transfer timeout in UART drivers. There are also some DMA
engines with limited hardware, which doesn't really support resuming.

Reporting pause and resume capabilities separately allows UART drivers to
properly check for the really required capabilities and operate in DMA
mode also in systems with limited DMA hardware. On the other hand drivers,
which rely on full channel suspend/resume support, should now check for
both 'pause' and 'resume' features.

Existing clients of dma_get_slave_caps() have been checked and the only
driver which rely on proper channel resuming is soc-generic-dmaengine-pcm
driver, which has been updated to check the newly added capability.
Existing 'cmd_pause' now only indicates that DMA engine support pausing
given DMA channel.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NVinod Koul <vkoul@kernel.org>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This reverts commit f91b1e73.

As explained by Lars-Peter Clausen:

"This creates a resource leak. dmaengine_pcm_request_chan_of() requests
bothtransmit and receive channels. It might return with an error if one
of them fails, but the other one succeeded. In this case we need to call
dmaengine_pcm_release_chan() to free the requested channel"

So revert the commit.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Allow dmaengine client to optionally register a processing callback.
This callback is intended to apply processing
on samples in buffer copied from/to user space, before/after DMA transfer.
Signed-off-by: NOlivier Moysan <olivier.moysan@st.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Currently the following sparse warnings are observed:

sound/soc/soc-generic-dmaengine-pcm.c:185:34: warning: restricted snd_pcm_format_t degrades to integer
sound/soc/soc-generic-dmaengine-pcm.c:186:66: warning: incorrect type in argument 1 (different base types)
sound/soc/soc-generic-dmaengine-pcm.c:186:66:    expected restricted snd_pcm_format_t [usertype] format
sound/soc/soc-generic-dmaengine-pcm.c:186:66:    got int [signed] [assigned] i

Fix it by changing the loop variable to be of 'snd_pcm_format_t'.

Also introduce a SNDRV_PCM_FORMAT_FIRST label, which corresponds to the
first member (index 0) of the snd_pcm_format_t formats.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When dmaengine_pcm_request_chan_of() fails it should release
the previously acquired resources, which in this case is to
call kfree(pcm), so jump to the correct point in the error
path.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

After the conversion from platform to component the following warnings
are seen:

fsl-ssi-dai 2028000.ssi: ASoC: Failed to create component debugfs
directory
fsl-spdif-dai 2004000.spdif: ASoC: Failed to create component debugfs
directory

As explained by Mark Brown:

"It's a legit warning - we shouldn't really be creating two components
for the same device.  However this is a bit of a corner case as it's the
dmaengine platform driver which is kind of a virtual device, it's not
really the device that we use with DMA that's being represented but
rather the link between that and the DMA controller."

Disambiguate the DMA component name by adding a "dma" debugfs_prefix
entry.
Suggested-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Now platform can be replaced to component, let's do it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

This reverts commit c6644119 and
restores the ability to specify DMA channel names per DAI dma_data.
Unfortunately the functionality removed in the patch being reverted
cannot be entirely replaced by specifying DMA channel names in struct
snd_dmaengine_pcm_config as that does not cover devices with more than
2 DMA channels.

Together with patch "ASoC: Revert "samsung: Remove unneeded
initialization of chan_name"" this fixes broken sound on the s3c24xx
SoC platforms.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Since commit 194c7dea
"ASoC: dmaengine: add custom DMA config to snd_dmaengine_pcm_config"
custom DMA channels can be also specified in chan_names[] field of
struct snd_dmaengine_pcm_config.  This patch removes chan_name field
of struct snd_dmaengine_dai_dma_data as it is now unused.
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

dmaengine_pcm currently only supports setups where FIFO reads/writes
correspond to exactly one sample, eg 16-bit sample data is transferred
via 16-bit FIFO accesses, 32-bit data via 32-bit accesses.

This patch adds support for setups with fixed width FIFOs where
multiple samples are packed into a larger word.

For example setups with a 32-bit wide FIFO register that expect
16-bit sample transfers to be done with the left+right sample data
packed into a 32-bit word.

Support for packed transfers is controlled via the
SND_DMAENGINE_PCM_DAI_FLAG_PACK flag in snd_dmaengine_dai_dma_data.flags

If this flag is set dmaengine_pcm doesn't put any restriction on the
supported formats and sets the DMA transfer width to undefined.

This means control over the constraints is now transferred to the DAI
driver and it's responsible to provide proper configuration and
check for possible corner cases that aren't handled by the ALSA core.
Signed-off-by: NMatthias Reichl <hias@horus.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Whether residue can be reported or not is not a property of the audio
controller but of the DMA controller. The FLAG_NO_RESIDUE was initially
added when the DMAengine framework had no support for describing the residue
reporting capabilities of the controller. Support for this was added quite a
while ago and recently the DMAengine framework started to complain if a
driver does not describe its capabilities and a lot of patches have been
merged that add support for this where it was missing. So it should be safe
to assume that driver on actively used platforms properly implement the DMA
capabilities API.

This patch makes the FLAG_NO_RESIDUE internal and no longer allows audio
controller drivers to manually set the flag. If a DMA driver against
expectations does not support reporting its capabilities for now the generic
DMAengine PCM driver will now emit a warning and simply assume that residue
reporting is not supported. In the future this might be changed to aborting
with an error.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The ALSA core takes care that all preallocated memory is freed when the PCM
itself is freed. There is no need to do this manually in the driver.
Similarly there is also no need to do it on the pcm_new() error path as the
PCM will be freed if a error is returned.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The dmaengine header abbreviates destination as at least two different strings.
Make a coherent use of a single one.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NMark Brown <broonie@kernel.org>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The platform and CODEC probe and remove code is now largely identical. This
patch consolidates it at the component level.

The resulting code is slightly larger due to all the boiler plate code setting
up the indirection for the table based control and DAPM registration.  Once all
drivers have been update to no longer use the snd_soc_codec_driver and
snd_soc_platform_driver specific fields for this the indirection can be removed
again.

This patch contains two noteworthy hacks that are only meant to be temporary to
be able to update drivers and the core in separate incremental patches.

The first hack is related to that some DPCM platforms expect that the DAPM
widgets for the DAIs of a snd_soc_component are created in the DAPM context of
the snd_soc_platform that has the same parent device. For handling this the
steal_sibling_dai_widgets attribute is introduced. It gets set for
snd_soc_platforms that register DAPM elements. When creating the DAI widgets for
a component this flag is checked and if it is found on one of the siblings the
component will not create any DAI widgets in its own DAPM context. If the
attribute is set on a platform it will look for siblings components and create
DAI widgets for them in its own context. The fix for this will be to update
the offending drivers to only register a single component rather than two.

The second hack deals with the fact that the ASoC card suspend and resume code
still needs a list of CODECs that have been registered for the card. To handle
this the generic probe and remove path have a check to see if the component is
CODEC and if yes add/remove it to the card's CODEC list. While it is possible to
clean up the suspend/resume code to not need the CODEC list anymore this is a
bit of a chicken and egg problem since it will become easier to clean up the
suspend/resume code once there is a unified component layer.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Based on the dma_slave_caps's addr_widths queried from the dma driver
prepare the hw.formats mask to include only formats which is supported by
the DMA engine.
In case the dma driver does not implement the slave_caps the default
assumption is that it supports 1, 2 and 4 bytes widths.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NVinod Koul <vinod.koul@intel.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Since the soc generic dmaengine pcm driver allows using the defualt settings,
so the pcm->config maybe NULL.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

The dmaengine framework now exposes the granularity with which it is able to
report the transfer residue for a certain DMA channel. Check the granularity in
the generic dmaengine PCM driver and
	a) Set the SNDRV_PCM_INFO_BATCH if the granularity is per period or worse.
	b) Fallback to the (race condition prone) period counting if the driver does
	not support any residue reporting.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently we have two different snd_soc_platform_driver structs in the generic
dmaengine PCM driver. One for dmaengine drivers that support residue reporting
and one for those which do not. When registering the PCM component we check
whether the NO_RESIDUE flag is set or not and use the corresponding
snd_soc_platform_driver. This patch modifies the driver to only have one
snd_soc_platform_driver struct where the pointer() callback checks the
NO_RESIDUE flag at runtime. This allows us to set the NO_RESIDUE flag after the
PCM component has been registered. This becomes necessary when querying whether
the dmaengine driver supports residue reporting from the dmaengine driver itself
since the DMA channel might only be requested after the PCM component has been
registered.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Because the "ASoC: dmaengine-pcm: Provide default config" has provided
us one defualt config of DMA. When using this, the config parameter of
devm_snd_dmaengine_pcm_register() will be NULL, so here we need to have
a check before using it.
Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Check the return value of dma_request_slave_channel_reason() to see if
deferred probe happens, not the variable the return value will be
assigned to later.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Fixes: 5eda87b8 ("ASoC: dmaengine: support deferred probe for DMA channels")
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Enhance dmaengine_pcm_request_chan_of() to support deferred probe for
DMA channels, by using the new dma_request_slave_channel_or_err() API.
This prevents snd_dmaengine_pcm_register() from succeeding without
acquiring DMA channels due to the relevant DMA controller not yet being
registered.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add fields to struct snd_dmaengine_pcm_config to allow custom:

- DMA channel names.

  This is useful when the default "tx" and "rx" channel names don't
  apply, for example if a HW module supports multiple channels, each
  having different DMA channel names. This is the case with the FIFOs
  in Tegra's AHUB. This new facility can replace
  SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME.

- DMA device

  This allows requesting DMA channels for a device other than the device
  which is registering the "PCM" driver. This is quite unusual, but is
  currently useful on Tegra. In much HW, and in Tegra20, each DAI HW
  module contains its own FIFOs which DMA writes to. However, in Tegra30,
  the DMA FIFOs were split out AHUB HW module, which then routes the data
  through a cross-bar, and into the DAI HW modules. However, the current
  ASoC driver structure does not expose this detail, and acts as if the
  FIFOs are still part of the DAI HW modules. Consequently, the "PCM"
  driver is registered with the DAI HW module, yet the DMA channels must
  be looked up in the AHUB HW module's device tree node. This new config
  field allows that to happen. Eventually, the Tegra drivers will be
  reworked to fully expose the AHUB, and this config field can be
  removed.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

If snd_dmaengine_pcm_register()'s call to snd_soc_add_platform() fails,
all objects allocated during registration are leaked. Fix this by adding
error-handling code.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Restructure the internals of dmaengine_pcm_request_chan_of() as a loop
over all channels to be allocated. This makes it easier to add logic
that applies to all allocated channels, without having to duplicate that
logic in each of the half-duplex/full-duplex paths.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

For dmaengine drivers which do not support transfer residue reporting we update
the PCM pointer with period granularity. Set the SNDRV_PCM_INFO_BATCH flag in
this case to let userspace know about this.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

When allocating memory space for DMA buffer, use on-chip internal SRAM
as default choice to save power. Since the core would allocate memory
from traditional external memory if iram allocation failed, we don't
need to worry about any side effect.
Signed-off-by: NNicolin Chen <b42378@freescale.com>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

We currently assume that the DMA Slave Config will be fully populated
by the platform, however some DMA Engines make decisions based on zero
(default) flags such as DMA_SLAVE_BUSWIDTH_UNDEFINED and as this is a
static declaration we need to memset it to clear the data area.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

... to make the meaning more obvious.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

When using the legacy filter function channel requests we currently pass
the audio specific struct snd_dmaengine_dai_dma_data which isn't likely to
be helpful for actual filtering. Since there's already a field in the
structure called filter_data clearly intended for use here convert the
driver to use that.

All existing users of plain filter functions have been converted to use
an explicit compat function to override this behaviour except i.MX which
is working around this issue in its filter function and is updated to
just use filter_data directly here.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>

Some devices have more than just simple TX and RX DMA channels, for example
modern Samsung I2S IPs support a secondary transmit DMA stream which is
mixed into the primary stream during playback. Allow such devices to
specify the names of the channels to be requested in their dma_data.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>

This patch adds some default settings for the generic dmaengine PCM driver for
the case that no config has been supplied. The following defaults are used:
	* Use snd_dmaengine_pcm_prepare_slave_config for preparing the DMA slave
	  config.
	* 512kB for the prealloc buffer size. This value has been chosen based on
	  'feels about right' and is not backed up by any scientific facts. We
	  may need to come up with something smarter in the future but it should
	  work fine for now.

With this infrastructure in place we can finally write DAI drivers which are
independent of the DMA controller they are connected to. This is e.g. useful if
the DAI IP core is reused across different SoCs, but the SoCs uses different DMA
controllers.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

Currently each platform making use the the generic dmaengine PCM driver still
needs to provide a custom snd_pcm_hardware struct which specifies the
capabilities of the DMA controller, e.g. the maximum period size that can be
supported. This patch adds code which uses the newly introduced
dma_get_slave_caps() API to query this information from the dmaengine driver.
The new code path will only be taken if the 'pcm_hardware' field of the
snd_dmaengine_pcm_config struct is NULL.

The patch also introduces a new 'fifo_size' field to the
snd_dmaengine_dai_dma_data struct which is used to initialize the
snd_pcm_hardware 'fifo_size' field and needs to be set by the DAI driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@linaro.org>

dma_request_slave_channel() is a more appropriate API for dmaengine
clients that adopt generic DMA bindings to call.  Let's use it instead
of of_dma_request_slave_channel() to save <linux/of_dma.h> include.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The examples in Documentation/devicetree/bindings/dma/dma.txt recommends
the name for dma channel doing both RX and TX to be "rx-tx".  This
becomes a common pattern that has been adopted by platforms that
converts to generic DMA bindings.  Let's follow this common pattern in
generic-dmaengine-pcm.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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>

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>