H.264 encoder QDMA hangs when executing simultaneously with other DMA processes.

Hi James,

H.264 encoder on OMAP3530 has 8 QDMA channels out of which 6 are used by the algorithm and remaining two can be used by the application.  Hence codec runs properly with number of QDMA channels set to 8.

We will analyse the DMAN3 parameters setting done at your end and get back to you soon.

Thanks,

Roopesh

Hi James,

(1)Can you please let us know which part of internal memory is the destination for your DMA transfer? If you want to try using the same scratch group, please make sure you don't preempt EDMA transfers. Please try adding a immediate DMA wait() to make sure preemption is not happening.

(2)Please set DMAN3.paRamBaseIndex    = 78 and check.

Thanks,

Roopesh

Roopesh,

Thank you for the information. Here are the answers to your questions:

(1) Our DMA transfers data from HW (FPGA) memory to DDR2 memory. So there are no internal memory destinations. For DMA operation, we do ACPY3_wait() immediately after ACPY3_start() so it should be ok as long as preemption goes.

(2) We have tried this before but I have double-checked this one more time per your request. Setting DMAN3.paRamBaseIndex = 78 does NOT help.

Thanks

James

Hi James,

Thanks for the information. Can you please share the command file(.cmd) that you are using and the destination DDR2 address of these DMA transfers? This is to make sure that these DMA transfers are not overwriting any existing DDR2 allocations of codec.

Thanks,

Roopesh

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

PS:Please click on 'Verified answer' button if my response answers your query.

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

Roopesh,

Please find .cmd files in the attachment (note that I changed file extension since .cmd was not allowed file type). Regarding your question about the destination DDR2 address of transfer, we do not have fixed address for that since receiving buffer is dynamically allocated.

Thanks

James

1351.topxcfg_cmd.txt

4520.topx_x64Pcfg_cmd.txt

Hi James,

Thanks for sharing cmd file. Although destination address for your DMA transfer is not fixed, can you please check if this DMA tranfer is overwriting any existing DDR2 alocations previously present?

Thanks,

Roopesh

Roopesh,

I guess I do not quite understand your question regarding if DMA transfer is overwriting any existing DDR2 allocations. Since our DMA destination buffer is dynamically allocated the address will be somewhere in heap memory that is managed by DSPBIOS. That said, if your question is if our DMA transfer is overwriting any memory that are allocated by video codec, we first need to know if codec allocates static memory with fixed address before I can answer your question. As you understand, I have no visibility on that kind of information on codec side since we cannot see internal operation of the codec (we only have binray lib. Is there any way we can find the address of the codec DMA buffer?). In any case, whether codec allocates static or dynamic memory buffer for its DMA memory should not be overwritten by our DMA buffer operation since they should be managed by compiler and DSPBIOS (unless Codec operation allocates and uses "hardcoded" memory address. I know we do not use any sort of hardcoded address).

I understand the current focus on this issue your side (correct me if I am wrong) seems to be in finding out if some sort of DMA memory conflict but I want to stress out one more observation regarding codec behaviour that I have mentioned in my first post ( the item 1 ). Specifically, we have noticed that allocating codec and our DMAs in different groups made the codec fails at start-up (which seems worse behaviour than the case of putting everything in the same group that we are currently looking at). Based on framework documentations and codec specs, allocating codec and other DMA process should provide favorable environment to codec since our DMA will not contend resource with codec. However, behaviour we observed was totally opposite which seemed totally illogical. So we would appreciated if you can provide some insight on this also while you investigate other things like .cmd files and stuff. For your information, the setting for the case that we try to allocate codec in group 0 and our DMA in group 1 is as follows:

DMAN3.paRamBaseIndex     = 64;  // 1st EDMA3 PaRAM set available for DMAN3
DMAN3.numPaRamEntries    = 64;  // number of PaRAM sets exclusively used by DMAN

DMAN3.tccAllocationMaskL = 0xffffffff;   // bit mask indicating which TCCs 0..31 to use
DMAN3.tccAllocationMaskH = 0xffffffff; // assign all TCCs 32..63 for DMAN

DMAN3.numTccGroup        = [32, 32]; // number of TCCs assigned to scratch group 0, 1
DMAN3.numPaRamGroup      = [48, 16]; // number of PaRAM sets for scratch group 0, 1

DMAN3.qdmaChannels       = [0, 1, 2, 3, 4, 5, 6, 7]; // choice of QDMA channels to use
DMAN3.numQdmaChannels    = 8;   // number of device's QDMA channels to use

Thanks

James

Closing this thread as your query is answered using direct email -  Suggested to move  from ‘QDMA transfer’ to implementing ‘EDMA3 LLD’ for the peripheral DMA transfer.

Yashwant,

What was the resolution of this issue?

The "Verified Answer" was on a question about overwriting data. So was this a bug in the original poster's DMA setup?

Or was it that the OP was manipulating QDMA resources directly rather than using EDMA3 LLD calls?

Thanks,

Doug

James,

Thanks for the clarification. I was hoping for a resolution that might shed some light on our problems with a DaVinci SDK (http://e2e.ti.com/support/embedded/f/354/p/140290/510872.aspx and http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/140023.aspx).

We have had no problems using the EDMA library from Linux. Good luck!

Doug