On 8/19/20 1:08 PM, Lars-Peter Clausen wrote:
On 8/17/20 9:28 AM, Benjamin Bara - SKIDATA wrote:
We think this is not an i.MX6-specific problem, but a problem of the
DMAengine usage from the PCM.
In case of a XRUN, the DMA channel is never closed but first a
SNDRV_PCM_TRIGGER_STOP next a
SNDRV_PCM_TRIGGER_START is triggered.
The SNDRV_PCM_TRIGGER_STOP simply executes a
dmaengine_terminate_async() [1]
but does not await the termination by calling dmaengine_synchronize(),
which is required as stated by the docu [2].
Anyways, we are not able to fix it in the pcm_dmaengine layer either
at the end of
SNDRV_PCM_TRIGGER_STOP (called from the DMA on complete interrupt
handler)
or at the beginning of SNDRV_PCM_TRIGGER_START (called from a PCM
ioctl),
since the dmaengine_synchronize() requires a non-atomic context.
I think this might be an sdma specific problem after all.
dmaengine_terminate_async() will issue a request to stop the DMA. But
it is still safe to issue the next transfer, even without calling
dmaengine_synchronize(). The DMA should start the new transfer at its
earliest convenience in that case.
dmaegine_synchronize() is so that the consumer has a guarantee that
the DMA is finished using the resources (e.g. the memory buffers)
associated with the DMA transfer so it can safely free them.
You can think of dmaengine_terminate_async() and
dmaengine_issue_pending() as adding operations to a command queue. The
DMA is responsible that the operations are executed in the same order
that they were added to the queue and to make sure that their execution
does not conflict.
dmaegine_synchronize() is for external consumers to wait until all
operations in the command queue have been completed.
