• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 819 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 SCR prioritied

Alexander Baehr
Intellectual 657 points

Other Parts Discussed in Thread: OMAP-L138

Dear all,

I a using the OMAP L138 CPU (ARM9 + DSP 674x dual core).

On the DSP, we have a task running at 125us, which is a sequence of

- DMA (edma31cc0) input from EMIFA parallel bus
- computational task
- DMA output to EMIFA

The task time is counted to the end of DMA output.

We found that the task time is not stable when we execute programmed read or write transfers from ARM to EMIFA bus (which should have low priority). On the scope, I noticed that the ARM transfers get executed during the DMA transfer, thus prolonging the DMA time.

I have tried to fix this in the MSTPRIx registers (see below). This did not have any measurable effect. A helpful measure was to insert wait loops in ARM code between the transfers. Now, we have up to 20ms prolonging of the fast task, which is still too much.

What exactly should the MSTPRIx registers do? Should the behaviour change if we set the priorities more extreme (ARM = 7)?

Are there other methods to prioritize the DMA?

Thanks for any hint.


-----------------------------

sysRegs->MSTPRI0 = CSL_FMK(SYSCFG_MSTPRI0_SATA, 7) |
                   CSL_FMK(SYSCFG_MSTPRI0_UPP, 7) |
                   CSL_FMK(SYSCFG_MSTPRI0_DSP_CFG, 1) | 
                   CSL_FMK(SYSCFG_MSTPRI0_DSP_MDMA, 1) |
                   CSL_FMK(SYSCFG_MSTPRI0_ARM_D, 2) |
                   CSL_FMK(SYSCFG_MSTPRI0_ARM_I, 2);

sysRegs->MSTPRI1 = CSL_FMK(SYSCFG_MSTPRI1_VPIF_DMA_1, 7) |
                   CSL_FMK(SYSCFG_MSTPRI1_VPIF_DMA_0, 7) |
                   CSL_FMK(SYSCFG_MSTPRI1_EDMA31TC0, 0) |
                   CSL_FMK(SYSCFG_MSTPRI1_EDMA30TC0, 0) |
                   CSL_FMK(SYSCFG_MSTPRI1_EDMA30TC1, 0) |
                   CSL_FMK(SYSCFG_MSTPRI1_PRU0, 7) |
                   CSL_FMK(SYSCFG_MSTPRI1_PRU1, 7);

sysRegs->MSTPRI2 = CSL_FMK(SYSCFG_MSTPRI2_LCDC, 7) |
                   CSL_FMK(SYSCFG_MSTPRI2_USB1, 7) |
                   CSL_FMK(SYSCFG_MSTPRI2_UHPI, 7) |
                   CSL_FMK(SYSCFG_MSTPRI2_USB0CDMA, 7) |
                   CSL_FMK(SYSCFG_MSTPRI2_USB0CFG, 7) |
                   CSL_FMK(SYSCFG_MSTPRI2_EMAC, 4);

  • 0
    TI__Guru* 86135 points
    Hi
    I would recommend going through the follow series of wikis on Soc Arch overview, constraints and optimization
    processors.wiki.ti.com/.../AM1x_SOC_Architecture_and_Throughput_Overview

    if your transfers are not scheduled , broken up appropriately, you may see head of line blocking between your EDMA accesses and ARM accesses to the same end point (EMIFA).

    Regards
    Mukul
  • 0
    TI__Guru* 84110 points
    Alexander,

    From your description, it sounds like the high priority task is supposed to take 125us, but there are times that it takes 20ms? Is that correct? That seems like a very extreme interaction with the two processes.

    The OMAP-L138 architecture is designed to allow optimum total system bandwidth and throughput and to minimize any transfers from being blocked for a long time. The priorities are implemented at a very low level to handle collisions between internal bus commands. Since the DMA operations are generally broken into DBS (default burst size) commands, the priority setting will allow one of those to get started and then allow the lower priority one to get started. A very long DMA transfer can easily have several smaller transfers interleaved within it. We very intentionally do not allow either the DMA transfers or the CPU transfers to be blocked for a long time.

    The only way to prevent any interleaving of CPU transfers is to hold off on doing those transfers until the DMA is completed. Two options are to 1) wait for a DMA completion interrupt and then do the CPU transfers, or 2) queue up a list of transfers that can be done by the DMA later and trigger those through chaining after the high-priority DMA transfer is completed.

    If you have more questions or concerns after going through the material Mukul references, post back here with more detail on your DMA transfers and the nature of the CPU transfers or how they could be split up.

    Regards,
    RandyP