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.

Need some help with L138's EDMA3

Hi,
  
We have some question with OMAP L138's EDMA3, particular on the mapping between events, PaRAM sets, and controllers.
 
By looking at TRM SPRUH77 Table 18-23. EDMA3 Channel Controller (EDMA3CC) Registers, the ending line showing that the length for PaRAM is 0x1000 = 4096 bytes. Because each PaRAM takes 32 bytes, this 4096 bytes area equals to 128 PaRAM sets.
   
In 18.1.2 Features, both CC0 and CC1 are described as having 128 PaRAM sets. How should we understand this with the fact above that 128 PaRAM sets already occupy the total register memory space reserved for them? If CC0 and CC1 each have non-overlapping 128 PaRAM sets, then where does the total 256 PaRAM sets reside in memory?
 
In addition, we also read in 18.2.1.1 EDMA3 Channel Controller (EDMA3CC),

18.2.1.1 EDMA3 Channel Controller (EDMA3CC) said:

Each channel is associated with a given event queue/transfer controller and with a given PaRAM set.

and in 18.2.6 Event, Channel, and PaRAM Mapping,
18.2.6 Event, Channel, and PaRAM Mapping said:

The association of an event to a channel is fixed. Each of the DMA channels has one specific event associated with it.

As well as seeing the table

Table 18-5. EDMA3 DMA Channel to PaRAM Mapping said:

Table 18-5. EDMA3 DMA Channel to PaRAM Mapping
PaRAM Set Number Mapping
PaRAM Set 0 DMA Channel 0/Reload/QDMA
PaRAM Set 1 DMA Channel 1/Reload/QDMA
... ...
PaRAM Set 30 DMA Channel 30/Reload/QDMA
PaRAM Set 31 DMA Channel 31/Reload/QDMA
PaRAM Set 32 Reload/QDMA
PaRAM Set 33 Reload/QDMA
... ...
PaRAM Set n - 2 Reload/QDMA
PaRAM Set n - 1 Reload/QDMA
PaRAM Set n Reload/QDMA

But none of these provided any illumination on how are event/channel/PaRAM sets associate with CC0 and CC1 controllers. In fact, it appears to me a bit obscuring after reading through the EDMA3 chapter with finding a clear diagram for the association scheme. Diagrams such as Figure 18-1 and Figure 18-2 doesn’t show this.
   
I am also confused on how could hetero- or multi-core devices make use of Shadow Region 0/1 Channel Registers, and a bit more plain and straightforward explanation would be appreciated. Both the ARM and DSP sides of our L138 uses EDMA3, and sometimes the program hangs at event clearing and we noticed that the error might due to the use of same event to trigger transfer on the two cores. The shadow region seems to have been offered to address issues like this, but we still haven't understood it after considerable effort in reading the document.   
 

There also seems to be some inconsistencies in description: 18.1.2 Features says CC0 and CC1 each have four shadow regions, whereas in Table 18-23. EDMA3 Channel Controller (EDMA3CC) Registers, only two (Shadow Region 0 Channel Registers, and Shadow Region 1 Channel Registers) are shown.
  
  

 
Paul

  • Hello Paul,

    You have probably find it now (sprs586), but...

    CC0 parameter set dedicated RAM base address is 0x01C04000, for CC1 it's 0x01E34000, each have 128 entries. The 32 first entries can be associated to fixed system events (different events for each controller). Each controller has two shadow regions. CC0 & CC1 are independant subsystems.

    Jakez

  • Thanks for the answer.

    I am still unclear on the purpose of shadow region so I google searched and read posts by Brad Griffis in “what is the shadow region”. Brad explained that the design intent was that each region (0 for ARM, 1 for DSP in multi-core environment) interrupts a specific core. This is the most basic information I got.

    That post was originally asked in DaVinci forum. The EDMA3 architecture in DM643x has only a single CC associated with three TC’s, whereas L138 also has three TC’s but assigns two to CC0 and one to CC1. Both the ARM and DSP sides of my application uses EDMA3, and following the “separate CC address” you pointed I have configured:

    1. CC0 to ARM
    2. CC1 to DSP

    and manually set events in their respective code. In addition, I poll Interrupt Pending Register (IPR) bits rather than using interrupts directly. Though I don’t fully understand how shadow region really works, I however guess in this configuration there should be no potential conflicts (not considering the potential competition between their master priorities) on EDMA3 usage on the two cores, since CC’s and consequently TC’s the two cores using are both different. Is this assumption correct?

    The EDMA3-intensive application has been running so far simultaneously on ARM and DSP cores without finding problem. So am I safe under this configuration, even still quite ignorant on the shadow region’s working mechanism?

  • Hello again,

    To my opinion and summarizing:

    By assigning a CC to each core and manually triggering events, conflict probability is near zero.

    Shadow regions are intended to ease sharing of each CC between cores. They enable core access to only a programmed subset (bit mask) of the (32) channels in the control registers, thus avoiding unattended modification of other channels. Shadow region capability will be used if the (2) cores require access to the same CC (with different synchronization events, for example MCASP0 to DSP and MMCSD0 to ARM).

    The QDMA channels can also be partitioned and protected in such a way.

    A specific interrupt for each region enables independant EDMA3 management for each core.

    If only one core use a CC, it can use the main control registers and ignore the shadow region registers. However, the transfer completion interrupts are always associated with a shadow region, requiring the DRAEm registers to be programmed (if no polling). For an explicit CC0 example: the DSP core will use the EDMA3_0_CC0_INT1 interrupt with register CC0.DRAE1=0xFFFFFFFF, while the ARM core will use the EDMA3_0_CC0_INT0 interrupt with register CC0.DRAE0=0xFFFFFFFF. Note that the DRAE0 & DRAE1 registers are all 0 at reset, masking any interrupt even if the IER register bits are set.

    Jakez

  • Jake,

    I think your explanation on shadow region's relationship to interrupts is clear. I have no more questions on this point.