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>

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>