[alsa-devel] [PATCH v3 0/6] dma: Indicate residue granularity in dma_slave_caps

[Lars-Peter Clausen]

New in v3:
	* Expanded the kernel doc documentation for the dma_residue_granularity
	  struct a bit

New in v2:
	* Dropped byte level granularity as discussed during v1 review
	* Added support for auto-detecting the NO_RESIDUE flag on the compat path in
      the generic ASoC dmaengine PCM driver
	* Updated a few ASoC drivers to take advantage of the new API

Updated original cover text from v1 below:

This patch series introduces a new field to the dma_slave_caps struct which
exposes the granularity with which the reported residue is updated, updates the
pl330 DMA driver to set this field and lets the generic dmaengine PCM audio
driver check that field.

The reason for introducing the field is that for audio we need to know the
granularity with which the reported residue is updated. The uncertainty of the
ALSA period pointer depends on the granularity of the reported residue. E.g. if
residue is only updated once every period this means that the position in the
buffer from/to which the hardware is currently reading/writing could be
anywhere between the reported PCM pointer and the reported PCM pointer plus one
period size (plus some extra margin for interrupt latency, etc). Certain
algorithms (e.g. pulseaudio's timer based scheduling) only work correctly if the
uncertainty of the PCM pointer is low enough. Exposing this information from the
DMA driver makes it possible for applications to switch to alternative modes of
operation which also work with a high granularity.

The patch series introduces four levels of granularity, which I think will cover
most DMA cores. I'd like some feedback though if anybody can think of a DMA
controller for which none of the levels would be correct. The four levels are:
	* DESCRIPTOR: The DMA channel is only able to tell whether a descriptor has
	  been completed or not, which means residue reporting is not supported by
	  this channel. The residue field of the dma_tx_state field will always be
	  0.
	* SEGMENT: The DMA channel updates the residue field after each successfully
	  completed segment of the transfer (For cyclic transfers this is after each
	  period). This is typically implemented by having the hardware generate an
	  interrupt after each transferred segment and then the driver updates the
	  outstanding residue by the size of the segment. Another possibility is if
	  the hardware supports SG and the segment descriptor has a field which gets
	  set by the hardware after the segment has been completed. The driver then
	  counts the number of segments which do not have the flag set to compute
	  the residue.
	* BURST: The DMA channel updates the residue field after each transferred
	  burst. This is typically only supported if the hardware has a progress
	  register of some sort (E.g. a register with the current read/write address
	  or a register with the amount of bursts/beats/bytes that have been
	  transferred or still need to be transferred).

 - Lars

Lars-Peter Clausen (6):
  dma: Indicate residue granularity in dma_slave_caps
  dma: pl330: Set residue_granularity
  ASoC: generic-dmaengine-pcm: Check NO_RESIDUE flag at runtime
  ASoC: generic-dmaengine-pcm: Check DMA residue granularity
  ASoC: axi-{spdif,i2s}: Remove SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag
  ASoC: samsung: Remove SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag

 drivers/dma/pl330.c                   |  1 +
 include/linux/dmaengine.h             | 28 +++++++++++++++
 sound/soc/adi/axi-i2s.c               |  3 +-
 sound/soc/adi/axi-spdif.c             |  3 +-
 sound/soc/samsung/dmaengine.c         |  1 -
 sound/soc/soc-generic-dmaengine-pcm.c | 66 ++++++++++++++++++++++-------------
 6 files changed, 73 insertions(+), 29 deletions(-)

-- 
1.8.0