IMX Scaler / CSC m2m driver.

[Ian Molton]

On 20/03/15 15:53, Nicolas Dufresne wrote:

> MMAP: Fixed size pool provided by the HW, mmap(dev_fd, offset)
> DMABUF: Fixed size pool provided by the HW, mmap(dma_fd, 0)
> USERPTR: Buffer from elsewhere (usually another driver in MMAP)
> DMABUF-IMPORT: DMABUF from elsewhere
>
> Nicolas

Hi!

gst-launch-1.0 filesrc location= Downloads/big_buck_bunny_1080p_h264.mov ! qtdemux ! h264parse ! queue ! v4l2video3videodec capture-io-mode=dmabuf ! v4l2video0convert output-io-mode=dmabuf-import ! video/x-raw,width=1920,height=1080 ! ximagesink sync=false

So, in the above pipeline, presumably everything up tov4l2video3videodec
is happening in userspace.

Does that mean the buffers allocated for h264parse to write its data into
are allocated by the CODA driver?

in coda_decoder_queue_init() there is:

dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
         dst_vq->io_modes = VB2_DMABUF | VB2_MMAP;


Does this mean that v4l2video0convert will automatically handle the data via
a DMABUF?

is there any practical difference between a DMABUF and a MMAP buf?
I presume one is allocated GFP_DMA and the other GFK_KERNEL, is that it? so
for the best performance, I'd want all the elements in the chain to be using
DMABUFs ?

Why would I ever want a USERPTR if a DMA/MMAP option is available? doesn't
that imply a copy (from userspace) ?

-Ian