After Mcasp_open completed

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

After 1

st

submit call

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

EMDA HW channel starts with param1

After 2

nd

submit call, if 1

st

not processed isr has

EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event 1 st App buffer EDMA Link Param 2 2 nd 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 3

nd

and later, submit call, if 1

st

isr has not processed • Application packet will be queued to driver’s internal queue

ISR for 1

st

packet, if app has issued 3

rd

app buffer

EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event Now working with param2 3 rd App buffer EDMA Link Param 2 2 nd App buffer Updates happens in red EMDA HW channel is now working with param2.

Now, param1 is updated with 3 rd app buffer (get the related info from queue) Params are being linked each other with valid configurations.

ISR for 1

st

packet, if app has NOT issued 3

rd

app buffer

EDMA Link Param 1 EDMA HW Channel (PaRAM) For mcasp tx event Now working with param2 Loop Job EDMA Link Param 2 2 nd 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 1 st 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 1 serviced before releasing the clock. See McASP UG st data

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