[RFC] audio: dai-zephyr: reset DMA buffer cursors on TRIGGER_RELEASE

[LaurentiuM1234]

On NXP platforms, stopping the DMAC and then re-configuring it leads to the internal DMA buffer cursors being reset. Leaving the SOF DMA buffer cursors in the same state means the DMA driver and SOF may potentially end up with two different views of the same buffer (from the cursors' point of view). This in, turn, may lead to the DAI consuming stale data because of the values of "free" and "pending" queried from dma_reload() stopping dai_common_copy() from copying new data. To fix this, reset the read and write cursors of the DMA buffer from SOF side. This way, both SOF and the DMA driver will have the same initial view of the DMA buffer cursors.

About the issue: when doing pause and resume very fast (holding the 'space' button) you get a screeching noise for a very short time. I was able to reproduce this during my first aplays but it may take several tries.

IMPORTANT: the main issue with this PR is that the conclusion (i.e: DAI consuming stale data because of buffer cursor mismatch) is just a hunch since I can't actually verify it. This is the only conclusion that makes sense since only resetting the buffer cursors from SOF side or not stopping and re-configuring the DMAC fixes this issue. Also, I've noticed that the buffers do indeed end up with different cursors after the pause and resume operations.

I've tested this with the following configurations:

1. i.MX93 + SAI w/ burst size = 384 bytes (i.e: a period's worth of data)
2. i.MX93 + SAI w/ burst size = 192 bytes (i.e: half a period's worth of data)
3. i.MX8QM + ESAI w/ burst size = 384 bytes
4. i.MX8QM + SAI w/ burst size = 192 bytes

Interestingly enough, configuration 1 works with and without this patch. I was able to get the issue in the rest of the configurations.

The issue only happens when you do pause and resume very fast. Specifically, you have to hold down the 'space' button when doing aplay with the following arguments: aplay -Dhw:... your_file_here -i -vv

A few words about our EDMA driver: each channel holds 2 cursors - read and write. For playback, the read cursor is updated after every chunk of 384 bytes. The write cursor is updated by SOF when calling dma_reload() with the number of copy bytes.

Alternatively, the issue can be solved by not doing dma_stop and dma_configure on RELEASE. This is because dma_config() resets the aforementioned cursors.

[lgirdwood]

This looks like the right thing todo here and the CI results that are published here look OK.
@marcinszkudlinski @plbossart @ujfalusi @abonislawski @kv2019i any comments ?
@wszypelt @lrudyX any related failure to this PR on internal CI ?

[wszypelt]

@lgirdwood after checking the logs and reruns, all tests passed

[kv2019i]

Seems like the correct fix to do.