Re: DMA Transfer Synchronization Issue in Out-of-Tree Sound Card Driver

[Mark Brown <broonie@xxxxxxxxxx>]

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