omap-l138 dsp/bios edma3 / linux spi hang

Mike,

Following are some of the assumptions, please confirm am i right:

          1.  SPI driver is configured to work in EDMA mode.

          2.  So the edma3init() is called from the SPI driver/application context, am i right?

Can i get some of the information as listed below:

         3.  In doing what operation (read/write), the SPI driver hangs?

         4. Is SPI edma callbacks are being generated after configuring and enabling the EDMA? If yes, what is the status carried by the edma callback? Is it missed event or error status or completion status?

         5. At the point when you kill the dsplink application, could you please confirm application is not in the error interrupt handler?

         6. Can you please name or describe the dsplink application which you killed befor talking to the SPI Port?

Thanks and Regards,

Sandeep K

Sandeep Krishnaswamy said:

          1.  SPI driver is configured to work in EDMA mode.

1. Yes, edma mode.

Sandeep Krishnaswamy said:

2.  So the edma3init() is called from the SPI driver/application context, am i right?

2. edma3init is called from a dsp application.  I had commented out anything that would have actually used the edma, so I think it is purely calling this function.

Sandeep Krishnaswamy said:

3.  In doing what operation (read/write), the SPI driver hangs?

3. I attempted read/write/erase operations, which always start with writing out the SPI port.

Sandeep Krishnaswamy said:

4. Is SPI edma callbacks are being generated after configuring and enabling the EDMA? If yes, what is the status carried by the edma callback? Is it missed event or error status or completion status?

4. The SPI driver is on the linux side, and I haven't debugged that yet.

Sandeep Krishnaswamy said:

5. At the point when you kill the dsplink application, could you please confirm application is not in the error interrupt handler?

5. Not sure what you mean here.

Sandeep Krishnaswamy said:

6. Can you please name or describe the dsplink application which you killed befor talking to the SPI Port?

6. It's custom, but mainly just loads the dsp binary and has a message queue between the dsp and arm.  Killing the dsplink application puts the dsp in reset.

Mike,

I think dsplink app is using the EDMA for its internal usage and could be stuck inside somewhere in the EDMA interrupt handler (missed event or any error interrupt) which is not allowing SPI work. To confirm this, you can try any other linux driver which uses the edma and then try read/write from the linux driver with the dsplink application running. With this set up Observe the linux side driver (edma) read/write happens properly or not.

Can you try this and share the observation?    

Thanks and Regards,

Sandeep K

OK, I'll take a look at that.  Part of my confusion was that I didn't know that other peripherals (such as USB) had their own DMA module.  I saw those drivers still working and was confused.  If I look at /proc/interrupts, I do see "edma_error" interrupts occurring on the ARM side.  I'll try to figure out what is causing that.

So far I have tracked it down to calling "registerEdma3Interrupts(edma3Id);" on the DSP that breaks the ARM edma.  I'll keep looking further to see what's going on in there.

If C64_enableIER(1 << 8) is called, spi stops working in linux.  I don't understand enough of the ECM and interrupt of the C6748 to know what this all is mapping to, but that particular interrupt on the DSP side is breaking the ARM side.  I will now try to find out what code executes when that interrupt is called to see what it is doing.

The code in particular to enable the ISR is:

    /* To enable EDMA3 CC Error interrupt */
    C64_enableIER(1u << hwIntCcErr[edma3InstanceId]);
    /* To enable EDMA3 TC Error interrupt */
    C64_enableIER(1u << hwIntTcErr[edma3InstanceId]);

I have tracked it down to event "56 EDMA3_0_CC0_ERRINT EDMA3_0 Channel Controller 0 Error Interrupt".  When this event in the ECM is not enabled, the ARM spi works.  When enabled, ARM spi does not work.  I placed a breakpoint on edma3CCErrHandler.  This function is called when I start using the SPI port on the ARM side.  If I put a breakpoint on "assert (rmObj != NULL);" at the beginning of the function, the ARM spi works.  Therefore, this function must be doing something to affect the edma that affects the completion of SPI edma calls on the ARM side.  Having the breakpoint suspends DSP execution so that it does not break edma.