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.

AM5716: DMA channel reservation

Part Number: AM5716

When using DSP and IPU cores, how to reserve some DMA channels so Linux doesn't conflict with them?

Currently when we use some channels from DSP core and trying to check DMA status flags, they always are cleared when Linux is also running. When in U-Boot, flags are correct.

I understand that it should be resolved globally with "Late attach" implementation expected by the end of year or later. But maybe there is a documented method of reserving DMA chammels using device tree similar to memory reservation?

  • Hello Oleg,

    I am looking into this. Could you help me by telling me which DMA you want to use, and where you got your "should be resolved globally with "Late attach" implementation" information?

    Regards,

    Nick

  • The DMA is requested using the following code from the DSP core with CSL:

    Channel controller:  ch_num  = 1
    Traffic controller: tcc_num = 1
    Event number: evtq_num = 0
    EDMA3RequestChannel(edmaBaseAddr, EDMA3_CHANNEL_TYPE_QDMA, ch_num, tcc_num, evtq_num);

    Region: EDMAsetRegion(0);

    #define EDMA3_CC_XFER_COMPLETION_INT            (34U)

    CSL_xbarIrqConfigure(CSL_XBAR_IRQ_CPU_ID_DSP1, EDMA3_CC_XFER_COMPLETION_INT - 31, CSL_XBAR_EDMA_TPCC_IRQ_REGION0);
    Intc_IntRegister(EDMA3_CC_XFER_COMPLETION_INT, (IntrFuncPtr) EdmaCompletionIsr, NULL);

    Interrupt is used to make some actions on DMA xfer completion. And this code works in DSP. But at the same time in Linux the top shows this line:

    38     2   root     SW       0   0%   5% [irq/30-43300000]

    As shown, this irq of channel controller is also processed in Linux (and steals DMA status flags), when it should not.

    So the questions are:

    1) Why Linux processes this interrupt routed by DSP core into DSP core only?

    2) How to ensure that Linux does not use the same DMA channel for own purposes (so it's safe to use in DSP)? That is, how to reserve it for DSP or IMU?

    Regarding "Late attach", it was my assumption based on last reply in this thread. It was discussed there that with proper implementation Linux must know about other cores, but should not touch them in any case including power management, sleep modes, and as I assumed, IRQ/DMA used and, perhaps, defined somewhere in device tree as reserved for DSP use. Same applied for IMU as well.

    Currently we are trying to use DSP's own DMA so Linux has no access to it. But IMU core does not have own DMA, so we should use system one, and the problem will happen again.

  • I should tell that we talk about early DSP/IMU core boot from U-Boot or even SPL. These cores do not use RTOS and should start on SoC reset. Linux should not reinitialize or reset them, but some Linux app should be able later to communicate with them. That is exaclty "early boot - late attach" feature is for, and why we are waiting for it. But until implemented, we should debug some code, but have conflicts with Linux.

  • Hello Oleg,

    I apologize for the delay. We do have patches in the pipeline that modify the edma driver. Those patches will allow the user to modify the device tree to tell Linux to leave certain channels alone. To the best of my knowledge, the driver in SDK 6.0 does not currently support telling Linux which channels it cannot touch.

    Regards,

    Nick

  • Just re-read your previous post. Yes, for the DSPs it would probably be easier to use the DSP's dedicated DMA. I am not sure the right answer for the IPUs right now; e.g., I do not know if you can do all Linux functionality through the EDMA and all IPU functionality through the system DMA. I am asking around on this end.

    Regards,

    Nick