• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1178 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.

AM5726: Dependency between DMA (DREQ) and interrupt (IRQ) requests

Butters
Expert 2021 points

Part Number: AM5726

Hello,

My colleagues and I are confused about what appears to be a dependency between DMA requests (DREQ) and interrupt requests (IRQ). Our specific use case is as follows:

  • We are configuring AM5726 pin A10 as GPIO8_23.
  • A rising edge on GPIO8 pin 23 is intended to trigger a DMA from DSP1, so we configure the PaRAM set for DSP1_EDMA channel 9 to perform the desired DMA transfer.
  • We then set the DMA_DSP1_DREQ_9_IRQ_9 field of the CTRL_CORE_DMA_DSP1_DREQ_8_9 register to the value 194 (DMA_CROSSBAR_194 is GPIO8_DREQ_EVT).

This DMA transfer is working, but only when we ALSO enable rising-edge interrupt detection for GPIO8 pin 23, by setting bit 23 of the GPIO8 GPIO_RISINGDETECT register and bit 23 of the GPIO8 GPIO_IRQSTATUS_SET_0 register. If we do not set these bits, then the DMA does not occur. This is confusing to us because, as far as we can tell from the TRM, there is no relationship between DMA requests (DREQ) and interrupt requests (IRQ). So why should an IRQ need to be enabled for a DMA request to be serviced? We would prefer to not have to enable the rising-edge interrupt detection for GPIO8 pin 23.

Thanks in advance for your assistance, and best regards,
Dave

  • +1
    TI__Guru** 123775 points

    Hello Dave,

    The DMA Crossbar input from peripheral devices are the DREQ_EVTs. This is GPIO8_DREQ_EVT for GPIO8 module.

    As per Table 16-6 Connection of The Device DREQs to The DMA_CROSSBAR Inputs of the TRM, and Table 27-4 GPIO Hardware Requests, the GPIO8_DREQ_EVT description says it as event/interrupt1. This suggests the conditions for DREQ_EVT signals to change seem to be the same as configuring it as a corresponding first interrupt line.

    I do not see any other references in the TRM either that suggests otherwise.

    You can also see the same in Figure 27-7. General-Purpose Interface Block Diagram and Figure 27-8. Synchronous Path.

    The GPIO_RISINGDETECT register is definitely needed as part of the internal GPIO event detection logic. And GPIO_IRQSTATUS_SET_0 would enable the corresponding interrupt signal.

    I hope you are also programming the DSP_SYS_DMAWAKEEN0 / DSP_SYS_DMAWAKEEN1 registers within the DSP software.

    regards

    Suman

  • 0 in reply to Suman Anna
    Expert 2021 points

    Hi Suman, thanks for your reply.

    Suman Anna said:
    the GPIO8_DREQ_EVT description says it as event/interrupt1. This suggests the conditions for DREQ_EVT signals to change seem to be the same as configuring it as a corresponding first interrupt line.

    Thank you for pointing that out; perhaps I should have understood from the start what "event/interrupt1" meant, but I admit that I did not.

    So, unfortunately, it seems that there is no way to get the second GPIO interrupt to trigger a DMA request, since only "event/interrupt1" is an input to the DMA crossbar. Just for your understanding, the reason that I was asking is because our Linux-side developers are saying that the TI Linux GPIO driver (gpio-omap.c) doesn't support the use of the second GPIO interrupt either, and there is a different pin in GPIO bank 8 that is needed to trigger an interrupt in Linux. So their workaround has been to modify gpio-omap.c, but they're not happy about it. I'm working on the DSP side of things, and was hoping to help them out by using the second GPIO interrupt to trigger this DMA request, but I now understand that this is not possible.

    Thanks again for your assistance, and best regards,
    Dave

  • 0 in reply to Butters
    TI__Guru** 123775 points

    Hi Dave,

    The two interrupts were present mostly to deal with the case of exercising them independently from the two Cortex-A15 cores when they are running independent OS.

    From Section 27.1 General-Purpose Interface Overview, 

    Two identical submodules can process synchronous interrupt requests from each channel to be used
    independently in a biprocessor environment.

    The Linux is running the Cortex-A15 MPU subsystem in SMP-mode, so it only needs one interrupt line. The driver definitely needs additional changes if it requires supporting both interrupt lines. It would probably be easier to swap one line for the other, but supporting both the interrupts may not be that straight-forward.

    regards

    Suman