• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 856 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.

EDMA Configuration - Two Channels, OMAP-L138

Alexey Tsirlin
Intellectual 555 points
Other Parts Discussed in Thread: OMAP-L138

Hi,

I am trying to use two EDMA channels in parallel. One channel is driving SPI DAC and the second channel is used for copying data chunk from SDRAM (connected to EMIFA) to DSP L2 RAM, I am using some unused DMA channel for this purpose (let's say channel 0). The SPI DMA channel is configured to move two bytes on each SPI TX event and the second DMA channel is configured to move some amount of data (about 15KBytes) as single burst and stop. The most important requirement is that the SPI events will be surved by DMA on time.

I have configured the SPI EDMA channel to use queue 1 and the data EDMA channel to use queue 0, I have also configured the masters bus access priority so, the EDMA0_TCC1 will have higher priority than EDMA0_TCC0. Dispite all this configuration I can still see that during the operation of the second DMA channel (data copy) the SPI DMA is not surved on time as the delay between SPI transactions is much higher than the delay in case of no activity on second DMA channel.

I was trying to understand the reason for such behaviour, and I saw that minmal DMA transaction size is 16 bytes, so I guess once and the second DMA channel gets bus access, it reads 16 bytes from the SDRAM and only then it can switch to SPI processing.

What is the correct EDMA configuration I should use in order to make sure the SPI events will be served in time (I don't care that the data copying from SDRAM will take a little more time).

 

Thanks, Alexey.

  • 0
    TI__Genius 14545 points

    Alexey,

    Alexey Tsirlin said:
    I have configured the SPI EDMA channel to use queue 1 and the data EDMA channel to use queue 0, I have also configured the masters bus access priority so, the EDMA0_TCC1 will have higher priority than EDMA0_TCC0. Dispite all this configuration I can still see that during the operation of the second DMA channel (data copy) the SPI DMA is not surved on time as the delay between SPI transactions is much higher than the delay in case of no activity on second DMA channel.

    I would suggest that you actually swap the order of the PaRAM Set's around for the following reason.

    If both Queue0 and Queue1 have have an event that happen to occur at the same time, Queue0 will always win arbitration over Queue1. Since the SPI transfer is most important, you will always want this to win priority if the two events are submitted by the transfer controller at the same time. Of course this means that you will have to swap the priority of the Transfer Controllers as well.

    Alexey Tsirlin said:
    The SPI DMA channel is configured to move two bytes on each SPI TX event and the second DMA channel is configured to move some amount of data (about 15KBytes) as single burst and stop.

    This is probably where where the hang-up is occurring. Please refer to the this wiki article. The first few sections are not important for you at this time since you have a good understanding of the system interconnect, however you will particularly want to pay attention in the Switched Central Resource (SRC) portion of the article. Also - be sure to read through the default burst size section. Lowering the burst size of the EMIF will give the SPI transfer a chance to win arbitration between EMIF burst packets.

     

     

  • 0 in reply to dabuan
    Intellectual 555 points

    Drew,

    Thank you for your answer.

    As I understood from the wiki article, the EMIFA is a slave port, so the burst size is configured through EDMA3_1_TCC0/1 and the minimal size is 16 bytes which is also a default value. So I can't see a way to reduce this burst size through TCC0/1 registers. Is there a way to reduce this burst size by the PaRAM configuration? May be converting my 1D transfer to artificial 2D transfer will make the EDMA split the transactions to smaller bursts?

    Regarding the queue0 and queue1 priorities, I will swap those, but as I understand, this priority may only delay one SPI transfer, as the SPI channel receives event for each transaction and EMIFA DMA channel has single event for whole transaction chunk.

     

    Thanks, Alexey.    

  • 0 in reply to Alexey Tsirlin
    TI__Genius 14545 points

    Alexey,

      You are correct in your understanding that the EMDA3 Transfer Controllers have a fixed maximum burst size that defaults to 16.  The Transfer Controllers have the ability to break up the single EMIF transaction into multiple burst of 16 bytes as you have read. This is outside the control of software and is done automatically by the hardware. 

    I would suggest that you do the following:

    [1] Configure EMDA3_0_TC0 to have highest priority in the SYSCFG registers, Configure EDMA3_0_TC1 to have the second highest. By default, they both share the highest priority level, so you'll need to bump EDMA3_0_TC1 down a priority level

    [2] Schedule the SPI transfers into Queue 0 of EMDA3_0_TC0, Schedule the EMIF transfers on EMDA3_0_TC1

    [3] Break up the single EMIF burst (~15kB) into smaller set of transfers by using a series of chained PaRAM Set Entries rather than having a single PaRAM Set for the entire transfer. When you use one EDMA3 event to set up a large burst size packet, the Transfer Controllers will individually schedule the smaller burst size transactions(16 bytes) as fast as they can. Since the main SCR on the OMAP-L138  for all TC's are linked to the other Satellite SCR's via a bridge, the bridge is getting bombarded with requests from the the Transfer Controller that corresponds to EMIF. Bridges do not have priority scheduling, they simply act as clocking / bus width converters. When you break up the larger transfer into smaller bursts, you will be inherently be introducing pockets of time between EMIF bursts where other scheduled transfers can be processed through the bridge.

     

    Do you have any other activity that is utilizing the system interconnect for large bursts?

  • 0 in reply to dabuan
    Intellectual 555 points

    Drew,

    I have replaced single EMIF burst by self chained, 2 byte transfers and the problem is gone now.

    Thanks you very much.