Link Transfer issue for EDMA3.0

The SPRUEQ5 document you mention is probably the best reference resource on the EDMA3, at least for using it in this fashion without a driver as is more common these days. In the most basic sense filling out the link address field of the EDMA PaRAM set should allow your transfer to link to whatever PaRAM you point it to. Could you elaborate on how the EDMA3 is failing in your case, is nothing being transferred, or part of it, or just the linked set?

HI,

I filled link field correctly. I am little bit confuse about OPT field, I took care of STATIC field and TCC. what other field are need to fill.

in my case only one transfer is happening.

With regards to OPT register, you will also want to look at ITCCHEN and TCCHEN fields; there are also corresponding interrupt fields which you may optionally want to take advantage of. 

Also, if you would like to send us your PaRAM settings, we can take a quick look at it.

hi these are the paramter settings.

Now Link Transfer  is working fine.

for T0->T1->T2

T0 is 1st one and T1 is intermediate and T2 is last.

T0 OPT field is ------

ITCCHEN_DISABLE,
TCCHEN_ENABLE,
ITCINTEN_DISABLE,
TCINTEN_DISABLE,

TCCMODE_NORMAL,
FWID_8,
STATIC_NORMAL,
SYNCDIM_ABSYNC,
DAM_INCR,
SAM_INCR ...

T1 OPT field is

ITCCHEN_DISABLE,
TCCHEN_ENABLE,
ITCINTEN_DISABLE,
TCINTEN_DISABLE,
tcc
TCCMODE_NORMAL,
FWID_8,
STATIC_NORMAL,
SYNCDIM_ABSYNC,
DAM_INCR,
SAM_INCR

T2 OPT field is

ITCCHEN_DISABLE,
TCCHEN_DISABLE,
ITCINTEN_DISABLE
TCINTEN_ENABLE,
tcc,
TCCMODE_NORMAL,
FWID_8,
STATIC_STATIC,
SYNCDIM_ABSYNC,
DAM_INCR,
SAM_INCR.

Is these settings are correct?.

And now I am trying select TC0 and TC1. to make DMA parellel for this I modified the

DMAQNUM0 = 0x10; // to select Q0 to TC0 and Q1 to Q1 to TC1

by looking performance statics i feel that they are not running in parellel.

I am glad to hear that your linking is working now, I am curious what you had to change to get it to work?

As to transfers in parallel, note that even though there are multiple transfer controllers, if both are accessing the same resource than having both submitting at the same time will have a negligible effect on performance. For example if you are accessing external memory, than one of the TCs can certainly use all the bandwidth already, so splitting into two transfer controllers to try to get parallel transfers is not effective. The same could be said even for internal memories, to get a true parallel transfer effect your sources and destinations would all have to be independent (such as if one transfer was from the McASP to internal memory, and another was from DDR to the AEMIF).

The register settings look ok to me; like Bernie suggested, there may be resource contention in other parts of the system that may prevent parallel execution of DMA transactions.  If you can give us a bit more information on your system setup, we may be able to offer more advice.

 HI,

I want to transfer some data  to co-processor, co processor have 3 ports read, write, read/write and 64 bit bus width, so i want transfer some data from DDR2 to Coprocessor and  and L2 to coprocessor. In this case parellel transfer  is possible?

And I also observed that both individual transfrs ( DDR2 -- CP and L2-CP) are taking same time, as L2 bus width is 64 bit I thought it will take less time but its not happening.

where i am missing? IS there other way to make above transfers in parellel.

Thank you,

Veeru

Since destination (CP) is the same, this would suggest resource contention, hence it may explain why you do note get parallel performance.

FYI, the following App Note details the DM6467 Switch Central Resource; this is a good reference to know which paths support 64-bit transfers and which do not (see Figure-1), as well as the operating frequencies of internal buses.  Also, one key thing to keep in mind is that is the path contains any bridges (normally used to change either bus width or frequency for compatibility with other buses in system), these bridges will cause delays.

HI,

CP have 3 ports cant write/read 2 data at time?.

I think the App Note u are telling is spraaw4.pdf. If one transfer from DDR2 to CP may use path as DDR2-SCR1-BR9 and other L2-SCR1-BR10.

and bus width from L2 to CP is 64 bit, but its taking same time as DDR2(32bit) to CP.why?

Thank you,

Veeru

I am assuming you mean the HDVICP in this case? What address are you using to access the co processor? If this is the HDVICP it is not currently supported for development outside of TI and some third party codec developers, anyone using it should have local engineering support.

My first guess on this would be that you are accessing the HDVICP through the CFG bus instead of directly through the SCR, which could explain the slowness, though since the HDVICP is not well defined in the documentation I am not sure if this is a real possibility.

Veeru,

Yes, this is the document I was referring to (sorry, forgot to include the link). 

Based on your description, it would appear that it is possible to do both transactions in parallel.  What performance are you expecting?

FYI, per the document, DDR2 memory controller is also 64-bit, hence this may explain why you are seeing the same time.

Veeru,

Actually, Bernie just pointed out that although DDR2 controller is 64-bits wide, the DDR2 bus is still 32-bit wide.