• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 865 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DM8168: Issue with V4L2 capture buffers with Shared Memory.

Krunal Patil
Genius 3120 points

Hi,

I am trying to allocate V4L2 capture buffers from Shared Region-2 instead of frame-buffer.

I am successfully able to allocate memory from shared region but when I start the capture driver (STREAM_ON) the kernel crashes and there is no log on the console. Also, the console does not take any keyboard inputs and the only way to recover is - reboot the board. Please see attached log.

If I understand correctly, Memory_alloc API used for allocating memory from shared region will return the Physical address. I tried to convert this physical address to virtual using "DomxCore_mapPhyAddr2UsrVirtual" and pass the return pointer to V4L2 capture driver (QBUF - USERPTR).

Can anyone please suggest what can be the problem here?

Regards,

Krunal

  • 0
    Guru 10685 points

    Couple of things. Firstly, how are you requesting memory allocation from Shared Region 2? How are you displaying video, if at all - FBDEV or V4L2 display driver?

    Secondly, I would have thought that you need to map the virtual address into Linux memory. I'm not sure if that is already done for you by the OpenMAX framework.

    Ralph

  • 0 in reply to _Ralph_
    Genius 3120 points

    Hi Ralph,

    As I mentioned, I am using "SharedRegion_getHeap" and "Memory_alloc" API to allocate memory. I am using V4L2 capture not display.

    I tried to use "DomxCore_mapPhyAddr2UsrVirtual" and "DomxCore_mapUsrVirtualAddr2phy" APIs but no luck.

    Is there any other way to map the virtual address into Linux memory? Any example?

    -- Krunal

  • 0 in reply to Krunal Patil
    TI__Intellectual 2785 points

    Krunal,

                In case if you are using EZSDK, have you looked at the sample code <Your-EZSDK-root>/example-applications/linux-driver-examples-psp04.07.00.01/video/saLoopBack.c

                This application allocates buffer from display driver and uses that buffer to give to capture.

                Allocating buffer through Shared region must work fine, I am not getting why you to use DomxCore_mapxxxxxx APIs for this purpose, the address returned by Memory_alloc API can be directly passed to capture driver.

               There are other ways to allocate physically contiguous buffers, Using CMEM, and using linux /dev/mem

              There are examples with in EZSDK for these CMEM (Refer Codec engine samples).

             For using /dev/mem <your EZSDK root>/board-support/media-controller-utils_3_00_00_04/src/prcm_config/ti814x-evm/prcm_config_app.c

    Thanks & Regards
    Velan

  • 0 in reply to Velan
    Genius 3120 points

    Hi Velan,

    Apolize for the delayed response. For some reason I didn't received email notification about your reply from e2e.

    What you suggested worked for me. I tried this previously but it did not work that time, not sure what was wrong.

    Anyways, Now I am facing another problem: I am trying to copy shared region buffer to simple linux buffer using Neon memory copy operation and it is failing. the neon routin crashes and I don't even have access to serial terminal. If I replace this Neon memory copy with linux memcpy(), everything works well.

    Please note: Neon memcpy routin is validated and worked for FB buffer -> linux buffer copy operations.

    Is there any limitation that we can not use Neon routins for Shared Region buffers? Can you suggest what can be the problem here?

    Regards,

    Krunal