ARM: tegra: document use of standard DMA DT bindings

Update all the Tegra DT bindings to require the standard dmas/dma-names
properties rather than non-standard nvidia,dma-request-selector property.

This is a DT-ABI-incompatible change. It is the second of two changes
required for me to consider the Tegra DT bindings as stable, the other
being the previous conversion to the common reset bindings.

Cc: treding@nvidia.com
Cc: pdeschrijver@nvidia.com
Cc: linux-tegra@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: update DT files to add DMA properties

This patch switches the Tegra DT files to use the standard DMA DT bindings
rather than custom properties. Note that the legacy properties are not yet
removed; the drivers must be updated to use the new properties first.

Cc: treding@nvidia.com
Cc: pdeschrijver@nvidia.com
Cc: linux-tegra@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@nvidia.com>
dma: add channel request API that supports deferred probe

dma_request_slave_channel() simply returns NULL whenever DMA channel
lookup fails. Lookup could fail for two distinct reasons:

a) No DMA specification exists for the channel name.
   This includes situations where no DMA specifications exist at all, or
   other general lookup problems.

b) A DMA specification does exist, yet the driver for that channel is not
   yet registered.

Case (b) should trigger deferred probe in client drivers. However, since
they have no way to differentiate the two situations, it cannot.

Implement new function dma_request_slave_channel_or_err(), which performs
identically to dma_request_slave_channel(), except that it returns an
error-pointer rather than NULL, which allows callers to detect when
deferred probe should occur.

Eventually, all drivers should be converted to this new API, the old API
removed, and the new API renamed to the more desirable name. This patch
doesn't convert the existing API and all drivers in one go, since some
drivers call dma_request_slave_channel() then dma_request_channel() if
that fails. That would require modifying dma_request_channel() in the
same way, which would then require modifying close to 100 drivers at once,
rather than just the 15-20 or so that use dma_request_slave_channel(),
which might be tenable in a single patch.

acpi_dma_request_slave_chan_by_index() doesn't actually implement
deferred probe. Perhaps it should?

Signed-off-by: Stephen Warren <swarren@nvidia.com>
dma: tegra: register as an OF DMA controller

Call of_dma_controller_register() so that DMA clients can look up the
Tegra DMA controller using standard APIs. This requires the OF filter
function to save off the DMA slave ID, and for tegra_dma_slave_config()
not to over-write this information; once DMA client drivers are converted
to dma_request_slave_channel() and DT-based lookups, they won't set this
field of struct dma_slave_config anymore.

Cc: treding@nvidia.com
Cc: pdeschrijver@nvidia.com
Cc: linux-tegra@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies.
ASoC: dmaengine: support deferred probe for DMA channels

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: Stephen Warren <swarren@nvidia.com>
ASoC: dmaengine: add custom DMA config to snd_dmaengine_pcm_config

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: Stephen Warren <swarren@nvidia.com>
ASoC: tegra: call pm_runtime APIs around register accesses

Call pm_runtime_get_sync() before all register accesses; the HW requires
clocks to be running when accessing registers.

This hasn't been needed to date, since all register IO was performed
while playback was active, and hence the ASoC core had already called
pm_runtime_get(). However, an imminent future commit will allocate and
set up the FIFOs and routing during probe(), when that "protection"
won't be in place.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ASoC: tegra: allocate AHUB FIFO during probe() not startup()

Teh Tegra30 I2S driver currently allocates DMA FIFOs from the AHUB only
when an audio stream starts playback. This is theoretically nice for
resource sharing, but makes no practical difference for any configuration
the drivers currently support. However, this deferral prevents conversion
to the standard DMA DT bindings, since conversion requires knowledge of
the specific DMA channel to be allocated, which in turn depends on which
specific FIFO was allocated.

For this reason, move the FIFO allocate into probe() to allow later
conversion to the standard DMA DT bindings.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ASoC: tegra: convert to standard DMA DT bindings

By passing no flags when calling snd_dmaengine_pcm_register() from
tegra_pcm.c, we end up using dma_request_slave_channel() rather than
dmaengine_pcm_compat_request_channel(), and hence rely on the standard
DMA DT bindings and stashing the DMA slave ID away during channel
allocation. This means there's no need to use a custom DT property to
store the slave ID. So, remove all the code that parsed it.

Cc: treding@nvidia.com
Cc: pdeschrijver@nvidia.com
Cc: linux-tegra@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies
spi: tegra: convert to standard DMA DT bindings

By using dma_request_slave_channel_or_err(), the DMA slave ID can be
looked up from standard DT properties, and squirrelled away during
channel allocation. Hence, there's no need to use a custom DT property
to store the slave ID.

Cc: treding@nvidia.com
Cc: pdeschrijver@nvidia.com
Cc: linux-tegra@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies.
serial: tegra: convert to standard DMA DT bindings

By using dma_request_slave_channel_or_err(), the DMA slave ID can be
looked up from standard DT properties, and squirrelled away during
channel allocation. Hence, there's no need to use a custom DT property
to store the slave ID.

DMA channel allocation is moved to probe() so that deferred probe works.

Cc: treding@nvidia.com
Cc: pdeschrijver@nvidia.com
Cc: linux-tegra@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies.
ARM: tegra: remove legacy DMA entries from DT

Now that all Tegra drivers have been converted to use DMA APIs which
retrieve DMA channel information from standard DMA DT properties, we can
remove all the legacy DT DMA-related properties.

Cc: treding@nvidia.com
Cc: pdeschrijver@nvidia.com
Cc: linux-tegra@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ASoC: dmaengine: remove SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME

struct snd_dmaengine_pcm_config's new chan_names field implements the
same feature, and nothing uses SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME,
so remove it.

Signed-off-by: Stephen Warren <swarren@nvidia.com>