This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EDMA with OMX output buffer after being decoded

Hi all,

I'm working on PCIe-EDMA driver to transfer decoded video data to a DSP through pci-e. My target processors would be DM8148 and TI DSP. I have been using EZSDK 5.03.01.15 version. My question is if or not it is possible to transfer decoded data(1600x1600 pixel) using EDMA3 because, as far as I know, only contiguous memory space will be accepted on EDMA3.  I believe that it could be possible modifying TestApp_WriteOutputData function in decode_test.c, as long as pBufferHeader->pBuffer has linear memory space - contiguou space. Basically, it is almost impossible to use memcpy because the output buffer from M3 processor is not cached area - out of linux memory space. So it is really really slow. To make long story short, the data flow looks like below.                                                                                 

encoded data ------>  OMX decoder ------->  output buffer ------> PCI-e transfer  ---------> DSP

                                                          1600x1600 contiguous space ?

On my understanding, I am only able to use pre-allocated image buffer from HDVICP2 or M3 processor and the buffer is a kind of black-box for me. Am I correct ? If it is, I'm right so far, can I use the buffer for EDMA3 ? 

Best Regards,

SK

  • Hi,

    Anybody knows the solution ? Well, I have been looking at syslink which takes care of communication between A8 and M3(HDVICP2) processor to find something like CMEM_getPhys on DM365 SDK. The CMEM is still present on EZSDK but it is just for DSP communication, not for M3. I believe that it is almost impossible to do anything for decoded data without DMA help because the video data seems to be non-cached one. Any suggestion or idea ?

    Regards,

    SK

  • You could do this:

    1. Allocate buffers from shared region 2 in A8. Following is the code snippet

    #include <ti/syslink/utils/IHeap.h>
    #include <ti/ipc/SharedRegion.h>

            IHeap_Handle    heap;

            heap = SharedRegion_getHeap(2);

            Buffer1 = Memory_alloc (heap,MAX_BUF_SIZE, 128, NULL);

      2. Instead of calling the OMX_AllocateBuffer on the out port of the decoder, call the OMX_UseBuffer API to give the Buffer1 (alocated in step 1) for its operation.

      3. Buffer1 is a contiguous buffer in A8 and can  be used for DMA.

    Have a question.

    Is the DSP on the DM814x is fully loaded? Since you're planning to have a external DSP, I'm assuming it is so. But can you confirm?

    regards,

    Tarakesh.

  • Hi Tarakesh,

    Thank you for the answer. Regarding your question - DSP, yes, we are using DSPs as a external device, not on-board DSP because of lack of horse power. To make your explanation clear, I need ask a additional questions.  According to OMX User Guide - OMX_05_02_00_30_userGuide.pdf, I can see the some restrict for memory management - "the output buffers are allocated by component upon request by IL client through OMX_AllocateBuffer() APIs". However, they - the output buffer could be done by OMX client and the client lets OMX IL core use them from your answer. Am I correct ? If I am, it would be great to know that.  Thank you again for the information. 

    I have a quick question for you regarding how to convert virtual address on shared memory to physical address to let DMA use it. I believe that there would be something like "CMEM_getPhys()" function to do that but I don't find any one yet. Please let me know that.

    Best Regards,

    SK

  • Hi Tarakesh,

    I have one more question for you regarding memory space and management on shared memory. I can see physical address, length and virtual address(user space) on the second shared region like following.  The messages come from DomxCore_mapPhyAddr2UsrVirtual function.

    function:memcfg_module_init_shared_region, phyaddr = 9a100000, len = 1048576, viraddr = 438d5000

    function:memcfg_module_init_shared_region, phyaddr = b3d00000, len = 197132288, viraddr = 439ec000

    function:memcfg_module_init_shared_region, phyaddr = 9f700000, len = 2097152, viraddr = 402f6000

    Also, I got virtual address from decode demo on OMX as following. My question is whether or not the physical addresses are correct ? If the shared memory space is linear and flat, my idea would be correct. Please let me know it.

     state IDLE 
    state execute
    etb / ftb done
    frame 1 decoded
    frame 2 decoded
    frame 3 decoded
    frame 4 decoded
    frame 5 decoded
    frame 1 displayed with buffer addr = 442ec980 
    --> physical address b4600980 = b3d00000 + 900980 
    frame 2 displayed with buffer addr = 446cf380 Offset 0x3e2a00 - from 0x442ec980 
    --> physical address b49e3380 = b4600980 + 3e2a00
     frame 3  displayed with buffer addr = 44ab1d80 Offset 0x3e2a00 
    --> physical address b4dc5d80 = b49e3380 + 3e2a00 
     frame 4  displayed with buffer addr = 44e94780 Offset 0x3e2a00 
    --> physical address b51a8780 = b4dc5d80 + 3e2a00
    frame 6 decoded
    frame 7 decoded
    frame 8 decoded
    frame 9 decoded
    frame 5 displayed with buffer addr = 45277180 Offset 0x3e2a00 --> same as above ....
    frame 6 displayed with buffer addr = 45659b80 Offset 0x3e2a00
    frame 7 displayed with buffer addr = 45a3c580 Offset 0x3e2a00
    frame 8 displayed with buffer addr = 45e1ef80 offset 0x3e2a00
    frame 10 decoded
    frame 11 decoded
    Tearing down the decode example
    free handle
    free handle done
  • >>is whether or not the physical addresses are correct

    Physical addresses that you're seeing are correct.

    regards,

    Tarakesh.

  • ProcMgr_translateAddr () can be used for this. Eg., you could add function similar to DomxCore_mapPhyAddr2UsrVirtual (); where in  it is translating from phy to virtual.

    code snippet could be as follows:

    DomxCore_mapUsrVirtual2PhyAddr (

    {

     ....

    status = ProcMgr_translateAddr (pSlaveProcHandle,
                                      (Ptr) & pUsrPhyAddr,
                                      ProcMgr_AddrType_MasterPhys,
                                      (Ptr) virtAddr, ProcMgr_AddrType_MasterUsrVirt);

    }

    thanks

    Tarakesh.

  • Hi Tarakesh,

    I have a quick question for you. I'm not sure if or not I have some mistakes to allocate new buffer on the heap but the function - Memory_alloc never returns and hangs. I haven't seen any error message. Basically, I used heap memory allocation which you recommended on last post and they look like below.

    	IHeap_Handle    heap;
    unsigned char *EDMA_buf;
    char *srPtr;
    Error_Block *eb;
    ...
    // TODO : Check availablity of the heap ?
    heap = (IHeap_Handle)SharedRegion_getHeap(2);
    if (heap == NULL)
    {
    printf("getting heap failed .....will exit..\n");
    close(fd);
    return NULL;
    }
    EDMA_buf = Memory_alloc (heap, width*height, 128, &eb); <-- never returns from Memory_alloc function call

    if (EDMA_buf == NULL)
    {
    printf("dst memory failed .....will exit..\n");
    close(fd);
    return NULL;
    }
    srPtr = (char*) SharedRegion_getSRPtr ((Ptr) EDMA_buf, 2); //This SR ptr should be given to omx_usebuffer call.
    ...
    Seeing above code, the memory block - EDMA_buf will be used for DMA destination buffer.
    Let me know if any issue or mistake.
    
    
    Best Regards,
    SK.

  • SK,

    which version of the sdk you are on? It appears like the SR is not available from A8. Would require minor changes to the firmware loader. Please confirm the sdk version.

    regards

    tarakesh

  • Hi Tarakesh,

    Sorry I miss your response.  The answer against yours - SDK version is  EZSDK 5.03.01.15 and the target board is DM8148. Could you let me which part should be changed on firmware loader ?

    Regards,

    SK

  • SK,

    Verified the firmware loader. Support is already there.

    Can you confirm you have already loaded the media controller binaries (hdvpss-m3 and hdvicp-m3)  before your app runs?

    thanks

    tarakesh.

  • Hi tarakesh,

    I have double checked it using decoder and decode_display demo.  Also, I have added "HeapBufMP_sharedMemReq (&heapbufmpParams)" function call to confirm heap size like below but I have same issue.

    ...

            HeapBufMP_Params_init (&heapbufmpParams);
            heapbufmpParams.sharedAddr = NULL;
            heapbufmpParams.align      = 128;
            heapbufmpParams.numBlocks  = 1;
            heapbufmpParams.blockSize  = width*height;
            heapSize = HeapBufMP_sharedMemReq (&heapbufmpParams);

            srHeap = (IHeap_Handle)SharedRegion_getHeap(region);
            if (srHeap == NULL)
            {
                    printf("getting heap failed .....will exit..\n");
                    close(fd);
                    return NULL;
            }
    printf("getting memory allocation size = %d\n", heapSize);
            heapBufPtr = Memory_alloc (srHeap, heapSize, 128, 0);

    printf("got memory allocation\n");

    ..

    Regards,

    SK