• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 434 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L137: HW question regarding EDMA3 LLD driver and use of edma3MemCpy() function

Stefan_Haas
Mastermind 25682 points

Other Parts Discussed in Thread: OMAP-L137

Hello,

one of my customer uses the OMAP-L137 and has modified some DSP code, below you can find the entire summary, but the the main question is:

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Is it fine to read the PaRaM while the DMA channel is running? The EDMA3 LLD implementation choice implies that this is not expected.

 

Here is the complete background:

"...

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

We have a new query regarding some issues we observe in the EDMA3 LLD driver. VERSION: EDMA3 LLD 01.10 / July 9, 2009.

 

We are using the TI PSP  GIO UART driver (which we have modifed to work at 1.5MBits). To do this we keep the RX running continuously with a auto-reloaded DMA channel and monitor how many bytes have been received by checking the EDMA3 PaRaM for that channel.

 

When we run at 50% DSP usage with some complex processing we see regular failures in a short period of time.

 

Investigating the EDMA3 LLD we have noted that the EDMA3_DRV_getPaRAM() function is implemented using a byte data move for the PaRaM from the peripheral via edma3MemCpy() function. What we observe in our software traces is that the cCnt reported by the EDMA3_DRV_getPaRAM() function has mismatched LSB and MSB bytes - which will explain the failure we see in our application.

 

To fix this we can make a simple modification to EDMA LLD code to ensure that the PaRaM field reads are atomic.

 

What we would like to have confirmed is that it is indeed fine to read the PaRaM while the DMA channel is running. The EDMA3 LLD implementation choice implies that this is not expected.

 

There are several places in the driver where the  edma3MemCpy() is used. We have not evaluated the impact in other usage.

..."

 

Thanks, Stefan

 

  • 0
    TI__Guru* 85315 points

    Hi Stefan
    We  recently came across a similar issue on another device, with similar EDMA3LLD and use-case

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/66011/244187.aspx#244187

    We have forwarded the inputs to the EDMA3LLD team for review and feedback.

    To answer your questions specifically

    Stefan_Haas said:
    To fix this we can make a simple modification to EDMA LLD code to ensure that the PaRaM field reads are atomic.

    I believe this implied that the work around was to do 32 bit reads of the PaRAM instead of 8 bit reads, by modifying the edma3MemCpy() function? From an EDMA3 architecture standpoint , this is the "right" thing to do , we recommend that PARAM should be accessed as 32 bit (not 8 or 16 bit). Will need to get the driver team's input on why the memCpy function was implemented the way it is and what other implications it could have since the function is used in other places.

    Stefan_Haas said:
    What we would like to have confirmed is that it is indeed fine to read the PaRaM while the DMA channel is running. The EDMA3 LLD implementation choice implies that this is not expected.

    This is generally not recommended, just because  the param is "live" with counts/source/dest values changing as the transfer progresses, it was certainly not the intended use model envisioned to check the status/progress of the transfer. We have seen customers get away with it.  From a CC architecture standpoint , it is ok ,as when CC is internally updating the param count/src/dst or doing a link update, these updates are "atomic" and while these updates are happening the CC will stall the CPU read/write accesses, so there is no possibility of race condition/condition between CPU accesses vs CC internal updates. So the only thing to worry about would be "reading a live param" where it could be different when read, incase the CPU read has stalled or blocked by some other access etc.

    Hope this clarifies some of your concerns. Please let us know if you have more questions.

    Regards

    Mukul