• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 518 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.

Using EDMA3 LLD driver on both ARM & DSP?

MikeH
Guru 15580 points
Other Parts Discussed in Thread: OMAP-L138, SYSBIOS, OMAPL138

I am trying to use the EDMA3 LLD on both the DSP and ARM of my OMAP-L138. I will be using the ARM to receive and process audio from an AIC3204 codec via the McASP using a ping-pong buffer on the incoming audio stream. I will use the DSP to process audio for the outgoing audio stream to the Codec D/A via the McASP. 

I assume that implementing the above will require an instance of the EDMA3 LLD on both the DSP and ARM. I also assume that these two instances of the LLD will require their respective events (EVT#8 for the DSP, and EVT#11 for the ARM) to be routed to the Interrupt Controllers of the two cores (AINTC and DSPINTC), in which a HWI must be selected. I also assume that these HWI's will be processed by the respective interrupt dispatcher for the two cores such that a callback function will be called on each core.

Is this correct? Will there be any issues running separate instances of EDMA3 LLC on the two cores? I would assume not, since the two cores are operating completely independently.

Guidance and suggestions appreciated......

Thx,

MikeH

 

  • 0
    TI__Genius 14545 points

    Mike,

       Just curious -  why wouldn't you get use the DSP /EDMA3 LLD's to capture/spit out the audio from McASP?. Is the ARM supposed to do something fancy before it passes to the DSP?

    To answer your question, i'm not sure if you'd need two instances or not, but it seems like a circuitous/complicated way to perform a simple task.

     

  • 0 in reply to dabuan
    Guru 15580 points

    Drew,

    Drew Abuan said:
    but it seems like a circuitous/complicated way to perform a simple task.

    This is by no means a simple task.

    Drew Abuan said:
    why wouldn't you get use the DSP /EDMA3 LLD's to capture/spit out the audio from McASP?

    The system load requires a split of functions between the ARM & DSP. I can't afford to burden the DSP with the additional cpu load of dealing with the audio stream from the codec.

    Drew Abuan said:
    Is the ARM supposed to do something fancy before it passes to the DSP?

    The ARM does not "pass" to the DSP. The incoming audio stream and outgoing audio streams are totally independent of each other.

     

    RandyP?? Mukul?? Jeff??

     

    Thx,

    MikeH

     

  • 0 in reply to MikeH
    TI__Guru* 83935 points

    Mike

    I have forwarded your query to subject matter experts on this topic. You are getting into the realms of resource manager (RM) concepts on EDMA3 as a shared resource between ARM and DSP. It also appears that you might not be using Linux on ARM side (correct?)

    Regards

    Mukul

     

  • 0 in reply to Mukul Bhatnagar
    Guru 15580 points

    Mukul,

    Mukul Bhatnagar said:
    It also appears that you might not be using Linux on ARM side (correct?)

    Correct. I am using SYSBIOS on both and IPC to intercommunicate between cores.

    Mukul Bhatnagar said:
    You are getting into the realms of resource manager (RM) concepts on EDMA3 as a shared resource between ARM and DSP

    Yes, scary stuff indeed....:). The incoming and outgoing audio streams to/from the codec will be transferred one sample at a time until a "frame" transfer has completed (~128 samples), so the resource congestion should not be too bad. Samples occur at a rate of 1/(48000*2) sec (stereo audio). Since I am using the McASP in DMA mode (as you know) the samples are transferred in 32-bit chunks.

    I guess my other basic question is, do you see anything fundamentally wrong with this approach (ie using the ARM for incoming audio streams and the DSP for outgoing audio streams)? Anything that would prevent the technique from working with EDMA3 LLD?

    Thanks for your help.

    MikeH

     

  • 0 in reply to MikeH
    TI__Expert 6065 points

    Mike,

    Are you facing any issues when you are trying to access EDMA from both the cores? What is the EDMA3LLD version you are using?

    As per my understanding EDMA can be invoked from both the cores simultaneously.
    But you need to make sure that in the configuration parameters the dma/qdma channels, param sets and tcc owned by the two hosts should be distinct. these are in resources owned by a specific region specified in the cfg files. In omapl138 region 0 is for arm and region 1 is for dsp.

    The two cores use their specific shadow region registers to configure the EDMA and once the transfer is complete the IPR register bits in their shadow region is set. This intern gives an interrupt to the corresponding core, hence the simultaneous access should be possible

    Prasad

  • 0 in reply to Prasad Konnur
    Guru 15580 points

    Prasad,

    Prasad Konnur said:
    Are you facing any issues when you are trying to access EDMA from both the cores?

    I don't know. I am still in the process of migrating from bios 5 to bios 6. I was hoping to get some feedback on the issues with dual-core access of EDMA3 before I put in the time and effort to  move to bios 6. From your comments above, it appears feasible.

    Prasad Konnur said:
    What is the EDMA3LLD version you are using?

    I had downloaded the most recent version (2.11.01.02) but noticed in the release notes a problem with ARM support. I will now download an earlier version that works with both ARM and DSP.

    Prasad Konnur said:
    As per my understanding EDMA can be invoked from both the cores simultaneously.
    But you need to make sure that in the configuration parameters the dma/qdma channels, param sets and tcc owned by the two hosts should be distinct. these are in resources owned by a specific region specified in the cfg files. In omapl138 region 0 is for arm and region 1 is for dsp.

    The two cores use their specific shadow region registers to configure the EDMA and once the transfer is complete the IPR register bits in their shadow region is set. This intern gives an interrupt to the corresponding core, hence the simultaneous access should be possible

    Great information! This statement has probably saved me weeks of potential troubleshooting!

    It's interesting, this question (multi-core access of peripheral devices) applies to several other peripherals I plan to use with both cores (SPI, GPIO, etc).

    Thanks!

    MikeH