From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Junghak Sung <jh1009.sung@samsung.com>,
linux-media@vger.kernel.org, mchehab@osg.samsung.com,
sakari.ailus@iki.fi, pawel@osciak.com, inki.dae@samsung.com,
sw0312.kim@samsung.com, nenggun.kim@samsung.com,
sangbae90.lee@samsung.com, rany.kwon@samsung.com
Subject: Re: [RFC PATCH v2 4/5] media: videobuf2: Define vb2_buf_type and vb2_memory
Date: Tue, 11 Aug 2015 16:56:54 +0300 [thread overview]
Message-ID: <30625903.5XtBkRR4hc@avalon> (raw)
In-Reply-To: <55C85F34.7040603@xs4all.nl>
Hello,
On Monday 10 August 2015 10:22:12 Hans Verkuil wrote:
> On 07/31/2015 10:44 AM, Junghak Sung wrote:
> > Define enum vb2_buf_type and enum vb2_memory for videobuf2-core. This
> > change requires translation functions that could covert v4l2-core stuffs
> > to videobuf2-core stuffs in videobuf2-v4l2.c file.
> > The v4l2-specific member variables(e.g. type, memory) remains in
> > struct vb2_queue for backward compatibility and performance of type
> > translation.
> >
> > Signed-off-by: Junghak Sung <jh1009.sung@samsung.com>
> > Signed-off-by: Geunyoung Kim <nenggun.kim@samsung.com>
> > Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> > Acked-by: Inki Dae <inki.dae@samsung.com>
> > ---
> >
> > drivers/media/v4l2-core/videobuf2-core.c | 139 +++++++++++---------
> > drivers/media/v4l2-core/videobuf2-v4l2.c | 209 ++++++++++++++++++-------
> > include/media/videobuf2-core.h | 99 +++++++++++---
> > include/media/videobuf2-v4l2.h | 12 +-
> > 4 files changed, 299 insertions(+), 160 deletions(-)
>
> <snip>
>
> > diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > b/drivers/media/v4l2-core/videobuf2-v4l2.c index 85527e9..22dd19c 100644
> > --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> > +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> > @@ -30,8 +30,46 @@
> >
> > #include <media/v4l2-common.h>
> > #include <media/videobuf2-v4l2.h>
> >
> > +#define CREATE_TRACE_POINTS
> >
> > #include <trace/events/v4l2.h>
> >
> > +static const enum vb2_buf_type _tbl_buf_type[] = {
> > + [V4L2_BUF_TYPE_VIDEO_CAPTURE] = VB2_BUF_TYPE_VIDEO_CAPTURE,
> > + [V4L2_BUF_TYPE_VIDEO_OUTPUT] = VB2_BUF_TYPE_VIDEO_OUTPUT,
> > + [V4L2_BUF_TYPE_VIDEO_OVERLAY] = VB2_BUF_TYPE_VIDEO_OVERLAY,
> > + [V4L2_BUF_TYPE_VBI_CAPTURE] = VB2_BUF_TYPE_VBI_CAPTURE,
> > + [V4L2_BUF_TYPE_VBI_OUTPUT] = VB2_BUF_TYPE_VBI_OUTPUT,
> > + [V4L2_BUF_TYPE_SLICED_VBI_CAPTURE] =
VB2_BUF_TYPE_SLICED_VBI_CAPTURE,
> > + [V4L2_BUF_TYPE_SLICED_VBI_OUTPUT] = VB2_BUF_TYPE_SLICED_VBI_OUTPUT,
> > + [V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY] =
> > VB2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY,
> > + [V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE] =
> > VB2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
> > + [V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE] =
VB2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> > + [V4L2_BUF_TYPE_SDR_CAPTURE] = VB2_BUF_TYPE_SDR_CAPTURE,
> > + [V4L2_BUF_TYPE_PRIVATE] = VB2_BUF_TYPE_PRIVATE,
> > +};
> > +
> > +static const enum vb2_memory _tbl_memory[] = {
> > + [V4L2_MEMORY_MMAP] = VB2_MEMORY_MMAP,
> > + [V4L2_MEMORY_USERPTR] = VB2_MEMORY_USERPTR,
> > + [V4L2_MEMORY_DMABUF] = VB2_MEMORY_DMABUF,
> > +};
> > +
> > +#define to_vb2_buf_type(type) \
> > +({ \
> > + enum vb2_buf_type ret = 0; \
> > + if( type > 0 && type < ARRAY_SIZE(_tbl_buf_type) ) \
> > + ret = (_tbl_buf_type[type]); \
> > + ret; \
> > +})
> > +
> > +#define to_vb2_memory(memory) \
> > +({ \
> > + enum vb2_memory ret = 0; \
> > + if( memory > 0 && memory < ARRAY_SIZE(_tbl_memory) ) \
> > + ret = (_tbl_memory[memory]); \
> > + ret; \
> > +})
> > +
>
> <snip>
>
> > diff --git a/include/media/videobuf2-core.h
> > b/include/media/videobuf2-core.h index dc405da..871fcc6 100644
> > --- a/include/media/videobuf2-core.h
> > +++ b/include/media/videobuf2-core.h
> > @@ -15,9 +15,47 @@
> >
> > #include <linux/mm_types.h>
> > #include <linux/mutex.h>
> > #include <linux/poll.h>
> >
> > -#include <linux/videodev2.h>
> >
> > #include <linux/dma-buf.h>
> >
> > +#define VB2_MAX_FRAME 32
> > +#define VB2_MAX_PLANES 8
> > +
> > +enum vb2_buf_type {
> > + VB2_BUF_TYPE_UNKNOWN = 0,
> > + VB2_BUF_TYPE_VIDEO_CAPTURE = 1,
> > + VB2_BUF_TYPE_VIDEO_OUTPUT = 2,
> > + VB2_BUF_TYPE_VIDEO_OVERLAY = 3,
> > + VB2_BUF_TYPE_VBI_CAPTURE = 4,
> > + VB2_BUF_TYPE_VBI_OUTPUT = 5,
> > + VB2_BUF_TYPE_SLICED_VBI_CAPTURE = 6,
> > + VB2_BUF_TYPE_SLICED_VBI_OUTPUT = 7,
> > + VB2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
> > + VB2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
> > + VB2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10,
> > + VB2_BUF_TYPE_SDR_CAPTURE = 11,
> > + VB2_BUF_TYPE_DVB_CAPTURE = 12,
> > + VB2_BUF_TYPE_PRIVATE = 0x80,
> > +};
> > +
> > +enum vb2_memory {
> > + VB2_MEMORY_UNKNOWN = 0,
> > + VB2_MEMORY_MMAP = 1,
> > + VB2_MEMORY_USERPTR = 2,
> > + VB2_MEMORY_DMABUF = 4,
> > +};
> > +
> > +#define VB2_TYPE_IS_MULTIPLANAR(type) \
> > + ((type) == VB2_BUF_TYPE_VIDEO_CAPTURE_MPLANE \
> > + || (type) == VB2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> > +
> > +#define VB2_TYPE_IS_OUTPUT(type) \
> > + ((type) == VB2_BUF_TYPE_VIDEO_OUTPUT \
> > + || (type) == VB2_BUF_TYPE_VIDEO_OUTPUT_MPLANE \
> > + || (type) == VB2_BUF_TYPE_VIDEO_OVERLAY \
> > + || (type) == VB2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY \
> > + || (type) == VB2_BUF_TYPE_VBI_OUTPUT \
> > + || (type) == VB2_BUF_TYPE_SLICED_VBI_OUTPUT)
>
> You don't actually need to create vb2_buf_type: unless I am mistaken, all
> that the vb2 core needs to know is if it is a capture or output queue and
> possibly (not sure about that) if it is single or multiplanar. So add
> fields to the vb2_queue struct for that information and leave the buf_type
> to the v4l2 specific header and code.
>
> You also don't need the _tbl_memory[] array. All you need to do is to check
> in videobuf2-v4l2.c that VB2_MEMORY* equals the V4L2_MEMORY_* defines and
> generate a #error if not:
>
> #if VB2_MEMORY_MMAP != V4L2_MEMORY_MMAP || VB2_MEMORY_....
> #error VB2_MEMORY_* != V4L2_MEMORY_*!
> #endif
Hijacking this e-mail thread a bit, would it make sense for the new vb2-core
to support different memory allocation for different planes ? I'm foreseeing
use cases for buffers that bundle image data with meta-data, where image data
should be captured to a dma-buf imported buffer, but meta-data doesn't need to
be shared. In that case it wouldn't be easy for userspace to find a dma-buf
provider for the meta-data buffers in order to import all planes. Being able
to use dma-buf import for the image plane(s) and mmap for the meta-data plane
would be easier.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2015-08-11 13:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 8:44 [RFC PATCH v2 0/5] Refactoring Videobuf2 for common use Junghak Sung
2015-07-31 8:44 ` [RFC PATCH v2 1/5] media: videobuf2: Rename videobuf2-core to videobuf2-v4l2 Junghak Sung
2015-08-10 8:06 ` Hans Verkuil
2015-07-31 8:44 ` [RFC PATCH v2 2/5] media: videobuf2: Restructurng struct vb2_buffer for common use Junghak Sung
2015-07-31 8:44 ` [RFC PATCH v2 3/5] media: videobuf2: Divide videobuf2-core into 2 parts Junghak Sung
2015-08-10 12:07 ` Hans Verkuil
2015-08-10 12:55 ` Mauro Carvalho Chehab
2015-08-10 13:38 ` Hans Verkuil
2015-08-11 13:51 ` Laurent Pinchart
2015-07-31 8:44 ` [RFC PATCH v2 4/5] media: videobuf2: Define vb2_buf_type and vb2_memory Junghak Sung
2015-08-10 8:22 ` Hans Verkuil
2015-08-11 2:19 ` Junghak Sung
2015-08-11 6:32 ` Hans Verkuil
2015-08-11 13:56 ` Laurent Pinchart [this message]
2015-08-11 13:59 ` Hans Verkuil
2015-08-11 14:04 ` Laurent Pinchart
2015-07-31 8:44 ` [RFC PATCH v2 5/5] media: videobuf2: Modify prefix for VB2 functions Junghak Sung
2015-08-10 8:31 ` [RFC PATCH v2 0/5] Refactoring Videobuf2 for common use Hans Verkuil
2015-08-10 9:32 ` Mauro Carvalho Chehab
2015-08-10 10:11 ` Hans Verkuil
2015-08-10 10:49 ` Mauro Carvalho Chehab
2015-08-10 11:44 ` Hans Verkuil
2015-08-11 1:37 ` Junghak Sung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30625903.5XtBkRR4hc@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=hverkuil@xs4all.nl \
--cc=inki.dae@samsung.com \
--cc=jh1009.sung@samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=nenggun.kim@samsung.com \
--cc=pawel@osciak.com \
--cc=rany.kwon@samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=sangbae90.lee@samsung.com \
--cc=sw0312.kim@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.