* [PATCH v6 00/10] Renesas VSP1 driver @ 2013-08-05 17:53 Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 01/10] media: Add support for circular graph traversal Laurent Pinchart ` (8 more replies) 0 siblings, 9 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki Hello, Here's the sixth version of the VSP1 engine (a Video Signal Processor found in several Renesas R-Car SoCs) driver. This version adds a videobuf2 mmap locking fix and improves the documentation patch (thanks to Hans for the discussion we had on IRC, hopefully we won't need another round now). The VSP1 is a video processing engine that includes a blender, scalers, filters and statistics computation. Configurable data path routing logic allows ordering the internal blocks in a flexible way, making this driver a prime candidate for the media controller API. Due to the configurable nature of the pipeline the driver doesn't use the V4L2 mem-to-mem framework, even though the device usually operates in memory to memory mode. Only the read pixel formatters, up/down scalers, write pixel formatters and LCDC interface are supported at this stage. The patch series starts with a fix for the media controller graph traversal code, three documentation fixes, a videobuf2 mmap locking fix and new pixel format and media bus code definitions. The last three patches finally add the VSP1 driver and fix two issues (I haven't squashed the patches together to keep proper attribution). Changes since v1: - Updated to the v3.11 media controller API changes - Only add the LIF entity to the entities list when the LIF is present - Added a MODULE_ALIAS() - Fixed file descriptions in comment blocks - Removed function prototypes for the unimplemented destroy functions - Fixed a typo in the HST register name - Fixed format propagation for the UDS entities - Added v4l2_capability::device_caps support - Prefix the device name with "platform:" in bus_info - Zero the v4l2_pix_format priv field in the internal try format handler - Use vb2_is_busy() instead of vb2_is_streaming() when setting the format - Use the vb2_ioctl_* handlers where possible Changes since v2: - Use a bitmap to track visited entities during graph traversal - Fixed a typo in the V4L2_MBUS_FMT_ARGB888_1X32 documentation - Fix register macros that were missing a n argument - Mask unused bits when clearing the interrupt status register - Explain why stride alignment to 128 bytes is needed - Use the aligned stride value when computing the image size - Assorted cosmetic changes Changes since v3: - Handle timeout errors when resetting WPFs - Use DECLARE_BITMAP - Update the NV16M/NV61M documentation to mention the multi-planar API for NV61M Changes since v4: - Clarify the VIDIOC_CREATE_BUFS format requirements in the V4L2 documentation - Clarify vb2 queue_setup() and buf_prepare() usage documentation - Remove duplicate printk's in devm_* error paths - Implement VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF support - Reject invalid buffers in the .buffer_queue() handler Changes since v5: - Use the vb2 fop helpers - Reword the VIDIOC_CREATE_BUFS clarification - Take the queue or device lock in vb2_fop_mmap() - Accept custom sizeimage values in .queue_setup() Katsuya Matsubara (2): vsp1: Fix lack of the sink entity registration for enabled links vsp1: Use the maximum number of entities defined in platform data Laurent Pinchart (8): media: Add support for circular graph traversal Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements media: vb2: Clarify queue_setup() and buf_prepare() usage documentation media: vb2: Take queue or device lock in vb2_fop_mmap() v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats v4l: Renesas R-Car VSP1 driver Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 171 ++++ Documentation/DocBook/media/v4l/pixfmt.xml | 1 + Documentation/DocBook/media/v4l/subdev-formats.xml | 611 +++++------ .../DocBook/media/v4l/vidioc-create-bufs.xml | 41 +- Documentation/DocBook/media_api.tmpl | 6 + drivers/media/media-entity.c | 14 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile | 2 + drivers/media/platform/vsp1/Makefile | 5 + drivers/media/platform/vsp1/vsp1.h | 73 ++ drivers/media/platform/vsp1/vsp1_drv.c | 495 +++++++++ drivers/media/platform/vsp1/vsp1_entity.c | 181 ++++ drivers/media/platform/vsp1/vsp1_entity.h | 68 ++ drivers/media/platform/vsp1/vsp1_lif.c | 238 +++++ drivers/media/platform/vsp1/vsp1_lif.h | 37 + drivers/media/platform/vsp1/vsp1_regs.h | 581 +++++++++++ drivers/media/platform/vsp1/vsp1_rpf.c | 209 ++++ drivers/media/platform/vsp1/vsp1_rwpf.c | 124 +++ drivers/media/platform/vsp1/vsp1_rwpf.h | 53 + drivers/media/platform/vsp1/vsp1_uds.c | 346 +++++++ drivers/media/platform/vsp1/vsp1_uds.h | 40 + drivers/media/platform/vsp1/vsp1_video.c | 1071 ++++++++++++++++++++ drivers/media/platform/vsp1/vsp1_video.h | 144 +++ drivers/media/platform/vsp1/vsp1_wpf.c | 233 +++++ drivers/media/v4l2-core/videobuf2-core.c | 9 +- include/linux/platform_data/vsp1.h | 25 + include/media/media-entity.h | 4 + include/media/videobuf2-core.h | 11 +- include/uapi/linux/v4l2-mediabus.h | 6 +- include/uapi/linux/videodev2.h | 2 + 30 files changed, 4420 insertions(+), 391 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml create mode 100644 drivers/media/platform/vsp1/Makefile create mode 100644 drivers/media/platform/vsp1/vsp1.h create mode 100644 drivers/media/platform/vsp1/vsp1_drv.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.c create mode 100644 drivers/media/platform/vsp1/vsp1_entity.h create mode 100644 drivers/media/platform/vsp1/vsp1_lif.c create mode 100644 drivers/media/platform/vsp1/vsp1_lif.h create mode 100644 drivers/media/platform/vsp1/vsp1_regs.h create mode 100644 drivers/media/platform/vsp1/vsp1_rpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.c create mode 100644 drivers/media/platform/vsp1/vsp1_rwpf.h create mode 100644 drivers/media/platform/vsp1/vsp1_uds.c create mode 100644 drivers/media/platform/vsp1/vsp1_uds.h create mode 100644 drivers/media/platform/vsp1/vsp1_video.c create mode 100644 drivers/media/platform/vsp1/vsp1_video.h create mode 100644 drivers/media/platform/vsp1/vsp1_wpf.c create mode 100644 include/linux/platform_data/vsp1.h -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v6 01/10] media: Add support for circular graph traversal 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 02/10] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements Laurent Pinchart ` (7 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki The graph traversal API (media_entity_graph_walk_*) doesn't support cyclic graphs and will fail to correctly walk a graph when circular links exist. Support circular graph traversal by checking whether an entity has already been visited before pushing it to the stack. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> --- drivers/media/media-entity.c | 14 +++++++++++--- include/media/media-entity.h | 4 ++++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c index cb30ffb..2c286c3 100644 --- a/drivers/media/media-entity.c +++ b/drivers/media/media-entity.c @@ -20,6 +20,7 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#include <linux/bitmap.h> #include <linux/module.h> #include <linux/slab.h> #include <media/media-entity.h> @@ -121,7 +122,6 @@ static struct media_entity *stack_pop(struct media_entity_graph *graph) return entity; } -#define stack_peek(en) ((en)->stack[(en)->top - 1].entity) #define link_top(en) ((en)->stack[(en)->top].link) #define stack_top(en) ((en)->stack[(en)->top].entity) @@ -140,6 +140,12 @@ void media_entity_graph_walk_start(struct media_entity_graph *graph, { graph->top = 0; graph->stack[graph->top].entity = NULL; + bitmap_zero(graph->entities, MEDIA_ENTITY_ENUM_MAX_ID); + + if (WARN_ON(entity->id >= MEDIA_ENTITY_ENUM_MAX_ID)) + return; + + __set_bit(entity->id, graph->entities); stack_push(graph, entity); } EXPORT_SYMBOL_GPL(media_entity_graph_walk_start); @@ -180,9 +186,11 @@ media_entity_graph_walk_next(struct media_entity_graph *graph) /* Get the entity in the other end of the link . */ next = media_entity_other(entity, link); + if (WARN_ON(next->id >= MEDIA_ENTITY_ENUM_MAX_ID)) + return NULL; - /* Was it the entity we came here from? */ - if (next = stack_peek(graph)) { + /* Has the entity already been visited? */ + if (__test_and_set_bit(next->id, graph->entities)) { link_top(graph)++; continue; } diff --git a/include/media/media-entity.h b/include/media/media-entity.h index 06bacf9..10df551 100644 --- a/include/media/media-entity.h +++ b/include/media/media-entity.h @@ -23,6 +23,7 @@ #ifndef _MEDIA_ENTITY_H #define _MEDIA_ENTITY_H +#include <linux/bitops.h> #include <linux/list.h> #include <linux/media.h> @@ -113,12 +114,15 @@ static inline u32 media_entity_subtype(struct media_entity *entity) } #define MEDIA_ENTITY_ENUM_MAX_DEPTH 16 +#define MEDIA_ENTITY_ENUM_MAX_ID 64 struct media_entity_graph { struct { struct media_entity *entity; int link; } stack[MEDIA_ENTITY_ENUM_MAX_DEPTH]; + + DECLARE_BITMAP(entities, MEDIA_ENTITY_ENUM_MAX_ID); int top; }; -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v6 02/10] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 01/10] media: Add support for circular graph traversal Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-06 10:36 ` Hans Verkuil 2013-08-05 17:53 ` [PATCH v6 03/10] media: vb2: Clarify queue_setup() and buf_prepare() usage documentation Laurent Pinchart ` (6 subsequent siblings) 8 siblings, 1 reply; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki The VIDIOC_CREATE_BUFS ioctl takes a format argument that must contain a valid format supported by the driver. Clarify the documentation. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> --- .../DocBook/media/v4l/vidioc-create-bufs.xml | 41 ++++++++++++++-------- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index cd99436..9b700a5 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -62,18 +62,29 @@ addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers is required. This ioctl can be called multiple times to create buffers of different sizes.</para> - <para>To allocate device buffers applications initialize relevant fields of -the <structname>v4l2_create_buffers</structname> structure. They set the -<structfield>type</structfield> field in the -&v4l2-format; structure, embedded in this -structure, to the respective stream or buffer type. -<structfield>count</structfield> must be set to the number of required buffers. -<structfield>memory</structfield> specifies the required I/O method. The -<structfield>format</structfield> field shall typically be filled in using -either the <constant>VIDIOC_TRY_FMT</constant> or -<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust -<structfield>sizeimage</structfield> fields to fit their specific needs. The -<structfield>reserved</structfield> array must be zeroed.</para> + <para>To allocate the device buffers applications must initialize the +relevant fields of the <structname>v4l2_create_buffers</structname> structure. +The <structfield>count</structfield> field must be set to the number of +requested buffers, the <structfield>memory</structfield> field specifies the +requested I/O method and the <structfield>reserved</structfield> array must be +zeroed.</para> + + <para>The <structfield>format</structfield> field specifies the image format +that the buffers must be able to handle. The application has to fill in this +&v4l2-format;. Usually this will be done using the +<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl() +to ensure that the requested format is supported by the driver. Unsupported +formats will result in an error.</para> + + <para>The buffers created by this ioctl will have as minimum size the size +defined by the <structfield>format.pix.sizeimage</structfield> field. If the +<structfield>format.pix.sizeimage</structfield> field is less than the minimum +required for the given format, then <structfield>sizeimage</structfield> will be +increased by the driver to that minimum to allocate the buffers. If it is +larger, then the value will be used as-is. The same applies to the +<structfield>sizeimage</structfield> field of the +<structname>v4l2_plane_pix_format</structname> structure in the case of +multiplanar formats.</para> <para>When the ioctl is called with a pointer to this structure the driver will attempt to allocate up to the requested number of buffers and store the @@ -144,9 +155,9 @@ mapped</link> I/O.</para> <varlistentry> <term><errorcode>EINVAL</errorcode></term> <listitem> - <para>The buffer type (<structfield>type</structfield> field) or the -requested I/O method (<structfield>memory</structfield>) is not -supported.</para> + <para>The buffer type (<structfield>format.type</structfield> field), +requested I/O method (<structfield>memory</structfield>) or format +(<structfield>format</structfield> field) is not valid.</para> </listitem> </varlistentry> </variablelist> -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v6 02/10] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements 2013-08-05 17:53 ` [PATCH v6 02/10] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements Laurent Pinchart @ 2013-08-06 10:36 ` Hans Verkuil 0 siblings, 0 replies; 21+ messages in thread From: Hans Verkuil @ 2013-08-06 10:36 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-media, linux-sh, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki On Mon 5 August 2013 19:53:21 Laurent Pinchart wrote: > The VIDIOC_CREATE_BUFS ioctl takes a format argument that must contain a > valid format supported by the driver. Clarify the documentation. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Regards, Hans > --- > .../DocBook/media/v4l/vidioc-create-bufs.xml | 41 ++++++++++++++-------- > 1 file changed, 26 insertions(+), 15 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > index cd99436..9b700a5 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > @@ -62,18 +62,29 @@ addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter > control over buffers is required. This ioctl can be called multiple times to > create buffers of different sizes.</para> > > - <para>To allocate device buffers applications initialize relevant fields of > -the <structname>v4l2_create_buffers</structname> structure. They set the > -<structfield>type</structfield> field in the > -&v4l2-format; structure, embedded in this > -structure, to the respective stream or buffer type. > -<structfield>count</structfield> must be set to the number of required buffers. > -<structfield>memory</structfield> specifies the required I/O method. The > -<structfield>format</structfield> field shall typically be filled in using > -either the <constant>VIDIOC_TRY_FMT</constant> or > -<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust > -<structfield>sizeimage</structfield> fields to fit their specific needs. The > -<structfield>reserved</structfield> array must be zeroed.</para> > + <para>To allocate the device buffers applications must initialize the > +relevant fields of the <structname>v4l2_create_buffers</structname> structure. > +The <structfield>count</structfield> field must be set to the number of > +requested buffers, the <structfield>memory</structfield> field specifies the > +requested I/O method and the <structfield>reserved</structfield> array must be > +zeroed.</para> > + > + <para>The <structfield>format</structfield> field specifies the image format > +that the buffers must be able to handle. The application has to fill in this > +&v4l2-format;. Usually this will be done using the > +<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl() > +to ensure that the requested format is supported by the driver. Unsupported > +formats will result in an error.</para> > + > + <para>The buffers created by this ioctl will have as minimum size the size > +defined by the <structfield>format.pix.sizeimage</structfield> field. If the > +<structfield>format.pix.sizeimage</structfield> field is less than the minimum > +required for the given format, then <structfield>sizeimage</structfield> will be > +increased by the driver to that minimum to allocate the buffers. If it is > +larger, then the value will be used as-is. The same applies to the > +<structfield>sizeimage</structfield> field of the > +<structname>v4l2_plane_pix_format</structname> structure in the case of > +multiplanar formats.</para> > > <para>When the ioctl is called with a pointer to this structure the driver > will attempt to allocate up to the requested number of buffers and store the > @@ -144,9 +155,9 @@ mapped</link> I/O.</para> > <varlistentry> > <term><errorcode>EINVAL</errorcode></term> > <listitem> > - <para>The buffer type (<structfield>type</structfield> field) or the > -requested I/O method (<structfield>memory</structfield>) is not > -supported.</para> > + <para>The buffer type (<structfield>format.type</structfield> field), > +requested I/O method (<structfield>memory</structfield>) or format > +(<structfield>format</structfield> field) is not valid.</para> > </listitem> > </varlistentry> > </variablelist> > ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v6 03/10] media: vb2: Clarify queue_setup() and buf_prepare() usage documentation 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 01/10] media: Add support for circular graph traversal Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 02/10] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap() Laurent Pinchart ` (5 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki Explain how the two operations must handle formats and validate buffer sizes when used with VIDIOC_CREATE_BUFS. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> --- include/media/videobuf2-core.h | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index d88a098..6781258 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -219,8 +219,9 @@ struct vb2_buffer { * configured format and *num_buffers is the total number * of buffers, that are being allocated. When called from * VIDIOC_CREATE_BUFS, fmt != NULL and it describes the - * target frame format. In this case *num_buffers are being - * allocated additionally to q->num_buffers. + * target frame format (if the format isn't valid the + * callback must return -EINVAL). In this case *num_buffers + * are being allocated additionally to q->num_buffers. * @wait_prepare: release any locks taken while calling vb2 functions; * it is called before an ioctl needs to wait for a new * buffer to arrive; required to avoid a deadlock in @@ -236,8 +237,10 @@ struct vb2_buffer { * @buf_prepare: called every time the buffer is queued from userspace * and from the VIDIOC_PREPARE_BUF ioctl; drivers may * perform any initialization required before each hardware - * operation in this callback; if an error is returned, the - * buffer will not be queued in driver; optional + * operation in this callback; drivers that support + * VIDIOC_CREATE_BUFS must also validate the buffer size; + * if an error is returned, the buffer will not be queued + * in driver; optional * @buf_finish: called before every dequeue of the buffer back to * userspace; drivers may perform any operations required * before userspace accesses the buffer; optional -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap() 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart ` (2 preceding siblings ...) 2013-08-05 17:53 ` [PATCH v6 03/10] media: vb2: Clarify queue_setup() and buf_prepare() usage documentation Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-06 10:39 ` Hans Verkuil 2013-08-05 17:53 ` [PATCH v6 05/10] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value Laurent Pinchart ` (4 subsequent siblings) 8 siblings, 1 reply; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki The vb2_fop_mmap() function is a plug-in implementation of the mmap() file operation that calls vb2_mmap() on the queue associated with the video device. Neither the vb2_fop_mmap() function nor the v4l2_mmap() mmap handler in the V4L2 core take any lock, leading to race conditions between mmap() and other buffer-related ioctls such as VIDIOC_REQBUFS. Fix it by taking the queue or device lock around the vb2_mmap() call. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> --- drivers/media/v4l2-core/videobuf2-core.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 9fc4bab..bd4bade 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) { struct video_device *vdev = video_devdata(file); + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; + int err; - return vb2_mmap(vdev->queue, vma); + if (lock && mutex_lock_interruptible(lock)) + return -ERESTARTSYS; + err = vb2_mmap(vdev->queue, vma); + if (lock) + mutex_unlock(lock); + return err; } EXPORT_SYMBOL_GPL(vb2_fop_mmap); -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap() 2013-08-05 17:53 ` [PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap() Laurent Pinchart @ 2013-08-06 10:39 ` Hans Verkuil 2013-08-06 20:09 ` Laurent Pinchart 2013-08-06 20:10 ` [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers Laurent Pinchart 0 siblings, 2 replies; 21+ messages in thread From: Hans Verkuil @ 2013-08-06 10:39 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-media, linux-sh, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki On Mon 5 August 2013 19:53:23 Laurent Pinchart wrote: > The vb2_fop_mmap() function is a plug-in implementation of the mmap() > file operation that calls vb2_mmap() on the queue associated with the > video device. Neither the vb2_fop_mmap() function nor the v4l2_mmap() > mmap handler in the V4L2 core take any lock, leading to race conditions > between mmap() and other buffer-related ioctls such as VIDIOC_REQBUFS. > > Fix it by taking the queue or device lock around the vb2_mmap() call. Hi Laurent, Can you do the same for vb2_fop_get_unmapped_area()? Thanks! Hans > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > --- > drivers/media/v4l2-core/videobuf2-core.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c > index 9fc4bab..bd4bade 100644 > --- a/drivers/media/v4l2-core/videobuf2-core.c > +++ b/drivers/media/v4l2-core/videobuf2-core.c > @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); > int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) > { > struct video_device *vdev = video_devdata(file); > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; > + int err; > > - return vb2_mmap(vdev->queue, vma); > + if (lock && mutex_lock_interruptible(lock)) > + return -ERESTARTSYS; > + err = vb2_mmap(vdev->queue, vma); > + if (lock) > + mutex_unlock(lock); > + return err; > } > EXPORT_SYMBOL_GPL(vb2_fop_mmap); > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap() 2013-08-06 10:39 ` Hans Verkuil @ 2013-08-06 20:09 ` Laurent Pinchart 2013-08-06 20:10 ` [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers Laurent Pinchart 1 sibling, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-06 20:09 UTC (permalink / raw) To: Hans Verkuil Cc: Laurent Pinchart, linux-media, linux-sh, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki Hi Hans, On Tuesday 06 August 2013 12:39:27 Hans Verkuil wrote: > On Mon 5 August 2013 19:53:23 Laurent Pinchart wrote: > > The vb2_fop_mmap() function is a plug-in implementation of the mmap() > > file operation that calls vb2_mmap() on the queue associated with the > > video device. Neither the vb2_fop_mmap() function nor the v4l2_mmap() > > mmap handler in the V4L2 core take any lock, leading to race conditions > > between mmap() and other buffer-related ioctls such as VIDIOC_REQBUFS. > > > > Fix it by taking the queue or device lock around the vb2_mmap() call. > > Hi Laurent, > > Can you do the same for vb2_fop_get_unmapped_area()? Sure. I'll repost a v7 of this patch that fixes both mmap and get_unmapped_area. > > Signed-off-by: Laurent Pinchart > > <laurent.pinchart+renesas@ideasonboard.com> > > --- > > > > drivers/media/v4l2-core/videobuf2-core.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c > > b/drivers/media/v4l2-core/videobuf2-core.c index 9fc4bab..bd4bade 100644 > > --- a/drivers/media/v4l2-core/videobuf2-core.c > > +++ b/drivers/media/v4l2-core/videobuf2-core.c > > @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); > > > > int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) > > { > > > > struct video_device *vdev = video_devdata(file); > > > > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev- >lock; > > + int err; > > > > - return vb2_mmap(vdev->queue, vma); > > + if (lock && mutex_lock_interruptible(lock)) > > + return -ERESTARTSYS; > > + err = vb2_mmap(vdev->queue, vma); > > + if (lock) > > + mutex_unlock(lock); > > + return err; > > > > } > > EXPORT_SYMBOL_GPL(vb2_fop_mmap); -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2013-08-06 10:39 ` Hans Verkuil 2013-08-06 20:09 ` Laurent Pinchart @ 2013-08-06 20:10 ` Laurent Pinchart 2013-08-07 6:30 ` Hans Verkuil 2014-05-23 13:54 ` Hans Verkuil 1 sibling, 2 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-06 20:10 UTC (permalink / raw) To: linux-media Cc: Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in implementation of the mmap() and get_unmapped_area() file operations that calls vb2_mmap() and vb2_get_unmapped_area() on the queue associated with the video device. Neither the vb2_fop_mmap/vb2_fop_get_unmapped_area nor the v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any lock, leading to race conditions between mmap/get_unmapped_area and other buffer-related ioctls such as VIDIOC_REQBUFS. Fix it by taking the queue or device lock around the vb2_mmap() and vb2_get_unmapped_area() calls. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> --- drivers/media/v4l2-core/videobuf2-core.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 9fc4bab..c9b50c7 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) { struct video_device *vdev = video_devdata(file); + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; + int err; - return vb2_mmap(vdev->queue, vma); + if (lock && mutex_lock_interruptible(lock)) + return -ERESTARTSYS; + err = vb2_mmap(vdev->queue, vma); + if (lock) + mutex_unlock(lock); + return err; } EXPORT_SYMBOL_GPL(vb2_fop_mmap); @@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) { struct video_device *vdev = video_devdata(file); + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; + int ret; - return vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); + if (lock && mutex_lock_interruptible(lock)) + return -ERESTARTSYS; + ret = vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); + if (lock) + mutex_unlock(lock); + return ret; } EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area); #endif -- Regards, Laurent Pinchart ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2013-08-06 20:10 ` [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers Laurent Pinchart @ 2013-08-07 6:30 ` Hans Verkuil 2014-05-23 13:54 ` Hans Verkuil 1 sibling, 0 replies; 21+ messages in thread From: Hans Verkuil @ 2013-08-07 6:30 UTC (permalink / raw) To: Laurent Pinchart Cc: linux-media, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh On 08/06/2013 10:10 PM, Laurent Pinchart wrote: > The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in > implementation of the mmap() and get_unmapped_area() file operations > that calls vb2_mmap() and vb2_get_unmapped_area() on the queue > associated with the video device. Neither the > vb2_fop_mmap/vb2_fop_get_unmapped_area nor the > v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any > lock, leading to race conditions between mmap/get_unmapped_area and > other buffer-related ioctls such as VIDIOC_REQBUFS. > > Fix it by taking the queue or device lock around the vb2_mmap() and > vb2_get_unmapped_area() calls. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Thanks! Hans > --- > drivers/media/v4l2-core/videobuf2-core.c | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c > index 9fc4bab..c9b50c7 100644 > --- a/drivers/media/v4l2-core/videobuf2-core.c > +++ b/drivers/media/v4l2-core/videobuf2-core.c > @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); > int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) > { > struct video_device *vdev = video_devdata(file); > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; > + int err; > > - return vb2_mmap(vdev->queue, vma); > + if (lock && mutex_lock_interruptible(lock)) > + return -ERESTARTSYS; > + err = vb2_mmap(vdev->queue, vma); > + if (lock) > + mutex_unlock(lock); > + return err; > } > EXPORT_SYMBOL_GPL(vb2_fop_mmap); > > @@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct file *file, unsigned long addr, > unsigned long len, unsigned long pgoff, unsigned long flags) > { > struct video_device *vdev = video_devdata(file); > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; > + int ret; > > - return vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > + if (lock && mutex_lock_interruptible(lock)) > + return -ERESTARTSYS; > + ret = vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > + if (lock) > + mutex_unlock(lock); > + return ret; > } > EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area); > #endif > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2013-08-06 20:10 ` [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers Laurent Pinchart 2013-08-07 6:30 ` Hans Verkuil @ 2014-05-23 13:54 ` Hans Verkuil 2014-05-26 22:38 ` Laurent Pinchart 2014-06-25 16:58 ` Sasha Levin 1 sibling, 2 replies; 21+ messages in thread From: Hans Verkuil @ 2014-05-23 13:54 UTC (permalink / raw) To: Laurent Pinchart, linux-media Cc: Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh, Sasha Levin, LKML, Dave Jones Hi Laurent, This patch caused a circular locking dependency as reported by Sasha Levin: https://lkml.org/lkml/2014/5/5/366 The reason is that copy_to/from_user is called in video_usercopy() with the core lock held. The copy functions can fault which takes the mmap_sem. If it was just video_usercopy() then it would be fairly easy to solve this, but the copy_to_/from_user functions are also called from read and write and they can be used in other unexpected places. I'm not sure if vb2_fop_get_unmapped_area() is a problem. I suspect (but I'm not sure) that when that one is called the mmap_sem isn't taken, in which case taking the lock is fine. But taking the lock in vb2_fop_mmap() does cause lockdep problems. Ideally I would like to drop taking that lock in vb2_fop_mmap and resolve the race condition that it intended to fix in a different way. Regards, Hans On 08/06/2013 10:10 PM, Laurent Pinchart wrote: > The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in > implementation of the mmap() and get_unmapped_area() file operations > that calls vb2_mmap() and vb2_get_unmapped_area() on the queue > associated with the video device. Neither the > vb2_fop_mmap/vb2_fop_get_unmapped_area nor the > v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any > lock, leading to race conditions between mmap/get_unmapped_area and > other buffer-related ioctls such as VIDIOC_REQBUFS. > > Fix it by taking the queue or device lock around the vb2_mmap() and > vb2_get_unmapped_area() calls. > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > --- > drivers/media/v4l2-core/videobuf2-core.c | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c > index 9fc4bab..c9b50c7 100644 > --- a/drivers/media/v4l2-core/videobuf2-core.c > +++ b/drivers/media/v4l2-core/videobuf2-core.c > @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); > int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) > { > struct video_device *vdev = video_devdata(file); > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; > + int err; > > - return vb2_mmap(vdev->queue, vma); > + if (lock && mutex_lock_interruptible(lock)) > + return -ERESTARTSYS; > + err = vb2_mmap(vdev->queue, vma); > + if (lock) > + mutex_unlock(lock); > + return err; > } > EXPORT_SYMBOL_GPL(vb2_fop_mmap); > > @@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct file *file, unsigned long addr, > unsigned long len, unsigned long pgoff, unsigned long flags) > { > struct video_device *vdev = video_devdata(file); > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; > + int ret; > > - return vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > + if (lock && mutex_lock_interruptible(lock)) > + return -ERESTARTSYS; > + ret = vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > + if (lock) > + mutex_unlock(lock); > + return ret; > } > EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area); > #endif > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2014-05-23 13:54 ` Hans Verkuil @ 2014-05-26 22:38 ` Laurent Pinchart 2014-06-25 16:58 ` Sasha Levin 1 sibling, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2014-05-26 22:38 UTC (permalink / raw) To: Hans Verkuil Cc: Laurent Pinchart, linux-media, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh, Sasha Levin, LKML, Dave Jones Hi Hans, On Friday 23 May 2014 15:54:29 Hans Verkuil wrote: > Hi Laurent, > > This patch caused a circular locking dependency as reported by Sasha Levin: > > https://lkml.org/lkml/2014/5/5/366 > > The reason is that copy_to/from_user is called in video_usercopy() with the > core lock held. The copy functions can fault which takes the mmap_sem. If it > was just video_usercopy() then it would be fairly easy to solve this, but > the copy_to_/from_user functions are also called from read and write and > they can be used in other unexpected places. > > I'm not sure if vb2_fop_get_unmapped_area() is a problem. I suspect (but I'm > not sure) that when that one is called the mmap_sem isn't taken, in which > case taking the lock is fine. > > But taking the lock in vb2_fop_mmap() does cause lockdep problems. > > Ideally I would like to drop taking that lock in vb2_fop_mmap and resolve > the race condition that it intended to fix in a different way. I'm of course fine with a different way to solve the race condition, if we can find a good one. Do you already know how you would like to solve this ? > On 08/06/2013 10:10 PM, Laurent Pinchart wrote: > > The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in > > implementation of the mmap() and get_unmapped_area() file operations > > that calls vb2_mmap() and vb2_get_unmapped_area() on the queue > > associated with the video device. Neither the > > vb2_fop_mmap/vb2_fop_get_unmapped_area nor the > > v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any > > lock, leading to race conditions between mmap/get_unmapped_area and > > other buffer-related ioctls such as VIDIOC_REQBUFS. > > > > Fix it by taking the queue or device lock around the vb2_mmap() and > > vb2_get_unmapped_area() calls. > > > > Signed-off-by: Laurent Pinchart > > <laurent.pinchart+renesas@ideasonboard.com> > > --- > > > > drivers/media/v4l2-core/videobuf2-core.c | 18 ++++++++++++++++-- > > 1 file changed, 16 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c > > b/drivers/media/v4l2-core/videobuf2-core.c index 9fc4bab..c9b50c7 100644 > > --- a/drivers/media/v4l2-core/videobuf2-core.c > > +++ b/drivers/media/v4l2-core/videobuf2-core.c > > @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); > > > > int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) > > { > > > > struct video_device *vdev = video_devdata(file); > > > > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev- >lock; > > + int err; > > > > - return vb2_mmap(vdev->queue, vma); > > + if (lock && mutex_lock_interruptible(lock)) > > + return -ERESTARTSYS; > > + err = vb2_mmap(vdev->queue, vma); > > + if (lock) > > + mutex_unlock(lock); > > + return err; > > > > } > > EXPORT_SYMBOL_GPL(vb2_fop_mmap); > > > > @@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct file > > *file, unsigned long addr,> > > unsigned long len, unsigned long pgoff, unsigned long flags) > > > > { > > > > struct video_device *vdev = video_devdata(file); > > > > + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev- >lock; > > + int ret; > > > > - return vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > > + if (lock && mutex_lock_interruptible(lock)) > > + return -ERESTARTSYS; > > + ret = vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > > + if (lock) > > + mutex_unlock(lock); > > + return ret; > > > > } > > EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area); > > #endif -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2014-05-23 13:54 ` Hans Verkuil 2014-05-26 22:38 ` Laurent Pinchart @ 2014-06-25 16:58 ` Sasha Levin 2014-07-01 21:08 ` Laurent Pinchart 1 sibling, 1 reply; 21+ messages in thread From: Sasha Levin @ 2014-06-25 16:58 UTC (permalink / raw) To: Hans Verkuil, Laurent Pinchart, linux-media Cc: Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh, LKML, Dave Jones Ping? On 05/23/2014 09:54 AM, Hans Verkuil wrote: > Hi Laurent, > > This patch caused a circular locking dependency as reported by Sasha Levin: > > https://lkml.org/lkml/2014/5/5/366 > > The reason is that copy_to/from_user is called in video_usercopy() with the > core lock held. The copy functions can fault which takes the mmap_sem. If it > was just video_usercopy() then it would be fairly easy to solve this, but > the copy_to_/from_user functions are also called from read and write and they > can be used in other unexpected places. > > I'm not sure if vb2_fop_get_unmapped_area() is a problem. I suspect (but I'm > not sure) that when that one is called the mmap_sem isn't taken, in which > case taking the lock is fine. > > But taking the lock in vb2_fop_mmap() does cause lockdep problems. > > Ideally I would like to drop taking that lock in vb2_fop_mmap and resolve the > race condition that it intended to fix in a different way. > > Regards, > > Hans > > On 08/06/2013 10:10 PM, Laurent Pinchart wrote: >> The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in >> implementation of the mmap() and get_unmapped_area() file operations >> that calls vb2_mmap() and vb2_get_unmapped_area() on the queue >> associated with the video device. Neither the >> vb2_fop_mmap/vb2_fop_get_unmapped_area nor the >> v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any >> lock, leading to race conditions between mmap/get_unmapped_area and >> other buffer-related ioctls such as VIDIOC_REQBUFS. >> >> Fix it by taking the queue or device lock around the vb2_mmap() and >> vb2_get_unmapped_area() calls. >> >> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> >> --- >> drivers/media/v4l2-core/videobuf2-core.c | 18 ++++++++++++++++-- >> 1 file changed, 16 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c >> index 9fc4bab..c9b50c7 100644 >> --- a/drivers/media/v4l2-core/videobuf2-core.c >> +++ b/drivers/media/v4l2-core/videobuf2-core.c >> @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); >> int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) >> { >> struct video_device *vdev = video_devdata(file); >> + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; >> + int err; >> >> - return vb2_mmap(vdev->queue, vma); >> + if (lock && mutex_lock_interruptible(lock)) >> + return -ERESTARTSYS; >> + err = vb2_mmap(vdev->queue, vma); >> + if (lock) >> + mutex_unlock(lock); >> + return err; >> } >> EXPORT_SYMBOL_GPL(vb2_fop_mmap); >> >> @@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct file *file, unsigned long addr, >> unsigned long len, unsigned long pgoff, unsigned long flags) >> { >> struct video_device *vdev = video_devdata(file); >> + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; >> + int ret; >> >> - return vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); >> + if (lock && mutex_lock_interruptible(lock)) >> + return -ERESTARTSYS; >> + ret = vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); >> + if (lock) >> + mutex_unlock(lock); >> + return ret; >> } >> EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area); >> #endif >> > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2014-06-25 16:58 ` Sasha Levin @ 2014-07-01 21:08 ` Laurent Pinchart 2014-07-02 6:33 ` Hans Verkuil 0 siblings, 1 reply; 21+ messages in thread From: Laurent Pinchart @ 2014-07-01 21:08 UTC (permalink / raw) To: Sasha Levin Cc: Hans Verkuil, Laurent Pinchart, linux-media, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh, LKML, Dave Jones On Wednesday 25 June 2014 12:58:03 Sasha Levin wrote: > Ping? Hans, I've replied to your previous e-mail with I'm of course fine with a different way to solve the race condition, if we can find a good one. Do you already know how you would like to solve this ? > On 05/23/2014 09:54 AM, Hans Verkuil wrote: > > Hi Laurent, > > > > This patch caused a circular locking dependency as reported by Sasha > > Levin: > > > > https://lkml.org/lkml/2014/5/5/366 > > > > The reason is that copy_to/from_user is called in video_usercopy() with > > the > > core lock held. The copy functions can fault which takes the mmap_sem. If > > it was just video_usercopy() then it would be fairly easy to solve this, > > but the copy_to_/from_user functions are also called from read and write > > and they can be used in other unexpected places. > > > > I'm not sure if vb2_fop_get_unmapped_area() is a problem. I suspect (but > > I'm not sure) that when that one is called the mmap_sem isn't taken, in > > which case taking the lock is fine. > > > > But taking the lock in vb2_fop_mmap() does cause lockdep problems. > > > > Ideally I would like to drop taking that lock in vb2_fop_mmap and resolve > > the race condition that it intended to fix in a different way. > > > > Regards, > > > > Hans > > > > On 08/06/2013 10:10 PM, Laurent Pinchart wrote: > >> The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in > >> implementation of the mmap() and get_unmapped_area() file operations > >> that calls vb2_mmap() and vb2_get_unmapped_area() on the queue > >> associated with the video device. Neither the > >> vb2_fop_mmap/vb2_fop_get_unmapped_area nor the > >> v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any > >> lock, leading to race conditions between mmap/get_unmapped_area and > >> other buffer-related ioctls such as VIDIOC_REQBUFS. > >> > >> Fix it by taking the queue or device lock around the vb2_mmap() and > >> vb2_get_unmapped_area() calls. > >> > >> Signed-off-by: Laurent Pinchart > >> <laurent.pinchart+renesas@ideasonboard.com> > >> --- > >> > >> drivers/media/v4l2-core/videobuf2-core.c | 18 ++++++++++++++++-- > >> 1 file changed, 16 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/media/v4l2-core/videobuf2-core.c > >> b/drivers/media/v4l2-core/videobuf2-core.c index 9fc4bab..c9b50c7 100644 > >> --- a/drivers/media/v4l2-core/videobuf2-core.c > >> +++ b/drivers/media/v4l2-core/videobuf2-core.c > >> @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); > >> int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) > >> { > >> struct video_device *vdev = video_devdata(file); > >> + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : > >> vdev->lock; > >> + int err; > >> > >> - return vb2_mmap(vdev->queue, vma); > >> + if (lock && mutex_lock_interruptible(lock)) > >> + return -ERESTARTSYS; > >> + err = vb2_mmap(vdev->queue, vma); > >> + if (lock) > >> + mutex_unlock(lock); > >> + return err; > >> } > >> EXPORT_SYMBOL_GPL(vb2_fop_mmap); > >> > >> @@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct > >> file *file, unsigned long addr,>> > >> unsigned long len, unsigned long pgoff, unsigned long flags) > >> { > >> struct video_device *vdev = video_devdata(file); > >> + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : > >> vdev->lock; > >> + int ret; > >> > >> - return vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > >> + if (lock && mutex_lock_interruptible(lock)) > >> + return -ERESTARTSYS; > >> + ret = vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); > >> + if (lock) > >> + mutex_unlock(lock); > >> + return ret; > >> > >> } > >> EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area); > >> #endif -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2014-07-01 21:08 ` Laurent Pinchart @ 2014-07-02 6:33 ` Hans Verkuil 2014-07-02 7:56 ` Laurent Pinchart 0 siblings, 1 reply; 21+ messages in thread From: Hans Verkuil @ 2014-07-02 6:33 UTC (permalink / raw) To: Laurent Pinchart, Sasha Levin Cc: Laurent Pinchart, linux-media, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh, LKML, Dave Jones For now it is -ENOTIME for me. It's on my TODO list, but there are a number of other things I want to finish first. Regards, Hans On 07/01/2014 11:08 PM, Laurent Pinchart wrote: > On Wednesday 25 June 2014 12:58:03 Sasha Levin wrote: >> Ping? > > Hans, I've replied to your previous e-mail with > > I'm of course fine with a different way to solve the race condition, if we can > find a good one. Do you already know how you would like to solve this ? > >> On 05/23/2014 09:54 AM, Hans Verkuil wrote: >>> Hi Laurent, >>> >>> This patch caused a circular locking dependency as reported by Sasha >>> Levin: >>> >>> https://lkml.org/lkml/2014/5/5/366 >>> >>> The reason is that copy_to/from_user is called in video_usercopy() with >>> the >>> core lock held. The copy functions can fault which takes the mmap_sem. If >>> it was just video_usercopy() then it would be fairly easy to solve this, >>> but the copy_to_/from_user functions are also called from read and write >>> and they can be used in other unexpected places. >>> >>> I'm not sure if vb2_fop_get_unmapped_area() is a problem. I suspect (but >>> I'm not sure) that when that one is called the mmap_sem isn't taken, in >>> which case taking the lock is fine. >>> >>> But taking the lock in vb2_fop_mmap() does cause lockdep problems. >>> >>> Ideally I would like to drop taking that lock in vb2_fop_mmap and resolve >>> the race condition that it intended to fix in a different way. >>> >>> Regards, >>> >>> Hans >>> >>> On 08/06/2013 10:10 PM, Laurent Pinchart wrote: >>>> The vb2_fop_mmap() and vb2_fop_get_unmapped_area() functions are plug-in >>>> implementation of the mmap() and get_unmapped_area() file operations >>>> that calls vb2_mmap() and vb2_get_unmapped_area() on the queue >>>> associated with the video device. Neither the >>>> vb2_fop_mmap/vb2_fop_get_unmapped_area nor the >>>> v4l2_mmap/vb2_get_unmapped_area functions in the V4L2 core take any >>>> lock, leading to race conditions between mmap/get_unmapped_area and >>>> other buffer-related ioctls such as VIDIOC_REQBUFS. >>>> >>>> Fix it by taking the queue or device lock around the vb2_mmap() and >>>> vb2_get_unmapped_area() calls. >>>> >>>> Signed-off-by: Laurent Pinchart >>>> <laurent.pinchart+renesas@ideasonboard.com> >>>> --- >>>> >>>> drivers/media/v4l2-core/videobuf2-core.c | 18 ++++++++++++++++-- >>>> 1 file changed, 16 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c >>>> b/drivers/media/v4l2-core/videobuf2-core.c index 9fc4bab..c9b50c7 100644 >>>> --- a/drivers/media/v4l2-core/videobuf2-core.c >>>> +++ b/drivers/media/v4l2-core/videobuf2-core.c >>>> @@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf); >>>> int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma) >>>> { >>>> struct video_device *vdev = video_devdata(file); >>>> + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : >>>> vdev->lock; >>>> + int err; >>>> >>>> - return vb2_mmap(vdev->queue, vma); >>>> + if (lock && mutex_lock_interruptible(lock)) >>>> + return -ERESTARTSYS; >>>> + err = vb2_mmap(vdev->queue, vma); >>>> + if (lock) >>>> + mutex_unlock(lock); >>>> + return err; >>>> } >>>> EXPORT_SYMBOL_GPL(vb2_fop_mmap); >>>> >>>> @@ -2685,8 +2692,15 @@ unsigned long vb2_fop_get_unmapped_area(struct >>>> file *file, unsigned long addr,>> >>>> unsigned long len, unsigned long pgoff, unsigned long flags) >>>> { >>>> struct video_device *vdev = video_devdata(file); >>>> + struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : >>>> vdev->lock; >>>> + int ret; >>>> >>>> - return vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); >>>> + if (lock && mutex_lock_interruptible(lock)) >>>> + return -ERESTARTSYS; >>>> + ret = vb2_get_unmapped_area(vdev->queue, addr, len, pgoff, flags); >>>> + if (lock) >>>> + mutex_unlock(lock); >>>> + return ret; >>>> >>>> } >>>> EXPORT_SYMBOL_GPL(vb2_fop_get_unmapped_area); >>>> #endif > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers 2014-07-02 6:33 ` Hans Verkuil @ 2014-07-02 7:56 ` Laurent Pinchart 0 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2014-07-02 7:56 UTC (permalink / raw) To: Hans Verkuil Cc: Sasha Levin, Laurent Pinchart, linux-media, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki, linux-sh, LKML, Dave Jones Hi Hans, On Wednesday 02 July 2014 08:33:47 Hans Verkuil wrote: > For now it is -ENOTIME for me. It's on my TODO list, but there are a number > of other things I want to finish first. No worries, I know how it feels. I just wanted to make sure you hadn't missed my e-mail. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v6 05/10] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart ` (3 preceding siblings ...) 2013-08-05 17:53 ` [PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap() Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 06/10] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses Laurent Pinchart ` (3 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki The V4L2_MBUS_FMT_YUV10_1X30 code is documented as being equal to 0x2014, while the v4l2-mediabus.h header defines it as 0x2016. Fix the documentation. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> --- Documentation/DocBook/media/v4l/subdev-formats.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index adc6198..0c2b1f2 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2574,7 +2574,7 @@ </row> <row id="V4L2-MBUS-FMT-YUV10-1X30"> <entry>V4L2_MBUS_FMT_YUV10_1X30</entry> - <entry>0x2014</entry> + <entry>0x2016</entry> <entry></entry> <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v6 06/10] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart ` (4 preceding siblings ...) 2013-08-05 17:53 ` [PATCH v6 05/10] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 07/10] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats Laurent Pinchart ` (2 subsequent siblings) 8 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> --- Documentation/DocBook/media/v4l/subdev-formats.xml | 609 +++++++++------------ Documentation/DocBook/media_api.tmpl | 6 + include/uapi/linux/v4l2-mediabus.h | 6 +- 3 files changed, 254 insertions(+), 367 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 0c2b1f2..f72c1cc 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -97,31 +97,39 @@ <colspec colname="id" align="left" /> <colspec colname="code" align="center"/> <colspec colname="bit" /> - <colspec colnum="4" colname="b23" align="center" /> - <colspec colnum="5" colname="b22" align="center" /> - <colspec colnum="6" colname="b21" align="center" /> - <colspec colnum="7" colname="b20" align="center" /> - <colspec colnum="8" colname="b19" align="center" /> - <colspec colnum="9" colname="b18" align="center" /> - <colspec colnum="10" colname="b17" align="center" /> - <colspec colnum="11" colname="b16" align="center" /> - <colspec colnum="12" colname="b15" align="center" /> - <colspec colnum="13" colname="b14" align="center" /> - <colspec colnum="14" colname="b13" align="center" /> - <colspec colnum="15" colname="b12" align="center" /> - <colspec colnum="16" colname="b11" align="center" /> - <colspec colnum="17" colname="b10" align="center" /> - <colspec colnum="18" colname="b09" align="center" /> - <colspec colnum="19" colname="b08" align="center" /> - <colspec colnum="20" colname="b07" align="center" /> - <colspec colnum="21" colname="b06" align="center" /> - <colspec colnum="22" colname="b05" align="center" /> - <colspec colnum="23" colname="b04" align="center" /> - <colspec colnum="24" colname="b03" align="center" /> - <colspec colnum="25" colname="b02" align="center" /> - <colspec colnum="26" colname="b01" align="center" /> - <colspec colnum="27" colname="b00" align="center" /> - <spanspec namest="b23" nameend="b00" spanname="b0" /> + <colspec colnum="4" colname="b31" align="center" /> + <colspec colnum="5" colname="b20" align="center" /> + <colspec colnum="6" colname="b29" align="center" /> + <colspec colnum="7" colname="b28" align="center" /> + <colspec colnum="8" colname="b27" align="center" /> + <colspec colnum="9" colname="b26" align="center" /> + <colspec colnum="10" colname="b25" align="center" /> + <colspec colnum="11" colname="b24" align="center" /> + <colspec colnum="12" colname="b23" align="center" /> + <colspec colnum="13" colname="b22" align="center" /> + <colspec colnum="14" colname="b21" align="center" /> + <colspec colnum="15" colname="b20" align="center" /> + <colspec colnum="16" colname="b19" align="center" /> + <colspec colnum="17" colname="b18" align="center" /> + <colspec colnum="18" colname="b17" align="center" /> + <colspec colnum="19" colname="b16" align="center" /> + <colspec colnum="20" colname="b15" align="center" /> + <colspec colnum="21" colname="b14" align="center" /> + <colspec colnum="22" colname="b13" align="center" /> + <colspec colnum="23" colname="b12" align="center" /> + <colspec colnum="24" colname="b11" align="center" /> + <colspec colnum="25" colname="b10" align="center" /> + <colspec colnum="26" colname="b09" align="center" /> + <colspec colnum="27" colname="b08" align="center" /> + <colspec colnum="28" colname="b07" align="center" /> + <colspec colnum="29" colname="b06" align="center" /> + <colspec colnum="30" colname="b05" align="center" /> + <colspec colnum="31" colname="b04" align="center" /> + <colspec colnum="32" colname="b03" align="center" /> + <colspec colnum="33" colname="b02" align="center" /> + <colspec colnum="34" colname="b01" align="center" /> + <colspec colnum="35" colname="b00" align="center" /> + <spanspec namest="b31" nameend="b00" spanname="b0" /> <thead> <row> <entry>Identifier</entry> @@ -133,6 +141,14 @@ <entry></entry> <entry></entry> <entry>Bit</entry> + <entry>31</entry> + <entry>30</entry> + <entry>29</entry> + <entry>28</entry> + <entry>27</entry> + <entry>26</entry> + <entry>25</entry> + <entry>24</entry> <entry>23</entry> <entry>22</entry> <entry>21</entry> @@ -164,7 +180,7 @@ <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry> <entry>0x1001</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>0</entry> <entry>0</entry> @@ -178,7 +194,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -192,7 +208,7 @@ <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry> <entry>0x1002</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -206,7 +222,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>0</entry> <entry>0</entry> @@ -220,7 +236,7 @@ <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry> <entry>0x1003</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> @@ -234,7 +250,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -248,7 +264,7 @@ <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry> <entry>0x1004</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -262,7 +278,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>0</entry> <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> @@ -276,7 +292,7 @@ <entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry> <entry>0x1005</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>b<subscript>4</subscript></entry> <entry>b<subscript>3</subscript></entry> <entry>b<subscript>2</subscript></entry> @@ -290,7 +306,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -304,7 +320,7 @@ <entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry> <entry>0x1006</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -318,7 +334,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>b<subscript>4</subscript></entry> <entry>b<subscript>3</subscript></entry> <entry>b<subscript>2</subscript></entry> @@ -332,7 +348,7 @@ <entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry> <entry>0x1007</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> <entry>r<subscript>2</subscript></entry> @@ -346,7 +362,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -360,7 +376,7 @@ <entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry> <entry>0x1008</entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> @@ -374,7 +390,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-16; + &dash-ent-24; <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> <entry>r<subscript>2</subscript></entry> @@ -388,12 +404,7 @@ <entry>V4L2_MBUS_FMT_RGB666_1X18</entry> <entry>0x1009</entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-14; <entry>r<subscript>5</subscript></entry> <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> @@ -417,6 +428,7 @@ <entry>V4L2_MBUS_FMT_RGB888_1X24</entry> <entry>0x100a</entry> <entry></entry> + &dash-ent-8; <entry>r<subscript>7</subscript></entry> <entry>r<subscript>6</subscript></entry> <entry>r<subscript>5</subscript></entry> @@ -446,9 +458,7 @@ <entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry> <entry>0x100b</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>r<subscript>7</subscript></entry> <entry>r<subscript>6</subscript></entry> <entry>r<subscript>5</subscript></entry> @@ -466,9 +476,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -486,9 +494,7 @@ <entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry> <entry>0x100c</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -506,9 +512,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>r<subscript>7</subscript></entry> <entry>r<subscript>6</subscript></entry> <entry>r<subscript>5</subscript></entry> @@ -522,6 +526,43 @@ <entry>g<subscript>5</subscript></entry> <entry>g<subscript>4</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-ARGB888-1X32"> + <entry>V4L2_MBUS_FMT_ARGB888_1X32</entry> + <entry>0x100d</entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> </tbody> </tgroup> </table> @@ -1149,6 +1190,7 @@ <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem> <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem> <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem> + <listitem><para>a<subscript>x</subscript> for alpha component bit number x</para></listitem> <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem> <listitem><para>d for dummy bits</para></listitem> </itemizedlist> @@ -1159,37 +1201,39 @@ <colspec colname="id" align="left" /> <colspec colname="code" align="center"/> <colspec colname="bit" /> - <colspec colnum="4" colname="b29" align="center" /> - <colspec colnum="5" colname="b28" align="center" /> - <colspec colnum="6" colname="b27" align="center" /> - <colspec colnum="7" colname="b26" align="center" /> - <colspec colnum="8" colname="b25" align="center" /> - <colspec colnum="9" colname="b24" align="center" /> - <colspec colnum="10" colname="b23" align="center" /> - <colspec colnum="11" colname="b22" align="center" /> - <colspec colnum="12" colname="b21" align="center" /> - <colspec colnum="13" colname="b20" align="center" /> - <colspec colnum="14" colname="b19" align="center" /> - <colspec colnum="15" colname="b18" align="center" /> - <colspec colnum="16" colname="b17" align="center" /> - <colspec colnum="17" colname="b16" align="center" /> - <colspec colnum="18" colname="b15" align="center" /> - <colspec colnum="19" colname="b14" align="center" /> - <colspec colnum="20" colname="b13" align="center" /> - <colspec colnum="21" colname="b12" align="center" /> - <colspec colnum="22" colname="b11" align="center" /> - <colspec colnum="23" colname="b10" align="center" /> - <colspec colnum="24" colname="b09" align="center" /> - <colspec colnum="25" colname="b08" align="center" /> - <colspec colnum="26" colname="b07" align="center" /> - <colspec colnum="27" colname="b06" align="center" /> - <colspec colnum="28" colname="b05" align="center" /> - <colspec colnum="29" colname="b04" align="center" /> - <colspec colnum="30" colname="b03" align="center" /> - <colspec colnum="31" colname="b02" align="center" /> - <colspec colnum="32" colname="b01" align="center" /> - <colspec colnum="33" colname="b00" align="center" /> - <spanspec namest="b29" nameend="b00" spanname="b0" /> + <colspec colnum="4" colname="b31" align="center" /> + <colspec colnum="5" colname="b20" align="center" /> + <colspec colnum="6" colname="b29" align="center" /> + <colspec colnum="7" colname="b28" align="center" /> + <colspec colnum="8" colname="b27" align="center" /> + <colspec colnum="9" colname="b26" align="center" /> + <colspec colnum="10" colname="b25" align="center" /> + <colspec colnum="11" colname="b24" align="center" /> + <colspec colnum="12" colname="b23" align="center" /> + <colspec colnum="13" colname="b22" align="center" /> + <colspec colnum="14" colname="b21" align="center" /> + <colspec colnum="15" colname="b20" align="center" /> + <colspec colnum="16" colname="b19" align="center" /> + <colspec colnum="17" colname="b18" align="center" /> + <colspec colnum="18" colname="b17" align="center" /> + <colspec colnum="19" colname="b16" align="center" /> + <colspec colnum="20" colname="b15" align="center" /> + <colspec colnum="21" colname="b14" align="center" /> + <colspec colnum="22" colname="b13" align="center" /> + <colspec colnum="23" colname="b12" align="center" /> + <colspec colnum="24" colname="b11" align="center" /> + <colspec colnum="25" colname="b10" align="center" /> + <colspec colnum="26" colname="b09" align="center" /> + <colspec colnum="27" colname="b08" align="center" /> + <colspec colnum="28" colname="b07" align="center" /> + <colspec colnum="29" colname="b06" align="center" /> + <colspec colnum="30" colname="b05" align="center" /> + <colspec colnum="31" colname="b04" align="center" /> + <colspec colnum="32" colname="b03" align="center" /> + <colspec colnum="33" colname="b02" align="center" /> + <colspec colnum="34" colname="b01" align="center" /> + <colspec colnum="35" colname="b00" align="center" /> + <spanspec namest="b31" nameend="b00" spanname="b0" /> <thead> <row> <entry>Identifier</entry> @@ -1201,6 +1245,8 @@ <entry></entry> <entry></entry> <entry>Bit</entry> + <entry>31</entry> + <entry>30</entry> <entry>29</entry> <entry>28</entry> <entry>27</entry> @@ -1238,10 +1284,7 @@ <entry>V4L2_MBUS_FMT_Y8_1X8</entry> <entry>0x2001</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1255,18 +1298,7 @@ <entry>V4L2_MBUS_FMT_UV8_1X8</entry> <entry>0x2015</entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1280,18 +1312,7 @@ <entry></entry> <entry></entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1305,10 +1326,7 @@ <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> <entry>0x2002</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1322,10 +1340,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1339,10 +1354,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1356,10 +1368,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1373,10 +1382,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1390,10 +1396,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1407,10 +1410,7 @@ <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry> <entry>0x2003</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1424,10 +1424,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1441,10 +1438,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1458,10 +1452,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1475,10 +1466,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1492,10 +1480,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1509,10 +1494,7 @@ <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry> <entry>0x2004</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1526,10 +1508,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1543,10 +1522,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1560,10 +1536,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1577,10 +1550,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1594,10 +1564,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1611,10 +1578,7 @@ <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry> <entry>0x2005</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1628,10 +1592,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1645,10 +1606,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1662,10 +1620,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1679,10 +1634,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1696,10 +1648,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1713,10 +1662,7 @@ <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry> <entry>0x2006</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1730,10 +1676,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1747,10 +1690,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1764,10 +1704,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1781,10 +1718,7 @@ <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry> <entry>0x2007</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1798,10 +1732,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1815,10 +1746,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1832,10 +1760,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1849,10 +1774,7 @@ <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry> <entry>0x2008</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1866,10 +1788,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1883,10 +1802,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1900,10 +1816,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1917,10 +1830,7 @@ <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry> <entry>0x2009</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1934,10 +1844,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -1951,10 +1858,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -1968,10 +1872,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> + &dash-ent-24; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -1985,8 +1886,7 @@ <entry>V4L2_MBUS_FMT_Y10_1X10</entry> <entry>0x200a</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2002,8 +1902,7 @@ <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> <entry>0x200b</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2019,8 +1918,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>u<subscript>9</subscript></entry> <entry>u<subscript>8</subscript></entry> <entry>u<subscript>7</subscript></entry> @@ -2036,8 +1934,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2053,8 +1950,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>v<subscript>9</subscript></entry> <entry>v<subscript>8</subscript></entry> <entry>v<subscript>7</subscript></entry> @@ -2070,8 +1966,7 @@ <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry> <entry>0x200c</entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2087,8 +1982,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>v<subscript>9</subscript></entry> <entry>v<subscript>8</subscript></entry> <entry>v<subscript>7</subscript></entry> @@ -2104,8 +1998,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2121,8 +2014,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - &dash-ent-10; + &dash-ent-22; <entry>u<subscript>9</subscript></entry> <entry>u<subscript>8</subscript></entry> <entry>u<subscript>7</subscript></entry> @@ -2138,15 +2030,7 @@ <entry>V4L2_MBUS_FMT_Y12_1X12</entry> <entry>0x2013</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-20; <entry>y<subscript>11</subscript></entry> <entry>y<subscript>10</subscript></entry> <entry>y<subscript>9</subscript></entry> @@ -2164,11 +2048,7 @@ <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> <entry>0x200f</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -2190,11 +2070,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -2216,11 +2092,7 @@ <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> <entry>0x2010</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>v<subscript>7</subscript></entry> <entry>v<subscript>6</subscript></entry> <entry>v<subscript>5</subscript></entry> @@ -2242,11 +2114,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>u<subscript>7</subscript></entry> <entry>u<subscript>6</subscript></entry> <entry>u<subscript>5</subscript></entry> @@ -2268,11 +2136,7 @@ <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> <entry>0x2011</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2294,11 +2158,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2320,11 +2180,7 @@ <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> <entry>0x2012</entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2346,11 +2202,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2372,10 +2224,7 @@ <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry> <entry>0x2014</entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2397,10 +2246,7 @@ <entry></entry> <entry></entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2422,10 +2268,7 @@ <entry></entry> <entry></entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2447,10 +2290,7 @@ <entry></entry> <entry></entry> <entry></entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> - <entry>-</entry> + &dash-ent-16; <entry>y<subscript>7</subscript></entry> <entry>y<subscript>6</subscript></entry> <entry>y<subscript>5</subscript></entry> @@ -2472,7 +2312,7 @@ <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> <entry>0x200d</entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2498,7 +2338,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2524,7 +2364,7 @@ <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry> <entry>0x200e</entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2550,7 +2390,7 @@ <entry></entry> <entry></entry> <entry></entry> - &dash-ent-10; + &dash-ent-12; <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2576,6 +2416,8 @@ <entry>V4L2_MBUS_FMT_YUV10_1X30</entry> <entry>0x2016</entry> <entry></entry> + <entry>-</entry> + <entry>-</entry> <entry>y<subscript>9</subscript></entry> <entry>y<subscript>8</subscript></entry> <entry>y<subscript>7</subscript></entry> @@ -2607,6 +2449,43 @@ <entry>v<subscript>1</subscript></entry> <entry>v<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-AYUV8-1X32"> + <entry>V4L2_MBUS_FMT_AYUV8_1X32</entry> + <entry>0x2017</entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 6a8b715..07e7eea 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -22,8 +22,14 @@ <!-- LinuxTV v4l-dvb repository. --> <!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> +<!ENTITY dash-ent-8 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> <!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> +<!ENTITY dash-ent-12 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> +<!ENTITY dash-ent-14 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> <!ENTITY dash-ent-16 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> +<!ENTITY dash-ent-20 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> +<!ENTITY dash-ent-22 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> +<!ENTITY dash-ent-24 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> ]> <book id="media_api"> diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h index 6ee63d0..a960125 100644 --- a/include/uapi/linux/v4l2-mediabus.h +++ b/include/uapi/linux/v4l2-mediabus.h @@ -37,7 +37,7 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_FIXED = 0x0001, - /* RGB - next is 0x100d */ + /* RGB - next is 0x100e */ V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001, V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002, V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003, @@ -50,8 +50,9 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_RGB888_1X24 = 0x100a, V4L2_MBUS_FMT_RGB888_2X12_BE = 0x100b, V4L2_MBUS_FMT_RGB888_2X12_LE = 0x100c, + V4L2_MBUS_FMT_ARGB8888_1X32 = 0x100d, - /* YUV (including grey) - next is 0x2017 */ + /* YUV (including grey) - next is 0x2018 */ V4L2_MBUS_FMT_Y8_1X8 = 0x2001, V4L2_MBUS_FMT_UV8_1X8 = 0x2015, V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, @@ -74,6 +75,7 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, V4L2_MBUS_FMT_YUV10_1X30 = 0x2016, + V4L2_MBUS_FMT_AYUV8_1X32 = 0x2017, /* Bayer - next is 0x3019 */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v6 07/10] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart ` (5 preceding siblings ...) 2013-08-05 17:53 ` [PATCH v6 06/10] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 09/10] vsp1: Fix lack of the sink entity registration for enabled links Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 10/10] vsp1: Use the maximum number of entities defined in platform data Laurent Pinchart 8 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki NV16M and NV61M are planar YCbCr 4:2:2 and YCrCb 4:2:2 formats with a luma plane followed by an interleaved chroma plane. The planes are not required to be contiguous in memory, and the formats can only be used with the multi-planar formats API. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> --- Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 171 +++++++++++++++++++++++ Documentation/DocBook/media/v4l/pixfmt.xml | 1 + include/uapi/linux/videodev2.h | 2 + 3 files changed, 174 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml new file mode 100644 index 0000000..c51d5a4 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml @@ -0,0 +1,171 @@ + <refentry> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M ('NM61')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-NV16M"><constant>V4L2_PIX_FMT_NV16M</constant></refname> + <refname id="V4L2-PIX-FMT-NV61M"><constant>V4L2_PIX_FMT_NV61M</constant></refname> + <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV16</constant> and <constant>V4L2_PIX_FMT_NV61</constant> with planes + non contiguous in memory. </refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format. +The three components are separated into two sub-images or planes. +<constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16 +</constant> in that the two planes are non-contiguous in memory, i.e. the chroma +plane does not necessarily immediately follows the luma plane. +The luminance data occupies the first plane. The Y plane has one byte per pixel. +In the second plane there is chrominance data with alternating chroma samples. +The CbCr plane is the same width and height, in bytes, as the Y plane. +Each CbCr pair belongs to four pixels. For example, +Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to +Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, +Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. +<constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant> +except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> + + <para><constant>V4L2_PIX_FMT_NV16M</constant> and +<constant>V4L2_PIX_FMT_NV61M</constant> are intended to be used only in drivers +and applications that support the multi-planar API, described in +<xref linkend="planar-apis"/>. </para> + + <example> + <title><constant>V4L2_PIX_FMT_NV16M</constant> 4 × 4 pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start0 + 0:</entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + </row> + <row> + <entry>start0 + 4:</entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + </row> + <row> + <entry>start0 + 8:</entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + </row> + <row> + <entry>start0 + 12:</entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Y'<subscript>33</subscript></entry> + </row> + <row> + <entry></entry> + </row> + <row> + <entry>start1 + 0:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cb<subscript>02</subscript></entry> + <entry>Cr<subscript>02</subscript></entry> + </row> + <row> + <entry>start1 + 4:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cb<subscript>12</subscript></entry> + <entry>Cr<subscript>12</subscript></entry> + </row> + <row> + <entry>start1 + 8:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cb<subscript>22</subscript></entry> + <entry>Cr<subscript>22</subscript></entry> + </row> + <row> + <entry>start1 + 12:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cb<subscript>32</subscript></entry> + <entry>Cr<subscript>32</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + + <formalpara> + <title>Color Sample Location.</title> + <para> + <informaltable frame="none"> + <tgroup cols="7" align="center"> + <tbody valign="top"> + <row> + <entry></entry> + <entry>0</entry><entry></entry><entry>1</entry><entry></entry> + <entry>2</entry><entry></entry><entry>3</entry> + </row> + <row> + <entry>0</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry></entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 99b8d2a..16db350 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -718,6 +718,7 @@ information.</para> &sub-nv12m; &sub-nv12mt; &sub-nv16; + &sub-nv16m; &sub-nv24; &sub-m420; </section> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 95ef455..fec0c20 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -348,6 +348,8 @@ struct v4l2_pix_format { /* two non contiguous planes - one Y, one Cr + Cb interleaved */ #define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */ #define V4L2_PIX_FMT_NV21M v4l2_fourcc('N', 'M', '2', '1') /* 21 Y/CrCb 4:2:0 */ +#define V4L2_PIX_FMT_NV16M v4l2_fourcc('N', 'M', '1', '6') /* 16 Y/CbCr 4:2:2 */ +#define V4L2_PIX_FMT_NV61M v4l2_fourcc('N', 'M', '6', '1') /* 16 Y/CrCb 4:2:2 */ #define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 macroblocks */ #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 16x16 macroblocks */ -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v6 09/10] vsp1: Fix lack of the sink entity registration for enabled links 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart ` (6 preceding siblings ...) 2013-08-05 17:53 ` [PATCH v6 07/10] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 10/10] vsp1: Use the maximum number of entities defined in platform data Laurent Pinchart 8 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki From: Katsuya Matsubara <matsu@igel.co.jp> Each source entity maintains a pointer to the counterpart sink entity while an enabled link connects them. It should be managed by the setup_link callback in the media controller framework at runtime. However, enabled links which connect RPFs and WPFs that have an equivalent index number are created during initialization. This registers the pointer to a sink entity from the source entity when an enabled link is created. Signed-off-by: Katsuya Matsubara <matsu@igel.co.jp> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> --- drivers/media/platform/vsp1/vsp1_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index e58e49c..41dd891 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -101,6 +101,9 @@ static int vsp1_create_links(struct vsp1_device *vsp1, struct vsp1_entity *sink) entity, pad, flags); if (ret < 0) return ret; + + if (flags & MEDIA_LNK_FL_ENABLED) + source->sink = entity; } } -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v6 10/10] vsp1: Use the maximum number of entities defined in platform data 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart ` (7 preceding siblings ...) 2013-08-05 17:53 ` [PATCH v6 09/10] vsp1: Fix lack of the sink entity registration for enabled links Laurent Pinchart @ 2013-08-05 17:53 ` Laurent Pinchart 8 siblings, 0 replies; 21+ messages in thread From: Laurent Pinchart @ 2013-08-05 17:53 UTC (permalink / raw) To: linux-media Cc: linux-sh, Hans Verkuil, Sakari Ailus, Katsuya MATSUBARA, Sylwester Nawrocki From: Katsuya Matsubara <matsu@igel.co.jp> The VSP1 driver allows to define the maximum number of each module such as RPF, WPF, and UDS in a platform data definition. This suppresses operations for nonexistent or unused modules. Signed-off-by: Katsuya Matsubara <matsu@igel.co.jp> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> --- drivers/media/platform/vsp1/vsp1_drv.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index 41dd891..8700842 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -35,7 +35,7 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data) irqreturn_t ret = IRQ_NONE; unsigned int i; - for (i = 0; i < VPS1_MAX_WPF; ++i) { + for (i = 0; i < vsp1->pdata->wpf_count; ++i) { struct vsp1_rwpf *wpf = vsp1->wpf[i]; struct vsp1_pipeline *pipe; u32 status; @@ -243,7 +243,7 @@ static int vsp1_device_init(struct vsp1_device *vsp1) /* Reset any channel that might be running. */ status = vsp1_read(vsp1, VI6_STATUS); - for (i = 0; i < VPS1_MAX_WPF; ++i) { + for (i = 0; i < vsp1->pdata->wpf_count; ++i) { unsigned int timeout; if (!(status & VI6_STATUS_SYS_ACT(i))) @@ -267,10 +267,10 @@ static int vsp1_device_init(struct vsp1_device *vsp1) vsp1_write(vsp1, VI6_CLK_DCSWT, (8 << VI6_CLK_DCSWT_CSTPW_SHIFT) | (8 << VI6_CLK_DCSWT_CSTRW_SHIFT)); - for (i = 0; i < VPS1_MAX_RPF; ++i) + for (i = 0; i < vsp1->pdata->rpf_count; ++i) vsp1_write(vsp1, VI6_DPR_RPF_ROUTE(i), VI6_DPR_NODE_UNUSED); - for (i = 0; i < VPS1_MAX_UDS; ++i) + for (i = 0; i < vsp1->pdata->uds_count; ++i) vsp1_write(vsp1, VI6_DPR_UDS_ROUTE(i), VI6_DPR_NODE_UNUSED); vsp1_write(vsp1, VI6_DPR_SRU_ROUTE, VI6_DPR_NODE_UNUSED); -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 21+ messages in thread
end of thread, other threads:[~2014-07-02 7:56 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-08-05 17:53 [PATCH v6 00/10] Renesas VSP1 driver Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 01/10] media: Add support for circular graph traversal Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 02/10] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements Laurent Pinchart 2013-08-06 10:36 ` Hans Verkuil 2013-08-05 17:53 ` [PATCH v6 03/10] media: vb2: Clarify queue_setup() and buf_prepare() usage documentation Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap() Laurent Pinchart 2013-08-06 10:39 ` Hans Verkuil 2013-08-06 20:09 ` Laurent Pinchart 2013-08-06 20:10 ` [PATCH v7] media: vb2: Take queue or device lock in mmap-related vb2 ioctl handlers Laurent Pinchart 2013-08-07 6:30 ` Hans Verkuil 2014-05-23 13:54 ` Hans Verkuil 2014-05-26 22:38 ` Laurent Pinchart 2014-06-25 16:58 ` Sasha Levin 2014-07-01 21:08 ` Laurent Pinchart 2014-07-02 6:33 ` Hans Verkuil 2014-07-02 7:56 ` Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 05/10] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 06/10] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 07/10] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 09/10] vsp1: Fix lack of the sink entity registration for enabled links Laurent Pinchart 2013-08-05 17:53 ` [PATCH v6 10/10] vsp1: Use the maximum number of entities defined in platform data Laurent Pinchart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).