ACPY3_Wait takes long with two video channels on DM648

Do you know what the DMA resource usage of the video driver is ? The idea is to ensure DMAN3 isn't touching any resources used by the driver (and vice versa).

-Gunjan

Its TI video driver so I don't know the DMA usage of the video driver. I thought DMAN3 interface makes sure no one touches others resources and it would have complained at the time initialization when granting DMA channels.

~ARM

Unfortunately DMAN3 has no way of ensuring no one else touches its resources. All it ensures is that DMAN3 itself doesn't touch resources it doesn't own (touches only the ones that it has been configured with).

At this point we need to determine the DMA resource usage of the video drive to be able to correctly configure DMAN3.

I learned the app uses "EDMA3_DRV_requestChannel" method to request the dma resources of video driver. It gets total 10 channels with edma channel id i.e. 0x6, 0x10, 0x11, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, and 0x3c.

Based on above information, can someone help me what I should be setting for DMAN3 configuration in .cfg file to fulfill the dma requirement of analytics channels?

Fyi.. only two instances of analytics alorithm runs in the app and each analytics channel requests 2 EDMA resources using DMAN3 framework.

    DMAN3.paRamBaseIndex = 256;
    DMAN3.numQdmaChannels = 7;
    DMAN3.qdmaPaRamBase  = 0x02A04000; 
    DMAN3.qdmaChannels = [0, 1, 2, 3, 4, 5, 7];
    DMAN3.numPaRamEntries = 48;
    DMAN3.numPaRamGroup[0] = 48;
    DMAN3.numTccGroup[0] = 16;
    DMAN3.tccAllocationMaskL = 0;
    DMAN3.tccAllocationMaskH = 0x000f ffff;

Thanks in advance.

After reading some other posts, DMAN3 uses QDMA channels, paRams and TCCs that it has been configured in DMAN3 configuration of .cfg file. As mentioned in previous post, the app uses "EDMA3_DRV_requestChannel" method to get 10 EDMA channels, which returns  edma channel id/tcc i.e. 0x6/0x6, 0x10/0x10, 0x11/0x11, 0x36/0x36, 0x37/0x37, 0x38/0x38, 0x39/0x39, 0x3a/0x3a, 0x3b/0x3b, and 0x3c/0x3c.

It means the occupied channels/tcc are 6, 16, 17, 54, 55, 56, 57, 58, 59,  and 60 so I assume its safe to use 32-40 for 8 QDMA channels.therefore, I set tccAllocationMaskH i.e. 0xff.

    DMAN3.paRamBaseIndex = 78;
    DMAN3.numQdmaChannels = 8;
    DMAN3.qdmaPaRamBase  = 0x02A04000; 
    DMAN3.qdmaChannels = [0, 1, 2, 3, 4, 5, 6, 7];
    DMAN3.numPaRamEntries = 48;
    DMAN3.numPaRamGroup[0] = 48;
    DMAN3.numTccGroup[0] = 8;
    DMAN3.tccAllocationMaskL = 0;
    DMAN3.tccAllocationMaskH = 0x000000ff;

With this configuration, the analytics instance creation fails on granting dma channels through DMAN3 framework.

Any one seen similar issues or any pointers for this problem. Thanks in advance.

Your assumption is correct. Looking at the above configuration, I don't see an overlap between DMAN3 and driver resource usage.

Could you let me know what error you are seeing from DMAN3 ? (error code returned in DMAN3 failure ?!)

I would also like to know the version of Framework Components you are using and the device on which you are running your app.

Thanks,

Gunjan.

Its framework_components_1_20_03 and dm648.

With following configuration when the ACPY3_Wait takes a long, I can see two analytics channels gets channel 0, 1, 2 and 3 (two for each channel). It doesn't conflict with what's been acquired using "EDMA3_DRV_requestChannel" method i.e. (edma ch id) 0x6, 0x10, 0x11, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, and 0x3c.

    DMAN3.paRamBaseIndex = 128;
    DMAN3.numQdmaChannels = 8;
    DMAN3.qdmaPaRamBase  = 0x02A04000; 
    DMAN3.qdmaChannels = [0, 1, 2, 3, 4, 5, 6, 7];
    DMAN3.numPaRamEntries = 48;
    DMAN3.numPaRamGroup[0] = 48;
    DMAN3.numTccGroup[0] = 8;
    DMAN3.tccAllocationMaskL = 0;
    DMAN3.tccAllocationMaskH = 0xffffffff;

Do you know how many TCCs are being used by the analytics channels ? Your current configuration of tccAllocationMaskH = 0xFFFFFFFF lets DMAN3 have access to TCC #s 32 to 63. This could be dangerous as the driver would be touching TCC#s 54 - 60.

You should change your tcc mask accordingly.

Also another thing to try is setting your nullPaRamIndex to a known unused PaRam.

DMAN3.nullPaRamIndex = 127;

Sometimes setting it to PaRam #0 (which is the default setting) causes issues since by default all QDMA channels point to this PaRam.

At this point, I am only guessing. Nothing in your DMAN3 configuration seems suspicious.

We may have to dig deeper to see why the transfer takes long. For instance, maybe you can peek at the source and destination buffers to check if the transfer has "actually" completed when your app is stuck in ACPy3_wait etc.

This is weird.. I have set "DMAN3.tccAllocationMaskH = 0x0000ffff;" means allowing analytics to get from 32-48 as shown below:

    DMAN3.paRamBaseIndex = 128;
    DMAN3.numQdmaChannels = 8;
    DMAN3.qdmaPaRamBase  = 0x02A04000; 
    DMAN3.qdmaChannels = [0, 1, 2, 3, 4, 5, 6, 7];
    DMAN3.numPaRamEntries = 48;
    DMAN3.numPaRamGroup[0] = 48;
    DMAN3.numTccGroup[0] = 8;
    DMAN3.tccAllocationMaskL = 0;
    DMAN3.tccAllocationMaskH = 0x0000ffff;

With above configuration, The first analytics channel creation itself fails. the VISA_create returns NULL pointer. Only thing I knew from debugging, it calls "dmaGetChannels" interface implemented by analytics to inquire its dma requirement and fails. Normally, it calls "dmaInit" with allocated dma resources and VISA_create returns valid analytics handle.

Just don't understand, the DMAN3 can't satisfy two qdma channels request with above configuration.

Any idea what's going on here?

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

When I set "tccAllocationMaskH = 0xffffffff;", I see the DMAN3 returning the qdma resources to analytics shown in attached snapshots:

The reason tccAllocationMaskH = 0x0000FFFF fails is that (from the above snapshot it looks like) the channel requirements for dmaTab[0] are 10 Tccs and then dmaTab[1] is another 10 Tccs.

Allocation mask is set to make only 16 TCCs available for DMAN3. For the two channels, depending on which scratch groups they are, you would need anywhere from 20 to 40 Tccs. the tccAllocationMask has to be configured to make atleast as many available.

Hope this clarifies.

Based on your comments and some serious debugging, both analytics channel shares the TCCs so all I needed is 20 TCCs. So now setting the tccAllocationMaskH  (32-42) to make 20 TCCs available to DMAN3 for allocating the analytics QDMA resources. It succeeds creating both analytics channels but the dma transfer through ACPY3 interface takes really long. The analytics frame processing takes 15-35sec with the video capture from VP0 and VP2. The analytic frame processing normally takes 30-45msec if I disable the video capture part. 

Theoretically, the DMAN3 configuration looks good and should not conflict with the video driver. I checked the analytics QDMA transfer params before making ACPY3 transfer and looks good.

I don't know what else to look into. Any issues reported for capturing the D1 video on VP0 and VP2 port on DM648 ?

Capturing on VP0 video port and feeding the same video to both analytics channels work absolutely fine - no slower analytics processing. As soon as, I capture on both video port VP0 and VP2, I start seeing the slower analytics processing - on halting I always found stuck in ACPY3_Wait.

These issue is reproducible on EVM  DM648 board. Any thoughts how to debug this issue or any known issues when capturing on VP0 and VP2 with other algorithms using DMAN3 interface to perform their internal data transfer?

Regards,

ARM

We too are having problems with our application spending a lot of time in DAT_wait. We have also found that using qdma rather than DAT_copy, seems to avoid the problem. If there is some sort of conflict when using VideoPorts and DMA, we'd appreciate a better understanding of the issue.