On Tue, May 21, 2024 at 10:31:12AM +0200, Louis Chauvet wrote:
To address this DMA issue, I have created a patch [1] that guarantees the completion of the DMA transfer upon the return of xdma_synchronize. This means xdma_synchronize now sleeps, but looking at other drivers around it appears expected to be able to do so.
You need to set the nonatomic flag for the PCM to allow this, the default is that triggers run in atomic context.
switch (command) { case SNDRV_PCM_TRIGGER_START: /* Synchronize on start, because the trigger stop is called from an IRQ context */ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) dmaengine_synchronize(my_dev->playback_dma_chan);
If any dmaengine work is needed put it in the generic dmaengine code and allow it to be configured there (ideally through discovery through the API).
The problem might be related to the sound driver. Should I avoid manually using dmaengine_synchronize? How to achieve the same effect in this case? Perhaps there is a more traditional way to properly clean the stream in the sound subsystem which I overlooked?
If there's no way of resetting things without blocking then I'm not sure you can do much better though I might be forgetting something, it does seem like disappointing hardware design and application behaviour.