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.
Attachment:
signature.asc
Description: PGP signature
