Possible EDMA conflict with H264 decoder

Marco Madrigal

Hi,

I am working on a gstreamer resizer pluging based on the EDMA hardware for a DM365-based board. I got it working but I am experimenting an issue. The details are as follows:

When using a preview pipeline from a camera sensor to a LCD scaling the video from 480P to 320x240 using this resizer it works correctly with a 30fps video output.

When I recorded a video file in H264 with a resolution of 480P and play it back to the LCD using the resizer to fit the video to the screen there is a random issue that causes the video to start shaking. That only happens when decoding the video and resizing it at the same time so my first guess is it could be due to a EDMA conflict. I am using chained transfers on the resizer. If I change this resizer for the dmairesizer I didn't get this issue but for me it is critical to get this edma resizer working properly.

I tried to find out where are defined the range of EDMA sets to be used by the dmai plugins on the dvsdk byt I didn't found it. I know some architectures such as DM6446 has a config file with a definition like this

        DMAN3.paRamBaseIndex     = 80; // 1st EDMA3 PaRAM set available for DMAN3
        DMAN3.numQdmaChannels    = 8;  // number of device's QDMA channels to use
        DMAN3.qdmaChannels       = [0,1,2,3,4,5,6,7]; // QDMA channels to use
        DMAN3.numPaRamEntries    = 48; // # of PaRAM sets exclusively used by DMAN
        DMAN3.numPaRamGroup[0]   = 48; // # of PaRAM sets for scratch group 0
        DMAN3.numTccGroup[0]     = 32; // # of TCCs assigned to scratch group 0
        DMAN3.tccAllocationMaskL = 0;  // bitmask indicating which TCCs 0..31 to use
        DMAN3.tccAllocationMaskH = 0xffffffff; // assign all TCCs 32..63 for DMAN

So in this case it could be possible to reserve the 48 entries in the dm6446.c file in order to prevent the kernel to use those entries.

I have found those links but I haven't got any solution yet:

http://e2e.ti.com/support/embedded/linux/f/354/t/96241.aspx#339195

http://e2e.ti.com/support/embedded/linux/f/354/t/140290.aspx?PageIndex=1

Anyway this is just an idea I want to try but as I said I am not completely sure if there is a conflict with the DMA channels. I will appreciate any help on this issue.

Best Regards,

Marco.

over 13 years ago

0 Gunjan over 13 years ago

TI__Expert 7415 points

Depending on how new your DM365 codec is, it could be using a completely different resource manager (not DMAN3) that reserves it's DMA resources by directly requesting it from the Linux kernel. In this case, there should not be a resource conflict, if all users of DMA resources request resources directly from the kernel.

The new(er) interface is IRES EDMA3CHAN and the resource manager used to grant resources is called RMAN. Could you check your codec sources and config file to see if these are being used ?

0 Marco Madrigal over 13 years ago in reply to Gunjan

Prodigy 130 points

Hi Gunjan,

Thanks a lot for your response. We are using the H264 codec on the following versions:

H264enc = 02.20.00.01
H264dec = 02.00.00.10

If I am not wrong they seem to use RMAN as you said. For the EDMA resizer we are using the API specified at ti/sdo/linuxutils/edma/include/edma.h

Could any channel request made by this API be conflicting with the RMAN controller when interacting with other plugins? In addition we saw the same issue if we are recording a video and at the same time we are resizing it to be displayed to a screen.

I have tried to reserve a DMA channel directly in the kernel and use it in our plugin but the problem still the same.

Best Regards,

Marco.

0 Gunjan over 13 years ago in reply to Marco Madrigal

TI__Expert 7415 points

I'm not a codec expert, so I wouldn't know if the above versions use RMAN/IRES. But if you have access to the codec sources, you could see if they include the file 'ti/sdo/fc/ires/ires_edma3chan.h' to describe the kind of DMA resources they need.

If you are using these more recent APIs, then the codec is using this same linuxutils/edma/include/edma.h API to request DMA resources. In that case, there shouldn't be a conflict between the resizer and the codecs, since they both request resources directly from the kernel.

In fact, you could include the debug version of the of edmak module and see some trace information. See this post on info on how to build and insmod the debug ko:-

http://e2e.ti.com/support/embedded/linux/f/354/t/134138.aspx#481913

This will give you details of which resources and being allocated.

0 Marco Madrigal over 13 years ago in reply to Gunjan

Prodigy 130 points

Hi Gunjan,

Thanks a lot for this information, it has been very useful. I have another little question and I hope you can help me with that. We found that is we copy the incoming buffer so that the codec and the resizer get a copy, the problem seems to disappear. Actually we tried another pipeline similar to the following:

[v4l2src] ----------- [tee] ---- [queue] ---- [edma resizer] ----- [video sink]

|-------- [queue] ---- [h264 encoder] ---- [rtp streaming]

And we got a corrupted output in the RTP side so that we see a corrupted video on the host machine. If we copy the incomming buffer as is shown below, we didn't get the corruption:

[v4l2src] ----------- [tee] ---- [queue] ---- [edma resizer] ----- [video sink]

|-------- [queue] ---- [copy buffer] ---- [h264 encoder] ---- [rtp streaming]

This force me to ask a basic question: since the resizer and the encoder uses EDMA as copy the same buffer are they able to start a EDMA transfer from the same memory space? Could the issue be a conflict between both threads regarding the use of the incoming buffer?

Regards,

Marco.

0 Mario Raffin over 13 years ago in reply to Gunjan

Expert 2405 points

Dear Gunjan,

I am experiencing a similar problem with DM365. H.264 encoder causes DMA event missed events on the DMA channels 2 and 3. These channels are used by the CQ93VC voice codec. The result is that after some minutes of use the audio is corrupted and the only way I found to fix it is rebooting.

How can I reserve the dma channels 2 and 3 for the voice codec?

Processors

Processors forum

Possible EDMA conflict with H264 decoder