AM62x: Audio capture DMA issue.
Command being used: arecord -t wav -r 48000 --period-size=64 1.wav -d 5
Issue: The first time the command is given, it seems to work. i.e. 5 seconds of audio is captured as expected. The second time the command is given, chaos happens.
Similar reports about problems with multiple audio captures and problems when ctrl-c is used to force a command to stop have been made. This issue may be a duplicate of those but reports of progress on those issues have not been seen. Maybe this report has a little more information and can help with progress to a solution.
I have added some debug messages to files in drivers/dma/ti to see if there is something that the software is doing incorrectly with regards to setting up the dma. Nothing has been found. Most of the dma activities seem to be in drivers/dma/ti/k3-udma.c and drivers/soc/ti/k3-ringacc.c. The sequence of dma related events seems to be the following:
First capture:
* udma_start() is called to setup and start the capture.
* The capture proceeds for 5 seconds.
* terminate_all() is called to stop the dma.
** udma_stop() is called. (this is device to memory)
*** Value for CTL_REG seems to show that a teardown is requested.
** An interrupt happens and it looks like the registers and ring think the teardown happened.
*** The handler calles udma_start() which seems strange but there is no "vd" entry so udma_start doesn't actually do anything.
* Everything looks like it is cleaned up.
Second Capture:
* udma_start() is called to setup and start the capture.
* The capture does not proceed. Instead, there is a call to terminate_all() that tries to do something to stop the just started dma. It does not go well.
After the call to terminate_all(), there can be repeated reports of overruns. Usually, the command does not terminate at all (even with ctrl-c) and a power-cycle is needed to recover control of the system. It is not possible to issue a reboot command at the console.
There is also a report of an unhandled RX event:
unhandled rx event. rxstat: 0x00000156, evtctrl: 0x00000001, rclkchk: 0x00000000, rcnt: 0, rmax: 0, rmin: 0, rps: 0
This is a modified report with additional values added to try and get info about the unhandled rx event.
The main issue seems to be that while the dma teardown on the first command seems to work, something is apparently amiss such that the second command is unable to operate at all and is unable to cleanup to return to a stable state.
A capture of the console log showing the various debug messages is attached. The first command is given at 115.426607, there is a pause of 5 seconds (while the capture is happening) until 120.945270 and the cleanup is complete at 122.150046.
The second command starts at 126.998449. The udma_start ends at 127.513385 with the next message at 127.534760 being the call to udma_terminate_all(). There is no 5 second pause while the audio capture happens. Instead, the udma_terminate_all() is called and a successful cleanup is not performed.
Is the software doing something incorrectly? Or is there a problem with the dma hardware that prevents subsequent commands from working?
