Hello Vincent, On Mon, Sep 12, 2016 at 4:47 AM, Vincent Abriou <[email protected]> wrote: > It allows to simulate the behavior of hardware with such limitations or > to connect vivid to real hardware with such limitations. > > Add the "allocators" module parameter option to let vivid use the > dma-contig instead of vmalloc. > > Signed-off-by: Philipp Zabel <[email protected]> > Signed-off-by: Hans Verkuil <[email protected]> > Signed-off-by: Vincent Abriou <[email protected]> > > Cc: Philipp Zabel <[email protected]> > Cc: Hans Verkuil <[email protected]> > ---
The patch looks good to me. Reviewed-by: Javier Martinez Canillas <[email protected]> I've also tested on an Exynos5 board to share DMA buffers between a vivid capture device and the Exynos DRM driver, so: Tested-by: Javier Martinez Canillas <[email protected]> Before $SUBJECT, when vivid was always using the vb2 vmalloc memory allocator, the Exynos DRM driver wasn't able to import the dma-buf because the GEM buffers are non-contiguous: $ gst-launch-1.0 v4l2src device=/dev/video7 io-mode=dmabuf ! kmssink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock 0:00:00.853895814 2957 0xd6260 ERROR kmsallocator gstkmsallocator.c:334:gst_kms_allocator_add_fb:<KMSMemory::allocator> Failed to bind to framebuffer: Invalid argument (-22) [ 1757.390564] [drm:exynos_drm_framebuffer_init] *ERROR* cannot use this gem memory type for fb. The issue goes away when using the the vb2 DMA contig memory allocator. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
