Hello Vincent, On Mon, Sep 12, 2016 at 4:47 AM, Vincent Abriou <vincent.abriou@xxxxxx> 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 <p.zabel@xxxxxxxxxxxxxx> > Signed-off-by: Hans Verkuil <hans.verkuil@xxxxxxxxx> > Signed-off-by: Vincent Abriou <vincent.abriou@xxxxxx> > > Cc: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> > Cc: Hans Verkuil <hans.verkuil@xxxxxxxxx> > --- The patch looks good to me. Reviewed-by: Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> 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 <javier@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
