• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 840 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.

[OMAP-3530 EVM] V4L2 Input Buffer Allocation - Continuous Requirement

Chris Read
Genius 3345 points
Other Parts Discussed in Thread: OMAP3530

I am trying to create an application for the OMAP-3530 EVM (Rev.G) that captures video using V4L2 then passes buffers to a Codec Engine configured  H.264 encoder on the DSP.  It seems that the buffers that are allocated by the V4L2 input driver aren't contiguous, or at least aren't known to be contiguous to the VIDENC1_process method:

@8,232,116us: [+0 T:0x41165490 S:0x41164b6c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x48a18, inBufs=0x41164c38, outBufs=0x41164c20, inArgs=0x41164d80, outArgs=0x41164d08)
@8,232,177us: [+5 T:0x41165490 S:0x41164afc] CV - VISA_allocMsg> Allocating message for messageId=0x00024d27
@8,232,360us: [+0 T:0x41165490 S:0x41164acc] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x41166000, size=691200)
@8,232,421us: [+1 T:0x41165490 S:0x41164acc] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x41166000, size=691200)
@8,232,452us: [+1 T:0x41165490 S:0x41164acc] OM - Memory__getPhysicalAddress> returning physAddr=0x0
@8,232,543us: [+1 T:0x41165490 S:0x41164acc] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x41166000) = 0x85a58000.
@8,232,604us: [+7 T:0x41165490 S:0x41164acc] OM - Memory_getBufferPhysicalAddress> ERROR: user buffer at addr=0x41166000, size=691200 is NOT contiguous
@8,232,666us: [+0 T:0x41165490 S:0x41164acc] OM - Memory_getBufferPhysicalAddress> return (0x0)
@8,232,727us: [+5 T:0x41165490 S:0x41164ae4] CV - VISA_freeMsg(0x48a18, 0x41b6e880): Freeing message with messageId=0x00024d27
@8,232,788us: [+0 T:0x41165490 S:0x41164b6c] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0x48a18, retVal=0xffffffff)

The address of the first buffer that is allocated by the V4L2 driver and mmap()'ed is the 0x41166000 shown above.

V4L2 documentation indicates that it allocates these buffers in physical memory, which seems to imply that they're contiguous.  However, the VIDENC1_process call doesn't recognize them as being contiguous.  Is there something I can do to flag them as known-to-be-contiguous?

I did try to use the user-ptr method for buffer handling with V4L2, but that doesn't seem to be supported in PSP-02.01.03.11.

Any other suggestions?  Thanks in advance

  • 0
    Genius 3345 points

    Actually my test to see if user-ptr buffer handling with V4L2 was flawed.  It does seem to be supported, and that's the path I'm headed down at the moment.

  • 0
    TI__Mastermind 18260 points
    If CE is complaining (and erroring) that the buffers are not contiguous then I would trust that.  The function Memory_getBufferPhysicalAddress() (which is called during the process() call when the VISA instance has the isChecked parameter set to TRUE) retrieves the start and ending physical addresses of a buffer and makes sure those address are "size" apart, which is a fairly solid method although it's possible that it would say it *is* contiguous when it's not, but it should never report that it's not contiguous when it actually is.
     
    I don't know the v4l2 interface, although I have followed threads enough on the linux-davinci maillist to know that you can request different kinds of buffers - one kind is suitable for scatter-gather lists, another kind is suitable for contiguous DMA.  Perhaps the customer needs to "configure" the interface differently, or "request" buffers differently.
    Regards,
     
    - Rob
  • 0 in reply to Robert Tivy
    Genius 3345 points

    The MMAP method of buffers seems to be the normal way to do this, and that's the way we did it in the DaVinci Linux Apps class where we used V4L2 to capture video and then passed it to the DSP for H.264 encoding.  There the buffers were never complained of by CE as not being contiguous, whereas under OMAP3530 and PSP 02.01.03.11, with linuxutils 2.25.01.06, and codec engine 02.24.01 they are cited as not contiguous.

    One observation that raises flags to me is that the buffer physical addresses that are given by the ioctl:VIDIOC_QUERYBUF are:  0x00000000, 0x000a9000, and 0x00152000.  Those don't seem like valid OMAP3530 physical memory addresses to me, but that's what the driver is providing.

  • 0 in reply to Chris Read
    Genius 3345 points

    Putting some debug information into the kernel, it seems that the video buffers are being mmap'ed using __videobuf_mmap_mapper from the file videobuf-dma-sg.c in the kernel's drivers/media/video/ directory.  This is the file for scatter/gather DMA, rather than contiguous DMA.  Since we need a contiguous buffer to hand off to the DSP, is mmap version a problem?

    Does the OMAP3530 driver need rewriting to provide contiguous buffers?

    Is there an option somewhere to make the buffers contiguous?

  • 0 in reply to Chris Read
    Genius 3345 points

    I appears that the "physical addresses" that the ioctl:VIDIOC_QUERYBUF returns are offsets, rather than absolute addresses, and that the mmap function that is called with the file descriptor as a parameter is specific to that driver type, and should remap it to a proper area of memory.