• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 509 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 L138 DSP EDMA Issue (QDMA works, EDMA does not)

Matthew Needes
Prodigy 20 points
Other Parts Discussed in Thread: OMAP-L138

For some reason I cannot get DSP-initiated EDMA transfers to work on the OMAP-L138 while Linux is running.  DSP-initiated QDMA transfers, however,  work just fine.   EDMA transfers cause linux to hang.

Configuration:
1. I'm using DSP/BIOS and Link/BIOS and am NOT using the EDMA3 LLD.  The LLD is overkill for our needs.
2. EDMA/QDMA are not being used by the linux side (though the kernel module (arch/arm/mach-davinci/dma.c) is operational).
3. The kernel module (dma.c) was modified to set the DRAE/QRAE registers to enable DSP-initiated EDMA/QDMA operation.
4. I'm using the 2nd EDMA channel controller and shadow region 1 for the DSP.
5. I'm using interrupts for transfer completion for both EDMA/QDMA.

When the DSP is running WITHOUT linux (via emulator), both EDMA and QDMA work just fine!  No error interrupts are generated.
I've tried disabling the linux DMA ISRs but nothing I've done has changed the symptoms.
It is as though the linux side is responding to channel events even though DRAE for shadow region 0 is set to ZERO !

Any help is appreciated !

Thanks,
Matt

 

 

 

 

  • 0
    TI__Expert 3990 points

    Matt,

    Some doubts/suggestions I have:

    1. Are you using any drivers on Linux which need EDMA3? Specifically, SPI, MMC and McBSP (audio) use EDMA3. Would it be possible to compile them out and see if the behavior changes?
    2. If you are not using EDMA3 at all on linux side, I would suggest completely compile out the module itself (if possible) or at least make sure the probe function doesn't get called. If some driver then tries to use EDMA3, it will fail.
    3. Any specific reason to set DRAE/QRAE registers from ARM and not from DSP? I suggest you do it from DSP where you are programming these channels.
    4. "When DSP is running WITHOUT..." is contradictory to statement (3) as without setting the right DRAE/QRAE bits, EDMA3 wont generate the completion interrupts. Are you using these channels in POLL mode?
    5. Can you check whether any error interrupt has occurred for the DMA channels, when DSP is running with linux?
    6. When you say linux hangs, you mean to say it fails to respond completely or are you still able to telnet to it? Can you check exactly where it is at that point of time. May be you can try using an emulator to find out its current position.

     

  • 0 in reply to Anuj Aggarwal
    Prodigy 20 points

    Hi Anuj,

    Thank you for your response !    I address each line item below:

    1.  SPI is needed for boot but by all evidence the ARM is not using EDMA during run-time (DRAE0 set to zero after boot from DSP trace).  We will try removing the MMC and have already removed McBSP.

    2.  We currently aren't using EDMA3 on Linux, but would prefer to have the EDMA driver on the linux side coexist with the DSP in case we need it in the future.

    3.  Since we want both drivers to coexist and the ARM is the "master" and a resource controller, we would prefer configuring the registers from the ARM side.

    4.  When the DSP is running by itself on the emulator we use a slightly different image that DOES set the DRAE/QRAE registers (using conditional compilation).  In this case transfer completion interrupts work for both EDMA and QDMA (as evidenced by semaphore synchronization).

    5. / 6.  We are in the process of figuring out how to use the emulator with Linux and DSP.   By "hanging" I mean that the serial terminal hangs.  Unfortunately we aren't that very experienced in troubleshooting Linux/DSP problems on this OMAP.  I guess we have to start somewhere.

    It would be nice if the ARM driver (dma.c) had a provision for reserving DSP resources.  This shouldn't be too hard to implement, but we need to fix this problem first ...

    Thanks again,

    Matt