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 DSP needs synchronous DMA

Other Parts Discussed in Thread: OMAP-L137

I met TI's Juan Gonzales in Schaumburg at the training class for codec engines. He suggested that he would help me by posting instructions (on wiki) for how to create a DSP thread that needs to use the EDMA for synchronous transfers (in my case SPI to DMA to external memory). The gist of it is that the codec engine assumes that all DMA transfers are controlled by its resource manager and all are asynchronous (QDMA). I need to steal one for synchronous use.

I currently plan to use both a codec engine *and* another thread that will coordinate the DMA transfers from outside hardware. I was told that I would need to create another thread (in main?) to perform the transfers. My intent is to have the codec use the most recently complete buffer for its work while the "other thread" creates the new data buffer. I suspect that globals would have to coordinate the buffer use.

I haven't found it out there, so maybe he hasn't posted it yet. Juan, are you listening?

  • Hello,

    Since coming back from the workshop, I have found that Framework components 2.20 and newer have bew features which allow DMAN3 to control EDMA resources as well.  I have not tried this myself because I am more of an ARM/Linux guy and spend little time on the DSP side; additionally, I am not too deeply involved with OMAP-L1, but do know the people in our team involved with this product.  I am certainly willing to help find the proper internal resources to help you in your quest, just note that this may not be me, specially if we are talking about the DSP side of things :).  I am still looking into this issue, unfortunately, as you can imagine, I had a week of catching up and have not gotten very far on this yet, but I will get around to this...

  • Any contacts you can give me would be great. If the EDMA resources can be controlled by the resource manager, I might be able to use another engine to run the spi->dma->external memory. It is unlikely that I would ever give the DMA back, but I think that would work. At least it would bring my DSP application in line with the expectation of engines-only.

    The training was not OMAP-L137 related, so we did not cover how to differentiate between QDMA and other DMA resources. I'm also going to look into the XDM Components tool that was discussed.

     

  • With regards to contacts, because this part is rather new, at present there are a few of us familiar with different aspects of the part; therefore, this will likely have to be a collaborative effort.  I have scheduled time to work on this with another engineer who is more knowledagable on DSP side tomorrow.  I could schedule a teleconference between all of us if necessary, but I believe you have done a good job of describing your needs and at present, our time is better spent investigating potential solutions.  Of course, we are always open to input.

  • Thanks. I look forward to hearing the results of your consultation. In a related vein, I'll need to know similar information for the GPIO. Remember in class I mentioned that I'll need DSP access to certain GPIO pins (to control other hardware).

  • Apologies for the delay and thank you for your patience.

    So we investigated two avenues for accessing EDMA channels from DSP (as opposed to QDMA)

    1) You can use framework components 2.20 or newer; I can see some support built-in and there is even an example; however, the examples did not seem very complete in my opinion and limited knoweldge.  I can see the examples allocating EDMA channels, but to not see any transactions being initiated.  Therefore, I would be cautious to go this route.

    2) Use EDMA low lewvel driver.  This is already available in EA release.  What I have yet to verify is if you can use DSP drivers aling with codec engine; otherwise, we may need to go with DSPLINK.  As a matter of fact, we have request examples that use DSPLINK and DSP drivers together as we expect other customers may be interested in this scenerio; however, initial feedback is that these examples will likely not be available anytime soon.  However, after analyzing all the options, in my opinion the software modules that require this approach are probrably more mature and will likely be the better path if you want more flexibility, but withino examples in the foreseeable future, you will likely need to implement much of the leg-work yourself. 

    In short, either way you will need to do some work yourself, but our team is here to help.  I want to reiterate that OMAP-L1 is not one of the primary platforms I support, so someone else from our team will likely jump in to continue supporting you, but I have enjoyed trying to help you as much as I could.

     

  • I intend to use the low-level drivers. I had hoped that the resource manager would pass the EDMA as a resource. I've asked MontaVista to look into how to remove an EDMA channel from its resource list.

  • Please note that if you are using DSP EDMA driver, you should consider not using ARM EDMA driver; this would likely solve the problem.  I believe ARM and DSP drivers are tested separately, so I am not sure to what extent you can mis and match them if at all.  If you really need to mix and match Linux and DSP drivers, you will likely need to modify drivers as you suggested above.  The software can be customized to do almost anything you can imagine; however, the software we provide does not necessarily cover every scenerio customers will need.  This is why we provide the source code for much of our software, so that customers can do their custimization to meet their needs.