Re: [PATCH v2] dma: omap-dma: add support for pause of non-cyclic transfers

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Fri, Aug 07, 2015 at 07:55:48PM +0200, Sebastian Andrzej Siewior wrote:
> /* 
>  * We do not allow DMA_MEM_TO_DEV transfers to be paused.
>  * From the AM572x TRM, 16.1.4.18 Disabling a Channel During Transfer:
>  * "When a channel is disabled during a transfer, the channel undergoes
>  * an abort, unless it is hardware-source-synchronized …".
>  * A source-synchronised channel is one where the fetching of data is
>  * under control of the device. In other words, a device-to-memory
>  * transfer. So, a destination-synchronised channel (which would be a
>  * memory-to-device transfer) undergoes an abort if the the CCR_ENABLE
>  * bit is cleared.
>  * From 16.1.4.20.4.6.2 Abort: "If an abort trigger occurs, the channel
>  * aborts immediately after completion of current read/write
>  * transactions and then the FIFO is cleaned up." The term "cleaned up"
>  * is not defined. TI recommends to check that RD_ACTIVE and WR_ACTIVE
>  * are both clear _before_ disabling the channel, otherwise data loss
>  * will occur.
>  * The problem is that if the channel is active, then device activity
>  * can result in DMA activity starting between reading those as both
>  * clear and the write to DMA_CCR to clear the enable bit hitting the
>  * hardware. If the DMA hardware can't drain the data in its FIFO to the
>  * destination, then data loss "might" occur (say if we write to an UART
>  * and the UART is not accepting any further data).
>  */
> 
> would that be okay?

Better, if a tad verbose.  I guess no one will miss that. :)

> If I google for it, I find it. pause/resume support for cyclic was added
> later without a note why it is only supported for cyclic.

Try searching for the "[PATCH 11/11] ASoC: omap-pcm: Convert to use
dmaengine" thread, which was the initial round of patches converting
omap-pcm to DMA engine, and where there was some discussion of how
to handle it at that time.

The result of that was it was felt that the safest approach was to
limit it to cyclic transfers for ASoC, and to use the method which
had been well proven over previous years/decade on numerous different
OMAP hardware.

It's all entirely sensible given that omap-dma has to cope with many
different hardware revisions with two major hardware versions and
people having limited testing resources for validation.  So you will
understand, given the data loss issues here, why it was decided that
omap-dma will only provide pause/resume support for cases where it
has been proven to work sufficiently well and where data loss is not
that a major issue (if a few samples of audio get lost over a
suspend/resume, it's not going to corrupt your data.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.