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.

C6678 - EDMA Transfer Completion to Generate PCIe Interrupt

Hello,

I am writing a Linux device driver for a C6678 based on the pciedemo.c example in the MCSDK. I'm using DMA for my read and write functions similar to the HAL_readDMA( ) and HAL_writeDMA( ) functions. Both of these functions start a DMA transfer and poll the IPR register in an infinite loop to know when the transfer is completed. I would like to instead have the DSP send a PCIe interrupt when the DMA transfer is completed so that my driver can be notified asynchronously and polling won't be needed. Is this possible on the C6678 without any code running on the DSP (i.e. only with register/memory reads/writes)? If so, how would I accomplish this or where should I look for details on how to do this?

Regards,

Chris Johnson

Signalogic

  • Chris,

    If I understand you correctly, you are trying to let C6678 generate one interrupt to C6678 itself after C6678 completes the EDMA transfer with PCIe.

    I think instead of polling EDMA register or PCIe interrupt, the EDMA itself could generate the "Transfer Completion Interrupts" to DSP after the transfer. Please refer to section 2.9.1 in EDMA user guide for details. 

    You have to setup the chip-level interrupt controller (CIC), CorePac interrupt controller and interrupt service routine (ISR) before you trigger the interrupt. 

    Those could be found in CIC user guide and CorePac user guide. There are also CSL example codes to demonstrate the usage of CSL interrupt APIs, such as "C:\ti\pdk_C6678_xxx\packages\ti\csl\example\cpintc\cpintc_test.c".

    The interrupt event number could be found in the interrupt event tables in the data manual.

    For example, the EDMA3CC1 CCINT0 (completion interrupt) is event #8 of CIC0 as mentioned in Table 7-39 of C6678 data manual.

    Alternatively, you can link one EDMA transfer to the end of the data transfer. The last EDMA transfer could set the write MSI vector bits in PCIe MSIn_IRQ_STATUS_RAW register to generate the PCIe MSI_n interrupt to CorePac in C6678.

    You have to enable the MSI_n interrupt first by setting the MSI0_IRQ_ENABLE_SET register and enable the CorePac interrupt controller and ISR.

    The PCIe_MSI_INTn is primary event #17 for CorePac. Please note that MSI_INTn only triggers interrupt in CorePacn (MSI_0 for CorePac0, MSI_1 for CorePac1, etc.).

    Please also note that writing to MSIn_IRQ_STATUS_RAW is only for debugging purpose as mentioned in the PCIe user guide. It is not the PCIe protocol (it is usually that one PCIe generates interrupt to another one, not generating interrupt to itself). 

    There are several posts regarding to MSI interrupt you can refer to, such as 

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/166202.aspx

    I think it is better to use the EDMA completion interrupt instead of PCIe interrupt if I understand your purpose correctly. Hope it helps.

     

  • Steven,

    I'm actually looking to generate an interrupt to the host over PCIe. This would be the EP_IRQ_STATUS register. Currently, when the EDMA transfer with PCIe completes, the IPR register in the EDMA is set and the host polls this register to know that the transfer has completed. It looks this could be done by linking an EDMA transfer that writes to the EP_IRQ_SET register. Is there any other way to do this that would avoid the extra EDMA transfer?

    Thanks,

    Chris

    Signalogic

  • Chris,

    The EDMA is on C6678 side, right? If so, I think it could be done by generating EDMA transfer completion interrupt to the DSP after the transfer instead of polling. Then the CorePac will be notified and the CorePac could write to EP_IRQ_SET in C6678 PCIe or write to MSI_IRQ on the host side to generate interrupt over PCIe link. It could avoid the extra EDMA transfer. But it is two-phase procedure.

    The extra EDMA transfer could save the EDMA interrupt and generate PCIe interrupt directly. It depends on the preference of your application. Maybe other members could share their thoughts as well.

     

  • Steven,

    Yes, EDMA is on C6678 side. From what I understand, this would require code running on the DSP as an interrupt handler would be needed to write to the EP_IRQ_SET register. This looks like what is done in the pcieboot_interrupt.c MCSDK example. Is there some other way to have the CorePac write to the EP_IRQ_SET register when it receives an interrupt, or is it be necessary to run code on the DSP so the CorePac would have an interrupt handler that would set the EP_IRQ_SET register?

    Thanks,

    Chris

    Signalogic

  • Chris,

    If you want to use CorePac to write to the PCIe register after receiving the EDMA completion interrupt, you need the interrupt handler (and interrupt service routine) for the interrupt setup in CorePac. When the CorePac receives an EDMA interrupt, it will jump to that ISR and service that interrupt. So I think we need to have the interrupt handler for CorePac and the CorePac will clean up the interrupt and write to the PCIe register to trigger the PCIe interrupt in ISR.

  • Steven,

    So it seems like the only option without running code on the DSP is to link an EDMA transfer that writes to the register. I guess this will have to do for now.

    Thanks for the help, Steven.

    -Chris

    Signalogic

  • Steven-

    There are no examples in the MCSDK of doing this?  I would think a PCIe interrupt would be crucial for any PCIe device.  Otherwise the host must always poll to get data result status.

    -Jeff

  • Jeff,

    There are several posts discussed about the MSI interrupt of PCIe. You can generate MSI interrupt from EP to RC (host) after the data transfer. 

    The following threads may contain some examples and explanation of how to do it. Hope it helps.

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/202251/718846.aspx#718846

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/181633.aspx

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/194406/717007.aspx#717007