After Mcasp_open completed EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event loopJob EDMA Link Param 2 Keep reloading Loop job loopJob After Mcasp_open, EMDA HW channel would be working as loopJob with Param2

After 1st submit call EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event 1st App buffer Directly update Link addr with param1 EDMA Link Param 2 loopJob Updates happens in red. EMDA HW channel starts with param1

After 2nd submit call, if 1st isr has not processed EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event 1st App buffer EDMA Link Param 2 2nd App buffer Updates happens in red EMDA HW channel is still working with param1. Now param2 can work with valid application buffer after param1 completion. Also, loop job is out of param. Params are being linked each other with valid configurations.

After 3nd and later, submit call, if 1st isr has not processed Application packet will be queued to driver’s internal queue

ISR for 1st packet, if app has issued 3rd app buffer EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event 3rd App buffer Now working with param2 EDMA Link Param 2 2nd App buffer Updates happens in red EMDA HW channel is now working with param2. Now, param1 is updated with 3rd app buffer (get the related info from queue) Params are being linked each other with valid configurations.

ISR for 1st packet, if app has NOT issued 3rd app buffer EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event Loop Job Now working with param2 EDMA Link Param 2 2nd App buffer Updates happens in red EMDA HW channel is now working with param2. Now, param1 is updated with loop job buffer (when the internal queue is empty) Params are being linked each other with valid configurations.

Unclear points In any slides, Param1 and 2 are both loaded with valid (loop job or app buffer) configurations. Unclear points Param1 and 2 have valid values and linked each other. Even if the next ISR has missed at this point, CPU and EDMA are out of sync, but EDMA channel itself would still be able to go with previously-configured values, right ? So, it is not clear for me why you can state missing ISR can cause underrun. Did you confirm invalid link info was specified in edma channel parameter when you saw underun ? If yes, I think your suggestion is correct. But if no, there should be other reasons for underrun.

Potential issues in driver code From my code review, and I found some potential issues are present in the driver code. Please note this is NOT related to this underun/overrun issue and this is Just for your information. If these are correct, please feedback it to your driver team. submitCount is not being protected correctly between task and isr thread. In Mcasp.c at Line 2952, restoring the interrupt (to allow the interrupt), and then at line 3000, disabling the interrupt again for checking submitCount. If interrupt would happen between 2952 and 3000, driver would not work correctly. There is no reason to restore the interrupt at line 2952, I think. Not checking 1st data is serviced by EDMA before enabling the clock in Mcasp_localactivatesmfsforxmt() For transmit case using EDMA, the driver should wait for the completion of 1st data serviced before releasing the clock. See McASP UG - Transmit/Receive Section Initialization, 7-a. It says that … If DMA is used to service the McASP, the DMA automatically services the McASP upon receiving AXEVT. Before proceeding in this step, you should verify that the XDATA bit in the XSTAT is cleared to 0, indicating that all transmit buffers are already serviced by the DMA