Hello Vincent,

On Mon, Sep 12, 2016 at 4:47 AM, Vincent Abriou <vincent.abr...@st.com> 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.za...@pengutronix.de>
> Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>
> Signed-off-by: Vincent Abriou <vincent.abr...@st.com>
>
> Cc: Philipp Zabel <p.za...@pengutronix.de>
> Cc: Hans Verkuil <hans.verk...@cisco.com>
> ---

The patch looks good to me.

Reviewed-by: Javier Martinez Canillas <jav...@osg.samsung.com>

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 <jav...@osg.samsung.com>

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to