Dummy QDMA transfer in linked set causes linked transfers to halt

Can you check if QSER set ? And is bit in the QEER set for this channel ?  Also can you please share the memory dump of the ParamSets, specifically of the Dummy set and the one it links to. 

In your linked list, if the dummy set is removed, then does the subsequent transfer take place ? Let us know.

Hi,

Thanks for your reply:

The QSER is not set.

The bit in QEER of the QDMA channel I am working with is set.

I am working with 4 PaRAM sets on EDMA3CC0 QDMA channel 0. The PaRAM sets addressess are 0x2704200 (Active channel) and 0x2704220,40,60 (Linked channels).

This memory dump is right before writing to the trigger word (setting address 0x270421C (CCNT field) to 1) of the active channel with no dummy PaRAM set:

0x2704200 80000804	800CB838	00080640	1081B100 06400640	00004220	00000000	00000000
0x2704220 80000800	8002C820	000100F0	10850F74 00000000	00004240	00000000	00000001
0x2704240 80000804	800CB838	00080640	10800D00 06400640	00004260	00000000	00000001
0x2704260  8010000C	8010D238	00080640	10838700 06400640	0000FFFF	00000000	00000001

I tried to configure the 0x4220 PaRAM set to a dummy transfer by two different ways: CCNT = 0 or A_B_CNT = 0 (in the memory location underlined in the memory dump). The phenomena occured in both cases. I did not configure both of them to zero to avoid a null transfer.

Here is a memory dump of the same memory after triggiring the transfer and the program is stuck since the third transfer didn't commence:

0x2704200 80000804	800CB838	00080640	10800D00 06400640	00004260	00000000	00000001
0x2704220 00000800	8002C820	000100F0	10850F74 00000000	00004240	00000000	00000000
0x2704240 80000804	800CB838	00080640	10800D00 06400640	00004260	00000000	00000001
0x2704260 8010000C	8010D238	00080640	10838700 06400640	0000FFFF	00000000	00000001

For your last question: If the dummy set is configured to a non dummy set (CCNT = 1 or A_B_CNT = 0x000100F0 as seen in the first memory dump) all 4 transfers work well.

Thanks,

Yossi

Yossi,

Thanks for the details response. 

Hmm ... everything seems fine. Since the next Pset after dummy set is now loaded, the transfer should have been triggered. I will see if I can loop the device expert.

The memory dump you posted above, was truncated, probably because of page width limit. I have hence copied it again, for reference. Let me know if this is correct. 

Before : First transfer, before write CCNT=1, for first Pset.

0x2704200 80000804 800CB838 00080640 1081B100 06400640 00004220 00000000 00000000 

0x2704220 80000800 8002C820 000100F0 10850F74 00000000 00004240 00000000 00000001 

0x2704240 80000804 800CB838 00080640 10800D00 06400640 00004260 00000000 00000001 

0x2704260 8010000C 8010D238 00080640 10838700 06400640 0000FFFF 00000000 00000001 

After trigger. Now halted as third Pset not complete....

0x2704200 80000804 800CB838 00080640 10800D00 06400640 00004260 00000000 00000001

0x2704220 00000800 8002C820 000100F0 10850F74 00000000 00004240 00000000 00000000 

0x2704240 80000804 800CB838 00080640 10800D00 06400640 00004260 00000000 00000001 

0x2704260 8010000C 8010D238 00080640 10838700 06400640 0000FFFF 00000000 00000001

Please await response.

Thanks.

Yossi,

I'm just curious ... Is this scenario important for your application, or are you just testing the basic hardware/software features?

Thanks

Kyle

Hi,

Thanks for your reply.

The memory dump you copied is correct.

Yossi

Hi,

Thanks for your reply

The dummy set issue is part of my design.

After reset, all 4 channels are configured and linked. During critical run time, not  necessarily all channels are active, and only during run time it is possible to know which and when one or two of the transfers should be configured to dummy transfers.

The only certain transfer that is always active is the first transfer and that is why it is set as the active PaRAM set in my design.

I'll be happy to answer more questions regarding this issue since it is in my critical real time path.

Thanks in advance,

Yossi 

Yossi,

I am not sure if I understand the need to use a dummy transfer. Do you need it to get some completion code/event ? In your design, instead of Dummy transfer(s), can there be a regular transfer of a small scratch data.

Await your reply.

Hi,

Your suggestion is exactly what is implemented currently in my application since I discovered the problem with the dummy transfer from beginning of 2012. However, this solution is good only as a workaround, Since the EDMA3 operation (and EDMA3CC1,2 are used as well) is the most critical path in our application due to huge amount of data transfers between DDR3, MSM, L2 and L1. A dummy transfer is the optimal way to avoid an unnecessary fetch to the EDMA3 mechanism.

This is why the 4 PaRAM sets are configured and linked only once right after reset, minimizing the need to touch the EDMA3 registers in run time. The completion code is always alerted at the last transfer, and the dummy transfer is used only in the scenario of no data to transfer for some cases in the application, not touching the basic PaRAM set configuration from reset.

For the same reason I don't re-link the PaRAM sets by that "discarding" the dummy transfer.

My question is if this issue is a permanent feature or not. if yes, I'll try to optimize the best workaround between a few other options I have that are not as efficient as the dummy transfer. I do very much prefer the dummy transfer design since it is the most elegant and efficient implementation.

Thanks in advance,

Yossi

Yossi,

I'm not sure about the root cause of the issue you're reporting.  This strikes me as an atypical use case, and thus it wouldn't completely surprise me if there were some underlying hardware issue.  We will continue to investigate this on our side.

Can you use DMA channels (as opposed to QDMA channels) instead? 

You can effectively accomplish the same thing by "link + self trigger".  In other words, the linked list will be copied onto the active channel and that channel will be chain triggered using early completion.

Let's say we have 4 PaRAM entries:

PaEntry0 -> Active DMA Channel0

PaEntry1 -> Link Entry 1

PaEntry2 -> Link Entry 2

PaEntry3 -> Link Entry 3

PaEntry0 links to PaEntry1 which links to PaEntry2 which links to PaEntry3.

PaEntry0, PaEntry1, and PaEntry2 chain triggers Active DMA Channel 0 (TCC = 0, TCCHEN = 1, Early completion mode)

PaEntry3 links to Null and triggers interrupt (TCC = n, TCINTEN = 1)

Regards
Kyle

Hi,

Thank you for your reply.

Using 2 DMA channels as you suggested is a good idea but unfortunately not in our implementation, since the same code will run on all 8 cores, hence using 16 of all available EDMA channels (and an addition of 16 TCC's.). We use the QDMA mechanism in our implementation in any case so we prefer reusing it rather than consuming more EDMA resources.

Please keep us informed about the underlying hardware issue, so we can decide how to finalize our implementation.

Regards,

Yossi

Hi Erik,

The 2 fixes you offered resolve the dummy transfer issue.

I prefered using CCNT = 0. However, these 2 fixes achieve my goal as well.

Thanks for your reply

Yossi