* [PATCHv15 01/35] uapi/linux/media.h: add request API
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-07-03 9:21 ` Mauro Carvalho Chehab
2018-06-04 11:46 ` [PATCHv15 02/35] media-request: implement media requests Hans Verkuil
` (33 subsequent siblings)
34 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Define the public request API.
This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
and two ioctls that operate on a request in order to queue the
contents of the request to the driver and to re-initialize the
request.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
include/uapi/linux/media.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index c7e9a5cba24e..0f0117742fa7 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -342,11 +342,23 @@ struct media_v2_topology {
/* ioctls */
+struct __attribute__ ((packed)) media_request_alloc {
+ __s32 fd;
+};
+
#define MEDIA_IOC_DEVICE_INFO _IOWR('|', 0x00, struct media_device_info)
#define MEDIA_IOC_ENUM_ENTITIES _IOWR('|', 0x01, struct media_entity_desc)
#define MEDIA_IOC_ENUM_LINKS _IOWR('|', 0x02, struct media_links_enum)
#define MEDIA_IOC_SETUP_LINK _IOWR('|', 0x03, struct media_link_desc)
#define MEDIA_IOC_G_TOPOLOGY _IOWR('|', 0x04, struct media_v2_topology)
+#define MEDIA_IOC_REQUEST_ALLOC _IOWR('|', 0x05, struct media_request_alloc)
+
+/*
+ * These ioctls are called on the request file descriptor as returned
+ * by MEDIA_IOC_REQUEST_ALLOC.
+ */
+#define MEDIA_REQUEST_IOC_QUEUE _IO('|', 0x80)
+#define MEDIA_REQUEST_IOC_REINIT _IO('|', 0x81)
#if !defined(__KERNEL__) || defined(__NEED_MEDIA_LEGACY_API)
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 01/35] uapi/linux/media.h: add request API
2018-06-04 11:46 ` [PATCHv15 01/35] uapi/linux/media.h: add request API Hans Verkuil
@ 2018-07-03 9:21 ` Mauro Carvalho Chehab
2018-07-03 9:33 ` Hans Verkuil
0 siblings, 1 reply; 61+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-03 9:21 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Hans Verkuil
Em Mon, 4 Jun 2018 13:46:14 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Define the public request API.
>
> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
> and two ioctls that operate on a request in order to queue the
> contents of the request to the driver and to re-initialize the
> request.
It would be better if you had added the documentation stuff here...
I can't review this patch without first reviewing the documentation
for the new ioctls...
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> include/uapi/linux/media.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
> index c7e9a5cba24e..0f0117742fa7 100644
> --- a/include/uapi/linux/media.h
> +++ b/include/uapi/linux/media.h
> @@ -342,11 +342,23 @@ struct media_v2_topology {
>
> /* ioctls */
>
> +struct __attribute__ ((packed)) media_request_alloc {
> + __s32 fd;
> +};
> +
> #define MEDIA_IOC_DEVICE_INFO _IOWR('|', 0x00, struct media_device_info)
> #define MEDIA_IOC_ENUM_ENTITIES _IOWR('|', 0x01, struct media_entity_desc)
> #define MEDIA_IOC_ENUM_LINKS _IOWR('|', 0x02, struct media_links_enum)
> #define MEDIA_IOC_SETUP_LINK _IOWR('|', 0x03, struct media_link_desc)
> #define MEDIA_IOC_G_TOPOLOGY _IOWR('|', 0x04, struct media_v2_topology)
> +#define MEDIA_IOC_REQUEST_ALLOC _IOWR('|', 0x05, struct media_request_alloc)
> +
> +/*
> + * These ioctls are called on the request file descriptor as returned
> + * by MEDIA_IOC_REQUEST_ALLOC.
> + */
> +#define MEDIA_REQUEST_IOC_QUEUE _IO('|', 0x80)
> +#define MEDIA_REQUEST_IOC_REINIT _IO('|', 0x81)
>
> #if !defined(__KERNEL__) || defined(__NEED_MEDIA_LEGACY_API)
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 01/35] uapi/linux/media.h: add request API
2018-07-03 9:21 ` Mauro Carvalho Chehab
@ 2018-07-03 9:33 ` Hans Verkuil
2018-07-03 10:04 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-07-03 9:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media, Hans Verkuil
On 03/07/18 11:21, Mauro Carvalho Chehab wrote:
> Em Mon, 4 Jun 2018 13:46:14 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> Define the public request API.
>>
>> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
>> and two ioctls that operate on a request in order to queue the
>> contents of the request to the driver and to re-initialize the
>> request.
>
> It would be better if you had added the documentation stuff here...
> I can't review this patch without first reviewing the documentation
> for the new ioctls...
I moved patch 29 to the front for the next version.
Regards,
Hans
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCHv15 01/35] uapi/linux/media.h: add request API
2018-07-03 9:33 ` Hans Verkuil
@ 2018-07-03 10:04 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 61+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-03 10:04 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Hans Verkuil
Em Tue, 3 Jul 2018 11:33:13 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 03/07/18 11:21, Mauro Carvalho Chehab wrote:
> > Em Mon, 4 Jun 2018 13:46:14 +0200
> > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >
> >> From: Hans Verkuil <hans.verkuil@cisco.com>
> >>
> >> Define the public request API.
> >>
> >> This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request
> >> and two ioctls that operate on a request in order to queue the
> >> contents of the request to the driver and to re-initialize the
> >> request.
> >
> > It would be better if you had added the documentation stuff here...
> > I can't review this patch without first reviewing the documentation
> > for the new ioctls...
>
> I moved patch 29 to the front for the next version.
Thanks! Be sure to move other documentation patches to be together
with the respective code changes. Reviewing a /35 patch series
is hard enough even without needing to review stuff on some
random order.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 02/35] media-request: implement media requests
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 01/35] uapi/linux/media.h: add request API Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-15 7:08 ` Hans Verkuil
2018-07-02 10:56 ` Tomasz Figa
2018-06-04 11:46 ` [PATCHv15 03/35] media: doc: Add media-request.h header to documentation build Hans Verkuil
` (32 subsequent siblings)
34 siblings, 2 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil, Sakari Ailus
From: Hans Verkuil <hans.verkuil@cisco.com>
Add initial media request support:
1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c
2) Add struct media_request to store request objects.
3) Add struct media_request_object to represent a request object.
4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support.
Basic lifecycle: the application allocates a request, adds
objects to it, queues the request, polls until it is completed
and can then read the final values of the objects at the time
of completion. When it closes the file descriptor the request
memory will be freed (actually, when the last user of that request
releases the request).
Drivers will bind an object to a request (the 'adds objects to it'
phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is
validated (req_validate op), then queued (the req_queue op).
When done with an object it can either be unbound from the request
(e.g. when the driver has finished with a vb2 buffer) or marked as
completed (e.g. for controls associated with a buffer). When all
objects in the request are completed (or unbound), then the request
fd will signal an exception (poll).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
---
drivers/media/Makefile | 3 +-
drivers/media/media-device.c | 14 ++
drivers/media/media-request.c | 421 ++++++++++++++++++++++++++++++++++
include/media/media-device.h | 24 ++
include/media/media-request.h | 326 ++++++++++++++++++++++++++
5 files changed, 787 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/media-request.c
create mode 100644 include/media/media-request.h
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 594b462ddf0e..985d35ec6b29 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -3,7 +3,8 @@
# Makefile for the kernel multimedia device drivers.
#
-media-objs := media-device.o media-devnode.o media-entity.o
+media-objs := media-device.o media-devnode.o media-entity.o \
+ media-request.o
#
# I2C drivers should come before other drivers, otherwise they'll fail
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index ae59c3177555..1119c1058e73 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -32,6 +32,7 @@
#include <media/media-device.h>
#include <media/media-devnode.h>
#include <media/media-entity.h>
+#include <media/media-request.h>
#ifdef CONFIG_MEDIA_CONTROLLER
@@ -367,6 +368,15 @@ static long media_device_get_topology(struct media_device *mdev, void *arg)
return ret;
}
+static long media_device_request_alloc(struct media_device *mdev,
+ struct media_request_alloc *alloc)
+{
+ if (!mdev->ops || !mdev->ops->req_validate || !mdev->ops->req_queue)
+ return -ENOTTY;
+
+ return media_request_alloc(mdev, alloc);
+}
+
static long copy_arg_from_user(void *karg, void __user *uarg, unsigned int cmd)
{
/* All media IOCTLs are _IOWR() */
@@ -415,6 +425,7 @@ static const struct media_ioctl_info ioctl_info[] = {
MEDIA_IOC(ENUM_LINKS, media_device_enum_links, MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(SETUP_LINK, media_device_setup_link, MEDIA_IOC_FL_GRAPH_MUTEX),
MEDIA_IOC(G_TOPOLOGY, media_device_get_topology, MEDIA_IOC_FL_GRAPH_MUTEX),
+ MEDIA_IOC(REQUEST_ALLOC, media_device_request_alloc, 0),
};
static long media_device_ioctl(struct file *filp, unsigned int cmd,
@@ -687,6 +698,8 @@ void media_device_init(struct media_device *mdev)
INIT_LIST_HEAD(&mdev->pads);
INIT_LIST_HEAD(&mdev->links);
INIT_LIST_HEAD(&mdev->entity_notify);
+
+ mutex_init(&mdev->req_queue_mutex);
mutex_init(&mdev->graph_mutex);
ida_init(&mdev->entity_internal_idx);
@@ -700,6 +713,7 @@ void media_device_cleanup(struct media_device *mdev)
mdev->entity_internal_idx_max = 0;
media_graph_walk_cleanup(&mdev->pm_count_walk);
mutex_destroy(&mdev->graph_mutex);
+ mutex_destroy(&mdev->req_queue_mutex);
}
EXPORT_SYMBOL_GPL(media_device_cleanup);
diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
new file mode 100644
index 000000000000..09823235e4c8
--- /dev/null
+++ b/drivers/media/media-request.c
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Media device request objects
+ *
+ * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights reserved.
+ * Copyright (C) 2018 Intel Corporation
+ * Copyright (C) 2018 Google, Inc.
+ *
+ * Author: Hans Verkuil <hans.verkuil@cisco.com>
+ * Author: Sakari Ailus <sakari.ailus@linux.intel.com>
+ */
+
+#include <linux/anon_inodes.h>
+#include <linux/file.h>
+#include <linux/refcount.h>
+
+#include <media/media-device.h>
+#include <media/media-request.h>
+
+static const char * const request_state[] = {
+ [MEDIA_REQUEST_STATE_IDLE] = "idle",
+ [MEDIA_REQUEST_STATE_VALIDATING] = "validating",
+ [MEDIA_REQUEST_STATE_QUEUED] = "queued",
+ [MEDIA_REQUEST_STATE_COMPLETE] = "complete",
+ [MEDIA_REQUEST_STATE_CLEANING] = "cleaning",
+ [MEDIA_REQUEST_STATE_UPDATING] = "updating",
+};
+
+static const char *
+media_request_state_str(enum media_request_state state)
+{
+ BUILD_BUG_ON(ARRAY_SIZE(request_state) != NR_OF_MEDIA_REQUEST_STATE);
+
+ if (WARN_ON(state >= ARRAY_SIZE(request_state)))
+ return "invalid";
+ return request_state[state];
+}
+
+static void media_request_clean(struct media_request *req)
+{
+ struct media_request_object *obj, *obj_safe;
+
+ /* Just a sanity check. No other code path is allowed to change this. */
+ WARN_ON(req->state != MEDIA_REQUEST_STATE_CLEANING);
+ WARN_ON(refcount_read(&req->updating_count));
+
+ list_for_each_entry_safe(obj, obj_safe, &req->objects, list) {
+ media_request_object_unbind(obj);
+ media_request_object_put(obj);
+ }
+
+ refcount_set(&req->updating_count, 0);
+ WARN_ON(req->num_incomplete_objects);
+ req->num_incomplete_objects = 0;
+ wake_up_interruptible_all(&req->poll_wait);
+}
+
+static void media_request_release(struct kref *kref)
+{
+ struct media_request *req =
+ container_of(kref, struct media_request, kref);
+ struct media_device *mdev = req->mdev;
+
+ dev_dbg(mdev->dev, "request: release %s\n", req->debug_str);
+
+ /* No other users, no need for a spinlock */
+ req->state = MEDIA_REQUEST_STATE_CLEANING;
+
+ media_request_clean(req);
+
+ if (mdev->ops->req_free)
+ mdev->ops->req_free(req);
+ else
+ kfree(req);
+}
+
+void media_request_put(struct media_request *req)
+{
+ kref_put(&req->kref, media_request_release);
+}
+EXPORT_SYMBOL_GPL(media_request_put);
+
+static int media_request_close(struct inode *inode, struct file *filp)
+{
+ struct media_request *req = filp->private_data;
+
+ media_request_put(req);
+ return 0;
+}
+
+static unsigned int media_request_poll(struct file *filp,
+ struct poll_table_struct *wait)
+{
+ struct media_request *req = filp->private_data;
+ unsigned long flags;
+ unsigned int ret = 0;
+
+ if (!(poll_requested_events(wait) & POLLPRI))
+ return 0;
+
+ spin_lock_irqsave(&req->lock, flags);
+ if (req->state == MEDIA_REQUEST_STATE_COMPLETE) {
+ ret = POLLPRI;
+ goto unlock;
+ }
+ if (req->state != MEDIA_REQUEST_STATE_QUEUED) {
+ ret = POLLERR;
+ goto unlock;
+ }
+
+ poll_wait(filp, &req->poll_wait, wait);
+
+unlock:
+ spin_unlock_irqrestore(&req->lock, flags);
+ return ret;
+}
+
+static long media_request_ioctl_queue(struct media_request *req)
+{
+ struct media_device *mdev = req->mdev;
+ enum media_request_state state;
+ unsigned long flags;
+ int ret;
+
+ dev_dbg(mdev->dev, "request: queue %s\n", req->debug_str);
+
+ /*
+ * Ensure the request that is validated will be the one that gets queued
+ * next by serialising the queueing process. This mutex is also used
+ * to serialize with canceling a vb2 queue and with setting values such
+ * as controls in a request.
+ */
+ mutex_lock(&mdev->req_queue_mutex);
+
+ spin_lock_irqsave(&req->lock, flags);
+ if (req->state == MEDIA_REQUEST_STATE_IDLE)
+ req->state = MEDIA_REQUEST_STATE_VALIDATING;
+ state = req->state;
+ spin_unlock_irqrestore(&req->lock, flags);
+ if (state != MEDIA_REQUEST_STATE_VALIDATING) {
+ dev_dbg(mdev->dev,
+ "request: unable to queue %s, request in state %s\n",
+ req->debug_str, media_request_state_str(state));
+ mutex_unlock(&mdev->req_queue_mutex);
+ return -EBUSY;
+ }
+
+ ret = mdev->ops->req_validate(req);
+
+ /*
+ * If the req_validate was successful, then we mark the state as QUEUED
+ * and call req_queue. The reason we set the state first is that this
+ * allows req_queue to unbind or complete the queued objects in case
+ * they are immediately 'consumed'. State changes from QUEUED to another
+ * state can only happen if either the driver changes the state or if
+ * the user cancels the vb2 queue. The driver can only change the state
+ * after each object is queued through the req_queue op (and note that
+ * that op cannot fail), so setting the state to QUEUED up front is
+ * safe.
+ *
+ * The other reason for changing the state is if the vb2 queue is
+ * canceled, and that uses the req_queue_mutex which is still locked
+ * while req_queue is called, so that's safe as well.
+ */
+ spin_lock_irqsave(&req->lock, flags);
+ req->state = ret ? MEDIA_REQUEST_STATE_IDLE
+ : MEDIA_REQUEST_STATE_QUEUED;
+ spin_unlock_irqrestore(&req->lock, flags);
+
+ if (!ret)
+ mdev->ops->req_queue(req);
+
+ mutex_unlock(&mdev->req_queue_mutex);
+
+ if (ret)
+ dev_dbg(mdev->dev, "request: can't queue %s (%d)\n",
+ req->debug_str, ret);
+ else
+ media_request_get(req);
+
+ return ret;
+}
+
+static long media_request_ioctl_reinit(struct media_request *req)
+{
+ struct media_device *mdev = req->mdev;
+ unsigned long flags;
+
+ spin_lock_irqsave(&req->lock, flags);
+ if (req->state != MEDIA_REQUEST_STATE_IDLE &&
+ req->state != MEDIA_REQUEST_STATE_COMPLETE) {
+ dev_dbg(mdev->dev,
+ "request: %s not in idle or complete state, cannot reinit\n",
+ req->debug_str);
+ spin_unlock_irqrestore(&req->lock, flags);
+ return -EBUSY;
+ }
+ req->state = MEDIA_REQUEST_STATE_CLEANING;
+ spin_unlock_irqrestore(&req->lock, flags);
+
+ media_request_clean(req);
+
+ spin_lock_irqsave(&req->lock, flags);
+ req->state = MEDIA_REQUEST_STATE_IDLE;
+ spin_unlock_irqrestore(&req->lock, flags);
+
+ return 0;
+}
+
+static long media_request_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
+{
+ struct media_request *req = filp->private_data;
+
+ switch (cmd) {
+ case MEDIA_REQUEST_IOC_QUEUE:
+ return media_request_ioctl_queue(req);
+ case MEDIA_REQUEST_IOC_REINIT:
+ return media_request_ioctl_reinit(req);
+ default:
+ return -ENOIOCTLCMD;
+ }
+}
+
+static const struct file_operations request_fops = {
+ .owner = THIS_MODULE,
+ .poll = media_request_poll,
+ .unlocked_ioctl = media_request_ioctl,
+ .release = media_request_close,
+};
+
+int media_request_alloc(struct media_device *mdev,
+ struct media_request_alloc *alloc)
+{
+ struct media_request *req;
+ struct file *filp;
+ char comm[TASK_COMM_LEN];
+ int fd;
+ int ret;
+
+ /* Either both are NULL or both are non-NULL */
+ if (WARN_ON(!mdev->ops->req_alloc ^ !mdev->ops->req_free))
+ return -ENOMEM;
+
+ fd = get_unused_fd_flags(O_CLOEXEC);
+ if (fd < 0)
+ return fd;
+
+ filp = anon_inode_getfile("request", &request_fops, NULL, O_CLOEXEC);
+ if (IS_ERR(filp)) {
+ ret = PTR_ERR(filp);
+ goto err_put_fd;
+ }
+
+ if (mdev->ops->req_alloc)
+ req = mdev->ops->req_alloc(mdev);
+ else
+ req = kzalloc(sizeof(*req), GFP_KERNEL);
+ if (!req) {
+ ret = -ENOMEM;
+ goto err_fput;
+ }
+
+ filp->private_data = req;
+ req->mdev = mdev;
+ req->state = MEDIA_REQUEST_STATE_IDLE;
+ req->num_incomplete_objects = 0;
+ kref_init(&req->kref);
+ INIT_LIST_HEAD(&req->objects);
+ spin_lock_init(&req->lock);
+ init_waitqueue_head(&req->poll_wait);
+ refcount_set(&req->updating_count, 0);
+
+ alloc->fd = fd;
+
+ get_task_comm(comm, current);
+ snprintf(req->debug_str, sizeof(req->debug_str), "%s:%d",
+ comm, fd);
+ dev_dbg(mdev->dev, "request: allocated %s\n", req->debug_str);
+
+ fd_install(fd, filp);
+
+ return 0;
+
+err_fput:
+ fput(filp);
+
+err_put_fd:
+ put_unused_fd(fd);
+
+ return ret;
+}
+
+static void media_request_object_release(struct kref *kref)
+{
+ struct media_request_object *obj =
+ container_of(kref, struct media_request_object, kref);
+ struct media_request *req = obj->req;
+
+ if (req)
+ media_request_object_unbind(obj);
+ obj->ops->release(obj);
+}
+
+void media_request_object_put(struct media_request_object *obj)
+{
+ kref_put(&obj->kref, media_request_object_release);
+}
+EXPORT_SYMBOL_GPL(media_request_object_put);
+
+void media_request_object_init(struct media_request_object *obj)
+{
+ obj->ops = NULL;
+ obj->req = NULL;
+ obj->priv = NULL;
+ obj->completed = false;
+ INIT_LIST_HEAD(&obj->list);
+ kref_init(&obj->kref);
+}
+EXPORT_SYMBOL_GPL(media_request_object_init);
+
+int media_request_object_bind(struct media_request *req,
+ const struct media_request_object_ops *ops,
+ void *priv,
+ struct media_request_object *obj)
+{
+ unsigned long flags;
+ int ret = -EBUSY;
+
+ if (WARN_ON(!ops->release))
+ return -EPERM;
+
+ spin_lock_irqsave(&req->lock, flags);
+
+ if (WARN_ON(req->state != MEDIA_REQUEST_STATE_UPDATING))
+ goto unlock;
+
+ obj->req = req;
+ obj->ops = ops;
+ obj->priv = priv;
+
+ list_add_tail(&obj->list, &req->objects);
+ req->num_incomplete_objects++;
+ ret = 0;
+
+unlock:
+ spin_unlock_irqrestore(&req->lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(media_request_object_bind);
+
+void media_request_object_unbind(struct media_request_object *obj)
+{
+ struct media_request *req = obj->req;
+ unsigned long flags;
+ bool completed = false;
+
+ if (WARN_ON(!req))
+ return;
+
+ spin_lock_irqsave(&req->lock, flags);
+ list_del(&obj->list);
+ obj->req = NULL;
+
+ if (req->state == MEDIA_REQUEST_STATE_COMPLETE)
+ goto unlock;
+
+ if (WARN_ON(req->state == MEDIA_REQUEST_STATE_VALIDATING))
+ goto unlock;
+
+ if (req->state == MEDIA_REQUEST_STATE_CLEANING) {
+ if (!obj->completed)
+ req->num_incomplete_objects--;
+ goto unlock;
+ }
+
+ if (WARN_ON(!req->num_incomplete_objects))
+ goto unlock;
+
+ req->num_incomplete_objects--;
+ if (req->state == MEDIA_REQUEST_STATE_QUEUED &&
+ !req->num_incomplete_objects) {
+ req->state = MEDIA_REQUEST_STATE_COMPLETE;
+ completed = true;
+ wake_up_interruptible_all(&req->poll_wait);
+ }
+
+unlock:
+ spin_unlock_irqrestore(&req->lock, flags);
+ if (obj->ops->unbind)
+ obj->ops->unbind(obj);
+ if (completed)
+ media_request_put(req);
+}
+EXPORT_SYMBOL_GPL(media_request_object_unbind);
+
+void media_request_object_complete(struct media_request_object *obj)
+{
+ struct media_request *req = obj->req;
+ unsigned long flags;
+ bool completed = false;
+
+ spin_lock_irqsave(&req->lock, flags);
+ if (obj->completed)
+ goto unlock;
+ obj->completed = true;
+ if (WARN_ON(!req->num_incomplete_objects) ||
+ WARN_ON(req->state != MEDIA_REQUEST_STATE_QUEUED))
+ goto unlock;
+
+ if (!--req->num_incomplete_objects) {
+ req->state = MEDIA_REQUEST_STATE_COMPLETE;
+ wake_up_interruptible_all(&req->poll_wait);
+ completed = true;
+ }
+unlock:
+ spin_unlock_irqrestore(&req->lock, flags);
+ if (completed)
+ media_request_put(req);
+}
+EXPORT_SYMBOL_GPL(media_request_object_complete);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index bcc6ec434f1f..cf52a74bada9 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -27,6 +27,7 @@
struct ida;
struct device;
+struct media_device;
/**
* struct media_entity_notify - Media Entity Notify
@@ -50,10 +51,26 @@ struct media_entity_notify {
* struct media_device_ops - Media device operations
* @link_notify: Link state change notification callback. This callback is
* called with the graph_mutex held.
+ * @req_alloc: Allocate a request. Set this if you need to allocate a struct
+ * larger then struct media_request. @req_alloc and @req_free must
+ * either both be set or both be NULL.
+ * @req_free: Free a request. Set this if @req_alloc was set as well, leave
+ * to NULL otherwise.
+ * @req_validate: Validate a request, but do not queue yet. The req_queue_mutex
+ * lock is held when this op is called.
+ * @req_queue: Queue a validated request, cannot fail. If something goes
+ * wrong when queueing this request then it should be marked
+ * as such internally in the driver and any related buffers
+ * must eventually return to vb2 with state VB2_BUF_STATE_ERROR.
+ * The req_queue_mutex lock is held when this op is called.
*/
struct media_device_ops {
int (*link_notify)(struct media_link *link, u32 flags,
unsigned int notification);
+ struct media_request *(*req_alloc)(struct media_device *mdev);
+ void (*req_free)(struct media_request *req);
+ int (*req_validate)(struct media_request *req);
+ void (*req_queue)(struct media_request *req);
};
/**
@@ -87,7 +104,12 @@ struct media_device_ops {
* @enable_source: Enable Source Handler function pointer
* @disable_source: Disable Source Handler function pointer
*
+ * @req_queue_mutex: Serialise validating and queueing requests in order to
+ * guarantee exclusive access to the state of the device on
+ * the tip of the request queue.
* @ops: Operation handler callbacks
+ * @req_queue_mutex: Serialise the MEDIA_REQUEST_IOC_QUEUE ioctl w.r.t.
+ * other operations that stop or start streaming.
*
* This structure represents an abstract high-level media device. It allows easy
* access to entities and provides basic media device-level support. The
@@ -158,6 +180,8 @@ struct media_device {
void (*disable_source)(struct media_entity *entity);
const struct media_device_ops *ops;
+
+ struct mutex req_queue_mutex;
};
/* We don't need to include pci.h or usb.h here */
diff --git a/include/media/media-request.h b/include/media/media-request.h
new file mode 100644
index 000000000000..8acd2627835c
--- /dev/null
+++ b/include/media/media-request.h
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Media device request objects
+ *
+ * Copyright 2018 Cisco Systems, Inc. and/or its affiliates. All rights reserved.
+ * Copyright (C) 2018 Intel Corporation
+ *
+ * Author: Hans Verkuil <hans.verkuil@cisco.com>
+ * Author: Sakari Ailus <sakari.ailus@linux.intel.com>
+ */
+
+#ifndef MEDIA_REQUEST_H
+#define MEDIA_REQUEST_H
+
+#include <linux/list.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/refcount.h>
+
+#include <media/media-device.h>
+
+/**
+ * enum media_request_state - media request state
+ *
+ * @MEDIA_REQUEST_STATE_IDLE: Idle
+ * @MEDIA_REQUEST_STATE_VALIDATING: Validating the request, no state changes
+ * allowed
+ * @MEDIA_REQUEST_STATE_QUEUED: Queued
+ * @MEDIA_REQUEST_STATE_COMPLETE: Completed, the request is done
+ * @MEDIA_REQUEST_STATE_CLEANING: Cleaning, the request is being re-inited
+ * @MEDIA_REQUEST_STATE_UPDATING: The request is being updated, i.e.
+ * request objects are being added,
+ * modified or removed
+ * @NR_OF_MEDIA_REQUEST_STATE: The number of media request states, used
+ * internally for sanity check purposes
+ */
+enum media_request_state {
+ MEDIA_REQUEST_STATE_IDLE,
+ MEDIA_REQUEST_STATE_VALIDATING,
+ MEDIA_REQUEST_STATE_QUEUED,
+ MEDIA_REQUEST_STATE_COMPLETE,
+ MEDIA_REQUEST_STATE_CLEANING,
+ MEDIA_REQUEST_STATE_UPDATING,
+ NR_OF_MEDIA_REQUEST_STATE,
+};
+
+struct media_request_object;
+
+/**
+ * struct media_request - Media device request
+ * @mdev: Media device this request belongs to
+ * @kref: Reference count
+ * @debug_str: Prefix for debug messages (process name:fd)
+ * @state: The state of the request
+ * @updating_count: count the number of request updates that are in progress
+ * @objects: List of @struct media_request_object request objects
+ * @num_incomplete_objects: The number of incomplete objects in the request
+ * @poll_wait: Wait queue for poll
+ * @lock: Serializes access to this struct
+ */
+struct media_request {
+ struct media_device *mdev;
+ struct kref kref;
+ char debug_str[TASK_COMM_LEN + 11];
+ enum media_request_state state;
+ refcount_t updating_count;
+ struct list_head objects;
+ unsigned int num_incomplete_objects;
+ struct wait_queue_head poll_wait;
+ spinlock_t lock;
+};
+
+#ifdef CONFIG_MEDIA_CONTROLLER
+
+/**
+ * media_request_lock_for_update - Lock the request for updating its objects
+ *
+ * @req: The media request
+ *
+ * Use before updating a request, i.e. adding, modifying or removing a request
+ * object in it. A reference to the request must be held during the update. This
+ * usually takes place automatically through a file handle. Use
+ * @media_request_unlock_for_update when done.
+ */
+static inline int __must_check
+media_request_lock_for_update(struct media_request *req)
+{
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&req->lock, flags);
+ if (req->state == MEDIA_REQUEST_STATE_IDLE ||
+ req->state == MEDIA_REQUEST_STATE_UPDATING) {
+ req->state = MEDIA_REQUEST_STATE_UPDATING;
+ refcount_inc(&req->updating_count);
+ } else {
+ ret = -EBUSY;
+ }
+ spin_unlock_irqrestore(&req->lock, flags);
+
+ return ret;
+}
+
+/**
+ * media_request_unlock_for_update - Unlock a request previously locked for
+ * update
+ *
+ * @req: The media request
+ *
+ * Unlock a request that has previously been locked using
+ * @media_request_lock_for_update.
+ */
+static inline void media_request_unlock_for_update(struct media_request *req)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&req->lock, flags);
+ if (refcount_dec_and_test(&req->updating_count))
+ req->state = MEDIA_REQUEST_STATE_IDLE;
+ spin_unlock_irqrestore(&req->lock, flags);
+}
+
+/**
+ * media_request_get - Get the media request
+ *
+ * @req: The media request
+ *
+ * Get the media request.
+ */
+static inline void media_request_get(struct media_request *req)
+{
+ kref_get(&req->kref);
+}
+
+/**
+ * media_request_put - Put the media request
+ *
+ * @req: The media request
+ *
+ * Put the media request. The media request will be released
+ * when the refcount reaches 0.
+ */
+void media_request_put(struct media_request *req);
+
+/**
+ * media_request_alloc - Allocate the media request
+ *
+ * @mdev: Media device this request belongs to
+ * @alloc: Store the request's file descriptor in this struct
+ *
+ * Allocated the media request and put the fd in @alloc->fd.
+ */
+int media_request_alloc(struct media_device *mdev,
+ struct media_request_alloc *alloc);
+
+#else
+
+static inline void media_request_get(struct media_request *req)
+{
+}
+
+static inline void media_request_put(struct media_request *req)
+{
+}
+
+#endif
+
+/**
+ * struct media_request_object_ops - Media request object operations
+ * @prepare: Validate and prepare the request object, optional.
+ * @unprepare: Unprepare the request object, optional.
+ * @queue: Queue the request object, optional.
+ * @unbind: Unbind the request object, optional.
+ * @release: Release the request object, required.
+ */
+struct media_request_object_ops {
+ int (*prepare)(struct media_request_object *object);
+ void (*unprepare)(struct media_request_object *object);
+ void (*queue)(struct media_request_object *object);
+ void (*unbind)(struct media_request_object *object);
+ void (*release)(struct media_request_object *object);
+};
+
+/**
+ * struct media_request_object - An opaque object that belongs to a media
+ * request
+ *
+ * @ops: object's operations
+ * @priv: object's priv pointer
+ * @req: the request this object belongs to (can be NULL)
+ * @list: List entry of the object for @struct media_request
+ * @kref: Reference count of the object, acquire before releasing req->lock
+ * @completed: If true, then this object was completed.
+ *
+ * An object related to the request. This struct is always embedded in
+ * another struct that contains the actual data for this request object.
+ */
+struct media_request_object {
+ const struct media_request_object_ops *ops;
+ void *priv;
+ struct media_request *req;
+ struct list_head list;
+ struct kref kref;
+ bool completed;
+};
+
+#ifdef CONFIG_MEDIA_CONTROLLER
+
+/**
+ * media_request_object_get - Get a media request object
+ *
+ * @obj: The object
+ *
+ * Get a media request object.
+ */
+static inline void media_request_object_get(struct media_request_object *obj)
+{
+ kref_get(&obj->kref);
+}
+
+/**
+ * media_request_object_put - Put a media request object
+ *
+ * @obj: The object
+ *
+ * Put a media request object. Once all references are gone, the
+ * object's memory is released.
+ */
+void media_request_object_put(struct media_request_object *obj);
+
+/**
+ * media_request_object_init - Initialise a media request object
+ *
+ * @obj: The object
+ *
+ * Initialise a media request object. The object will be released using the
+ * release callback of the ops once it has no references (this function
+ * initialises references to one).
+ */
+void media_request_object_init(struct media_request_object *obj);
+
+/**
+ * media_request_object_bind - Bind a media request object to a request
+ *
+ * @req: The media request
+ * @ops: The object ops for this object
+ * @priv: A driver-specific priv pointer associated with this object
+ * @obj: The object
+ *
+ * Bind this object to the request and set the ops and priv values of
+ * the object so it can be found later with media_request_object_find().
+ *
+ * Every bound object must be unbound or completed by the kernel at some
+ * point in time, otherwise the request will never complete. When the
+ * request is released all completed objects will be unbound by the
+ * request core code.
+ */
+int media_request_object_bind(struct media_request *req,
+ const struct media_request_object_ops *ops,
+ void *priv,
+ struct media_request_object *obj);
+
+/**
+ * media_request_object_unbind - Unbind a media request object
+ *
+ * @obj: The object
+ *
+ * Unbind the media request object from the request.
+ */
+void media_request_object_unbind(struct media_request_object *obj);
+
+/**
+ * media_request_object_complete - Mark the media request object as complete
+ *
+ * @obj: The object
+ *
+ * Mark the media request object as complete. Only bound objects can
+ * be completed.
+ */
+void media_request_object_complete(struct media_request_object *obj);
+
+#else
+
+static inline int __must_check
+media_request_lock_for_update(struct media_request *req)
+{
+ return -EINVAL;
+}
+
+static inline void media_request_unlock_for_update(struct media_request *req)
+{
+}
+
+static inline void media_request_object_get(struct media_request_object *obj)
+{
+}
+
+static inline void media_request_object_put(struct media_request_object *obj)
+{
+}
+
+static inline void media_request_object_init(struct media_request_object *obj)
+{
+ obj->ops = NULL;
+ obj->req = NULL;
+}
+
+static inline int media_request_object_bind(struct media_request *req,
+ const struct media_request_object_ops *ops,
+ void *priv,
+ struct media_request_object *obj)
+{
+ return 0;
+}
+
+static inline void media_request_object_unbind(struct media_request_object *obj)
+{
+}
+
+static inline void media_request_object_complete(struct media_request_object *obj)
+{
+}
+
+#endif
+
+#endif
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 02/35] media-request: implement media requests
2018-06-04 11:46 ` [PATCHv15 02/35] media-request: implement media requests Hans Verkuil
@ 2018-06-15 7:08 ` Hans Verkuil
2018-07-02 8:58 ` Tomasz Figa
2018-07-02 10:56 ` Tomasz Figa
1 sibling, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-15 7:08 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil, Sakari Ailus
On 04/06/18 13:46, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add initial media request support:
>
> 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c
> 2) Add struct media_request to store request objects.
> 3) Add struct media_request_object to represent a request object.
> 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support.
>
> Basic lifecycle: the application allocates a request, adds
> objects to it, queues the request, polls until it is completed
> and can then read the final values of the objects at the time
> of completion. When it closes the file descriptor the request
> memory will be freed (actually, when the last user of that request
> releases the request).
>
> Drivers will bind an object to a request (the 'adds objects to it'
> phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is
> validated (req_validate op), then queued (the req_queue op).
>
> When done with an object it can either be unbound from the request
> (e.g. when the driver has finished with a vb2 buffer) or marked as
> completed (e.g. for controls associated with a buffer). When all
> objects in the request are completed (or unbound), then the request
> fd will signal an exception (poll).
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
> ---
> drivers/media/Makefile | 3 +-
> drivers/media/media-device.c | 14 ++
> drivers/media/media-request.c | 421 ++++++++++++++++++++++++++++++++++
> include/media/media-device.h | 24 ++
> include/media/media-request.h | 326 ++++++++++++++++++++++++++
> 5 files changed, 787 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/media-request.c
> create mode 100644 include/media/media-request.h
>
<snip>
> diff --git a/include/media/media-request.h b/include/media/media-request.h
> new file mode 100644
> index 000000000000..8acd2627835c
> --- /dev/null
> +++ b/include/media/media-request.h
> @@ -0,0 +1,326 @@
<snip>
> +/**
> + * struct media_request - Media device request
> + * @mdev: Media device this request belongs to
> + * @kref: Reference count
> + * @debug_str: Prefix for debug messages (process name:fd)
> + * @state: The state of the request
> + * @updating_count: count the number of request updates that are in progress
> + * @objects: List of @struct media_request_object request objects
> + * @num_incomplete_objects: The number of incomplete objects in the request
> + * @poll_wait: Wait queue for poll
> + * @lock: Serializes access to this struct
> + */
> +struct media_request {
> + struct media_device *mdev;
> + struct kref kref;
> + char debug_str[TASK_COMM_LEN + 11];
> + enum media_request_state state;
> + refcount_t updating_count;
This will be replaced by unsigned int: it turns out that if CONFIG_REFCOUNT_FULL is set,
the refcount implementation will complain when you increase the refcount from 0 to 1
since it expects that refcount_t it used as it is in kref. Since updating_count is
protected by the spinlock anyway there is no need to use refcount_t, a simple
unsigned int works just as well.
Regards,
Hans
> + struct list_head objects;
> + unsigned int num_incomplete_objects;
> + struct wait_queue_head poll_wait;
> + spinlock_t lock;
> +};
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 02/35] media-request: implement media requests
2018-06-15 7:08 ` Hans Verkuil
@ 2018-07-02 8:58 ` Tomasz Figa
2018-07-02 9:11 ` Hans Verkuil
0 siblings, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2018-07-02 8:58 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Hans Verkuil, Sakari Ailus
Hi Hans,
On Fri, Jun 15, 2018 at 4:09 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 04/06/18 13:46, Hans Verkuil wrote:
> > From: Hans Verkuil <hans.verkuil@cisco.com>
> >
> > Add initial media request support:
> >
> > 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c
> > 2) Add struct media_request to store request objects.
> > 3) Add struct media_request_object to represent a request object.
> > 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support.
> >
> > Basic lifecycle: the application allocates a request, adds
> > objects to it, queues the request, polls until it is completed
> > and can then read the final values of the objects at the time
> > of completion. When it closes the file descriptor the request
> > memory will be freed (actually, when the last user of that request
> > releases the request).
> >
> > Drivers will bind an object to a request (the 'adds objects to it'
> > phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is
> > validated (req_validate op), then queued (the req_queue op).
> >
> > When done with an object it can either be unbound from the request
> > (e.g. when the driver has finished with a vb2 buffer) or marked as
> > completed (e.g. for controls associated with a buffer). When all
> > objects in the request are completed (or unbound), then the request
> > fd will signal an exception (poll).
> >
> > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
> > ---
> > drivers/media/Makefile | 3 +-
> > drivers/media/media-device.c | 14 ++
> > drivers/media/media-request.c | 421 ++++++++++++++++++++++++++++++++++
> > include/media/media-device.h | 24 ++
> > include/media/media-request.h | 326 ++++++++++++++++++++++++++
> > 5 files changed, 787 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/media/media-request.c
> > create mode 100644 include/media/media-request.h
> >
>
> <snip>
>
> > diff --git a/include/media/media-request.h b/include/media/media-request.h
> > new file mode 100644
> > index 000000000000..8acd2627835c
> > --- /dev/null
> > +++ b/include/media/media-request.h
> > @@ -0,0 +1,326 @@
>
> <snip>
>
> > +/**
> > + * struct media_request - Media device request
> > + * @mdev: Media device this request belongs to
> > + * @kref: Reference count
> > + * @debug_str: Prefix for debug messages (process name:fd)
> > + * @state: The state of the request
> > + * @updating_count: count the number of request updates that are in progress
> > + * @objects: List of @struct media_request_object request objects
> > + * @num_incomplete_objects: The number of incomplete objects in the request
> > + * @poll_wait: Wait queue for poll
> > + * @lock: Serializes access to this struct
> > + */
> > +struct media_request {
> > + struct media_device *mdev;
> > + struct kref kref;
> > + char debug_str[TASK_COMM_LEN + 11];
> > + enum media_request_state state;
> > + refcount_t updating_count;
>
> This will be replaced by unsigned int: it turns out that if CONFIG_REFCOUNT_FULL is set,
> the refcount implementation will complain when you increase the refcount from 0 to 1
> since it expects that refcount_t it used as it is in kref. Since updating_count is
> protected by the spinlock anyway there is no need to use refcount_t, a simple
> unsigned int works just as well.
It seems to be read in media_request_clean(), which can be called by
media_request_release() or media_request_ioctl_reinit() and neither
acquires the spinlock for the time of the call.
Agreed, though, that refcount_t doesn't really match what we need
updating_count here for.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 02/35] media-request: implement media requests
2018-07-02 8:58 ` Tomasz Figa
@ 2018-07-02 9:11 ` Hans Verkuil
2018-07-02 10:57 ` Tomasz Figa
0 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-07-02 9:11 UTC (permalink / raw)
To: Tomasz Figa; +Cc: Linux Media Mailing List, Hans Verkuil, Sakari Ailus
On 02/07/18 10:58, Tomasz Figa wrote:
> Hi Hans,
>
> On Fri, Jun 15, 2018 at 4:09 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>> On 04/06/18 13:46, Hans Verkuil wrote:
>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>
>>> Add initial media request support:
>>>
>>> 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c
>>> 2) Add struct media_request to store request objects.
>>> 3) Add struct media_request_object to represent a request object.
>>> 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support.
>>>
>>> Basic lifecycle: the application allocates a request, adds
>>> objects to it, queues the request, polls until it is completed
>>> and can then read the final values of the objects at the time
>>> of completion. When it closes the file descriptor the request
>>> memory will be freed (actually, when the last user of that request
>>> releases the request).
>>>
>>> Drivers will bind an object to a request (the 'adds objects to it'
>>> phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is
>>> validated (req_validate op), then queued (the req_queue op).
>>>
>>> When done with an object it can either be unbound from the request
>>> (e.g. when the driver has finished with a vb2 buffer) or marked as
>>> completed (e.g. for controls associated with a buffer). When all
>>> objects in the request are completed (or unbound), then the request
>>> fd will signal an exception (poll).
>>>
>>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>>> Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>>> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>> Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
>>> ---
>>> drivers/media/Makefile | 3 +-
>>> drivers/media/media-device.c | 14 ++
>>> drivers/media/media-request.c | 421 ++++++++++++++++++++++++++++++++++
>>> include/media/media-device.h | 24 ++
>>> include/media/media-request.h | 326 ++++++++++++++++++++++++++
>>> 5 files changed, 787 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/media/media-request.c
>>> create mode 100644 include/media/media-request.h
>>>
>>
>> <snip>
>>
>>> diff --git a/include/media/media-request.h b/include/media/media-request.h
>>> new file mode 100644
>>> index 000000000000..8acd2627835c
>>> --- /dev/null
>>> +++ b/include/media/media-request.h
>>> @@ -0,0 +1,326 @@
>>
>> <snip>
>>
>>> +/**
>>> + * struct media_request - Media device request
>>> + * @mdev: Media device this request belongs to
>>> + * @kref: Reference count
>>> + * @debug_str: Prefix for debug messages (process name:fd)
>>> + * @state: The state of the request
>>> + * @updating_count: count the number of request updates that are in progress
>>> + * @objects: List of @struct media_request_object request objects
>>> + * @num_incomplete_objects: The number of incomplete objects in the request
>>> + * @poll_wait: Wait queue for poll
>>> + * @lock: Serializes access to this struct
>>> + */
>>> +struct media_request {
>>> + struct media_device *mdev;
>>> + struct kref kref;
>>> + char debug_str[TASK_COMM_LEN + 11];
>>> + enum media_request_state state;
>>> + refcount_t updating_count;
>>
>> This will be replaced by unsigned int: it turns out that if CONFIG_REFCOUNT_FULL is set,
>> the refcount implementation will complain when you increase the refcount from 0 to 1
>> since it expects that refcount_t it used as it is in kref. Since updating_count is
>> protected by the spinlock anyway there is no need to use refcount_t, a simple
>> unsigned int works just as well.
>
> It seems to be read in media_request_clean(), which can be called by
> media_request_release() or media_request_ioctl_reinit() and neither
> acquires the spinlock for the time of the call.
The request object is in state CLEANING at that time, and that guarantees
that nobody else will make changes to the request.
Regards,
Hans
>
> Agreed, though, that refcount_t doesn't really match what we need
> updating_count here for.
>
> Best regards,
> Tomasz
>
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 02/35] media-request: implement media requests
2018-07-02 9:11 ` Hans Verkuil
@ 2018-07-02 10:57 ` Tomasz Figa
0 siblings, 0 replies; 61+ messages in thread
From: Tomasz Figa @ 2018-07-02 10:57 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Hans Verkuil, Sakari Ailus
On Mon, Jul 2, 2018 at 6:11 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 02/07/18 10:58, Tomasz Figa wrote:
> > Hi Hans,
> >
> > On Fri, Jun 15, 2018 at 4:09 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> >>
> >> On 04/06/18 13:46, Hans Verkuil wrote:
> >>> From: Hans Verkuil <hans.verkuil@cisco.com>
> >>>
> >>> Add initial media request support:
> >>>
> >>> 1) Add MEDIA_IOC_REQUEST_ALLOC ioctl support to media-device.c
> >>> 2) Add struct media_request to store request objects.
> >>> 3) Add struct media_request_object to represent a request object.
> >>> 4) Add MEDIA_REQUEST_IOC_QUEUE/REINIT ioctl support.
> >>>
> >>> Basic lifecycle: the application allocates a request, adds
> >>> objects to it, queues the request, polls until it is completed
> >>> and can then read the final values of the objects at the time
> >>> of completion. When it closes the file descriptor the request
> >>> memory will be freed (actually, when the last user of that request
> >>> releases the request).
> >>>
> >>> Drivers will bind an object to a request (the 'adds objects to it'
> >>> phase), when MEDIA_REQUEST_IOC_QUEUE is called the request is
> >>> validated (req_validate op), then queued (the req_queue op).
> >>>
> >>> When done with an object it can either be unbound from the request
> >>> (e.g. when the driver has finished with a vb2 buffer) or marked as
> >>> completed (e.g. for controls associated with a buffer). When all
> >>> objects in the request are completed (or unbound), then the request
> >>> fd will signal an exception (poll).
> >>>
> >>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> >>> Co-developed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> >>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> >>> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >>> Co-developed-by: Alexandre Courbot <acourbot@chromium.org>
> >>> ---
> >>> drivers/media/Makefile | 3 +-
> >>> drivers/media/media-device.c | 14 ++
> >>> drivers/media/media-request.c | 421 ++++++++++++++++++++++++++++++++++
> >>> include/media/media-device.h | 24 ++
> >>> include/media/media-request.h | 326 ++++++++++++++++++++++++++
> >>> 5 files changed, 787 insertions(+), 1 deletion(-)
> >>> create mode 100644 drivers/media/media-request.c
> >>> create mode 100644 include/media/media-request.h
> >>>
> >>
> >> <snip>
> >>
> >>> diff --git a/include/media/media-request.h b/include/media/media-request.h
> >>> new file mode 100644
> >>> index 000000000000..8acd2627835c
> >>> --- /dev/null
> >>> +++ b/include/media/media-request.h
> >>> @@ -0,0 +1,326 @@
> >>
> >> <snip>
> >>
> >>> +/**
> >>> + * struct media_request - Media device request
> >>> + * @mdev: Media device this request belongs to
> >>> + * @kref: Reference count
> >>> + * @debug_str: Prefix for debug messages (process name:fd)
> >>> + * @state: The state of the request
> >>> + * @updating_count: count the number of request updates that are in progress
> >>> + * @objects: List of @struct media_request_object request objects
> >>> + * @num_incomplete_objects: The number of incomplete objects in the request
> >>> + * @poll_wait: Wait queue for poll
> >>> + * @lock: Serializes access to this struct
> >>> + */
> >>> +struct media_request {
> >>> + struct media_device *mdev;
> >>> + struct kref kref;
> >>> + char debug_str[TASK_COMM_LEN + 11];
> >>> + enum media_request_state state;
> >>> + refcount_t updating_count;
> >>
> >> This will be replaced by unsigned int: it turns out that if CONFIG_REFCOUNT_FULL is set,
> >> the refcount implementation will complain when you increase the refcount from 0 to 1
> >> since it expects that refcount_t it used as it is in kref. Since updating_count is
> >> protected by the spinlock anyway there is no need to use refcount_t, a simple
> >> unsigned int works just as well.
> >
> > It seems to be read in media_request_clean(), which can be called by
> > media_request_release() or media_request_ioctl_reinit() and neither
> > acquires the spinlock for the time of the call.
>
> The request object is in state CLEANING at that time, and that guarantees
> that nobody else will make changes to the request.
Makes sense. Thanks for clarification.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCHv15 02/35] media-request: implement media requests
2018-06-04 11:46 ` [PATCHv15 02/35] media-request: implement media requests Hans Verkuil
2018-06-15 7:08 ` Hans Verkuil
@ 2018-07-02 10:56 ` Tomasz Figa
2018-07-02 11:26 ` Hans Verkuil
1 sibling, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2018-07-02 10:56 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Hans Verkuil, Sakari Ailus
Hi Hans,
On Mon, Jun 4, 2018 at 8:47 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
[snip]
> +static void media_request_object_release(struct kref *kref)
> +{
> + struct media_request_object *obj =
> + container_of(kref, struct media_request_object, kref);
> + struct media_request *req = obj->req;
> +
> + if (req)
> + media_request_object_unbind(obj);
Is it possible and fine to have a request bound here?
media_request_clean() seems to explicitly unbind before releasing and
this function would be only called if last reference is put, so maybe
we should actually WARN_ON(req)?
> + obj->ops->release(obj);
> +}
[snip]
> @@ -87,7 +104,12 @@ struct media_device_ops {
> * @enable_source: Enable Source Handler function pointer
> * @disable_source: Disable Source Handler function pointer
> *
> + * @req_queue_mutex: Serialise validating and queueing requests in order to
> + * guarantee exclusive access to the state of the device on
> + * the tip of the request queue.
> * @ops: Operation handler callbacks
> + * @req_queue_mutex: Serialise the MEDIA_REQUEST_IOC_QUEUE ioctl w.r.t.
> + * other operations that stop or start streaming.
Merge conflict? req_queue_mutex is documented twice.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 02/35] media-request: implement media requests
2018-07-02 10:56 ` Tomasz Figa
@ 2018-07-02 11:26 ` Hans Verkuil
0 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-07-02 11:26 UTC (permalink / raw)
To: Tomasz Figa; +Cc: Linux Media Mailing List, Hans Verkuil, Sakari Ailus
On 02/07/18 12:56, Tomasz Figa wrote:
> Hi Hans,
>
> On Mon, Jun 4, 2018 at 8:47 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> [snip]
>> +static void media_request_object_release(struct kref *kref)
>> +{
>> + struct media_request_object *obj =
>> + container_of(kref, struct media_request_object, kref);
>> + struct media_request *req = obj->req;
>> +
>> + if (req)
>> + media_request_object_unbind(obj);
>
> Is it possible and fine to have a request bound here?
> media_request_clean() seems to explicitly unbind before releasing and
> this function would be only called if last reference is put, so maybe
> we should actually WARN_ON(req)?
I agree. It used to be that req could be non-NULL for valid reasons in
previous versions of the series (at least, I think so), but this is no
longer the case in the current code. Adding a WARN_ON makes a lot of
sense.
>
>> + obj->ops->release(obj);
>> +}
> [snip]
>> @@ -87,7 +104,12 @@ struct media_device_ops {
>> * @enable_source: Enable Source Handler function pointer
>> * @disable_source: Disable Source Handler function pointer
>> *
>> + * @req_queue_mutex: Serialise validating and queueing requests in order to
>> + * guarantee exclusive access to the state of the device on
>> + * the tip of the request queue.
>> * @ops: Operation handler callbacks
>> + * @req_queue_mutex: Serialise the MEDIA_REQUEST_IOC_QUEUE ioctl w.r.t.
>> + * other operations that stop or start streaming.
>
> Merge conflict? req_queue_mutex is documented twice.
Thanks, I'll remove that.
Regards,
Hans
>
> Best regards,
> Tomasz
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 03/35] media: doc: Add media-request.h header to documentation build
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 01/35] uapi/linux/media.h: add request API Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 02/35] media-request: implement media requests Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 04/35] media-request: add media_request_get_by_fd Hans Verkuil
` (31 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Sakari Ailus, Hans Verkuil
From: Sakari Ailus <sakari.ailus@linux.intel.com>
media-request.h has been recently added; add it to the documentation build
as well.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
Documentation/media/kapi/mc-core.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/media/kapi/mc-core.rst b/Documentation/media/kapi/mc-core.rst
index 0c05503eaf1f..69362b3135c2 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -262,3 +262,5 @@ in the end provide a way to use driver-specific callbacks.
.. kernel-doc:: include/media/media-devnode.h
.. kernel-doc:: include/media/media-entity.h
+
+.. kernel-doc:: include/media/media-request.h
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 04/35] media-request: add media_request_get_by_fd
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (2 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 03/35] media: doc: Add media-request.h header to documentation build Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 05/35] media-request: add media_request_object_find Hans Verkuil
` (30 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add media_request_get_by_fd() to find a request based on the file
descriptor.
The caller has to call media_request_put() for the returned
request since this function increments the refcount.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/media/media-request.c | 40 +++++++++++++++++++++++++++++++++++
include/media/media-request.h | 24 +++++++++++++++++++++
2 files changed, 64 insertions(+)
diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
index 09823235e4c8..b011f9911fbd 100644
--- a/drivers/media/media-request.c
+++ b/drivers/media/media-request.c
@@ -229,6 +229,46 @@ static const struct file_operations request_fops = {
.release = media_request_close,
};
+struct media_request *
+media_request_get_by_fd(struct media_device *mdev, int request_fd)
+{
+ struct file *filp;
+ struct media_request *req;
+
+ if (!mdev || !mdev->ops ||
+ !mdev->ops->req_validate || !mdev->ops->req_queue)
+ return ERR_PTR(-EPERM);
+
+ filp = fget(request_fd);
+ if (!filp)
+ return ERR_PTR(-ENOENT);
+
+ if (filp->f_op != &request_fops)
+ goto err_fput;
+ req = filp->private_data;
+ if (req->mdev != mdev)
+ goto err_fput;
+
+ /*
+ * Note: as long as someone has an open filehandle of the request,
+ * the request can never be released. The fget() above ensures that
+ * even if userspace closes the request filehandle, the release()
+ * fop won't be called, so the media_request_get() always succeeds
+ * and there is no race condition where the request was released
+ * before media_request_get() is called.
+ */
+ media_request_get(req);
+ fput(filp);
+
+ return req;
+
+err_fput:
+ fput(filp);
+
+ return ERR_PTR(-ENOENT);
+}
+EXPORT_SYMBOL_GPL(media_request_get_by_fd);
+
int media_request_alloc(struct media_device *mdev,
struct media_request_alloc *alloc)
{
diff --git a/include/media/media-request.h b/include/media/media-request.h
index 8acd2627835c..d9931dddb3a8 100644
--- a/include/media/media-request.h
+++ b/include/media/media-request.h
@@ -142,6 +142,24 @@ static inline void media_request_get(struct media_request *req)
*/
void media_request_put(struct media_request *req);
+/**
+ * media_request_get_by_fd - Get a media request by fd
+ *
+ * @mdev: Media device this request belongs to
+ * @request_fd: The file descriptor of the request
+ *
+ * Get the request represented by @request_fd that is owned
+ * by the media device.
+ *
+ * Return a -EPERM error pointer if requests are not supported
+ * by this driver. Return -ENOENT if the request was not found.
+ * Return the pointer to the request if found: the caller will
+ * have to call @media_request_put when it finished using the
+ * request.
+ */
+struct media_request *
+media_request_get_by_fd(struct media_device *mdev, int request_fd);
+
/**
* media_request_alloc - Allocate the media request
*
@@ -163,6 +181,12 @@ static inline void media_request_put(struct media_request *req)
{
}
+static inline struct media_request *
+media_request_get_by_fd(struct media_device *mdev, int request_fd)
+{
+ return ERR_PTR(-EPERM);
+}
+
#endif
/**
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 05/35] media-request: add media_request_object_find
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (3 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 04/35] media-request: add media_request_get_by_fd Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-07-02 12:33 ` Tomasz Figa
2018-06-04 11:46 ` [PATCHv15 06/35] v4l2-device.h: add v4l2_device_supports_requests() helper Hans Verkuil
` (29 subsequent siblings)
34 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add media_request_object_find to find a request object inside a
request based on ops and/or priv values.
Objects of the same type (vb2 buffer, control handler) will have
the same ops value. And objects that refer to the same 'parent'
object (e.g. the v4l2_ctrl_handler that has the current driver
state) will have the same priv value.
The caller has to call media_request_object_put() for the returned
object since this function increments the refcount.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/media/media-request.c | 25 +++++++++++++++++++++++++
include/media/media-request.h | 28 ++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
index b011f9911fbd..6b9a4fc0248b 100644
--- a/drivers/media/media-request.c
+++ b/drivers/media/media-request.c
@@ -342,6 +342,31 @@ static void media_request_object_release(struct kref *kref)
obj->ops->release(obj);
}
+struct media_request_object *
+media_request_object_find(struct media_request *req,
+ const struct media_request_object_ops *ops,
+ void *priv)
+{
+ struct media_request_object *obj;
+ struct media_request_object *found = NULL;
+ unsigned long flags;
+
+ if (WARN_ON(!ops || !priv))
+ return NULL;
+
+ spin_lock_irqsave(&req->lock, flags);
+ list_for_each_entry(obj, &req->objects, list) {
+ if (obj->ops == ops && obj->priv == priv) {
+ media_request_object_get(obj);
+ found = obj;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&req->lock, flags);
+ return found;
+}
+EXPORT_SYMBOL_GPL(media_request_object_find);
+
void media_request_object_put(struct media_request_object *obj)
{
kref_put(&obj->kref, media_request_object_release);
diff --git a/include/media/media-request.h b/include/media/media-request.h
index d9931dddb3a8..2b458d4d8a65 100644
--- a/include/media/media-request.h
+++ b/include/media/media-request.h
@@ -252,6 +252,26 @@ static inline void media_request_object_get(struct media_request_object *obj)
*/
void media_request_object_put(struct media_request_object *obj);
+/**
+ * media_request_object_find - Find an object in a request
+ *
+ * @req: The media request
+ * @ops: Find an object with this ops value
+ * @priv: Find an object with this priv value
+ *
+ * Both @ops and @priv must be non-NULL.
+ *
+ * Returns the object pointer or NULL if not found. The caller must
+ * call media_request_object_put() once it finished using the object.
+ *
+ * Since this function needs to walk the list of objects it takes
+ * the @req->lock spin lock to make this safe.
+ */
+struct media_request_object *
+media_request_object_find(struct media_request *req,
+ const struct media_request_object_ops *ops,
+ void *priv);
+
/**
* media_request_object_init - Initialise a media request object
*
@@ -323,6 +343,14 @@ static inline void media_request_object_put(struct media_request_object *obj)
{
}
+static inline struct media_request_object *
+media_request_object_find(struct media_request *req,
+ const struct media_request_object_ops *ops,
+ void *priv)
+{
+ return NULL;
+}
+
static inline void media_request_object_init(struct media_request_object *obj)
{
obj->ops = NULL;
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 05/35] media-request: add media_request_object_find
2018-06-04 11:46 ` [PATCHv15 05/35] media-request: add media_request_object_find Hans Verkuil
@ 2018-07-02 12:33 ` Tomasz Figa
2018-07-02 12:37 ` Hans Verkuil
0 siblings, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2018-07-02 12:33 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Hans Verkuil
Hi Hans,
On Mon, Jun 4, 2018 at 8:48 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add media_request_object_find to find a request object inside a
> request based on ops and/or priv values.
Current code seems to always find based on both ops and priv values.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCHv15 05/35] media-request: add media_request_object_find
2018-07-02 12:33 ` Tomasz Figa
@ 2018-07-02 12:37 ` Hans Verkuil
0 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-07-02 12:37 UTC (permalink / raw)
To: Tomasz Figa; +Cc: Linux Media Mailing List, Hans Verkuil
On 02/07/18 14:33, Tomasz Figa wrote:
> Hi Hans,
> On Mon, Jun 4, 2018 at 8:48 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> Add media_request_object_find to find a request object inside a
>> request based on ops and/or priv values.
>
> Current code seems to always find based on both ops and priv values.
Outdated commit log. I'll change it.
Regards,
Hans
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 06/35] v4l2-device.h: add v4l2_device_supports_requests() helper
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (4 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 05/35] media-request: add media_request_object_find Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-07-02 13:01 ` Sakari Ailus
2018-06-04 11:46 ` [PATCHv15 07/35] v4l2-dev: lock req_queue_mutex Hans Verkuil
` (28 subsequent siblings)
34 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add a simple helper function that tests if the driver supports
the request API.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
include/media/v4l2-device.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index b330e4a08a6b..ac7677a183ff 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -211,6 +211,17 @@ static inline void v4l2_subdev_notify(struct v4l2_subdev *sd,
sd->v4l2_dev->notify(sd, notification, arg);
}
+/**
+ * v4l2_device_supports_requests - Test if requests are supported.
+ *
+ * @v4l2_dev: pointer to struct v4l2_device
+ */
+static inline bool v4l2_device_supports_requests(struct v4l2_device *v4l2_dev)
+{
+ return v4l2_dev->mdev && v4l2_dev->mdev->ops &&
+ v4l2_dev->mdev->ops->req_queue;
+}
+
/* Helper macros to iterate over all subdevs. */
/**
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 07/35] v4l2-dev: lock req_queue_mutex
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (5 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 06/35] v4l2-device.h: add v4l2_device_supports_requests() helper Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-07-02 13:06 ` Tomasz Figa
2018-06-04 11:46 ` [PATCHv15 08/35] videodev2.h: add request_fd field to v4l2_ext_controls Hans Verkuil
` (27 subsequent siblings)
34 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil, Sakari Ailus
From: Hans Verkuil <hans.verkuil@cisco.com>
We need to serialize streamon/off with queueing new requests.
These ioctls may trigger the cancellation of a streaming
operation, and that should not be mixed with queuing a new
request at the same time.
Finally close() needs this lock since that too can trigger the
cancellation of a streaming operation.
We take the req_queue_mutex here before any other locks since
it is a very high-level lock.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/media/v4l2-core/v4l2-dev.c | 13 +++++++++++++
drivers/media/v4l2-core/v4l2-ioctl.c | 22 +++++++++++++++++++++-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c b/drivers/media/v4l2-core/v4l2-dev.c
index 4ffd7d60a901..d23e82ab1e27 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -444,8 +444,21 @@ static int v4l2_release(struct inode *inode, struct file *filp)
struct video_device *vdev = video_devdata(filp);
int ret = 0;
+ /*
+ * We need to serialize the release() with queueing new requests.
+ * The release() may trigger the cancellation of a streaming
+ * operation, and that should not be mixed with queueing a new
+ * request at the same time.
+ */
+ if (v4l2_device_supports_requests(vdev->v4l2_dev))
+ mutex_lock(&vdev->v4l2_dev->mdev->req_queue_mutex);
+
if (vdev->fops->release)
ret = vdev->fops->release(filp);
+
+ if (v4l2_device_supports_requests(vdev->v4l2_dev))
+ mutex_unlock(&vdev->v4l2_dev->mdev->req_queue_mutex);
+
if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
dprintk("%s: release\n",
video_device_node_name(vdev));
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 965fd301f617..27a893aa0664 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2714,6 +2714,7 @@ static long __video_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
{
struct video_device *vfd = video_devdata(file);
+ struct mutex *req_queue_lock = NULL;
struct mutex *lock; /* ioctl serialization mutex */
const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
bool write_only = false;
@@ -2733,10 +2734,27 @@ static long __video_do_ioctl(struct file *file,
if (test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
vfh = file->private_data;
+ /*
+ * We need to serialize streamon/off with queueing new requests.
+ * These ioctls may trigger the cancellation of a streaming
+ * operation, and that should not be mixed with queueing a new
+ * request at the same time.
+ */
+ if (v4l2_device_supports_requests(vfd->v4l2_dev) &&
+ (cmd == VIDIOC_STREAMON || cmd == VIDIOC_STREAMOFF)) {
+ req_queue_lock = &vfd->v4l2_dev->mdev->req_queue_mutex;
+
+ if (req_queue_lock && mutex_lock_interruptible(req_queue_lock))
+ return -ERESTARTSYS;
+ }
+
lock = v4l2_ioctl_get_lock(vfd, cmd);
- if (lock && mutex_lock_interruptible(lock))
+ if (lock && mutex_lock_interruptible(lock)) {
+ if (req_queue_lock)
+ mutex_unlock(req_queue_lock);
return -ERESTARTSYS;
+ }
if (!video_is_registered(vfd)) {
ret = -ENODEV;
@@ -2795,6 +2813,8 @@ static long __video_do_ioctl(struct file *file,
unlock:
if (lock)
mutex_unlock(lock);
+ if (req_queue_lock)
+ mutex_unlock(req_queue_lock);
return ret;
}
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 07/35] v4l2-dev: lock req_queue_mutex
2018-06-04 11:46 ` [PATCHv15 07/35] v4l2-dev: lock req_queue_mutex Hans Verkuil
@ 2018-07-02 13:06 ` Tomasz Figa
2018-07-02 13:23 ` Hans Verkuil
0 siblings, 1 reply; 61+ messages in thread
From: Tomasz Figa @ 2018-07-02 13:06 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Linux Media Mailing List, Hans Verkuil, Sakari Ailus
Hi Hans,
On Mon, Jun 4, 2018 at 8:48 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
[snip]
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 965fd301f617..27a893aa0664 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2714,6 +2714,7 @@ static long __video_do_ioctl(struct file *file,
> unsigned int cmd, void *arg)
> {
> struct video_device *vfd = video_devdata(file);
> + struct mutex *req_queue_lock = NULL;
> struct mutex *lock; /* ioctl serialization mutex */
> const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
> bool write_only = false;
> @@ -2733,10 +2734,27 @@ static long __video_do_ioctl(struct file *file,
> if (test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
> vfh = file->private_data;
>
> + /*
> + * We need to serialize streamon/off with queueing new requests.
> + * These ioctls may trigger the cancellation of a streaming
> + * operation, and that should not be mixed with queueing a new
> + * request at the same time.
> + */
> + if (v4l2_device_supports_requests(vfd->v4l2_dev) &&
> + (cmd == VIDIOC_STREAMON || cmd == VIDIOC_STREAMOFF)) {
Are STREAMON and STREAMOFF the only ioctls we need to acquire
req_queue_lock for? How about a race with, for example, S_CTRL(control
X, request_fd = -1) and req_validate() on a request that depends on
the value of control X? Maybe we should just lock here for any ioctl?
> + req_queue_lock = &vfd->v4l2_dev->mdev->req_queue_mutex;
> +
> + if (req_queue_lock && mutex_lock_interruptible(req_queue_lock))
I believe it isn't possible for req_queue_lock to be NULL here.
> + return -ERESTARTSYS;
I guess it isn't really possible for mutex_lock_interruptible() to
return anything non-zero other than this, but I'd still return what it
returns here just in case.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 07/35] v4l2-dev: lock req_queue_mutex
2018-07-02 13:06 ` Tomasz Figa
@ 2018-07-02 13:23 ` Hans Verkuil
0 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-07-02 13:23 UTC (permalink / raw)
To: Tomasz Figa; +Cc: Linux Media Mailing List, Hans Verkuil, Sakari Ailus
On 02/07/18 15:06, Tomasz Figa wrote:
> Hi Hans,
>
> On Mon, Jun 4, 2018 at 8:48 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> [snip]
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index 965fd301f617..27a893aa0664 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -2714,6 +2714,7 @@ static long __video_do_ioctl(struct file *file,
>> unsigned int cmd, void *arg)
>> {
>> struct video_device *vfd = video_devdata(file);
>> + struct mutex *req_queue_lock = NULL;
>> struct mutex *lock; /* ioctl serialization mutex */
>> const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
>> bool write_only = false;
>> @@ -2733,10 +2734,27 @@ static long __video_do_ioctl(struct file *file,
>> if (test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags))
>> vfh = file->private_data;
>>
>> + /*
>> + * We need to serialize streamon/off with queueing new requests.
>> + * These ioctls may trigger the cancellation of a streaming
>> + * operation, and that should not be mixed with queueing a new
>> + * request at the same time.
>> + */
>> + if (v4l2_device_supports_requests(vfd->v4l2_dev) &&
>> + (cmd == VIDIOC_STREAMON || cmd == VIDIOC_STREAMOFF)) {
>
> Are STREAMON and STREAMOFF the only ioctls we need to acquire
> req_queue_lock for? How about a race with, for example, S_CTRL(control
> X, request_fd = -1) and req_validate() on a request that depends on
> the value of control X? Maybe we should just lock here for any ioctl?
Definitely not, that would seriously impact performance since this is such
a high-level lock.
It is indeed possible to set controls directly even if the same control is
also used in a request. It is intentional that you can still set controls
directly: for some controls (e.g. POWERLINE frequency) it makes no sense to
use them in a request and you just want to be able to set them directly. It
is also very useful for debugging. So even though it can potentially mess
things up, it is practical to allow this.
Drivers need to be able to handle such situations anyway since setting
controls from a request can fail regardless due to HW errors of some kind,
so a control might not have the value that you expected.
And worse case there will only be a wrong control value until a request is
applied containing a new value of this control.
It might be that in the future we need to restrict this for selected controls
in some manner, but for now I think this is fine.
Note that this is different for buffers: once you've switched to using requests
to queue buffers, you can no longer queue a buffer directly. Mixing that is
theoretically possible, but it is very confusing.
>
>> + req_queue_lock = &vfd->v4l2_dev->mdev->req_queue_mutex;
>> +
>> + if (req_queue_lock && mutex_lock_interruptible(req_queue_lock))
>
> I believe it isn't possible for req_queue_lock to be NULL here.
True, I can remove that test.
Regards,
Hans
>
>> + return -ERESTARTSYS;
>
> I guess it isn't really possible for mutex_lock_interruptible() to
> return anything non-zero other than this, but I'd still return what it
> returns here just in case.
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 08/35] videodev2.h: add request_fd field to v4l2_ext_controls
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (6 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 07/35] v4l2-dev: lock req_queue_mutex Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev Hans Verkuil
` (26 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Alexandre Courbot, Hans Verkuil
From: Alexandre Courbot <acourbot@chromium.org>
If 'which' is V4L2_CTRL_WHICH_REQUEST_VAL, then the 'request_fd' field
can be used to specify a request for the G/S/TRY_EXT_CTRLS ioctls.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 5 ++++-
drivers/media/v4l2-core/v4l2-ioctl.c | 6 +++---
include/uapi/linux/videodev2.h | 4 +++-
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 6481212fda77..dcce86c1fe40 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -834,7 +834,8 @@ struct v4l2_ext_controls32 {
__u32 which;
__u32 count;
__u32 error_idx;
- __u32 reserved[2];
+ __s32 request_fd;
+ __u32 reserved[1];
compat_caddr_t controls; /* actually struct v4l2_ext_control32 * */
};
@@ -909,6 +910,7 @@ static int get_v4l2_ext_controls32(struct file *file,
get_user(count, &p32->count) ||
put_user(count, &p64->count) ||
assign_in_user(&p64->error_idx, &p32->error_idx) ||
+ assign_in_user(&p64->request_fd, &p32->request_fd) ||
copy_in_user(p64->reserved, p32->reserved, sizeof(p64->reserved)))
return -EFAULT;
@@ -974,6 +976,7 @@ static int put_v4l2_ext_controls32(struct file *file,
get_user(count, &p64->count) ||
put_user(count, &p32->count) ||
assign_in_user(&p32->error_idx, &p64->error_idx) ||
+ assign_in_user(&p32->request_fd, &p64->request_fd) ||
copy_in_user(p32->reserved, p64->reserved, sizeof(p32->reserved)) ||
get_user(kcontrols, &p64->controls))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 27a893aa0664..3fa66103ffd0 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -553,8 +553,8 @@ static void v4l_print_ext_controls(const void *arg, bool write_only)
const struct v4l2_ext_controls *p = arg;
int i;
- pr_cont("which=0x%x, count=%d, error_idx=%d",
- p->which, p->count, p->error_idx);
+ pr_cont("which=0x%x, count=%d, error_idx=%d, request_fd=%d",
+ p->which, p->count, p->error_idx, p->request_fd);
for (i = 0; i < p->count; i++) {
if (!p->controls[i].size)
pr_cont(", id/val=0x%x/0x%x",
@@ -870,7 +870,7 @@ static int check_ext_ctrls(struct v4l2_ext_controls *c, int allow_priv)
__u32 i;
/* zero the reserved fields */
- c->reserved[0] = c->reserved[1] = 0;
+ c->reserved[0] = 0;
for (i = 0; i < c->count; i++)
c->controls[i].reserved2[0] = 0;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 600877be5c22..16b53b82496c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1592,7 +1592,8 @@ struct v4l2_ext_controls {
};
__u32 count;
__u32 error_idx;
- __u32 reserved[2];
+ __s32 request_fd;
+ __u32 reserved[1];
struct v4l2_ext_control *controls;
};
@@ -1605,6 +1606,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_MAX_DIMS (4)
#define V4L2_CTRL_WHICH_CUR_VAL 0
#define V4L2_CTRL_WHICH_DEF_VAL 0x0f000000
+#define V4L2_CTRL_WHICH_REQUEST_VAL 0x0f010000
enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_INTEGER = 1,
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (7 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 08/35] videodev2.h: add request_fd field to v4l2_ext_controls Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 16:22 ` Hans Verkuil
2018-06-04 17:11 ` Ezequiel Garcia
2018-06-04 11:46 ` [PATCHv15 10/35] v4l2-ctrls: prepare internal structs for request API Hans Verkuil
` (25 subsequent siblings)
34 siblings, 2 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil, Alexandre Courbot
From: Hans Verkuil <hans.verkuil@cisco.com>
Add a 'bool from_other_dev' argument: set to true if the two
handlers refer to different devices (e.g. it is true when
inheriting controls from a subdev into a main v4l2 bridge
driver).
This will be used later when implementing support for the
request API since we need to skip such controls.
TODO: check drivers/staging/media/imx/imx-media-fim.c change.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
---
drivers/media/dvb-frontends/rtl2832_sdr.c | 5 +-
drivers/media/pci/bt8xx/bttv-driver.c | 2 +-
drivers/media/pci/cx23885/cx23885-417.c | 2 +-
drivers/media/pci/cx88/cx88-blackbird.c | 2 +-
drivers/media/pci/cx88/cx88-video.c | 2 +-
drivers/media/pci/saa7134/saa7134-empress.c | 4 +-
drivers/media/pci/saa7134/saa7134-video.c | 2 +-
.../media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
drivers/media/platform/rcar_drif.c | 2 +-
.../media/platform/soc_camera/soc_camera.c | 3 +-
drivers/media/platform/vivid/vivid-ctrls.c | 46 +++++++++----------
drivers/media/usb/cx231xx/cx231xx-417.c | 2 +-
drivers/media/usb/cx231xx/cx231xx-video.c | 4 +-
drivers/media/usb/msi2500/msi2500.c | 2 +-
drivers/media/usb/tm6000/tm6000-video.c | 2 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++--
drivers/media/v4l2-core/v4l2-device.c | 3 +-
drivers/staging/media/imx/imx-media-dev.c | 2 +-
drivers/staging/media/imx/imx-media-fim.c | 2 +-
include/media/v4l2-ctrls.h | 8 +++-
21 files changed, 61 insertions(+), 49 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c b/drivers/media/dvb-frontends/rtl2832_sdr.c
index c6e78d870ccd..6064d28224e8 100644
--- a/drivers/media/dvb-frontends/rtl2832_sdr.c
+++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
@@ -1394,7 +1394,8 @@ static int rtl2832_sdr_probe(struct platform_device *pdev)
case RTL2832_SDR_TUNER_E4000:
v4l2_ctrl_handler_init(&dev->hdl, 9);
if (subdev)
- v4l2_ctrl_add_handler(&dev->hdl, subdev->ctrl_handler, NULL);
+ v4l2_ctrl_add_handler(&dev->hdl, subdev->ctrl_handler,
+ NULL, true);
break;
case RTL2832_SDR_TUNER_R820T:
case RTL2832_SDR_TUNER_R828D:
@@ -1423,7 +1424,7 @@ static int rtl2832_sdr_probe(struct platform_device *pdev)
v4l2_ctrl_handler_init(&dev->hdl, 2);
if (subdev)
v4l2_ctrl_add_handler(&dev->hdl, subdev->ctrl_handler,
- NULL);
+ NULL, true);
break;
default:
v4l2_ctrl_handler_init(&dev->hdl, 0);
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c
index de3f44b8dec6..9341ef6e154f 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -4211,7 +4211,7 @@ static int bttv_probe(struct pci_dev *dev, const struct pci_device_id *pci_id)
/* register video4linux + input */
if (!bttv_tvcards[btv->c.type].no_video) {
v4l2_ctrl_add_handler(&btv->radio_ctrl_handler, hdl,
- v4l2_ctrl_radio_filter);
+ v4l2_ctrl_radio_filter, false);
if (btv->radio_ctrl_handler.error) {
result = btv->radio_ctrl_handler.error;
goto fail2;
diff --git a/drivers/media/pci/cx23885/cx23885-417.c b/drivers/media/pci/cx23885/cx23885-417.c
index a71f3c7569ce..762823871c78 100644
--- a/drivers/media/pci/cx23885/cx23885-417.c
+++ b/drivers/media/pci/cx23885/cx23885-417.c
@@ -1527,7 +1527,7 @@ int cx23885_417_register(struct cx23885_dev *dev)
dev->cxhdl.priv = dev;
dev->cxhdl.func = cx23885_api_func;
cx2341x_handler_set_50hz(&dev->cxhdl, tsport->height == 576);
- v4l2_ctrl_add_handler(&dev->ctrl_handler, &dev->cxhdl.hdl, NULL);
+ v4l2_ctrl_add_handler(&dev->ctrl_handler, &dev->cxhdl.hdl, NULL, false);
/* Allocate and initialize V4L video device */
dev->v4l_device = cx23885_video_dev_alloc(tsport,
diff --git a/drivers/media/pci/cx88/cx88-blackbird.c b/drivers/media/pci/cx88/cx88-blackbird.c
index 7a4876cf9f08..722dd101c9b0 100644
--- a/drivers/media/pci/cx88/cx88-blackbird.c
+++ b/drivers/media/pci/cx88/cx88-blackbird.c
@@ -1183,7 +1183,7 @@ static int cx8802_blackbird_probe(struct cx8802_driver *drv)
err = cx2341x_handler_init(&dev->cxhdl, 36);
if (err)
goto fail_core;
- v4l2_ctrl_add_handler(&dev->cxhdl.hdl, &core->video_hdl, NULL);
+ v4l2_ctrl_add_handler(&dev->cxhdl.hdl, &core->video_hdl, NULL, false);
/* blackbird stuff */
pr_info("cx23416 based mpeg encoder (blackbird reference design)\n");
diff --git a/drivers/media/pci/cx88/cx88-video.c b/drivers/media/pci/cx88/cx88-video.c
index 7b113bad70d2..85e2b6c9fb1c 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -1378,7 +1378,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
if (vc->id == V4L2_CID_CHROMA_AGC)
core->chroma_agc = vc;
}
- v4l2_ctrl_add_handler(&core->video_hdl, &core->audio_hdl, NULL);
+ v4l2_ctrl_add_handler(&core->video_hdl, &core->audio_hdl, NULL, false);
/* load and configure helper modules */
diff --git a/drivers/media/pci/saa7134/saa7134-empress.c b/drivers/media/pci/saa7134/saa7134-empress.c
index 66acfd35ffc6..fc75ce00dbf8 100644
--- a/drivers/media/pci/saa7134/saa7134-empress.c
+++ b/drivers/media/pci/saa7134/saa7134-empress.c
@@ -265,9 +265,9 @@ static int empress_init(struct saa7134_dev *dev)
"%s empress (%s)", dev->name,
saa7134_boards[dev->board].name);
v4l2_ctrl_handler_init(hdl, 21);
- v4l2_ctrl_add_handler(hdl, &dev->ctrl_handler, empress_ctrl_filter);
+ v4l2_ctrl_add_handler(hdl, &dev->ctrl_handler, empress_ctrl_filter, false);
if (dev->empress_sd)
- v4l2_ctrl_add_handler(hdl, dev->empress_sd->ctrl_handler, NULL);
+ v4l2_ctrl_add_handler(hdl, dev->empress_sd->ctrl_handler, NULL, true);
if (hdl->error) {
video_device_release(dev->empress_dev);
return hdl->error;
diff --git a/drivers/media/pci/saa7134/saa7134-video.c b/drivers/media/pci/saa7134/saa7134-video.c
index 1a50ec9d084f..41d46488d22e 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2136,7 +2136,7 @@ int saa7134_video_init1(struct saa7134_dev *dev)
hdl = &dev->radio_ctrl_handler;
v4l2_ctrl_handler_init(hdl, 2);
v4l2_ctrl_add_handler(hdl, &dev->ctrl_handler,
- v4l2_ctrl_radio_filter);
+ v4l2_ctrl_radio_filter, false);
if (hdl->error)
return hdl->error;
}
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
index a3cdac188190..2164375f0ee0 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -1424,7 +1424,7 @@ static int fimc_link_setup(struct media_entity *entity,
return 0;
return v4l2_ctrl_add_handler(&vc->ctx->ctrls.handler,
- sensor->ctrl_handler, NULL);
+ sensor->ctrl_handler, NULL, true);
}
static const struct media_entity_operations fimc_sd_media_ops = {
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
index d3072e166a1c..2c115c6651b0 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -442,7 +442,7 @@ static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
return ret;
ret = v4l2_ctrl_add_handler(&vin->ctrl_handler, subdev->ctrl_handler,
- NULL);
+ NULL, true);
if (ret < 0) {
v4l2_ctrl_handler_free(&vin->ctrl_handler);
return ret;
diff --git a/drivers/media/platform/rcar_drif.c b/drivers/media/platform/rcar_drif.c
index dc7e280c91b4..159c7d2c2066 100644
--- a/drivers/media/platform/rcar_drif.c
+++ b/drivers/media/platform/rcar_drif.c
@@ -1168,7 +1168,7 @@ static int rcar_drif_notify_complete(struct v4l2_async_notifier *notifier)
}
ret = v4l2_ctrl_add_handler(&sdr->ctrl_hdl,
- sdr->ep.subdev->ctrl_handler, NULL);
+ sdr->ep.subdev->ctrl_handler, NULL, true);
if (ret) {
rdrif_err(sdr, "failed: ctrl add hdlr ret %d\n", ret);
goto error;
diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c
index 69f0d8e80bd8..e6787abc34ae 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1180,7 +1180,8 @@ static int soc_camera_probe_finish(struct soc_camera_device *icd)
v4l2_subdev_call(sd, video, g_tvnorms, &icd->vdev->tvnorms);
- ret = v4l2_ctrl_add_handler(&icd->ctrl_handler, sd->ctrl_handler, NULL);
+ ret = v4l2_ctrl_add_handler(&icd->ctrl_handler, sd->ctrl_handler,
+ NULL, true);
if (ret < 0)
return ret;
diff --git a/drivers/media/platform/vivid/vivid-ctrls.c b/drivers/media/platform/vivid/vivid-ctrls.c
index 6b0bfa091592..f369b94ad7ff 100644
--- a/drivers/media/platform/vivid/vivid-ctrls.c
+++ b/drivers/media/platform/vivid/vivid-ctrls.c
@@ -1662,59 +1662,59 @@ int vivid_create_controls(struct vivid_dev *dev, bool show_ccs_cap,
v4l2_ctrl_auto_cluster(2, &dev->autogain, 0, true);
if (dev->has_vid_cap) {
- v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_gen, NULL);
- v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_vid, NULL);
- v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_aud, NULL);
- v4l2_ctrl_add_handler(hdl_vid_cap, hdl_streaming, NULL);
- v4l2_ctrl_add_handler(hdl_vid_cap, hdl_sdtv_cap, NULL);
- v4l2_ctrl_add_handler(hdl_vid_cap, hdl_loop_cap, NULL);
- v4l2_ctrl_add_handler(hdl_vid_cap, hdl_fb, NULL);
+ v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_gen, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_vid, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_aud, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_cap, hdl_streaming, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_cap, hdl_sdtv_cap, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_cap, hdl_loop_cap, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_cap, hdl_fb, NULL, false);
if (hdl_vid_cap->error)
return hdl_vid_cap->error;
dev->vid_cap_dev.ctrl_handler = hdl_vid_cap;
}
if (dev->has_vid_out) {
- v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_gen, NULL);
- v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_aud, NULL);
- v4l2_ctrl_add_handler(hdl_vid_out, hdl_streaming, NULL);
- v4l2_ctrl_add_handler(hdl_vid_out, hdl_fb, NULL);
+ v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_gen, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_aud, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_out, hdl_streaming, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vid_out, hdl_fb, NULL, false);
if (hdl_vid_out->error)
return hdl_vid_out->error;
dev->vid_out_dev.ctrl_handler = hdl_vid_out;
}
if (dev->has_vbi_cap) {
- v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_user_gen, NULL);
- v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_streaming, NULL);
- v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_sdtv_cap, NULL);
- v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_loop_cap, NULL);
+ v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_user_gen, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_streaming, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_sdtv_cap, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_loop_cap, NULL, false);
if (hdl_vbi_cap->error)
return hdl_vbi_cap->error;
dev->vbi_cap_dev.ctrl_handler = hdl_vbi_cap;
}
if (dev->has_vbi_out) {
- v4l2_ctrl_add_handler(hdl_vbi_out, hdl_user_gen, NULL);
- v4l2_ctrl_add_handler(hdl_vbi_out, hdl_streaming, NULL);
+ v4l2_ctrl_add_handler(hdl_vbi_out, hdl_user_gen, NULL, false);
+ v4l2_ctrl_add_handler(hdl_vbi_out, hdl_streaming, NULL, false);
if (hdl_vbi_out->error)
return hdl_vbi_out->error;
dev->vbi_out_dev.ctrl_handler = hdl_vbi_out;
}
if (dev->has_radio_rx) {
- v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_gen, NULL);
- v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_aud, NULL);
+ v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_gen, NULL, false);
+ v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_aud, NULL, false);
if (hdl_radio_rx->error)
return hdl_radio_rx->error;
dev->radio_rx_dev.ctrl_handler = hdl_radio_rx;
}
if (dev->has_radio_tx) {
- v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_gen, NULL);
- v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_aud, NULL);
+ v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_gen, NULL, false);
+ v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_aud, NULL, false);
if (hdl_radio_tx->error)
return hdl_radio_tx->error;
dev->radio_tx_dev.ctrl_handler = hdl_radio_tx;
}
if (dev->has_sdr_cap) {
- v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_user_gen, NULL);
- v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_streaming, NULL);
+ v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_user_gen, NULL, false);
+ v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_streaming, NULL, false);
if (hdl_sdr_cap->error)
return hdl_sdr_cap->error;
dev->sdr_cap_dev.ctrl_handler = hdl_sdr_cap;
diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c b/drivers/media/usb/cx231xx/cx231xx-417.c
index 2f3b0564d676..e3cb9eefd36a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-417.c
+++ b/drivers/media/usb/cx231xx/cx231xx-417.c
@@ -1992,7 +1992,7 @@ int cx231xx_417_register(struct cx231xx *dev)
dev->mpeg_ctrl_handler.ops = &cx231xx_ops;
if (dev->sd_cx25840)
v4l2_ctrl_add_handler(&dev->mpeg_ctrl_handler.hdl,
- dev->sd_cx25840->ctrl_handler, NULL);
+ dev->sd_cx25840->ctrl_handler, NULL, false);
if (dev->mpeg_ctrl_handler.hdl.error) {
err = dev->mpeg_ctrl_handler.hdl.error;
dprintk(3, "%s: can't add cx25840 controls\n", dev->name);
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c b/drivers/media/usb/cx231xx/cx231xx-video.c
index f7fcd733a2ca..2dedb18f63a0 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -2204,10 +2204,10 @@ int cx231xx_register_analog_devices(struct cx231xx *dev)
if (dev->sd_cx25840) {
v4l2_ctrl_add_handler(&dev->ctrl_handler,
- dev->sd_cx25840->ctrl_handler, NULL);
+ dev->sd_cx25840->ctrl_handler, NULL, true);
v4l2_ctrl_add_handler(&dev->radio_ctrl_handler,
dev->sd_cx25840->ctrl_handler,
- v4l2_ctrl_radio_filter);
+ v4l2_ctrl_radio_filter, true);
}
if (dev->ctrl_handler.error)
diff --git a/drivers/media/usb/msi2500/msi2500.c b/drivers/media/usb/msi2500/msi2500.c
index 65ef755adfdc..4aacd77a5d58 100644
--- a/drivers/media/usb/msi2500/msi2500.c
+++ b/drivers/media/usb/msi2500/msi2500.c
@@ -1278,7 +1278,7 @@ static int msi2500_probe(struct usb_interface *intf,
}
/* currently all controls are from subdev */
- v4l2_ctrl_add_handler(&dev->hdl, sd->ctrl_handler, NULL);
+ v4l2_ctrl_add_handler(&dev->hdl, sd->ctrl_handler, NULL, true);
dev->v4l2_dev.ctrl_handler = &dev->hdl;
dev->vdev.v4l2_dev = &dev->v4l2_dev;
diff --git a/drivers/media/usb/tm6000/tm6000-video.c b/drivers/media/usb/tm6000/tm6000-video.c
index aa85fe31c835..d2850ce13e76 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -1622,7 +1622,7 @@ int tm6000_v4l2_register(struct tm6000_core *dev)
v4l2_ctrl_new_std(&dev->ctrl_handler, &tm6000_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
v4l2_ctrl_add_handler(&dev->ctrl_handler,
- &dev->radio_ctrl_handler, NULL);
+ &dev->radio_ctrl_handler, NULL, false);
if (dev->radio_ctrl_handler.error)
ret = dev->radio_ctrl_handler.error;
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index d29e45516eb7..aa1dd2015e84 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1995,7 +1995,8 @@ EXPORT_SYMBOL(v4l2_ctrl_find);
/* Allocate a new v4l2_ctrl_ref and hook it into the handler. */
static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
- struct v4l2_ctrl *ctrl)
+ struct v4l2_ctrl *ctrl,
+ bool from_other_dev)
{
struct v4l2_ctrl_ref *ref;
struct v4l2_ctrl_ref *new_ref;
@@ -2019,6 +2020,7 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
if (!new_ref)
return handler_set_err(hdl, -ENOMEM);
new_ref->ctrl = ctrl;
+ new_ref->from_other_dev = from_other_dev;
if (ctrl->handler == hdl) {
/* By default each control starts in a cluster of its own.
new_ref->ctrl is basically a cluster array with one
@@ -2199,7 +2201,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
ctrl->type_ops->init(ctrl, idx, ctrl->p_new);
}
- if (handler_new_ref(hdl, ctrl)) {
+ if (handler_new_ref(hdl, ctrl, false)) {
kvfree(ctrl);
return NULL;
}
@@ -2368,7 +2370,8 @@ EXPORT_SYMBOL(v4l2_ctrl_new_int_menu);
/* Add the controls from another handler to our own. */
int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl_handler *add,
- bool (*filter)(const struct v4l2_ctrl *ctrl))
+ bool (*filter)(const struct v4l2_ctrl *ctrl),
+ bool from_other_dev)
{
struct v4l2_ctrl_ref *ref;
int ret = 0;
@@ -2391,7 +2394,7 @@ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
/* Filter any unwanted controls */
if (filter && !filter(ctrl))
continue;
- ret = handler_new_ref(hdl, ctrl);
+ ret = handler_new_ref(hdl, ctrl, from_other_dev);
if (ret)
break;
}
diff --git a/drivers/media/v4l2-core/v4l2-device.c b/drivers/media/v4l2-core/v4l2-device.c
index 937c6de85606..8391a7f0895b 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -178,7 +178,8 @@ int v4l2_device_register_subdev(struct v4l2_device *v4l2_dev,
sd->v4l2_dev = v4l2_dev;
/* This just returns 0 if either of the two args is NULL */
- err = v4l2_ctrl_add_handler(v4l2_dev->ctrl_handler, sd->ctrl_handler, NULL);
+ err = v4l2_ctrl_add_handler(v4l2_dev->ctrl_handler, sd->ctrl_handler,
+ NULL, true);
if (err)
goto error_module;
diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
index 289d775c4820..08799beaea42 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -391,7 +391,7 @@ static int imx_media_inherit_controls(struct imx_media_dev *imxmd,
ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
sd->ctrl_handler,
- NULL);
+ NULL, true);
if (ret)
return ret;
}
diff --git a/drivers/staging/media/imx/imx-media-fim.c b/drivers/staging/media/imx/imx-media-fim.c
index 6df189135db8..8cf773eef9da 100644
--- a/drivers/staging/media/imx/imx-media-fim.c
+++ b/drivers/staging/media/imx/imx-media-fim.c
@@ -463,7 +463,7 @@ int imx_media_fim_add_controls(struct imx_media_fim *fim)
{
/* add the FIM controls to the calling subdev ctrl handler */
return v4l2_ctrl_add_handler(fim->sd->ctrl_handler,
- &fim->ctrl_handler, NULL);
+ &fim->ctrl_handler, NULL, false);
}
EXPORT_SYMBOL_GPL(imx_media_fim_add_controls);
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 5b445b5654f7..d26b8ddebb56 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -247,6 +247,8 @@ struct v4l2_ctrl {
* @ctrl: The actual control information.
* @helper: Pointer to helper struct. Used internally in
* ``prepare_ext_ctrls`` function at ``v4l2-ctrl.c``.
+ * @from_other_dev: If true, then @ctrl was defined in another
+ * device than the &struct v4l2_ctrl_handler.
*
* Each control handler has a list of these refs. The list_head is used to
* keep a sorted-by-control-ID list of all controls, while the next pointer
@@ -257,6 +259,7 @@ struct v4l2_ctrl_ref {
struct v4l2_ctrl_ref *next;
struct v4l2_ctrl *ctrl;
struct v4l2_ctrl_helper *helper;
+ bool from_other_dev;
};
/**
@@ -633,6 +636,8 @@ typedef bool (*v4l2_ctrl_filter)(const struct v4l2_ctrl *ctrl);
* @add: The control handler whose controls you want to add to
* the @hdl control handler.
* @filter: This function will filter which controls should be added.
+ * @from_other_dev: If true, then the controls in @add were defined in another
+ * device than @hdl.
*
* Does nothing if either of the two handlers is a NULL pointer.
* If @filter is NULL, then all controls are added. Otherwise only those
@@ -642,7 +647,8 @@ typedef bool (*v4l2_ctrl_filter)(const struct v4l2_ctrl *ctrl);
*/
int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl_handler *add,
- v4l2_ctrl_filter filter);
+ v4l2_ctrl_filter filter,
+ bool from_other_dev);
/**
* v4l2_ctrl_radio_filter() - Standard filter for radio controls.
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev
2018-06-04 11:46 ` [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev Hans Verkuil
@ 2018-06-04 16:22 ` Hans Verkuil
2018-06-05 10:16 ` Philipp Zabel
2018-06-04 17:11 ` Ezequiel Garcia
1 sibling, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 16:22 UTC (permalink / raw)
To: linux-media, Steve Longerbeam, Philipp Zabel
Cc: Hans Verkuil, Alexandre Courbot
Steve or Philipp,
Can one of you verify the imx-media-fim.c patch?
See the description of the change below:
On 06/04/2018 01:46 PM, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add a 'bool from_other_dev' argument: set to true if the two
> handlers refer to different devices (e.g. it is true when
> inheriting controls from a subdev into a main v4l2 bridge
> driver).
>
> This will be used later when implementing support for the
> request API since we need to skip such controls.
>
> TODO: check drivers/staging/media/imx/imx-media-fim.c change.
The basic idea is that while controls for a subdev can be
added ('inherited') to a handler for a another parent subdev or
video device, they should be marked as belonging to another device.
This is needed when the Request API is introduced since the request
should not have two copies of the same control (one belonging to the
subdev, one inherited by e.g. a video device).
However, I am not sure if I need to use true or false in the.
imx_media_fim_add_controls() case. Do the controls added here belong
to the same csi subdev or do they belong to another device?
BTW, with 'belongs to' I mean that that's the device driver that
implements the s_ctrl() call, i.e. actually sets up the hardware.
Regards,
Hans
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
> ---
> drivers/media/dvb-frontends/rtl2832_sdr.c | 5 +-
> drivers/media/pci/bt8xx/bttv-driver.c | 2 +-
> drivers/media/pci/cx23885/cx23885-417.c | 2 +-
> drivers/media/pci/cx88/cx88-blackbird.c | 2 +-
> drivers/media/pci/cx88/cx88-video.c | 2 +-
> drivers/media/pci/saa7134/saa7134-empress.c | 4 +-
> drivers/media/pci/saa7134/saa7134-video.c | 2 +-
> .../media/platform/exynos4-is/fimc-capture.c | 2 +-
> drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
> drivers/media/platform/rcar_drif.c | 2 +-
> .../media/platform/soc_camera/soc_camera.c | 3 +-
> drivers/media/platform/vivid/vivid-ctrls.c | 46 +++++++++----------
> drivers/media/usb/cx231xx/cx231xx-417.c | 2 +-
> drivers/media/usb/cx231xx/cx231xx-video.c | 4 +-
> drivers/media/usb/msi2500/msi2500.c | 2 +-
> drivers/media/usb/tm6000/tm6000-video.c | 2 +-
> drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++--
> drivers/media/v4l2-core/v4l2-device.c | 3 +-
> drivers/staging/media/imx/imx-media-dev.c | 2 +-
> drivers/staging/media/imx/imx-media-fim.c | 2 +-
> include/media/v4l2-ctrls.h | 8 +++-
> 21 files changed, 61 insertions(+), 49 deletions(-)
>
<snip>
> diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
> index 289d775c4820..08799beaea42 100644
> --- a/drivers/staging/media/imx/imx-media-dev.c
> +++ b/drivers/staging/media/imx/imx-media-dev.c
> @@ -391,7 +391,7 @@ static int imx_media_inherit_controls(struct imx_media_dev *imxmd,
>
> ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
> sd->ctrl_handler,
> - NULL);
> + NULL, true);
> if (ret)
> return ret;
> }
> diff --git a/drivers/staging/media/imx/imx-media-fim.c b/drivers/staging/media/imx/imx-media-fim.c
> index 6df189135db8..8cf773eef9da 100644
> --- a/drivers/staging/media/imx/imx-media-fim.c
> +++ b/drivers/staging/media/imx/imx-media-fim.c
> @@ -463,7 +463,7 @@ int imx_media_fim_add_controls(struct imx_media_fim *fim)
> {
> /* add the FIM controls to the calling subdev ctrl handler */
> return v4l2_ctrl_add_handler(fim->sd->ctrl_handler,
> - &fim->ctrl_handler, NULL);
> + &fim->ctrl_handler, NULL, false);
> }
> EXPORT_SYMBOL_GPL(imx_media_fim_add_controls);
>
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev
2018-06-04 16:22 ` Hans Verkuil
@ 2018-06-05 10:16 ` Philipp Zabel
0 siblings, 0 replies; 61+ messages in thread
From: Philipp Zabel @ 2018-06-05 10:16 UTC (permalink / raw)
To: Hans Verkuil, linux-media, Steve Longerbeam
Cc: Hans Verkuil, Alexandre Courbot
Hi Hans,
On Mon, 2018-06-04 at 18:22 +0200, Hans Verkuil wrote:
> Steve or Philipp,
>
> Can one of you verify the imx-media-fim.c patch?
>
> See the description of the change below:
>
> On 06/04/2018 01:46 PM, Hans Verkuil wrote:
> > From: Hans Verkuil <hans.verkuil@cisco.com>
> >
> > Add a 'bool from_other_dev' argument: set to true if the two
> > handlers refer to different devices (e.g. it is true when
> > inheriting controls from a subdev into a main v4l2 bridge
> > driver).
> >
> > This will be used later when implementing support for the
> > request API since we need to skip such controls.
> >
> > TODO: check drivers/staging/media/imx/imx-media-fim.c change.
>
> The basic idea is that while controls for a subdev can be
> added ('inherited') to a handler for a another parent subdev or
> video device, they should be marked as belonging to another device.
>
> This is needed when the Request API is introduced since the request
> should not have two copies of the same control (one belonging to the
> subdev, one inherited by e.g. a video device).
>
> However, I am not sure if I need to use true or false in the.
> imx_media_fim_add_controls() case. Do the controls added here belong
> to the same csi subdev or do they belong to another device?
>
> BTW, with 'belongs to' I mean that that's the device driver that
> implements the s_ctrl() call, i.e. actually sets up the hardware.
The FIM controls are created on the CSI subdev
via imx_media_fim_add_controls and then collected by the connected video
capture device:
$ media-ctl -p
[...]
- entity 53: ipu1_csi0 (3 pads, 4 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev8
[...]
pad2: Source
[fmt:AYUV8_1X32/1920x1080@1/30 field:none colorspace:rec709 xfer:709 ycbcr:709 quantization:lim-range]
-> "ipu1_csi0 capture":0 [ENABLED]
[...]
- entity 57: ipu1_csi0 capture (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video8
pad0: Sink
<- "ipu1_csi0":2 [ENABLED]
$ v4l2-ctl -d /dev/v4l-subdev8 -l
User Controls
fim_enable 0x00981990 (bool) : default=0 value=0
fim_num_average 0x00981991 (int) : min=1 max=64 step=1 default=8 value=8
fim_tolerance_min 0x00981992 (int) : min=2 max=200 step=1 default=50 value=50
fim_tolerance_max 0x00981993 (int) : min=0 max=500 step=1 default=0 value=0
fim_num_skip 0x00981994 (int) : min=0 max=256 step=1 default=2 value=2
fim_input_capture_edge 0x00981995 (int) : min=0 max=3 step=1 default=0 value=0
fim_input_capture_channel 0x00981996 (int) : min=0 max=1 step=1 default=0 value=0
$ v4l2-ctl -d /dev/video8 -l
User Controls
audio_sampling_rate 0x00981980 (int) : min=0 max=768000 step=1 default=0 value=0 flags=read-only
audio_present 0x00981981 (bool) : default=0 value=0 flags=read-only
fim_enable 0x00981990 (bool) : default=0 value=0
fim_num_average 0x00981991 (int) : min=1 max=64 step=1 default=8 value=8
fim_tolerance_min 0x00981992 (int) : min=2 max=200 step=1 default=50 value=50
fim_tolerance_max 0x00981993 (int) : min=0 max=500 step=1 default=0 value=0
fim_num_skip 0x00981994 (int) : min=0 max=256 step=1 default=2 value=2
fim_input_capture_edge 0x00981995 (int) : min=0 max=3 step=1 default=0 value=0
fim_input_capture_channel 0x00981996 (int) : min=0 max=1 step=1 default=0 value=0
Digital Video Controls
power_present 0x00a00964 (bitmask): max=0x00000001 default=0x00000000 value=0x00000001 flags=read-only
I believe this means your patch is correct, as the controls are created
for the CSI subdev, not inherited from another subdev.
regards
Philipp
> Regards,
>
> Hans
>
> >
> > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
> > ---
> > drivers/media/dvb-frontends/rtl2832_sdr.c | 5 +-
> > drivers/media/pci/bt8xx/bttv-driver.c | 2 +-
> > drivers/media/pci/cx23885/cx23885-417.c | 2 +-
> > drivers/media/pci/cx88/cx88-blackbird.c | 2 +-
> > drivers/media/pci/cx88/cx88-video.c | 2 +-
> > drivers/media/pci/saa7134/saa7134-empress.c | 4 +-
> > drivers/media/pci/saa7134/saa7134-video.c | 2 +-
> > .../media/platform/exynos4-is/fimc-capture.c | 2 +-
> > drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
> > drivers/media/platform/rcar_drif.c | 2 +-
> > .../media/platform/soc_camera/soc_camera.c | 3 +-
> > drivers/media/platform/vivid/vivid-ctrls.c | 46 +++++++++----------
> > drivers/media/usb/cx231xx/cx231xx-417.c | 2 +-
> > drivers/media/usb/cx231xx/cx231xx-video.c | 4 +-
> > drivers/media/usb/msi2500/msi2500.c | 2 +-
> > drivers/media/usb/tm6000/tm6000-video.c | 2 +-
> > drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++--
> > drivers/media/v4l2-core/v4l2-device.c | 3 +-
> > drivers/staging/media/imx/imx-media-dev.c | 2 +-
> > drivers/staging/media/imx/imx-media-fim.c | 2 +-
> > include/media/v4l2-ctrls.h | 8 +++-
> > 21 files changed, 61 insertions(+), 49 deletions(-)
> >
>
> <snip>
>
> > diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c
> > index 289d775c4820..08799beaea42 100644
> > --- a/drivers/staging/media/imx/imx-media-dev.c
> > +++ b/drivers/staging/media/imx/imx-media-dev.c
> > @@ -391,7 +391,7 @@ static int imx_media_inherit_controls(struct imx_media_dev *imxmd,
> >
> > ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
> > sd->ctrl_handler,
> > - NULL);
> > + NULL, true);
> > if (ret)
> > return ret;
> > }
> > diff --git a/drivers/staging/media/imx/imx-media-fim.c b/drivers/staging/media/imx/imx-media-fim.c
> > index 6df189135db8..8cf773eef9da 100644
> > --- a/drivers/staging/media/imx/imx-media-fim.c
> > +++ b/drivers/staging/media/imx/imx-media-fim.c
> > @@ -463,7 +463,7 @@ int imx_media_fim_add_controls(struct imx_media_fim *fim)
> > {
> > /* add the FIM controls to the calling subdev ctrl handler */
> > return v4l2_ctrl_add_handler(fim->sd->ctrl_handler,
> > - &fim->ctrl_handler, NULL);
> > + &fim->ctrl_handler, NULL, false);
> > }
> > EXPORT_SYMBOL_GPL(imx_media_fim_add_controls);
> >
>
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev
2018-06-04 11:46 ` [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev Hans Verkuil
2018-06-04 16:22 ` Hans Verkuil
@ 2018-06-04 17:11 ` Ezequiel Garcia
1 sibling, 0 replies; 61+ messages in thread
From: Ezequiel Garcia @ 2018-06-04 17:11 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Hans Verkuil, Alexandre Courbot
On 4 June 2018 at 08:46, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add a 'bool from_other_dev' argument: set to true if the two
> handlers refer to different devices (e.g. it is true when
> inheriting controls from a subdev into a main v4l2 bridge
> driver).
>
> This will be used later when implementing support for the
> request API since we need to skip such controls.
>
> TODO: check drivers/staging/media/imx/imx-media-fim.c change.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
> ---
> drivers/media/dvb-frontends/rtl2832_sdr.c | 5 +-
> drivers/media/pci/bt8xx/bttv-driver.c | 2 +-
> drivers/media/pci/cx23885/cx23885-417.c | 2 +-
> drivers/media/pci/cx88/cx88-blackbird.c | 2 +-
> drivers/media/pci/cx88/cx88-video.c | 2 +-
> drivers/media/pci/saa7134/saa7134-empress.c | 4 +-
> drivers/media/pci/saa7134/saa7134-video.c | 2 +-
> .../media/platform/exynos4-is/fimc-capture.c | 2 +-
> drivers/media/platform/rcar-vin/rcar-core.c | 2 +-
> drivers/media/platform/rcar_drif.c | 2 +-
> .../media/platform/soc_camera/soc_camera.c | 3 +-
> drivers/media/platform/vivid/vivid-ctrls.c | 46 +++++++++----------
> drivers/media/usb/cx231xx/cx231xx-417.c | 2 +-
> drivers/media/usb/cx231xx/cx231xx-video.c | 4 +-
> drivers/media/usb/msi2500/msi2500.c | 2 +-
> drivers/media/usb/tm6000/tm6000-video.c | 2 +-
> drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++--
> drivers/media/v4l2-core/v4l2-device.c | 3 +-
> drivers/staging/media/imx/imx-media-dev.c | 2 +-
> drivers/staging/media/imx/imx-media-fim.c | 2 +-
> include/media/v4l2-ctrls.h | 8 +++-
> 21 files changed, 61 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/rtl2832_sdr.c b/drivers/media/dvb-frontends/rtl2832_sdr.c
> index c6e78d870ccd..6064d28224e8 100644
> --- a/drivers/media/dvb-frontends/rtl2832_sdr.c
> +++ b/drivers/media/dvb-frontends/rtl2832_sdr.c
> @@ -1394,7 +1394,8 @@ static int rtl2832_sdr_probe(struct platform_device *pdev)
> case RTL2832_SDR_TUNER_E4000:
> v4l2_ctrl_handler_init(&dev->hdl, 9);
> if (subdev)
> - v4l2_ctrl_add_handler(&dev->hdl, subdev->ctrl_handler, NULL);
> + v4l2_ctrl_add_handler(&dev->hdl, subdev->ctrl_handler,
> + NULL, true);
> break;
> case RTL2832_SDR_TUNER_R820T:
> case RTL2832_SDR_TUNER_R828D:
> @@ -1423,7 +1424,7 @@ static int rtl2832_sdr_probe(struct platform_device *pdev)
> v4l2_ctrl_handler_init(&dev->hdl, 2);
> if (subdev)
> v4l2_ctrl_add_handler(&dev->hdl, subdev->ctrl_handler,
> - NULL);
> + NULL, true);
> break;
> default:
> v4l2_ctrl_handler_init(&dev->hdl, 0);
> diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c
> index de3f44b8dec6..9341ef6e154f 100644
> --- a/drivers/media/pci/bt8xx/bttv-driver.c
> +++ b/drivers/media/pci/bt8xx/bttv-driver.c
> @@ -4211,7 +4211,7 @@ static int bttv_probe(struct pci_dev *dev, const struct pci_device_id *pci_id)
> /* register video4linux + input */
> if (!bttv_tvcards[btv->c.type].no_video) {
> v4l2_ctrl_add_handler(&btv->radio_ctrl_handler, hdl,
> - v4l2_ctrl_radio_filter);
> + v4l2_ctrl_radio_filter, false);
> if (btv->radio_ctrl_handler.error) {
> result = btv->radio_ctrl_handler.error;
> goto fail2;
> diff --git a/drivers/media/pci/cx23885/cx23885-417.c b/drivers/media/pci/cx23885/cx23885-417.c
> index a71f3c7569ce..762823871c78 100644
> --- a/drivers/media/pci/cx23885/cx23885-417.c
> +++ b/drivers/media/pci/cx23885/cx23885-417.c
> @@ -1527,7 +1527,7 @@ int cx23885_417_register(struct cx23885_dev *dev)
> dev->cxhdl.priv = dev;
> dev->cxhdl.func = cx23885_api_func;
> cx2341x_handler_set_50hz(&dev->cxhdl, tsport->height == 576);
> - v4l2_ctrl_add_handler(&dev->ctrl_handler, &dev->cxhdl.hdl, NULL);
> + v4l2_ctrl_add_handler(&dev->ctrl_handler, &dev->cxhdl.hdl, NULL, false);
>
> /* Allocate and initialize V4L video device */
> dev->v4l_device = cx23885_video_dev_alloc(tsport,
> diff --git a/drivers/media/pci/cx88/cx88-blackbird.c b/drivers/media/pci/cx88/cx88-blackbird.c
> index 7a4876cf9f08..722dd101c9b0 100644
> --- a/drivers/media/pci/cx88/cx88-blackbird.c
> +++ b/drivers/media/pci/cx88/cx88-blackbird.c
> @@ -1183,7 +1183,7 @@ static int cx8802_blackbird_probe(struct cx8802_driver *drv)
> err = cx2341x_handler_init(&dev->cxhdl, 36);
> if (err)
> goto fail_core;
> - v4l2_ctrl_add_handler(&dev->cxhdl.hdl, &core->video_hdl, NULL);
> + v4l2_ctrl_add_handler(&dev->cxhdl.hdl, &core->video_hdl, NULL, false);
>
> /* blackbird stuff */
> pr_info("cx23416 based mpeg encoder (blackbird reference design)\n");
> diff --git a/drivers/media/pci/cx88/cx88-video.c b/drivers/media/pci/cx88/cx88-video.c
> index 7b113bad70d2..85e2b6c9fb1c 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -1378,7 +1378,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
> if (vc->id == V4L2_CID_CHROMA_AGC)
> core->chroma_agc = vc;
> }
> - v4l2_ctrl_add_handler(&core->video_hdl, &core->audio_hdl, NULL);
> + v4l2_ctrl_add_handler(&core->video_hdl, &core->audio_hdl, NULL, false);
>
> /* load and configure helper modules */
>
> diff --git a/drivers/media/pci/saa7134/saa7134-empress.c b/drivers/media/pci/saa7134/saa7134-empress.c
> index 66acfd35ffc6..fc75ce00dbf8 100644
> --- a/drivers/media/pci/saa7134/saa7134-empress.c
> +++ b/drivers/media/pci/saa7134/saa7134-empress.c
> @@ -265,9 +265,9 @@ static int empress_init(struct saa7134_dev *dev)
> "%s empress (%s)", dev->name,
> saa7134_boards[dev->board].name);
> v4l2_ctrl_handler_init(hdl, 21);
> - v4l2_ctrl_add_handler(hdl, &dev->ctrl_handler, empress_ctrl_filter);
> + v4l2_ctrl_add_handler(hdl, &dev->ctrl_handler, empress_ctrl_filter, false);
> if (dev->empress_sd)
> - v4l2_ctrl_add_handler(hdl, dev->empress_sd->ctrl_handler, NULL);
> + v4l2_ctrl_add_handler(hdl, dev->empress_sd->ctrl_handler, NULL, true);
> if (hdl->error) {
> video_device_release(dev->empress_dev);
> return hdl->error;
> diff --git a/drivers/media/pci/saa7134/saa7134-video.c b/drivers/media/pci/saa7134/saa7134-video.c
> index 1a50ec9d084f..41d46488d22e 100644
> --- a/drivers/media/pci/saa7134/saa7134-video.c
> +++ b/drivers/media/pci/saa7134/saa7134-video.c
> @@ -2136,7 +2136,7 @@ int saa7134_video_init1(struct saa7134_dev *dev)
> hdl = &dev->radio_ctrl_handler;
> v4l2_ctrl_handler_init(hdl, 2);
> v4l2_ctrl_add_handler(hdl, &dev->ctrl_handler,
> - v4l2_ctrl_radio_filter);
> + v4l2_ctrl_radio_filter, false);
> if (hdl->error)
> return hdl->error;
> }
> diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c
> index a3cdac188190..2164375f0ee0 100644
> --- a/drivers/media/platform/exynos4-is/fimc-capture.c
> +++ b/drivers/media/platform/exynos4-is/fimc-capture.c
> @@ -1424,7 +1424,7 @@ static int fimc_link_setup(struct media_entity *entity,
> return 0;
>
> return v4l2_ctrl_add_handler(&vc->ctx->ctrls.handler,
> - sensor->ctrl_handler, NULL);
> + sensor->ctrl_handler, NULL, true);
> }
>
> static const struct media_entity_operations fimc_sd_media_ops = {
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
> index d3072e166a1c..2c115c6651b0 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -442,7 +442,7 @@ static int rvin_digital_subdevice_attach(struct rvin_dev *vin,
> return ret;
>
> ret = v4l2_ctrl_add_handler(&vin->ctrl_handler, subdev->ctrl_handler,
> - NULL);
> + NULL, true);
> if (ret < 0) {
> v4l2_ctrl_handler_free(&vin->ctrl_handler);
> return ret;
> diff --git a/drivers/media/platform/rcar_drif.c b/drivers/media/platform/rcar_drif.c
> index dc7e280c91b4..159c7d2c2066 100644
> --- a/drivers/media/platform/rcar_drif.c
> +++ b/drivers/media/platform/rcar_drif.c
> @@ -1168,7 +1168,7 @@ static int rcar_drif_notify_complete(struct v4l2_async_notifier *notifier)
> }
>
> ret = v4l2_ctrl_add_handler(&sdr->ctrl_hdl,
> - sdr->ep.subdev->ctrl_handler, NULL);
> + sdr->ep.subdev->ctrl_handler, NULL, true);
> if (ret) {
> rdrif_err(sdr, "failed: ctrl add hdlr ret %d\n", ret);
> goto error;
> diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c
> index 69f0d8e80bd8..e6787abc34ae 100644
> --- a/drivers/media/platform/soc_camera/soc_camera.c
> +++ b/drivers/media/platform/soc_camera/soc_camera.c
> @@ -1180,7 +1180,8 @@ static int soc_camera_probe_finish(struct soc_camera_device *icd)
>
> v4l2_subdev_call(sd, video, g_tvnorms, &icd->vdev->tvnorms);
>
> - ret = v4l2_ctrl_add_handler(&icd->ctrl_handler, sd->ctrl_handler, NULL);
> + ret = v4l2_ctrl_add_handler(&icd->ctrl_handler, sd->ctrl_handler,
> + NULL, true);
> if (ret < 0)
> return ret;
>
> diff --git a/drivers/media/platform/vivid/vivid-ctrls.c b/drivers/media/platform/vivid/vivid-ctrls.c
> index 6b0bfa091592..f369b94ad7ff 100644
> --- a/drivers/media/platform/vivid/vivid-ctrls.c
> +++ b/drivers/media/platform/vivid/vivid-ctrls.c
> @@ -1662,59 +1662,59 @@ int vivid_create_controls(struct vivid_dev *dev, bool show_ccs_cap,
> v4l2_ctrl_auto_cluster(2, &dev->autogain, 0, true);
>
> if (dev->has_vid_cap) {
> - v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_gen, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_vid, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_aud, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_cap, hdl_streaming, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_cap, hdl_sdtv_cap, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_cap, hdl_loop_cap, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_cap, hdl_fb, NULL);
> + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_gen, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_vid, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_user_aud, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_streaming, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_sdtv_cap, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_loop_cap, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_cap, hdl_fb, NULL, false);
> if (hdl_vid_cap->error)
> return hdl_vid_cap->error;
> dev->vid_cap_dev.ctrl_handler = hdl_vid_cap;
> }
> if (dev->has_vid_out) {
> - v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_gen, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_aud, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_out, hdl_streaming, NULL);
> - v4l2_ctrl_add_handler(hdl_vid_out, hdl_fb, NULL);
> + v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_gen, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_out, hdl_user_aud, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_out, hdl_streaming, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vid_out, hdl_fb, NULL, false);
> if (hdl_vid_out->error)
> return hdl_vid_out->error;
> dev->vid_out_dev.ctrl_handler = hdl_vid_out;
> }
> if (dev->has_vbi_cap) {
> - v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_user_gen, NULL);
> - v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_streaming, NULL);
> - v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_sdtv_cap, NULL);
> - v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_loop_cap, NULL);
> + v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_user_gen, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_streaming, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_sdtv_cap, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vbi_cap, hdl_loop_cap, NULL, false);
> if (hdl_vbi_cap->error)
> return hdl_vbi_cap->error;
> dev->vbi_cap_dev.ctrl_handler = hdl_vbi_cap;
> }
> if (dev->has_vbi_out) {
> - v4l2_ctrl_add_handler(hdl_vbi_out, hdl_user_gen, NULL);
> - v4l2_ctrl_add_handler(hdl_vbi_out, hdl_streaming, NULL);
> + v4l2_ctrl_add_handler(hdl_vbi_out, hdl_user_gen, NULL, false);
> + v4l2_ctrl_add_handler(hdl_vbi_out, hdl_streaming, NULL, false);
> if (hdl_vbi_out->error)
> return hdl_vbi_out->error;
> dev->vbi_out_dev.ctrl_handler = hdl_vbi_out;
> }
> if (dev->has_radio_rx) {
> - v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_gen, NULL);
> - v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_aud, NULL);
> + v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_gen, NULL, false);
> + v4l2_ctrl_add_handler(hdl_radio_rx, hdl_user_aud, NULL, false);
> if (hdl_radio_rx->error)
> return hdl_radio_rx->error;
> dev->radio_rx_dev.ctrl_handler = hdl_radio_rx;
> }
> if (dev->has_radio_tx) {
> - v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_gen, NULL);
> - v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_aud, NULL);
> + v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_gen, NULL, false);
> + v4l2_ctrl_add_handler(hdl_radio_tx, hdl_user_aud, NULL, false);
> if (hdl_radio_tx->error)
> return hdl_radio_tx->error;
> dev->radio_tx_dev.ctrl_handler = hdl_radio_tx;
> }
> if (dev->has_sdr_cap) {
> - v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_user_gen, NULL);
> - v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_streaming, NULL);
> + v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_user_gen, NULL, false);
> + v4l2_ctrl_add_handler(hdl_sdr_cap, hdl_streaming, NULL, false);
> if (hdl_sdr_cap->error)
> return hdl_sdr_cap->error;
> dev->sdr_cap_dev.ctrl_handler = hdl_sdr_cap;
> diff --git a/drivers/media/usb/cx231xx/cx231xx-417.c b/drivers/media/usb/cx231xx/cx231xx-417.c
> index 2f3b0564d676..e3cb9eefd36a 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-417.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-417.c
> @@ -1992,7 +1992,7 @@ int cx231xx_417_register(struct cx231xx *dev)
> dev->mpeg_ctrl_handler.ops = &cx231xx_ops;
> if (dev->sd_cx25840)
> v4l2_ctrl_add_handler(&dev->mpeg_ctrl_handler.hdl,
> - dev->sd_cx25840->ctrl_handler, NULL);
> + dev->sd_cx25840->ctrl_handler, NULL, false);
> if (dev->mpeg_ctrl_handler.hdl.error) {
> err = dev->mpeg_ctrl_handler.hdl.error;
> dprintk(3, "%s: can't add cx25840 controls\n", dev->name);
> diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c b/drivers/media/usb/cx231xx/cx231xx-video.c
> index f7fcd733a2ca..2dedb18f63a0 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-video.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-video.c
> @@ -2204,10 +2204,10 @@ int cx231xx_register_analog_devices(struct cx231xx *dev)
>
> if (dev->sd_cx25840) {
> v4l2_ctrl_add_handler(&dev->ctrl_handler,
> - dev->sd_cx25840->ctrl_handler, NULL);
> + dev->sd_cx25840->ctrl_handler, NULL, true);
> v4l2_ctrl_add_handler(&dev->radio_ctrl_handler,
> dev->sd_cx25840->ctrl_handler,
> - v4l2_ctrl_radio_filter);
> + v4l2_ctrl_radio_filter, true);
> }
>
> if (dev->ctrl_handler.error)
> diff --git a/drivers/media/usb/msi2500/msi2500.c b/drivers/media/usb/msi2500/msi2500.c
> index 65ef755adfdc..4aacd77a5d58 100644
> --- a/drivers/media/usb/msi2500/msi2500.c
> +++ b/drivers/media/usb/msi2500/msi2500.c
> @@ -1278,7 +1278,7 @@ static int msi2500_probe(struct usb_interface *intf,
> }
>
> /* currently all controls are from subdev */
> - v4l2_ctrl_add_handler(&dev->hdl, sd->ctrl_handler, NULL);
> + v4l2_ctrl_add_handler(&dev->hdl, sd->ctrl_handler, NULL, true);
>
> dev->v4l2_dev.ctrl_handler = &dev->hdl;
> dev->vdev.v4l2_dev = &dev->v4l2_dev;
> diff --git a/drivers/media/usb/tm6000/tm6000-video.c b/drivers/media/usb/tm6000/tm6000-video.c
> index aa85fe31c835..d2850ce13e76 100644
> --- a/drivers/media/usb/tm6000/tm6000-video.c
> +++ b/drivers/media/usb/tm6000/tm6000-video.c
> @@ -1622,7 +1622,7 @@ int tm6000_v4l2_register(struct tm6000_core *dev)
> v4l2_ctrl_new_std(&dev->ctrl_handler, &tm6000_ctrl_ops,
> V4L2_CID_HUE, -128, 127, 1, 0);
> v4l2_ctrl_add_handler(&dev->ctrl_handler,
> - &dev->radio_ctrl_handler, NULL);
> + &dev->radio_ctrl_handler, NULL, false);
>
> if (dev->radio_ctrl_handler.error)
> ret = dev->radio_ctrl_handler.error;
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index d29e45516eb7..aa1dd2015e84 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1995,7 +1995,8 @@ EXPORT_SYMBOL(v4l2_ctrl_find);
>
> /* Allocate a new v4l2_ctrl_ref and hook it into the handler. */
> static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
> - struct v4l2_ctrl *ctrl)
> + struct v4l2_ctrl *ctrl,
> + bool from_other_dev)
> {
> struct v4l2_ctrl_ref *ref;
> struct v4l2_ctrl_ref *new_ref;
> @@ -2019,6 +2020,7 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
> if (!new_ref)
> return handler_set_err(hdl, -ENOMEM);
> new_ref->ctrl = ctrl;
> + new_ref->from_other_dev = from_other_dev;
> if (ctrl->handler == hdl) {
> /* By default each control starts in a cluster of its own.
> new_ref->ctrl is basically a cluster array with one
> @@ -2199,7 +2201,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
> ctrl->type_ops->init(ctrl, idx, ctrl->p_new);
> }
>
> - if (handler_new_ref(hdl, ctrl)) {
> + if (handler_new_ref(hdl, ctrl, false)) {
> kvfree(ctrl);
> return NULL;
> }
> @@ -2368,7 +2370,8 @@ EXPORT_SYMBOL(v4l2_ctrl_new_int_menu);
> /* Add the controls from another handler to our own. */
> int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
> struct v4l2_ctrl_handler *add,
> - bool (*filter)(const struct v4l2_ctrl *ctrl))
> + bool (*filter)(const struct v4l2_ctrl *ctrl),
> + bool from_other_dev)
I am wondering if it would make the patch less invasive,
and the code cleaner, to rename this to v4l2_ctrl_add_handler_ex().
v4l2_ctrl_add_handler would then default from_other_dev to false.
In fact -but not related to this patch- given the number of users
setting a non-NULL filter, we could even consider v4l2_ctrl_add_handler
to set a NULL filter.
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 10/35] v4l2-ctrls: prepare internal structs for request API
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (8 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 09/35] v4l2-ctrls: v4l2_ctrl_add_handler: add from_other_dev Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 11/35] v4l2-ctrls: alloc memory for p_req Hans Verkuil
` (24 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil, Alexandre Courbot
From: Hans Verkuil <hans.verkuil@cisco.com>
Embed and initialize a media_request_object in struct v4l2_ctrl_handler.
Add a p_req field to struct v4l2_ctrl_ref that will store the
request value.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
---
drivers/media/v4l2-core/v4l2-ctrls.c | 1 +
include/media/v4l2-ctrls.h | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index aa1dd2015e84..d09f49530d9e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1880,6 +1880,7 @@ int v4l2_ctrl_handler_init_class(struct v4l2_ctrl_handler *hdl,
sizeof(hdl->buckets[0]),
GFP_KERNEL | __GFP_ZERO);
hdl->error = hdl->buckets ? 0 : -ENOMEM;
+ media_request_object_init(&hdl->req_obj);
return hdl->error;
}
EXPORT_SYMBOL(v4l2_ctrl_handler_init_class);
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index d26b8ddebb56..847d6f543e4a 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -20,6 +20,7 @@
#include <linux/list.h>
#include <linux/mutex.h>
#include <linux/videodev2.h>
+#include <media/media-request.h>
/* forward references */
struct file;
@@ -249,6 +250,11 @@ struct v4l2_ctrl {
* ``prepare_ext_ctrls`` function at ``v4l2-ctrl.c``.
* @from_other_dev: If true, then @ctrl was defined in another
* device than the &struct v4l2_ctrl_handler.
+ * @p_req: If the control handler containing this control reference
+ * is bound to a media request, then this points to the
+ * value of the control that should be applied when the request
+ * is executed, or to the value of the control at the time
+ * that the request was completed.
*
* Each control handler has a list of these refs. The list_head is used to
* keep a sorted-by-control-ID list of all controls, while the next pointer
@@ -260,6 +266,7 @@ struct v4l2_ctrl_ref {
struct v4l2_ctrl *ctrl;
struct v4l2_ctrl_helper *helper;
bool from_other_dev;
+ union v4l2_ctrl_ptr p_req;
};
/**
@@ -283,6 +290,8 @@ struct v4l2_ctrl_ref {
* @notify_priv: Passed as argument to the v4l2_ctrl notify callback.
* @nr_of_buckets: Total number of buckets in the array.
* @error: The error code of the first failed control addition.
+ * @req_obj: The &struct media_request_object, used to link into a
+ * &struct media_request. This request object has a refcount.
*/
struct v4l2_ctrl_handler {
struct mutex _lock;
@@ -295,6 +304,7 @@ struct v4l2_ctrl_handler {
void *notify_priv;
u16 nr_of_buckets;
int error;
+ struct media_request_object req_obj;
};
/**
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 11/35] v4l2-ctrls: alloc memory for p_req
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (9 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 10/35] v4l2-ctrls: prepare internal structs for request API Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 12/35] v4l2-ctrls: use ref in helper instead of ctrl Hans Verkuil
` (23 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
To store request data the handler_new_ref() allocates memory
for it if needed.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/v4l2-core/v4l2-ctrls.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index d09f49530d9e..3c1b00baa8d0 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1997,13 +1997,18 @@ EXPORT_SYMBOL(v4l2_ctrl_find);
/* Allocate a new v4l2_ctrl_ref and hook it into the handler. */
static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
struct v4l2_ctrl *ctrl,
- bool from_other_dev)
+ struct v4l2_ctrl_ref **ctrl_ref,
+ bool from_other_dev, bool allocate_req)
{
struct v4l2_ctrl_ref *ref;
struct v4l2_ctrl_ref *new_ref;
u32 id = ctrl->id;
u32 class_ctrl = V4L2_CTRL_ID2WHICH(id) | 1;
int bucket = id % hdl->nr_of_buckets; /* which bucket to use */
+ unsigned int sz_extra = 0;
+
+ if (ctrl_ref)
+ *ctrl_ref = NULL;
/*
* Automatically add the control class if it is not yet present and
@@ -2017,11 +2022,16 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
if (hdl->error)
return hdl->error;
- new_ref = kzalloc(sizeof(*new_ref), GFP_KERNEL);
+ if (allocate_req)
+ sz_extra = ctrl->elems * ctrl->elem_size;
+ new_ref = kzalloc(sizeof(*new_ref) + sz_extra, GFP_KERNEL);
if (!new_ref)
return handler_set_err(hdl, -ENOMEM);
new_ref->ctrl = ctrl;
new_ref->from_other_dev = from_other_dev;
+ if (sz_extra)
+ new_ref->p_req.p = &new_ref[1];
+
if (ctrl->handler == hdl) {
/* By default each control starts in a cluster of its own.
new_ref->ctrl is basically a cluster array with one
@@ -2061,6 +2071,8 @@ static int handler_new_ref(struct v4l2_ctrl_handler *hdl,
/* Insert the control node in the hash */
new_ref->next = hdl->buckets[bucket];
hdl->buckets[bucket] = new_ref;
+ if (ctrl_ref)
+ *ctrl_ref = new_ref;
unlock:
mutex_unlock(hdl->lock);
@@ -2202,7 +2214,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
ctrl->type_ops->init(ctrl, idx, ctrl->p_new);
}
- if (handler_new_ref(hdl, ctrl, false)) {
+ if (handler_new_ref(hdl, ctrl, NULL, false, false)) {
kvfree(ctrl);
return NULL;
}
@@ -2395,7 +2407,7 @@ int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
/* Filter any unwanted controls */
if (filter && !filter(ctrl))
continue;
- ret = handler_new_ref(hdl, ctrl, from_other_dev);
+ ret = handler_new_ref(hdl, ctrl, NULL, from_other_dev, false);
if (ret)
break;
}
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 12/35] v4l2-ctrls: use ref in helper instead of ctrl
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (10 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 11/35] v4l2-ctrls: alloc memory for p_req Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 13/35] v4l2-ctrls: add core request support Hans Verkuil
` (22 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
The next patch needs the reference to a control instead of the
control itself, so change struct v4l2_ctrl_helper accordingly.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/v4l2-core/v4l2-ctrls.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index 3c1b00baa8d0..da4cc1485dc4 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -37,8 +37,8 @@
struct v4l2_ctrl_helper {
/* Pointer to the control reference of the master control */
struct v4l2_ctrl_ref *mref;
- /* The control corresponding to the v4l2_ext_control ID field. */
- struct v4l2_ctrl *ctrl;
+ /* The control ref corresponding to the v4l2_ext_control ID field. */
+ struct v4l2_ctrl_ref *ref;
/* v4l2_ext_control index of the next control belonging to the
same cluster, or 0 if there isn't any. */
u32 next;
@@ -2887,6 +2887,7 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler *hdl,
ref = find_ref_lock(hdl, id);
if (ref == NULL)
return -EINVAL;
+ h->ref = ref;
ctrl = ref->ctrl;
if (ctrl->flags & V4L2_CTRL_FLAG_DISABLED)
return -EINVAL;
@@ -2909,7 +2910,6 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler *hdl,
}
/* Store the ref to the master control of the cluster */
h->mref = ref;
- h->ctrl = ctrl;
/* Initially set next to 0, meaning that there is no other
control in this helper array belonging to the same
cluster */
@@ -2994,7 +2994,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs
cs->error_idx = cs->count;
for (i = 0; !ret && i < cs->count; i++)
- if (helpers[i].ctrl->flags & V4L2_CTRL_FLAG_WRITE_ONLY)
+ if (helpers[i].ref->ctrl->flags & V4L2_CTRL_FLAG_WRITE_ONLY)
ret = -EACCES;
for (i = 0; !ret && i < cs->count; i++) {
@@ -3029,7 +3029,7 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs
do {
ret = ctrl_to_user(cs->controls + idx,
- helpers[idx].ctrl);
+ helpers[idx].ref->ctrl);
idx = helpers[idx].next;
} while (!ret && idx);
}
@@ -3168,7 +3168,7 @@ static int validate_ctrls(struct v4l2_ext_controls *cs,
cs->error_idx = cs->count;
for (i = 0; i < cs->count; i++) {
- struct v4l2_ctrl *ctrl = helpers[i].ctrl;
+ struct v4l2_ctrl *ctrl = helpers[i].ref->ctrl;
union v4l2_ctrl_ptr p_new;
cs->error_idx = i;
@@ -3280,7 +3280,7 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
do {
/* Check if the auto control is part of the
list, and remember the new value. */
- if (helpers[tmp_idx].ctrl == master)
+ if (helpers[tmp_idx].ref->ctrl == master)
new_auto_val = cs->controls[tmp_idx].value;
tmp_idx = helpers[tmp_idx].next;
} while (tmp_idx);
@@ -3293,7 +3293,7 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
/* Copy the new caller-supplied control values.
user_to_new() sets 'is_new' to 1. */
do {
- struct v4l2_ctrl *ctrl = helpers[idx].ctrl;
+ struct v4l2_ctrl *ctrl = helpers[idx].ref->ctrl;
ret = user_to_new(cs->controls + idx, ctrl);
if (!ret && ctrl->is_ptr)
@@ -3309,7 +3309,7 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
idx = i;
do {
ret = new_to_user(cs->controls + idx,
- helpers[idx].ctrl);
+ helpers[idx].ref->ctrl);
idx = helpers[idx].next;
} while (!ret && idx);
}
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 13/35] v4l2-ctrls: add core request support
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (11 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 12/35] v4l2-ctrls: use ref in helper instead of ctrl Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 17:18 ` Ezequiel Garcia
2018-06-15 7:18 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 14/35] v4l2-ctrls: support g/s_ext_ctrls for requests Hans Verkuil
` (21 subsequent siblings)
34 siblings, 2 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Integrate the request support. This adds the v4l2_ctrl_request_complete
and v4l2_ctrl_request_setup functions to complete a request and (as a
helper function) to apply a request to the hardware.
It takes care of queuing requests and correctly chaining control values
in the request queue.
Note that when a request is marked completed it will copy control values
to the internal request state. This can be optimized in the future since
this is sub-optimal when dealing with large compound and/or array controls.
For the initial 'stateless codec' use-case the current implementation is
sufficient.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/v4l2-core/v4l2-ctrls.c | 331 ++++++++++++++++++++++++++-
include/media/v4l2-ctrls.h | 51 +++++
2 files changed, 376 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index da4cc1485dc4..bd4818507486 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1647,6 +1647,13 @@ static int new_to_user(struct v4l2_ext_control *c,
return ptr_to_user(c, ctrl, ctrl->p_new);
}
+/* Helper function: copy the request value back to the caller */
+static int req_to_user(struct v4l2_ext_control *c,
+ struct v4l2_ctrl_ref *ref)
+{
+ return ptr_to_user(c, ref->ctrl, ref->p_req);
+}
+
/* Helper function: copy the initial control value back to the caller */
static int def_to_user(struct v4l2_ext_control *c, struct v4l2_ctrl *ctrl)
{
@@ -1766,6 +1773,26 @@ static void cur_to_new(struct v4l2_ctrl *ctrl)
ptr_to_ptr(ctrl, ctrl->p_cur, ctrl->p_new);
}
+/* Copy the new value to the request value */
+static void new_to_req(struct v4l2_ctrl_ref *ref)
+{
+ if (!ref)
+ return;
+ ptr_to_ptr(ref->ctrl, ref->ctrl->p_new, ref->p_req);
+ ref->req = ref;
+}
+
+/* Copy the request value to the new value */
+static void req_to_new(struct v4l2_ctrl_ref *ref)
+{
+ if (!ref)
+ return;
+ if (ref->req)
+ ptr_to_ptr(ref->ctrl, ref->req->p_req, ref->ctrl->p_new);
+ else
+ ptr_to_ptr(ref->ctrl, ref->ctrl->p_cur, ref->ctrl->p_new);
+}
+
/* Return non-zero if one or more of the controls in the cluster has a new
value that differs from the current value. */
static int cluster_changed(struct v4l2_ctrl *master)
@@ -1875,6 +1902,9 @@ int v4l2_ctrl_handler_init_class(struct v4l2_ctrl_handler *hdl,
lockdep_set_class_and_name(hdl->lock, key, name);
INIT_LIST_HEAD(&hdl->ctrls);
INIT_LIST_HEAD(&hdl->ctrl_refs);
+ INIT_LIST_HEAD(&hdl->requests);
+ INIT_LIST_HEAD(&hdl->requests_queued);
+ hdl->request_is_queued = false;
hdl->nr_of_buckets = 1 + nr_of_controls_hint / 8;
hdl->buckets = kvmalloc_array(hdl->nr_of_buckets,
sizeof(hdl->buckets[0]),
@@ -1895,6 +1925,14 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
if (hdl == NULL || hdl->buckets == NULL)
return;
+ if (!hdl->req_obj.req && !list_empty(&hdl->requests)) {
+ struct v4l2_ctrl_handler *req, *next_req;
+
+ list_for_each_entry_safe(req, next_req, &hdl->requests, requests) {
+ media_request_object_unbind(&req->req_obj);
+ media_request_object_put(&req->req_obj);
+ }
+ }
mutex_lock(hdl->lock);
/* Free all nodes */
list_for_each_entry_safe(ref, next_ref, &hdl->ctrl_refs, node) {
@@ -2816,6 +2854,128 @@ int v4l2_querymenu(struct v4l2_ctrl_handler *hdl, struct v4l2_querymenu *qm)
}
EXPORT_SYMBOL(v4l2_querymenu);
+static int v4l2_ctrl_request_clone(struct v4l2_ctrl_handler *hdl,
+ const struct v4l2_ctrl_handler *from)
+{
+ struct v4l2_ctrl_ref *ref;
+ int err;
+
+ if (WARN_ON(!hdl || hdl == from))
+ return -EINVAL;
+
+ if (hdl->error)
+ return hdl->error;
+
+ WARN_ON(hdl->lock != &hdl->_lock);
+
+ mutex_lock(from->lock);
+ list_for_each_entry(ref, &from->ctrl_refs, node) {
+ struct v4l2_ctrl *ctrl = ref->ctrl;
+ struct v4l2_ctrl_ref *new_ref;
+
+ /* Skip refs inherited from other devices */
+ if (ref->from_other_dev)
+ continue;
+ /* And buttons */
+ if (ctrl->type == V4L2_CTRL_TYPE_BUTTON)
+ continue;
+ err = handler_new_ref(hdl, ctrl, &new_ref, false, true);
+ if (err) {
+ printk("%s: handler_new_ref on control %x (%s) returned %d\n", __func__, ctrl->id, ctrl->name, err);
+ err = 0;
+ continue;
+ }
+ if (err)
+ break;
+ }
+ mutex_unlock(from->lock);
+ return err;
+}
+
+static void v4l2_ctrl_request_queue(struct media_request_object *obj)
+{
+ struct v4l2_ctrl_handler *hdl =
+ container_of(obj, struct v4l2_ctrl_handler, req_obj);
+ struct v4l2_ctrl_handler *main_hdl = obj->priv;
+ struct v4l2_ctrl_handler *prev_hdl = NULL;
+ struct v4l2_ctrl_ref *ref_ctrl, *ref_ctrl_prev = NULL;
+
+ if (list_empty(&main_hdl->requests_queued))
+ goto queue;
+
+ prev_hdl = list_last_entry(&main_hdl->requests_queued,
+ struct v4l2_ctrl_handler, requests_queued);
+ /*
+ * Note: prev_hdl and hdl must contain the same list of control
+ * references, so if any differences are detected then that is a
+ * driver bug and the WARN_ON is triggered.
+ */
+ mutex_lock(prev_hdl->lock);
+ ref_ctrl_prev = list_first_entry(&prev_hdl->ctrl_refs,
+ struct v4l2_ctrl_ref, node);
+ list_for_each_entry(ref_ctrl, &hdl->ctrl_refs, node) {
+ if (ref_ctrl->req)
+ continue;
+ while (ref_ctrl_prev->ctrl->id < ref_ctrl->ctrl->id) {
+ /* Should never happen, but just in case... */
+ if (list_is_last(&ref_ctrl_prev->node,
+ &prev_hdl->ctrl_refs))
+ break;
+ ref_ctrl_prev = list_next_entry(ref_ctrl_prev, node);
+ }
+ if (WARN_ON(ref_ctrl_prev->ctrl->id != ref_ctrl->ctrl->id))
+ break;
+ ref_ctrl->req = ref_ctrl_prev->req;
+ }
+ mutex_unlock(prev_hdl->lock);
+queue:
+ list_add_tail(&hdl->requests_queued, &main_hdl->requests_queued);
+ hdl->request_is_queued = true;
+}
+
+static void v4l2_ctrl_request_unbind(struct media_request_object *obj)
+{
+ struct v4l2_ctrl_handler *hdl =
+ container_of(obj, struct v4l2_ctrl_handler, req_obj);
+
+ list_del_init(&hdl->requests);
+ if (hdl->request_is_queued) {
+ list_del_init(&hdl->requests_queued);
+ hdl->request_is_queued = false;
+ }
+}
+
+static void v4l2_ctrl_request_release(struct media_request_object *obj)
+{
+ struct v4l2_ctrl_handler *hdl =
+ container_of(obj, struct v4l2_ctrl_handler, req_obj);
+
+ v4l2_ctrl_handler_free(hdl);
+ kfree(hdl);
+}
+
+static const struct media_request_object_ops req_ops = {
+ .queue = v4l2_ctrl_request_queue,
+ .unbind = v4l2_ctrl_request_unbind,
+ .release = v4l2_ctrl_request_release,
+};
+
+static int v4l2_ctrl_request_bind(struct media_request *req,
+ struct v4l2_ctrl_handler *hdl,
+ struct v4l2_ctrl_handler *from)
+{
+ int ret;
+
+ ret = v4l2_ctrl_request_clone(hdl, from);
+
+ if (!ret) {
+ ret = media_request_object_bind(req, &req_ops,
+ from, &hdl->req_obj);
+ if (!ret)
+ list_add_tail(&hdl->requests, &from->requests);
+ }
+ return ret;
+}
/* Some general notes on the atomic requirements of VIDIOC_G/TRY/S_EXT_CTRLS:
@@ -2877,6 +3037,7 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler *hdl,
if (cs->which &&
cs->which != V4L2_CTRL_WHICH_DEF_VAL &&
+ cs->which != V4L2_CTRL_WHICH_REQUEST_VAL &&
V4L2_CTRL_ID2WHICH(id) != cs->which)
return -EINVAL;
@@ -2956,13 +3117,12 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler *hdl,
whether there are any controls at all. */
static int class_check(struct v4l2_ctrl_handler *hdl, u32 which)
{
- if (which == 0 || which == V4L2_CTRL_WHICH_DEF_VAL)
+ if (which == 0 || which == V4L2_CTRL_WHICH_DEF_VAL ||
+ which == V4L2_CTRL_WHICH_REQUEST_VAL)
return 0;
return find_ref_lock(hdl, which | 1) ? 0 : -EINVAL;
}
-
-
/* Get extended controls. Allocates the helpers array if needed. */
int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs)
{
@@ -3028,8 +3188,12 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs
u32 idx = i;
do {
- ret = ctrl_to_user(cs->controls + idx,
- helpers[idx].ref->ctrl);
+ if (helpers[idx].ref->req)
+ ret = req_to_user(cs->controls + idx,
+ helpers[idx].ref->req);
+ else
+ ret = ctrl_to_user(cs->controls + idx,
+ helpers[idx].ref->ctrl);
idx = helpers[idx].next;
} while (!ret && idx);
}
@@ -3302,7 +3466,16 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
} while (!ret && idx);
if (!ret)
- ret = try_or_set_cluster(fh, master, set, 0);
+ ret = try_or_set_cluster(fh, master,
+ !hdl->req_obj.req && set, 0);
+ if (!ret && hdl->req_obj.req && set) {
+ for (j = 0; j < master->ncontrols; j++) {
+ struct v4l2_ctrl_ref *ref =
+ find_ref(hdl, master->cluster[j]->id);
+
+ new_to_req(ref);
+ }
+ }
/* Copy the new values back to userspace. */
if (!ret) {
@@ -3429,6 +3602,152 @@ int __v4l2_ctrl_s_ctrl_string(struct v4l2_ctrl *ctrl, const char *s)
}
EXPORT_SYMBOL(__v4l2_ctrl_s_ctrl_string);
+void v4l2_ctrl_request_complete(struct media_request *req,
+ struct v4l2_ctrl_handler *main_hdl)
+{
+ struct media_request_object *obj;
+ struct v4l2_ctrl_handler *hdl;
+ struct v4l2_ctrl_ref *ref;
+
+ if (!req || !main_hdl)
+ return;
+
+ obj = media_request_object_find(req, &req_ops, main_hdl);
+ if (!obj)
+ return;
+ hdl = container_of(obj, struct v4l2_ctrl_handler, req_obj);
+
+ list_for_each_entry(ref, &hdl->ctrl_refs, node) {
+ struct v4l2_ctrl *ctrl = ref->ctrl;
+ struct v4l2_ctrl *master = ctrl->cluster[0];
+ unsigned int i;
+
+ if (ctrl->flags & V4L2_CTRL_FLAG_VOLATILE) {
+ ref->req = ref;
+
+ v4l2_ctrl_lock(master);
+ /* g_volatile_ctrl will update the current control values */
+ for (i = 0; i < master->ncontrols; i++)
+ cur_to_new(master->cluster[i]);
+ call_op(master, g_volatile_ctrl);
+ new_to_req(ref);
+ v4l2_ctrl_unlock(master);
+ continue;
+ }
+ if (ref->req == ref)
+ continue;
+
+ v4l2_ctrl_lock(ctrl);
+ if (ref->req)
+ ptr_to_ptr(ctrl, ref->req->p_req, ref->p_req);
+ else
+ ptr_to_ptr(ctrl, ctrl->p_cur, ref->p_req);
+ v4l2_ctrl_unlock(ctrl);
+ }
+
+ WARN_ON(!hdl->request_is_queued);
+ list_del_init(&hdl->requests_queued);
+ hdl->request_is_queued = false;
+ media_request_object_complete(obj);
+ media_request_object_put(obj);
+}
+EXPORT_SYMBOL(v4l2_ctrl_request_complete);
+
+void v4l2_ctrl_request_setup(struct media_request *req,
+ struct v4l2_ctrl_handler *main_hdl)
+{
+ struct media_request_object *obj;
+ struct v4l2_ctrl_handler *hdl;
+ struct v4l2_ctrl_ref *ref;
+
+ if (!req || !main_hdl)
+ return;
+
+ obj = media_request_object_find(req, &req_ops, main_hdl);
+ if (!obj)
+ return;
+ if (obj->completed) {
+ media_request_object_put(obj);
+ return;
+ }
+ hdl = container_of(obj, struct v4l2_ctrl_handler, req_obj);
+
+ mutex_lock(hdl->lock);
+
+ list_for_each_entry(ref, &hdl->ctrl_refs, node)
+ ref->req_done = false;
+
+ list_for_each_entry(ref, &hdl->ctrl_refs, node) {
+ struct v4l2_ctrl *ctrl = ref->ctrl;
+ struct v4l2_ctrl *master = ctrl->cluster[0];
+ bool have_new_data = false;
+ int i;
+
+ /*
+ * Skip if this control was already handled by a cluster.
+ * Skip button controls and read-only controls.
+ */
+ if (ref->req_done || ctrl->type == V4L2_CTRL_TYPE_BUTTON ||
+ (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY))
+ continue;
+
+ v4l2_ctrl_lock(master);
+ for (i = 0; i < master->ncontrols; i++) {
+ if (master->cluster[i]) {
+ struct v4l2_ctrl_ref *r =
+ find_ref(hdl, master->cluster[i]->id);
+
+ if (r->req && r == r->req) {
+ have_new_data = true;
+ break;
+ }
+ }
+ }
+ if (!have_new_data) {
+ v4l2_ctrl_unlock(master);
+ continue;
+ }
+
+ for (i = 0; i < master->ncontrols; i++) {
+ if (master->cluster[i]) {
+ struct v4l2_ctrl_ref *r =
+ find_ref(hdl, master->cluster[i]->id);
+
+ req_to_new(r);
+ master->cluster[i]->is_new = 1;
+ r->req_done = true;
+ }
+ }
+ /*
+ * For volatile autoclusters that are currently in auto mode
+ * we need to discover if it will be set to manual mode.
+ * If so, then we have to copy the current volatile values
+ * first since those will become the new manual values (which
+ * may be overwritten by explicit new values from this set
+ * of controls).
+ */
+ if (master->is_auto && master->has_volatiles &&
+ !is_cur_manual(master)) {
+ s32 new_auto_val = *master->p_new.p_s32;
+
+ /*
+ * If the new value == the manual value, then copy
+ * the current volatile values.
+ */
+ if (new_auto_val == master->manual_mode_value)
+ update_from_auto_cluster(master);
+ }
+
+ try_or_set_cluster(NULL, master, true, 0);
+
+ v4l2_ctrl_unlock(master);
+ }
+
+ mutex_unlock(hdl->lock);
+ media_request_object_put(obj);
+}
+EXPORT_SYMBOL(v4l2_ctrl_request_setup);
+
void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, v4l2_ctrl_notify_fnc notify, void *priv)
{
if (ctrl == NULL)
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 847d6f543e4a..65eade646156 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -250,6 +250,12 @@ struct v4l2_ctrl {
* ``prepare_ext_ctrls`` function at ``v4l2-ctrl.c``.
* @from_other_dev: If true, then @ctrl was defined in another
* device than the &struct v4l2_ctrl_handler.
+ * @req_done: Internal flag: if the control handler containing this control
+ * reference is bound to a media request, then this is set when
+ * the control has been applied. This prevents applying controls
+ * from a cluster with multiple controls twice (when the first
+ * control of a cluster is applied, they all are).
+ * @req: If set, this refers to another request that sets this control.
* @p_req: If the control handler containing this control reference
* is bound to a media request, then this points to the
* value of the control that should be applied when the request
@@ -266,6 +272,8 @@ struct v4l2_ctrl_ref {
struct v4l2_ctrl *ctrl;
struct v4l2_ctrl_helper *helper;
bool from_other_dev;
+ bool req_done;
+ struct v4l2_ctrl_ref *req;
union v4l2_ctrl_ptr p_req;
};
@@ -290,6 +298,15 @@ struct v4l2_ctrl_ref {
* @notify_priv: Passed as argument to the v4l2_ctrl notify callback.
* @nr_of_buckets: Total number of buckets in the array.
* @error: The error code of the first failed control addition.
+ * @request_is_queued: True if the request was queued.
+ * @requests: List to keep track of open control handler request objects.
+ * For the parent control handler (@req_obj.req == NULL) this
+ * is the list header. When the parent control handler is
+ * removed, it has to unbind and put all these requests since
+ * they refer to the parent.
+ * @requests_queued: List of the queued requests. This determines the order
+ * in which these controls are applied. Once the request is
+ * completed it is removed from this list.
* @req_obj: The &struct media_request_object, used to link into a
* &struct media_request. This request object has a refcount.
*/
@@ -304,6 +321,9 @@ struct v4l2_ctrl_handler {
void *notify_priv;
u16 nr_of_buckets;
int error;
+ bool request_is_queued;
+ struct list_head requests;
+ struct list_head requests_queued;
struct media_request_object req_obj;
};
@@ -1062,6 +1082,37 @@ int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
*/
__poll_t v4l2_ctrl_poll(struct file *file, struct poll_table_struct *wait);
+/**
+ * v4l2_ctrl_request_setup - helper function to apply control values in a request
+ *
+ * @req: The request
+ * @hdl: The control handler
+ *
+ * This is a helper function to call the control handler's s_ctrl callback with
+ * the control values contained in the request. Do note that this approach of
+ * applying control values in a request is only applicable to memory-to-memory
+ * devices.
+ */
+void v4l2_ctrl_request_setup(struct media_request *req,
+ struct v4l2_ctrl_handler *hdl);
+
+/**
+ * v4l2_ctrl_request_complete - Complete a control handler request object
+ *
+ * @req: The request
+ * @hdl: The control handler
+ *
+ * This function is to be called on each control handler that may have had a
+ * request object associated with it, i.e. control handlers of a driver that
+ * supports requests.
+ *
+ * The function first obtains the values of any volatile controls in the control
+ * handler and attach them to the request. Then, the function completes the
+ * request object.
+ */
+void v4l2_ctrl_request_complete(struct media_request *req,
+ struct v4l2_ctrl_handler *hdl);
+
/* Helpers for ioctl_ops */
/**
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 13/35] v4l2-ctrls: add core request support
2018-06-04 11:46 ` [PATCHv15 13/35] v4l2-ctrls: add core request support Hans Verkuil
@ 2018-06-04 17:18 ` Ezequiel Garcia
2018-06-15 7:18 ` Hans Verkuil
1 sibling, 0 replies; 61+ messages in thread
From: Ezequiel Garcia @ 2018-06-04 17:18 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Hans Verkuil
On 4 June 2018 at 08:46, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Integrate the request support. This adds the v4l2_ctrl_request_complete
> and v4l2_ctrl_request_setup functions to complete a request and (as a
> helper function) to apply a request to the hardware.
>
> It takes care of queuing requests and correctly chaining control values
> in the request queue.
>
> Note that when a request is marked completed it will copy control values
> to the internal request state. This can be optimized in the future since
> this is sub-optimal when dealing with large compound and/or array controls.
>
> For the initial 'stateless codec' use-case the current implementation is
> sufficient.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 331 ++++++++++++++++++++++++++-
> include/media/v4l2-ctrls.h | 51 +++++
> 2 files changed, 376 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index da4cc1485dc4..bd4818507486 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1647,6 +1647,13 @@ static int new_to_user(struct v4l2_ext_control *c,
> return ptr_to_user(c, ctrl, ctrl->p_new);
> }
>
> +/* Helper function: copy the request value back to the caller */
> +static int req_to_user(struct v4l2_ext_control *c,
> + struct v4l2_ctrl_ref *ref)
> +{
> + return ptr_to_user(c, ref->ctrl, ref->p_req);
> +}
> +
> /* Helper function: copy the initial control value back to the caller */
> static int def_to_user(struct v4l2_ext_control *c, struct v4l2_ctrl *ctrl)
> {
> @@ -1766,6 +1773,26 @@ static void cur_to_new(struct v4l2_ctrl *ctrl)
> ptr_to_ptr(ctrl, ctrl->p_cur, ctrl->p_new);
> }
>
> +/* Copy the new value to the request value */
> +static void new_to_req(struct v4l2_ctrl_ref *ref)
> +{
> + if (!ref)
> + return;
> + ptr_to_ptr(ref->ctrl, ref->ctrl->p_new, ref->p_req);
> + ref->req = ref;
> +}
> +
> +/* Copy the request value to the new value */
> +static void req_to_new(struct v4l2_ctrl_ref *ref)
> +{
> + if (!ref)
> + return;
> + if (ref->req)
> + ptr_to_ptr(ref->ctrl, ref->req->p_req, ref->ctrl->p_new);
> + else
> + ptr_to_ptr(ref->ctrl, ref->ctrl->p_cur, ref->ctrl->p_new);
> +}
> +
> /* Return non-zero if one or more of the controls in the cluster has a new
> value that differs from the current value. */
> static int cluster_changed(struct v4l2_ctrl *master)
> @@ -1875,6 +1902,9 @@ int v4l2_ctrl_handler_init_class(struct v4l2_ctrl_handler *hdl,
> lockdep_set_class_and_name(hdl->lock, key, name);
> INIT_LIST_HEAD(&hdl->ctrls);
> INIT_LIST_HEAD(&hdl->ctrl_refs);
> + INIT_LIST_HEAD(&hdl->requests);
> + INIT_LIST_HEAD(&hdl->requests_queued);
> + hdl->request_is_queued = false;
> hdl->nr_of_buckets = 1 + nr_of_controls_hint / 8;
> hdl->buckets = kvmalloc_array(hdl->nr_of_buckets,
> sizeof(hdl->buckets[0]),
> @@ -1895,6 +1925,14 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
> if (hdl == NULL || hdl->buckets == NULL)
> return;
>
> + if (!hdl->req_obj.req && !list_empty(&hdl->requests)) {
> + struct v4l2_ctrl_handler *req, *next_req;
> +
> + list_for_each_entry_safe(req, next_req, &hdl->requests, requests) {
> + media_request_object_unbind(&req->req_obj);
> + media_request_object_put(&req->req_obj);
> + }
> + }
> mutex_lock(hdl->lock);
> /* Free all nodes */
> list_for_each_entry_safe(ref, next_ref, &hdl->ctrl_refs, node) {
> @@ -2816,6 +2854,128 @@ int v4l2_querymenu(struct v4l2_ctrl_handler *hdl, struct v4l2_querymenu *qm)
> }
> EXPORT_SYMBOL(v4l2_querymenu);
>
> +static int v4l2_ctrl_request_clone(struct v4l2_ctrl_handler *hdl,
> + const struct v4l2_ctrl_handler *from)
> +{
> + struct v4l2_ctrl_ref *ref;
> + int err;
> +
> + if (WARN_ON(!hdl || hdl == from))
> + return -EINVAL;
> +
> + if (hdl->error)
> + return hdl->error;
> +
> + WARN_ON(hdl->lock != &hdl->_lock);
> +
> + mutex_lock(from->lock);
> + list_for_each_entry(ref, &from->ctrl_refs, node) {
> + struct v4l2_ctrl *ctrl = ref->ctrl;
> + struct v4l2_ctrl_ref *new_ref;
> +
> + /* Skip refs inherited from other devices */
> + if (ref->from_other_dev)
> + continue;
> + /* And buttons */
> + if (ctrl->type == V4L2_CTRL_TYPE_BUTTON)
> + continue;
> + err = handler_new_ref(hdl, ctrl, &new_ref, false, true);
> + if (err) {
> + printk("%s: handler_new_ref on control %x (%s) returned %d\n", __func__, ctrl->id, ctrl->name, err);
Nit: pr_err + pr_fmt above?
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 13/35] v4l2-ctrls: add core request support
2018-06-04 11:46 ` [PATCHv15 13/35] v4l2-ctrls: add core request support Hans Verkuil
2018-06-04 17:18 ` Ezequiel Garcia
@ 2018-06-15 7:18 ` Hans Verkuil
1 sibling, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-15 7:18 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
On 04/06/18 13:46, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Integrate the request support. This adds the v4l2_ctrl_request_complete
> and v4l2_ctrl_request_setup functions to complete a request and (as a
> helper function) to apply a request to the hardware.
>
> It takes care of queuing requests and correctly chaining control values
> in the request queue.
>
> Note that when a request is marked completed it will copy control values
> to the internal request state. This can be optimized in the future since
> this is sub-optimal when dealing with large compound and/or array controls.
>
> For the initial 'stateless codec' use-case the current implementation is
> sufficient.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 331 ++++++++++++++++++++++++++-
> include/media/v4l2-ctrls.h | 51 +++++
> 2 files changed, 376 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index da4cc1485dc4..bd4818507486 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1647,6 +1647,13 @@ static int new_to_user(struct v4l2_ext_control *c,
> return ptr_to_user(c, ctrl, ctrl->p_new);
> }
>
> +/* Helper function: copy the request value back to the caller */
> +static int req_to_user(struct v4l2_ext_control *c,
> + struct v4l2_ctrl_ref *ref)
> +{
> + return ptr_to_user(c, ref->ctrl, ref->p_req);
> +}
> +
> /* Helper function: copy the initial control value back to the caller */
> static int def_to_user(struct v4l2_ext_control *c, struct v4l2_ctrl *ctrl)
> {
> @@ -1766,6 +1773,26 @@ static void cur_to_new(struct v4l2_ctrl *ctrl)
> ptr_to_ptr(ctrl, ctrl->p_cur, ctrl->p_new);
> }
>
> +/* Copy the new value to the request value */
> +static void new_to_req(struct v4l2_ctrl_ref *ref)
> +{
> + if (!ref)
> + return;
> + ptr_to_ptr(ref->ctrl, ref->ctrl->p_new, ref->p_req);
> + ref->req = ref;
> +}
> +
> +/* Copy the request value to the new value */
> +static void req_to_new(struct v4l2_ctrl_ref *ref)
> +{
> + if (!ref)
> + return;
> + if (ref->req)
> + ptr_to_ptr(ref->ctrl, ref->req->p_req, ref->ctrl->p_new);
> + else
> + ptr_to_ptr(ref->ctrl, ref->ctrl->p_cur, ref->ctrl->p_new);
> +}
> +
> /* Return non-zero if one or more of the controls in the cluster has a new
> value that differs from the current value. */
> static int cluster_changed(struct v4l2_ctrl *master)
> @@ -1875,6 +1902,9 @@ int v4l2_ctrl_handler_init_class(struct v4l2_ctrl_handler *hdl,
> lockdep_set_class_and_name(hdl->lock, key, name);
> INIT_LIST_HEAD(&hdl->ctrls);
> INIT_LIST_HEAD(&hdl->ctrl_refs);
> + INIT_LIST_HEAD(&hdl->requests);
> + INIT_LIST_HEAD(&hdl->requests_queued);
> + hdl->request_is_queued = false;
> hdl->nr_of_buckets = 1 + nr_of_controls_hint / 8;
> hdl->buckets = kvmalloc_array(hdl->nr_of_buckets,
> sizeof(hdl->buckets[0]),
> @@ -1895,6 +1925,14 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler *hdl)
> if (hdl == NULL || hdl->buckets == NULL)
> return;
>
> + if (!hdl->req_obj.req && !list_empty(&hdl->requests)) {
> + struct v4l2_ctrl_handler *req, *next_req;
> +
> + list_for_each_entry_safe(req, next_req, &hdl->requests, requests) {
> + media_request_object_unbind(&req->req_obj);
> + media_request_object_put(&req->req_obj);
> + }
> + }
> mutex_lock(hdl->lock);
> /* Free all nodes */
> list_for_each_entry_safe(ref, next_ref, &hdl->ctrl_refs, node) {
> @@ -2816,6 +2854,128 @@ int v4l2_querymenu(struct v4l2_ctrl_handler *hdl, struct v4l2_querymenu *qm)
> }
> EXPORT_SYMBOL(v4l2_querymenu);
>
> +static int v4l2_ctrl_request_clone(struct v4l2_ctrl_handler *hdl,
> + const struct v4l2_ctrl_handler *from)
> +{
> + struct v4l2_ctrl_ref *ref;
> + int err;
> +
> + if (WARN_ON(!hdl || hdl == from))
> + return -EINVAL;
> +
> + if (hdl->error)
> + return hdl->error;
> +
> + WARN_ON(hdl->lock != &hdl->_lock);
> +
> + mutex_lock(from->lock);
> + list_for_each_entry(ref, &from->ctrl_refs, node) {
> + struct v4l2_ctrl *ctrl = ref->ctrl;
> + struct v4l2_ctrl_ref *new_ref;
> +
> + /* Skip refs inherited from other devices */
> + if (ref->from_other_dev)
> + continue;
> + /* And buttons */
> + if (ctrl->type == V4L2_CTRL_TYPE_BUTTON)
> + continue;
> + err = handler_new_ref(hdl, ctrl, &new_ref, false, true);
> + if (err) {
> + printk("%s: handler_new_ref on control %x (%s) returned %d\n", __func__, ctrl->id, ctrl->name, err);
> + err = 0;
> + continue;
> + }
> + if (err)
> + break;
> + }
> + mutex_unlock(from->lock);
> + return err;
> +}
> +
> +static void v4l2_ctrl_request_queue(struct media_request_object *obj)
> +{
> + struct v4l2_ctrl_handler *hdl =
> + container_of(obj, struct v4l2_ctrl_handler, req_obj);
> + struct v4l2_ctrl_handler *main_hdl = obj->priv;
> + struct v4l2_ctrl_handler *prev_hdl = NULL;
> + struct v4l2_ctrl_ref *ref_ctrl, *ref_ctrl_prev = NULL;
> +
> + if (list_empty(&main_hdl->requests_queued))
> + goto queue;
> +
> + prev_hdl = list_last_entry(&main_hdl->requests_queued,
> + struct v4l2_ctrl_handler, requests_queued);
> + /*
> + * Note: prev_hdl and hdl must contain the same list of control
> + * references, so if any differences are detected then that is a
> + * driver bug and the WARN_ON is triggered.
> + */
> + mutex_lock(prev_hdl->lock);
> + ref_ctrl_prev = list_first_entry(&prev_hdl->ctrl_refs,
> + struct v4l2_ctrl_ref, node);
> + list_for_each_entry(ref_ctrl, &hdl->ctrl_refs, node) {
> + if (ref_ctrl->req)
> + continue;
> + while (ref_ctrl_prev->ctrl->id < ref_ctrl->ctrl->id) {
> + /* Should never happen, but just in case... */
> + if (list_is_last(&ref_ctrl_prev->node,
> + &prev_hdl->ctrl_refs))
> + break;
> + ref_ctrl_prev = list_next_entry(ref_ctrl_prev, node);
> + }
> + if (WARN_ON(ref_ctrl_prev->ctrl->id != ref_ctrl->ctrl->id))
> + break;
> + ref_ctrl->req = ref_ctrl_prev->req;
> + }
> + mutex_unlock(prev_hdl->lock);
> +queue:
> + list_add_tail(&hdl->requests_queued, &main_hdl->requests_queued);
> + hdl->request_is_queued = true;
> +}
> +
> +static void v4l2_ctrl_request_unbind(struct media_request_object *obj)
> +{
> + struct v4l2_ctrl_handler *hdl =
> + container_of(obj, struct v4l2_ctrl_handler, req_obj);
> +
> + list_del_init(&hdl->requests);
> + if (hdl->request_is_queued) {
> + list_del_init(&hdl->requests_queued);
> + hdl->request_is_queued = false;
> + }
> +}
> +
> +static void v4l2_ctrl_request_release(struct media_request_object *obj)
> +{
> + struct v4l2_ctrl_handler *hdl =
> + container_of(obj, struct v4l2_ctrl_handler, req_obj);
> +
> + v4l2_ctrl_handler_free(hdl);
> + kfree(hdl);
> +}
> +
> +static const struct media_request_object_ops req_ops = {
> + .queue = v4l2_ctrl_request_queue,
> + .unbind = v4l2_ctrl_request_unbind,
> + .release = v4l2_ctrl_request_release,
> +};
> +
> +static int v4l2_ctrl_request_bind(struct media_request *req,
> + struct v4l2_ctrl_handler *hdl,
> + struct v4l2_ctrl_handler *from)
> +{
> + int ret;
> +
> + ret = v4l2_ctrl_request_clone(hdl, from);
> +
> + if (!ret) {
> + ret = media_request_object_bind(req, &req_ops,
> + from, &hdl->req_obj);
> + if (!ret)
> + list_add_tail(&hdl->requests, &from->requests);
> + }
> + return ret;
> +}
>
> /* Some general notes on the atomic requirements of VIDIOC_G/TRY/S_EXT_CTRLS:
>
> @@ -2877,6 +3037,7 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler *hdl,
>
> if (cs->which &&
> cs->which != V4L2_CTRL_WHICH_DEF_VAL &&
> + cs->which != V4L2_CTRL_WHICH_REQUEST_VAL &&
> V4L2_CTRL_ID2WHICH(id) != cs->which)
> return -EINVAL;
>
> @@ -2956,13 +3117,12 @@ static int prepare_ext_ctrls(struct v4l2_ctrl_handler *hdl,
> whether there are any controls at all. */
> static int class_check(struct v4l2_ctrl_handler *hdl, u32 which)
> {
> - if (which == 0 || which == V4L2_CTRL_WHICH_DEF_VAL)
> + if (which == 0 || which == V4L2_CTRL_WHICH_DEF_VAL ||
> + which == V4L2_CTRL_WHICH_REQUEST_VAL)
> return 0;
> return find_ref_lock(hdl, which | 1) ? 0 : -EINVAL;
> }
>
> -
> -
> /* Get extended controls. Allocates the helpers array if needed. */
> int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs)
> {
> @@ -3028,8 +3188,12 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs
> u32 idx = i;
>
> do {
> - ret = ctrl_to_user(cs->controls + idx,
> - helpers[idx].ref->ctrl);
> + if (helpers[idx].ref->req)
> + ret = req_to_user(cs->controls + idx,
> + helpers[idx].ref->req);
> + else
> + ret = ctrl_to_user(cs->controls + idx,
> + helpers[idx].ref->ctrl);
> idx = helpers[idx].next;
> } while (!ret && idx);
> }
> @@ -3302,7 +3466,16 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
> } while (!ret && idx);
>
> if (!ret)
> - ret = try_or_set_cluster(fh, master, set, 0);
> + ret = try_or_set_cluster(fh, master,
> + !hdl->req_obj.req && set, 0);
> + if (!ret && hdl->req_obj.req && set) {
> + for (j = 0; j < master->ncontrols; j++) {
> + struct v4l2_ctrl_ref *ref =
> + find_ref(hdl, master->cluster[j]->id);
> +
> + new_to_req(ref);
> + }
> + }
>
> /* Copy the new values back to userspace. */
> if (!ret) {
> @@ -3429,6 +3602,152 @@ int __v4l2_ctrl_s_ctrl_string(struct v4l2_ctrl *ctrl, const char *s)
> }
> EXPORT_SYMBOL(__v4l2_ctrl_s_ctrl_string);
>
> +void v4l2_ctrl_request_complete(struct media_request *req,
> + struct v4l2_ctrl_handler *main_hdl)
> +{
> + struct media_request_object *obj;
> + struct v4l2_ctrl_handler *hdl;
> + struct v4l2_ctrl_ref *ref;
> +
> + if (!req || !main_hdl)
> + return;
> +
> + obj = media_request_object_find(req, &req_ops, main_hdl);
> + if (!obj)
> + return;
> + hdl = container_of(obj, struct v4l2_ctrl_handler, req_obj);
> +
> + list_for_each_entry(ref, &hdl->ctrl_refs, node) {
> + struct v4l2_ctrl *ctrl = ref->ctrl;
> + struct v4l2_ctrl *master = ctrl->cluster[0];
> + unsigned int i;
> +
> + if (ctrl->flags & V4L2_CTRL_FLAG_VOLATILE) {
> + ref->req = ref;
> +
> + v4l2_ctrl_lock(master);
> + /* g_volatile_ctrl will update the current control values */
> + for (i = 0; i < master->ncontrols; i++)
> + cur_to_new(master->cluster[i]);
> + call_op(master, g_volatile_ctrl);
> + new_to_req(ref);
> + v4l2_ctrl_unlock(master);
> + continue;
> + }
> + if (ref->req == ref)
> + continue;
> +
> + v4l2_ctrl_lock(ctrl);
> + if (ref->req)
> + ptr_to_ptr(ctrl, ref->req->p_req, ref->p_req);
> + else
> + ptr_to_ptr(ctrl, ctrl->p_cur, ref->p_req);
> + v4l2_ctrl_unlock(ctrl);
> + }
> +
> + WARN_ON(!hdl->request_is_queued);
> + list_del_init(&hdl->requests_queued);
> + hdl->request_is_queued = false;
> + media_request_object_complete(obj);
> + media_request_object_put(obj);
> +}
> +EXPORT_SYMBOL(v4l2_ctrl_request_complete);
> +
> +void v4l2_ctrl_request_setup(struct media_request *req,
> + struct v4l2_ctrl_handler *main_hdl)
> +{
> + struct media_request_object *obj;
> + struct v4l2_ctrl_handler *hdl;
> + struct v4l2_ctrl_ref *ref;
> +
> + if (!req || !main_hdl)
> + return;
> +
We should check that the request is in QUEUED state to avoid this
function being called at the wrong time. Just WARN and return if
the request is in the wrong state.
> + obj = media_request_object_find(req, &req_ops, main_hdl);
> + if (!obj)
> + return;
> + if (obj->completed) {
> + media_request_object_put(obj);
> + return;
> + }
> + hdl = container_of(obj, struct v4l2_ctrl_handler, req_obj);
> +
> + mutex_lock(hdl->lock);
This lock should be dropped. Since we're in QUEUED state userspace is no
longer allowed to make changes to the request, so we do not need to lock this
control handler.
Locking here causes false lockdep warnings. The real cause of that is that
all control handlers created by v4l2_ctrls_find_req_obj() (next patch) look
as if they use the same mutex to lockdep since they use the same
struct lock_class_key. There is no easy way around that (at least none that I
could find).
The easiest way to solve this is actually to simple not lock. Provided the
request is in state QUEUED that is fine.
Regards,
Hans
> +
> + list_for_each_entry(ref, &hdl->ctrl_refs, node)
> + ref->req_done = false;
> +
> + list_for_each_entry(ref, &hdl->ctrl_refs, node) {
> + struct v4l2_ctrl *ctrl = ref->ctrl;
> + struct v4l2_ctrl *master = ctrl->cluster[0];
> + bool have_new_data = false;
> + int i;
> +
> + /*
> + * Skip if this control was already handled by a cluster.
> + * Skip button controls and read-only controls.
> + */
> + if (ref->req_done || ctrl->type == V4L2_CTRL_TYPE_BUTTON ||
> + (ctrl->flags & V4L2_CTRL_FLAG_READ_ONLY))
> + continue;
> +
> + v4l2_ctrl_lock(master);
> + for (i = 0; i < master->ncontrols; i++) {
> + if (master->cluster[i]) {
> + struct v4l2_ctrl_ref *r =
> + find_ref(hdl, master->cluster[i]->id);
> +
> + if (r->req && r == r->req) {
> + have_new_data = true;
> + break;
> + }
> + }
> + }
> + if (!have_new_data) {
> + v4l2_ctrl_unlock(master);
> + continue;
> + }
> +
> + for (i = 0; i < master->ncontrols; i++) {
> + if (master->cluster[i]) {
> + struct v4l2_ctrl_ref *r =
> + find_ref(hdl, master->cluster[i]->id);
> +
> + req_to_new(r);
> + master->cluster[i]->is_new = 1;
> + r->req_done = true;
> + }
> + }
> + /*
> + * For volatile autoclusters that are currently in auto mode
> + * we need to discover if it will be set to manual mode.
> + * If so, then we have to copy the current volatile values
> + * first since those will become the new manual values (which
> + * may be overwritten by explicit new values from this set
> + * of controls).
> + */
> + if (master->is_auto && master->has_volatiles &&
> + !is_cur_manual(master)) {
> + s32 new_auto_val = *master->p_new.p_s32;
> +
> + /*
> + * If the new value == the manual value, then copy
> + * the current volatile values.
> + */
> + if (new_auto_val == master->manual_mode_value)
> + update_from_auto_cluster(master);
> + }
> +
> + try_or_set_cluster(NULL, master, true, 0);
> +
> + v4l2_ctrl_unlock(master);
> + }
> +
> + mutex_unlock(hdl->lock);
> + media_request_object_put(obj);
> +}
> +EXPORT_SYMBOL(v4l2_ctrl_request_setup);
> +
> void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, v4l2_ctrl_notify_fnc notify, void *priv)
> {
> if (ctrl == NULL)
> diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
> index 847d6f543e4a..65eade646156 100644
> --- a/include/media/v4l2-ctrls.h
> +++ b/include/media/v4l2-ctrls.h
> @@ -250,6 +250,12 @@ struct v4l2_ctrl {
> * ``prepare_ext_ctrls`` function at ``v4l2-ctrl.c``.
> * @from_other_dev: If true, then @ctrl was defined in another
> * device than the &struct v4l2_ctrl_handler.
> + * @req_done: Internal flag: if the control handler containing this control
> + * reference is bound to a media request, then this is set when
> + * the control has been applied. This prevents applying controls
> + * from a cluster with multiple controls twice (when the first
> + * control of a cluster is applied, they all are).
> + * @req: If set, this refers to another request that sets this control.
> * @p_req: If the control handler containing this control reference
> * is bound to a media request, then this points to the
> * value of the control that should be applied when the request
> @@ -266,6 +272,8 @@ struct v4l2_ctrl_ref {
> struct v4l2_ctrl *ctrl;
> struct v4l2_ctrl_helper *helper;
> bool from_other_dev;
> + bool req_done;
> + struct v4l2_ctrl_ref *req;
> union v4l2_ctrl_ptr p_req;
> };
>
> @@ -290,6 +298,15 @@ struct v4l2_ctrl_ref {
> * @notify_priv: Passed as argument to the v4l2_ctrl notify callback.
> * @nr_of_buckets: Total number of buckets in the array.
> * @error: The error code of the first failed control addition.
> + * @request_is_queued: True if the request was queued.
> + * @requests: List to keep track of open control handler request objects.
> + * For the parent control handler (@req_obj.req == NULL) this
> + * is the list header. When the parent control handler is
> + * removed, it has to unbind and put all these requests since
> + * they refer to the parent.
> + * @requests_queued: List of the queued requests. This determines the order
> + * in which these controls are applied. Once the request is
> + * completed it is removed from this list.
> * @req_obj: The &struct media_request_object, used to link into a
> * &struct media_request. This request object has a refcount.
> */
> @@ -304,6 +321,9 @@ struct v4l2_ctrl_handler {
> void *notify_priv;
> u16 nr_of_buckets;
> int error;
> + bool request_is_queued;
> + struct list_head requests;
> + struct list_head requests_queued;
> struct media_request_object req_obj;
> };
>
> @@ -1062,6 +1082,37 @@ int v4l2_ctrl_subscribe_event(struct v4l2_fh *fh,
> */
> __poll_t v4l2_ctrl_poll(struct file *file, struct poll_table_struct *wait);
>
> +/**
> + * v4l2_ctrl_request_setup - helper function to apply control values in a request
> + *
> + * @req: The request
> + * @hdl: The control handler
> + *
> + * This is a helper function to call the control handler's s_ctrl callback with
> + * the control values contained in the request. Do note that this approach of
> + * applying control values in a request is only applicable to memory-to-memory
> + * devices.
> + */
> +void v4l2_ctrl_request_setup(struct media_request *req,
> + struct v4l2_ctrl_handler *hdl);
> +
> +/**
> + * v4l2_ctrl_request_complete - Complete a control handler request object
> + *
> + * @req: The request
> + * @hdl: The control handler
> + *
> + * This function is to be called on each control handler that may have had a
> + * request object associated with it, i.e. control handlers of a driver that
> + * supports requests.
> + *
> + * The function first obtains the values of any volatile controls in the control
> + * handler and attach them to the request. Then, the function completes the
> + * request object.
> + */
> +void v4l2_ctrl_request_complete(struct media_request *req,
> + struct v4l2_ctrl_handler *hdl);
> +
> /* Helpers for ioctl_ops */
>
> /**
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 14/35] v4l2-ctrls: support g/s_ext_ctrls for requests
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (12 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 13/35] v4l2-ctrls: add core request support Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-15 7:20 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 15/35] vb2: store userspace data in vb2_v4l2_buffer Hans Verkuil
` (20 subsequent siblings)
34 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
The v4l2_g/s_ext_ctrls functions now support control handlers that
represent requests.
The v4l2_ctrls_find_req_obj() function is responsible for finding the
request from the fd.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/platform/omap3isp/ispvideo.c | 2 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 128 +++++++++++++++++++--
drivers/media/v4l2-core/v4l2-ioctl.c | 12 +-
drivers/media/v4l2-core/v4l2-subdev.c | 9 +-
include/media/v4l2-ctrls.h | 7 +-
5 files changed, 139 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispvideo.c b/drivers/media/platform/omap3isp/ispvideo.c
index 9d228eac24ea..674e7fd3ad99 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1028,7 +1028,7 @@ static int isp_video_check_external_subdevs(struct isp_video *video,
ctrls.count = 1;
ctrls.controls = &ctrl;
- ret = v4l2_g_ext_ctrls(pipe->external->ctrl_handler, &ctrls);
+ ret = v4l2_g_ext_ctrls(pipe->external->ctrl_handler, NULL, &ctrls);
if (ret < 0) {
dev_warn(isp->dev, "no pixel rate control in subdev %s\n",
pipe->external->name);
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index bd4818507486..ab5e8827fde0 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3124,7 +3124,8 @@ static int class_check(struct v4l2_ctrl_handler *hdl, u32 which)
}
/* Get extended controls. Allocates the helpers array if needed. */
-int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs)
+int __v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+ struct v4l2_ext_controls *cs)
{
struct v4l2_ctrl_helper helper[4];
struct v4l2_ctrl_helper *helpers = helper;
@@ -3204,6 +3205,77 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs
kvfree(helpers);
return ret;
}
+
+static struct media_request_object *
+v4l2_ctrls_find_req_obj(struct v4l2_ctrl_handler *hdl,
+ struct media_request *req, bool set)
+{
+ struct media_request_object *obj;
+ struct v4l2_ctrl_handler *new_hdl;
+ int ret;
+
+ if (IS_ERR(req))
+ return ERR_CAST(req);
+
+ if (set && WARN_ON(req->state != MEDIA_REQUEST_STATE_UPDATING))
+ return ERR_PTR(-EBUSY);
+
+ obj = media_request_object_find(req, &req_ops, hdl);
+ if (obj)
+ return obj;
+ if (!set)
+ return ERR_PTR(-ENOENT);
+
+ new_hdl = kzalloc(sizeof(*new_hdl), GFP_KERNEL);
+ if (!new_hdl)
+ return ERR_PTR(-ENOMEM);
+
+ obj = &new_hdl->req_obj;
+ ret = v4l2_ctrl_handler_init(new_hdl, (hdl->nr_of_buckets - 1) * 8);
+ if (!ret)
+ ret = v4l2_ctrl_request_bind(req, new_hdl, hdl);
+ if (ret) {
+ kfree(new_hdl);
+
+ return ERR_PTR(ret);
+ }
+
+ media_request_object_get(obj);
+ return obj;
+}
+
+int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
+ struct v4l2_ext_controls *cs)
+{
+ struct media_request_object *obj = NULL;
+ int ret;
+
+ if (cs->which == V4L2_CTRL_WHICH_REQUEST_VAL) {
+ struct media_request *req;
+
+ if (!mdev || cs->request_fd < 0)
+ return -EINVAL;
+
+ req = media_request_get_by_fd(mdev, cs->request_fd);
+ if (IS_ERR(req))
+ return PTR_ERR(req);
+
+ obj = v4l2_ctrls_find_req_obj(hdl, req, false);
+ /* Reference to the request held through obj */
+ media_request_put(req);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ hdl = container_of(obj, struct v4l2_ctrl_handler,
+ req_obj);
+ }
+
+ ret = __v4l2_g_ext_ctrls(hdl, cs);
+
+ if (obj)
+ media_request_object_put(obj);
+ return ret;
+}
EXPORT_SYMBOL(v4l2_g_ext_ctrls);
/* Helper function to get a single control */
@@ -3379,9 +3451,9 @@ static void update_from_auto_cluster(struct v4l2_ctrl *master)
}
/* Try or try-and-set controls */
-static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
- struct v4l2_ext_controls *cs,
- bool set)
+static int __try_set_ext_ctrls(struct v4l2_fh *fh,
+ struct v4l2_ctrl_handler *hdl,
+ struct v4l2_ext_controls *cs, bool set)
{
struct v4l2_ctrl_helper helper[4];
struct v4l2_ctrl_helper *helpers = helper;
@@ -3494,16 +3566,56 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
return ret;
}
-int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs)
+static int try_set_ext_ctrls(struct v4l2_fh *fh,
+ struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
+ struct v4l2_ext_controls *cs, bool set)
+{
+ struct media_request_object *obj = NULL;
+ struct media_request *req = NULL;
+ int ret;
+
+ if (cs->which == V4L2_CTRL_WHICH_REQUEST_VAL) {
+ if (!mdev || cs->request_fd < 0)
+ return -EINVAL;
+
+ req = media_request_get_by_fd(mdev, cs->request_fd);
+ if (IS_ERR(req))
+ return PTR_ERR(req);
+
+ ret = media_request_lock_for_update(req);
+ if (ret) {
+ media_request_put(req);
+ return ret;
+ }
+
+ obj = v4l2_ctrls_find_req_obj(hdl, req, set);
+ /* Reference to the request held through obj */
+ media_request_put(req);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+ hdl = container_of(obj, struct v4l2_ctrl_handler,
+ req_obj);
+ }
+
+ ret = __try_set_ext_ctrls(fh, hdl, cs, set);
+
+ if (obj)
+ media_request_unlock_for_update(obj->req);
+
+ return ret;
+}
+
+int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
+ struct v4l2_ext_controls *cs)
{
- return try_set_ext_ctrls(NULL, hdl, cs, false);
+ return try_set_ext_ctrls(NULL, hdl, mdev, cs, false);
}
EXPORT_SYMBOL(v4l2_try_ext_ctrls);
int v4l2_s_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
- struct v4l2_ext_controls *cs)
+ struct media_device *mdev, struct v4l2_ext_controls *cs)
{
- return try_set_ext_ctrls(fh, hdl, cs, true);
+ return try_set_ext_ctrls(fh, hdl, mdev, cs, true);
}
EXPORT_SYMBOL(v4l2_s_ext_ctrls);
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 3fa66103ffd0..fd3ea7e504e3 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2094,9 +2094,9 @@ static int v4l_g_ext_ctrls(const struct v4l2_ioctl_ops *ops,
p->error_idx = p->count;
if (vfh && vfh->ctrl_handler)
- return v4l2_g_ext_ctrls(vfh->ctrl_handler, p);
+ return v4l2_g_ext_ctrls(vfh->ctrl_handler, vfd->v4l2_dev->mdev, p);
if (vfd->ctrl_handler)
- return v4l2_g_ext_ctrls(vfd->ctrl_handler, p);
+ return v4l2_g_ext_ctrls(vfd->ctrl_handler, vfd->v4l2_dev->mdev, p);
if (ops->vidioc_g_ext_ctrls == NULL)
return -ENOTTY;
return check_ext_ctrls(p, 0) ? ops->vidioc_g_ext_ctrls(file, fh, p) :
@@ -2113,9 +2113,9 @@ static int v4l_s_ext_ctrls(const struct v4l2_ioctl_ops *ops,
p->error_idx = p->count;
if (vfh && vfh->ctrl_handler)
- return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler, p);
+ return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler, vfd->v4l2_dev->mdev, p);
if (vfd->ctrl_handler)
- return v4l2_s_ext_ctrls(NULL, vfd->ctrl_handler, p);
+ return v4l2_s_ext_ctrls(NULL, vfd->ctrl_handler, vfd->v4l2_dev->mdev, p);
if (ops->vidioc_s_ext_ctrls == NULL)
return -ENOTTY;
return check_ext_ctrls(p, 0) ? ops->vidioc_s_ext_ctrls(file, fh, p) :
@@ -2132,9 +2132,9 @@ static int v4l_try_ext_ctrls(const struct v4l2_ioctl_ops *ops,
p->error_idx = p->count;
if (vfh && vfh->ctrl_handler)
- return v4l2_try_ext_ctrls(vfh->ctrl_handler, p);
+ return v4l2_try_ext_ctrls(vfh->ctrl_handler, vfd->v4l2_dev->mdev, p);
if (vfd->ctrl_handler)
- return v4l2_try_ext_ctrls(vfd->ctrl_handler, p);
+ return v4l2_try_ext_ctrls(vfd->ctrl_handler, vfd->v4l2_dev->mdev, p);
if (ops->vidioc_try_ext_ctrls == NULL)
return -ENOTTY;
return check_ext_ctrls(p, 0) ? ops->vidioc_try_ext_ctrls(file, fh, p) :
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
index 6a7f7f75dfd7..b9cff2389eae 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -222,17 +222,20 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg)
case VIDIOC_G_EXT_CTRLS:
if (!vfh->ctrl_handler)
return -ENOTTY;
- return v4l2_g_ext_ctrls(vfh->ctrl_handler, arg);
+ return v4l2_g_ext_ctrls(vfh->ctrl_handler,
+ sd->v4l2_dev->mdev, arg);
case VIDIOC_S_EXT_CTRLS:
if (!vfh->ctrl_handler)
return -ENOTTY;
- return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler, arg);
+ return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler,
+ sd->v4l2_dev->mdev, arg);
case VIDIOC_TRY_EXT_CTRLS:
if (!vfh->ctrl_handler)
return -ENOTTY;
- return v4l2_try_ext_ctrls(vfh->ctrl_handler, arg);
+ return v4l2_try_ext_ctrls(vfh->ctrl_handler,
+ sd->v4l2_dev->mdev, arg);
case VIDIOC_DQEVENT:
if (!(sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS))
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index 65eade646156..de70cc3a1b80 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -1179,11 +1179,12 @@ int v4l2_s_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
* :ref:`VIDIOC_G_EXT_CTRLS <vidioc_g_ext_ctrls>` ioctl
*
* @hdl: pointer to &struct v4l2_ctrl_handler
+ * @mdev: pointer to &struct media_device
* @c: pointer to &struct v4l2_ext_controls
*
* If hdl == NULL then they will all return -EINVAL.
*/
-int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
struct v4l2_ext_controls *c);
/**
@@ -1191,11 +1192,13 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
* :ref:`VIDIOC_TRY_EXT_CTRLS <vidioc_g_ext_ctrls>` ioctl
*
* @hdl: pointer to &struct v4l2_ctrl_handler
+ * @mdev: pointer to &struct media_device
* @c: pointer to &struct v4l2_ext_controls
*
* If hdl == NULL then they will all return -EINVAL.
*/
int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl,
+ struct media_device *mdev,
struct v4l2_ext_controls *c);
/**
@@ -1204,11 +1207,13 @@ int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl,
*
* @fh: pointer to &struct v4l2_fh
* @hdl: pointer to &struct v4l2_ctrl_handler
+ * @mdev: pointer to &struct media_device
* @c: pointer to &struct v4l2_ext_controls
*
* If hdl == NULL then they will all return -EINVAL.
*/
int v4l2_s_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
+ struct media_device *mdev,
struct v4l2_ext_controls *c);
/**
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 14/35] v4l2-ctrls: support g/s_ext_ctrls for requests
2018-06-04 11:46 ` [PATCHv15 14/35] v4l2-ctrls: support g/s_ext_ctrls for requests Hans Verkuil
@ 2018-06-15 7:20 ` Hans Verkuil
0 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-15 7:20 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
On 04/06/18 13:46, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> The v4l2_g/s_ext_ctrls functions now support control handlers that
> represent requests.
>
> The v4l2_ctrls_find_req_obj() function is responsible for finding the
> request from the fd.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> drivers/media/platform/omap3isp/ispvideo.c | 2 +-
> drivers/media/v4l2-core/v4l2-ctrls.c | 128 +++++++++++++++++++--
> drivers/media/v4l2-core/v4l2-ioctl.c | 12 +-
> drivers/media/v4l2-core/v4l2-subdev.c | 9 +-
> include/media/v4l2-ctrls.h | 7 +-
> 5 files changed, 139 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c b/drivers/media/platform/omap3isp/ispvideo.c
> index 9d228eac24ea..674e7fd3ad99 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -1028,7 +1028,7 @@ static int isp_video_check_external_subdevs(struct isp_video *video,
> ctrls.count = 1;
> ctrls.controls = &ctrl;
>
> - ret = v4l2_g_ext_ctrls(pipe->external->ctrl_handler, &ctrls);
> + ret = v4l2_g_ext_ctrls(pipe->external->ctrl_handler, NULL, &ctrls);
> if (ret < 0) {
> dev_warn(isp->dev, "no pixel rate control in subdev %s\n",
> pipe->external->name);
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index bd4818507486..ab5e8827fde0 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -3124,7 +3124,8 @@ static int class_check(struct v4l2_ctrl_handler *hdl, u32 which)
> }
>
> /* Get extended controls. Allocates the helpers array if needed. */
> -int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs)
> +int __v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
> + struct v4l2_ext_controls *cs)
> {
> struct v4l2_ctrl_helper helper[4];
> struct v4l2_ctrl_helper *helpers = helper;
> @@ -3204,6 +3205,77 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs
> kvfree(helpers);
> return ret;
> }
> +
> +static struct media_request_object *
> +v4l2_ctrls_find_req_obj(struct v4l2_ctrl_handler *hdl,
> + struct media_request *req, bool set)
> +{
> + struct media_request_object *obj;
> + struct v4l2_ctrl_handler *new_hdl;
> + int ret;
> +
> + if (IS_ERR(req))
> + return ERR_CAST(req);
> +
> + if (set && WARN_ON(req->state != MEDIA_REQUEST_STATE_UPDATING))
> + return ERR_PTR(-EBUSY);
> +
> + obj = media_request_object_find(req, &req_ops, hdl);
> + if (obj)
> + return obj;
> + if (!set)
> + return ERR_PTR(-ENOENT);
> +
> + new_hdl = kzalloc(sizeof(*new_hdl), GFP_KERNEL);
> + if (!new_hdl)
> + return ERR_PTR(-ENOMEM);
> +
> + obj = &new_hdl->req_obj;
> + ret = v4l2_ctrl_handler_init(new_hdl, (hdl->nr_of_buckets - 1) * 8);
> + if (!ret)
> + ret = v4l2_ctrl_request_bind(req, new_hdl, hdl);
> + if (ret) {
> + kfree(new_hdl);
> +
> + return ERR_PTR(ret);
> + }
> +
> + media_request_object_get(obj);
> + return obj;
> +}
> +
> +int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
> + struct v4l2_ext_controls *cs)
> +{
> + struct media_request_object *obj = NULL;
> + int ret;
> +
> + if (cs->which == V4L2_CTRL_WHICH_REQUEST_VAL) {
> + struct media_request *req;
> +
> + if (!mdev || cs->request_fd < 0)
> + return -EINVAL;
> +
> + req = media_request_get_by_fd(mdev, cs->request_fd);
> + if (IS_ERR(req))
> + return PTR_ERR(req);
> +
> + obj = v4l2_ctrls_find_req_obj(hdl, req, false);
> + /* Reference to the request held through obj */
> + media_request_put(req);
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> +
> + hdl = container_of(obj, struct v4l2_ctrl_handler,
> + req_obj);
> + }
> +
> + ret = __v4l2_g_ext_ctrls(hdl, cs);
> +
> + if (obj)
> + media_request_object_put(obj);
> + return ret;
> +}
> EXPORT_SYMBOL(v4l2_g_ext_ctrls);
>
> /* Helper function to get a single control */
> @@ -3379,9 +3451,9 @@ static void update_from_auto_cluster(struct v4l2_ctrl *master)
> }
>
> /* Try or try-and-set controls */
> -static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
> - struct v4l2_ext_controls *cs,
> - bool set)
> +static int __try_set_ext_ctrls(struct v4l2_fh *fh,
> + struct v4l2_ctrl_handler *hdl,
> + struct v4l2_ext_controls *cs, bool set)
> {
> struct v4l2_ctrl_helper helper[4];
> struct v4l2_ctrl_helper *helpers = helper;
> @@ -3494,16 +3566,56 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
> return ret;
> }
>
> -int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct v4l2_ext_controls *cs)
> +static int try_set_ext_ctrls(struct v4l2_fh *fh,
> + struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
> + struct v4l2_ext_controls *cs, bool set)
> +{
> + struct media_request_object *obj = NULL;
> + struct media_request *req = NULL;
> + int ret;
> +
> + if (cs->which == V4L2_CTRL_WHICH_REQUEST_VAL) {
> + if (!mdev || cs->request_fd < 0)
> + return -EINVAL;
> +
> + req = media_request_get_by_fd(mdev, cs->request_fd);
> + if (IS_ERR(req))
> + return PTR_ERR(req);
> +
> + ret = media_request_lock_for_update(req);
> + if (ret) {
> + media_request_put(req);
Missing call to media_request_unlock_for_update().
> + return ret;
> + }
> +
> + obj = v4l2_ctrls_find_req_obj(hdl, req, set);
> + /* Reference to the request held through obj */
> + media_request_put(req);
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> + hdl = container_of(obj, struct v4l2_ctrl_handler,
> + req_obj);
> + }
> +
> + ret = __try_set_ext_ctrls(fh, hdl, cs, set);
> +
> + if (obj)
> + media_request_unlock_for_update(obj->req);
Missing call to media_request_object_put(obj)!
Regards,
Hans
> +
> + return ret;
> +}
> +
> +int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
> + struct v4l2_ext_controls *cs)
> {
> - return try_set_ext_ctrls(NULL, hdl, cs, false);
> + return try_set_ext_ctrls(NULL, hdl, mdev, cs, false);
> }
> EXPORT_SYMBOL(v4l2_try_ext_ctrls);
>
> int v4l2_s_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
> - struct v4l2_ext_controls *cs)
> + struct media_device *mdev, struct v4l2_ext_controls *cs)
> {
> - return try_set_ext_ctrls(fh, hdl, cs, true);
> + return try_set_ext_ctrls(fh, hdl, mdev, cs, true);
> }
> EXPORT_SYMBOL(v4l2_s_ext_ctrls);
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 3fa66103ffd0..fd3ea7e504e3 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2094,9 +2094,9 @@ static int v4l_g_ext_ctrls(const struct v4l2_ioctl_ops *ops,
>
> p->error_idx = p->count;
> if (vfh && vfh->ctrl_handler)
> - return v4l2_g_ext_ctrls(vfh->ctrl_handler, p);
> + return v4l2_g_ext_ctrls(vfh->ctrl_handler, vfd->v4l2_dev->mdev, p);
> if (vfd->ctrl_handler)
> - return v4l2_g_ext_ctrls(vfd->ctrl_handler, p);
> + return v4l2_g_ext_ctrls(vfd->ctrl_handler, vfd->v4l2_dev->mdev, p);
> if (ops->vidioc_g_ext_ctrls == NULL)
> return -ENOTTY;
> return check_ext_ctrls(p, 0) ? ops->vidioc_g_ext_ctrls(file, fh, p) :
> @@ -2113,9 +2113,9 @@ static int v4l_s_ext_ctrls(const struct v4l2_ioctl_ops *ops,
>
> p->error_idx = p->count;
> if (vfh && vfh->ctrl_handler)
> - return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler, p);
> + return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler, vfd->v4l2_dev->mdev, p);
> if (vfd->ctrl_handler)
> - return v4l2_s_ext_ctrls(NULL, vfd->ctrl_handler, p);
> + return v4l2_s_ext_ctrls(NULL, vfd->ctrl_handler, vfd->v4l2_dev->mdev, p);
> if (ops->vidioc_s_ext_ctrls == NULL)
> return -ENOTTY;
> return check_ext_ctrls(p, 0) ? ops->vidioc_s_ext_ctrls(file, fh, p) :
> @@ -2132,9 +2132,9 @@ static int v4l_try_ext_ctrls(const struct v4l2_ioctl_ops *ops,
>
> p->error_idx = p->count;
> if (vfh && vfh->ctrl_handler)
> - return v4l2_try_ext_ctrls(vfh->ctrl_handler, p);
> + return v4l2_try_ext_ctrls(vfh->ctrl_handler, vfd->v4l2_dev->mdev, p);
> if (vfd->ctrl_handler)
> - return v4l2_try_ext_ctrls(vfd->ctrl_handler, p);
> + return v4l2_try_ext_ctrls(vfd->ctrl_handler, vfd->v4l2_dev->mdev, p);
> if (ops->vidioc_try_ext_ctrls == NULL)
> return -ENOTTY;
> return check_ext_ctrls(p, 0) ? ops->vidioc_try_ext_ctrls(file, fh, p) :
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
> index 6a7f7f75dfd7..b9cff2389eae 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -222,17 +222,20 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg)
> case VIDIOC_G_EXT_CTRLS:
> if (!vfh->ctrl_handler)
> return -ENOTTY;
> - return v4l2_g_ext_ctrls(vfh->ctrl_handler, arg);
> + return v4l2_g_ext_ctrls(vfh->ctrl_handler,
> + sd->v4l2_dev->mdev, arg);
>
> case VIDIOC_S_EXT_CTRLS:
> if (!vfh->ctrl_handler)
> return -ENOTTY;
> - return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler, arg);
> + return v4l2_s_ext_ctrls(vfh, vfh->ctrl_handler,
> + sd->v4l2_dev->mdev, arg);
>
> case VIDIOC_TRY_EXT_CTRLS:
> if (!vfh->ctrl_handler)
> return -ENOTTY;
> - return v4l2_try_ext_ctrls(vfh->ctrl_handler, arg);
> + return v4l2_try_ext_ctrls(vfh->ctrl_handler,
> + sd->v4l2_dev->mdev, arg);
>
> case VIDIOC_DQEVENT:
> if (!(sd->flags & V4L2_SUBDEV_FL_HAS_EVENTS))
> diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
> index 65eade646156..de70cc3a1b80 100644
> --- a/include/media/v4l2-ctrls.h
> +++ b/include/media/v4l2-ctrls.h
> @@ -1179,11 +1179,12 @@ int v4l2_s_ctrl(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
> * :ref:`VIDIOC_G_EXT_CTRLS <vidioc_g_ext_ctrls>` ioctl
> *
> * @hdl: pointer to &struct v4l2_ctrl_handler
> + * @mdev: pointer to &struct media_device
> * @c: pointer to &struct v4l2_ext_controls
> *
> * If hdl == NULL then they will all return -EINVAL.
> */
> -int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
> +int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl, struct media_device *mdev,
> struct v4l2_ext_controls *c);
>
> /**
> @@ -1191,11 +1192,13 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
> * :ref:`VIDIOC_TRY_EXT_CTRLS <vidioc_g_ext_ctrls>` ioctl
> *
> * @hdl: pointer to &struct v4l2_ctrl_handler
> + * @mdev: pointer to &struct media_device
> * @c: pointer to &struct v4l2_ext_controls
> *
> * If hdl == NULL then they will all return -EINVAL.
> */
> int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl,
> + struct media_device *mdev,
> struct v4l2_ext_controls *c);
>
> /**
> @@ -1204,11 +1207,13 @@ int v4l2_try_ext_ctrls(struct v4l2_ctrl_handler *hdl,
> *
> * @fh: pointer to &struct v4l2_fh
> * @hdl: pointer to &struct v4l2_ctrl_handler
> + * @mdev: pointer to &struct media_device
> * @c: pointer to &struct v4l2_ext_controls
> *
> * If hdl == NULL then they will all return -EINVAL.
> */
> int v4l2_s_ext_ctrls(struct v4l2_fh *fh, struct v4l2_ctrl_handler *hdl,
> + struct media_device *mdev,
> struct v4l2_ext_controls *c);
>
> /**
>
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 15/35] vb2: store userspace data in vb2_v4l2_buffer
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (13 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 14/35] v4l2-ctrls: support g/s_ext_ctrls for requests Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 16/35] davinci_vpfe: remove bogus vb2->state check Hans Verkuil
` (19 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
The userspace-provided plane data needs to be stored in
vb2_v4l2_buffer. Currently this information is applied by
__fill_vb2_buffer() which is called by the core prepare_buf
and qbuf functions, but when using requests these functions
aren't called yet since the buffer won't be prepared until
the media request is actually queued.
In the meantime this information has to be stored somewhere
and vb2_v4l2_buffer is a good place for it.
The __fill_vb2_buffer callback now just copies the relevant
information from vb2_v4l2_buffer into the planes array.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
.../media/common/videobuf2/videobuf2-core.c | 43 +--
.../media/common/videobuf2/videobuf2-v4l2.c | 327 ++++++++++--------
drivers/media/dvb-core/dvb_vb2.c | 3 +-
include/media/videobuf2-core.h | 3 +-
include/media/videobuf2-v4l2.h | 2 +
5 files changed, 209 insertions(+), 169 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index f32ec7342ef0..c25bad134ba3 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -967,20 +967,19 @@ EXPORT_SYMBOL_GPL(vb2_discard_done);
/*
* __prepare_mmap() - prepare an MMAP buffer
*/
-static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
+static int __prepare_mmap(struct vb2_buffer *vb)
{
int ret = 0;
- if (pb)
- ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
- vb, pb, vb->planes);
+ ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
+ vb, vb->planes);
return ret ? ret : call_vb_qop(vb, buf_prepare, vb);
}
/*
* __prepare_userptr() - prepare a USERPTR buffer
*/
-static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
+static int __prepare_userptr(struct vb2_buffer *vb)
{
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -991,12 +990,10 @@ static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
/* Copy relevant information provided by the userspace */
- if (pb) {
- ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
- vb, pb, planes);
- if (ret)
- return ret;
- }
+ ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
+ vb, planes);
+ if (ret)
+ return ret;
for (plane = 0; plane < vb->num_planes; ++plane) {
/* Skip the plane if already verified */
@@ -1096,7 +1093,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
/*
* __prepare_dmabuf() - prepare a DMABUF buffer
*/
-static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
+static int __prepare_dmabuf(struct vb2_buffer *vb)
{
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1107,12 +1104,10 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
/* Copy relevant information provided by the userspace */
- if (pb) {
- ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
- vb, pb, planes);
- if (ret)
- return ret;
- }
+ ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
+ vb, planes);
+ if (ret)
+ return ret;
for (plane = 0; plane < vb->num_planes; ++plane) {
struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
@@ -1241,7 +1236,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
call_void_vb_qop(vb, buf_queue, vb);
}
-static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
+static int __buf_prepare(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb->vb2_queue;
unsigned int plane;
@@ -1256,13 +1251,13 @@ static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
switch (q->memory) {
case VB2_MEMORY_MMAP:
- ret = __prepare_mmap(vb, pb);
+ ret = __prepare_mmap(vb);
break;
case VB2_MEMORY_USERPTR:
- ret = __prepare_userptr(vb, pb);
+ ret = __prepare_userptr(vb);
break;
case VB2_MEMORY_DMABUF:
- ret = __prepare_dmabuf(vb, pb);
+ ret = __prepare_dmabuf(vb);
break;
default:
WARN(1, "Invalid queue type\n");
@@ -1296,7 +1291,7 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
return -EINVAL;
}
- ret = __buf_prepare(vb, pb);
+ ret = __buf_prepare(vb);
if (ret)
return ret;
@@ -1381,7 +1376,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
switch (vb->state) {
case VB2_BUF_STATE_DEQUEUED:
- ret = __buf_prepare(vb, pb);
+ ret = __buf_prepare(vb);
if (ret)
return ret;
break;
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 886a2d8d5c6c..360dc4e7d413 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -154,9 +154,177 @@ static void vb2_warn_zero_bytesused(struct vb2_buffer *vb)
pr_warn("use the actual size instead.\n");
}
+static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b)
+{
+ struct vb2_queue *q = vb->vb2_queue;
+ struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+ struct vb2_plane *planes = vbuf->planes;
+ unsigned int plane;
+ int ret;
+
+ ret = __verify_length(vb, b);
+ if (ret < 0) {
+ dprintk(1, "plane parameters verification failed: %d\n", ret);
+ return ret;
+ }
+ if (b->field == V4L2_FIELD_ALTERNATE && q->is_output) {
+ /*
+ * If the format's field is ALTERNATE, then the buffer's field
+ * should be either TOP or BOTTOM, not ALTERNATE since that
+ * makes no sense. The driver has to know whether the
+ * buffer represents a top or a bottom field in order to
+ * program any DMA correctly. Using ALTERNATE is wrong, since
+ * that just says that it is either a top or a bottom field,
+ * but not which of the two it is.
+ */
+ dprintk(1, "the field is incorrectly set to ALTERNATE for an output buffer\n");
+ return -EINVAL;
+ }
+ vbuf->sequence = 0;
+
+ if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
+ switch (b->memory) {
+ case VB2_MEMORY_USERPTR:
+ for (plane = 0; plane < vb->num_planes; ++plane) {
+ planes[plane].m.userptr =
+ b->m.planes[plane].m.userptr;
+ planes[plane].length =
+ b->m.planes[plane].length;
+ }
+ break;
+ case VB2_MEMORY_DMABUF:
+ for (plane = 0; plane < vb->num_planes; ++plane) {
+ planes[plane].m.fd =
+ b->m.planes[plane].m.fd;
+ planes[plane].length =
+ b->m.planes[plane].length;
+ }
+ break;
+ default:
+ for (plane = 0; plane < vb->num_planes; ++plane) {
+ planes[plane].m.offset =
+ vb->planes[plane].m.offset;
+ planes[plane].length =
+ vb->planes[plane].length;
+ }
+ break;
+ }
+
+ /* Fill in driver-provided information for OUTPUT types */
+ if (V4L2_TYPE_IS_OUTPUT(b->type)) {
+ /*
+ * Will have to go up to b->length when API starts
+ * accepting variable number of planes.
+ *
+ * If bytesused == 0 for the output buffer, then fall
+ * back to the full buffer size. In that case
+ * userspace clearly never bothered to set it and
+ * it's a safe assumption that they really meant to
+ * use the full plane sizes.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused == 0
+ * as a way to indicate that streaming is finished.
+ * In that case, the driver should use the
+ * allow_zero_bytesused flag to keep old userspace
+ * applications working.
+ */
+ for (plane = 0; plane < vb->num_planes; ++plane) {
+ struct vb2_plane *pdst = &planes[plane];
+ struct v4l2_plane *psrc = &b->m.planes[plane];
+
+ if (psrc->bytesused == 0)
+ vb2_warn_zero_bytesused(vb);
+
+ if (vb->vb2_queue->allow_zero_bytesused)
+ pdst->bytesused = psrc->bytesused;
+ else
+ pdst->bytesused = psrc->bytesused ?
+ psrc->bytesused : pdst->length;
+ pdst->data_offset = psrc->data_offset;
+ }
+ }
+ } else {
+ /*
+ * Single-planar buffers do not use planes array,
+ * so fill in relevant v4l2_buffer struct fields instead.
+ * In videobuf we use our internal V4l2_planes struct for
+ * single-planar buffers as well, for simplicity.
+ *
+ * If bytesused == 0 for the output buffer, then fall back
+ * to the full buffer size as that's a sensible default.
+ *
+ * Some drivers, e.g. old codec drivers, use bytesused == 0 as
+ * a way to indicate that streaming is finished. In that case,
+ * the driver should use the allow_zero_bytesused flag to keep
+ * old userspace applications working.
+ */
+ switch (b->memory) {
+ case VB2_MEMORY_USERPTR:
+ planes[0].m.userptr = b->m.userptr;
+ planes[0].length = b->length;
+ break;
+ case VB2_MEMORY_DMABUF:
+ planes[0].m.fd = b->m.fd;
+ planes[0].length = b->length;
+ break;
+ default:
+ planes[0].m.offset = vb->planes[0].m.offset;
+ planes[0].length = vb->planes[0].length;
+ break;
+ }
+
+ planes[0].data_offset = 0;
+ if (V4L2_TYPE_IS_OUTPUT(b->type)) {
+ if (b->bytesused == 0)
+ vb2_warn_zero_bytesused(vb);
+
+ if (vb->vb2_queue->allow_zero_bytesused)
+ planes[0].bytesused = b->bytesused;
+ else
+ planes[0].bytesused = b->bytesused ?
+ b->bytesused : planes[0].length;
+ } else
+ planes[0].bytesused = 0;
+
+ }
+
+ /* Zero flags that we handle */
+ vbuf->flags = b->flags & ~V4L2_BUFFER_MASK_FLAGS;
+ if (!vb->vb2_queue->copy_timestamp || !V4L2_TYPE_IS_OUTPUT(b->type)) {
+ /*
+ * Non-COPY timestamps and non-OUTPUT queues will get
+ * their timestamp and timestamp source flags from the
+ * queue.
+ */
+ vbuf->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+ }
+
+ if (V4L2_TYPE_IS_OUTPUT(b->type)) {
+ /*
+ * For output buffers mask out the timecode flag:
+ * this will be handled later in vb2_qbuf().
+ * The 'field' is valid metadata for this output buffer
+ * and so that needs to be copied here.
+ */
+ vbuf->flags &= ~V4L2_BUF_FLAG_TIMECODE;
+ vbuf->field = b->field;
+ } else {
+ /* Zero any output buffer flags as this is a capture buffer */
+ vbuf->flags &= ~V4L2_BUFFER_OUT_FLAGS;
+ /* Zero last flag, this is a signal from driver to userspace */
+ vbuf->flags &= ~V4L2_BUF_FLAG_LAST;
+ }
+
+ return 0;
+}
+
static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b,
const char *opname)
{
+ struct vb2_v4l2_buffer *vbuf;
+ struct vb2_buffer *vb;
+ int ret;
+
if (b->type != q->type) {
dprintk(1, "%s: invalid buffer type\n", opname);
return -EINVAL;
@@ -178,7 +346,15 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b,
return -EINVAL;
}
- return __verify_planes_array(q->bufs[b->index], b);
+ vb = q->bufs[b->index];
+ vbuf = to_vb2_v4l2_buffer(vb);
+ ret = __verify_planes_array(vb, b);
+ if (ret)
+ return ret;
+
+ /* Copy relevant information provided by the userspace */
+ memset(vbuf->planes, 0, sizeof(vbuf->planes[0]) * vb->num_planes);
+ return vb2_fill_vb2_v4l2_buffer(vb, b);
}
/*
@@ -291,153 +467,22 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb)
* v4l2_buffer by the userspace. It also verifies that struct
* v4l2_buffer has a valid number of planes.
*/
-static int __fill_vb2_buffer(struct vb2_buffer *vb,
- const void *pb, struct vb2_plane *planes)
+static int __fill_vb2_buffer(struct vb2_buffer *vb, struct vb2_plane *planes)
{
- struct vb2_queue *q = vb->vb2_queue;
- const struct v4l2_buffer *b = pb;
struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
unsigned int plane;
- int ret;
-
- ret = __verify_length(vb, b);
- if (ret < 0) {
- dprintk(1, "plane parameters verification failed: %d\n", ret);
- return ret;
- }
- if (b->field == V4L2_FIELD_ALTERNATE && q->is_output) {
- /*
- * If the format's field is ALTERNATE, then the buffer's field
- * should be either TOP or BOTTOM, not ALTERNATE since that
- * makes no sense. The driver has to know whether the
- * buffer represents a top or a bottom field in order to
- * program any DMA correctly. Using ALTERNATE is wrong, since
- * that just says that it is either a top or a bottom field,
- * but not which of the two it is.
- */
- dprintk(1, "the field is incorrectly set to ALTERNATE for an output buffer\n");
- return -EINVAL;
- }
- vb->timestamp = 0;
- vbuf->sequence = 0;
-
- if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
- if (b->memory == VB2_MEMORY_USERPTR) {
- for (plane = 0; plane < vb->num_planes; ++plane) {
- planes[plane].m.userptr =
- b->m.planes[plane].m.userptr;
- planes[plane].length =
- b->m.planes[plane].length;
- }
- }
- if (b->memory == VB2_MEMORY_DMABUF) {
- for (plane = 0; plane < vb->num_planes; ++plane) {
- planes[plane].m.fd =
- b->m.planes[plane].m.fd;
- planes[plane].length =
- b->m.planes[plane].length;
- }
- }
-
- /* Fill in driver-provided information for OUTPUT types */
- if (V4L2_TYPE_IS_OUTPUT(b->type)) {
- /*
- * Will have to go up to b->length when API starts
- * accepting variable number of planes.
- *
- * If bytesused == 0 for the output buffer, then fall
- * back to the full buffer size. In that case
- * userspace clearly never bothered to set it and
- * it's a safe assumption that they really meant to
- * use the full plane sizes.
- *
- * Some drivers, e.g. old codec drivers, use bytesused == 0
- * as a way to indicate that streaming is finished.
- * In that case, the driver should use the
- * allow_zero_bytesused flag to keep old userspace
- * applications working.
- */
- for (plane = 0; plane < vb->num_planes; ++plane) {
- struct vb2_plane *pdst = &planes[plane];
- struct v4l2_plane *psrc = &b->m.planes[plane];
-
- if (psrc->bytesused == 0)
- vb2_warn_zero_bytesused(vb);
- if (vb->vb2_queue->allow_zero_bytesused)
- pdst->bytesused = psrc->bytesused;
- else
- pdst->bytesused = psrc->bytesused ?
- psrc->bytesused : pdst->length;
- pdst->data_offset = psrc->data_offset;
- }
- }
- } else {
- /*
- * Single-planar buffers do not use planes array,
- * so fill in relevant v4l2_buffer struct fields instead.
- * In videobuf we use our internal V4l2_planes struct for
- * single-planar buffers as well, for simplicity.
- *
- * If bytesused == 0 for the output buffer, then fall back
- * to the full buffer size as that's a sensible default.
- *
- * Some drivers, e.g. old codec drivers, use bytesused == 0 as
- * a way to indicate that streaming is finished. In that case,
- * the driver should use the allow_zero_bytesused flag to keep
- * old userspace applications working.
- */
- if (b->memory == VB2_MEMORY_USERPTR) {
- planes[0].m.userptr = b->m.userptr;
- planes[0].length = b->length;
- }
+ if (!vb->vb2_queue->is_output || !vb->vb2_queue->copy_timestamp)
+ vb->timestamp = 0;
- if (b->memory == VB2_MEMORY_DMABUF) {
- planes[0].m.fd = b->m.fd;
- planes[0].length = b->length;
+ for (plane = 0; plane < vb->num_planes; ++plane) {
+ if (vb->vb2_queue->memory != VB2_MEMORY_MMAP) {
+ planes[plane].m = vbuf->planes[plane].m;
+ planes[plane].length = vbuf->planes[plane].length;
}
-
- if (V4L2_TYPE_IS_OUTPUT(b->type)) {
- if (b->bytesused == 0)
- vb2_warn_zero_bytesused(vb);
-
- if (vb->vb2_queue->allow_zero_bytesused)
- planes[0].bytesused = b->bytesused;
- else
- planes[0].bytesused = b->bytesused ?
- b->bytesused : planes[0].length;
- } else
- planes[0].bytesused = 0;
-
- }
-
- /* Zero flags that the vb2 core handles */
- vbuf->flags = b->flags & ~V4L2_BUFFER_MASK_FLAGS;
- if (!vb->vb2_queue->copy_timestamp || !V4L2_TYPE_IS_OUTPUT(b->type)) {
- /*
- * Non-COPY timestamps and non-OUTPUT queues will get
- * their timestamp and timestamp source flags from the
- * queue.
- */
- vbuf->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+ planes[plane].bytesused = vbuf->planes[plane].bytesused;
+ planes[plane].data_offset = vbuf->planes[plane].data_offset;
}
-
- if (V4L2_TYPE_IS_OUTPUT(b->type)) {
- /*
- * For output buffers mask out the timecode flag:
- * this will be handled later in vb2_qbuf().
- * The 'field' is valid metadata for this output buffer
- * and so that needs to be copied here.
- */
- vbuf->flags &= ~V4L2_BUF_FLAG_TIMECODE;
- vbuf->field = b->field;
- } else {
- /* Zero any output buffer flags as this is a capture buffer */
- vbuf->flags &= ~V4L2_BUFFER_OUT_FLAGS;
- /* Zero last flag, this is a signal from driver to userspace */
- vbuf->flags &= ~V4L2_BUF_FLAG_LAST;
- }
-
return 0;
}
diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c
index b811adf88afa..da6a8cec7d42 100644
--- a/drivers/media/dvb-core/dvb_vb2.c
+++ b/drivers/media/dvb-core/dvb_vb2.c
@@ -146,8 +146,7 @@ static void _fill_dmx_buffer(struct vb2_buffer *vb, void *pb)
dprintk(3, "[%s]\n", ctx->name);
}
-static int _fill_vb2_buffer(struct vb2_buffer *vb,
- const void *pb, struct vb2_plane *planes)
+static int _fill_vb2_buffer(struct vb2_buffer *vb, struct vb2_plane *planes)
{
struct dvb_vb2_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index f6818f732f34..224c4820a044 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -417,8 +417,7 @@ struct vb2_ops {
struct vb2_buf_ops {
int (*verify_planes_array)(struct vb2_buffer *vb, const void *pb);
void (*fill_user_buffer)(struct vb2_buffer *vb, void *pb);
- int (*fill_vb2_buffer)(struct vb2_buffer *vb, const void *pb,
- struct vb2_plane *planes);
+ int (*fill_vb2_buffer)(struct vb2_buffer *vb, struct vb2_plane *planes);
void (*copy_timestamp)(struct vb2_buffer *vb, const void *pb);
};
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 3d5e2d739f05..097bf3e6951d 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -32,6 +32,7 @@
* &enum v4l2_field.
* @timecode: frame timecode.
* @sequence: sequence count of this frame.
+ * @planes: plane information (userptr/fd, length, bytesused, data_offset).
*
* Should contain enough information to be able to cover all the fields
* of &struct v4l2_buffer at ``videodev2.h``.
@@ -43,6 +44,7 @@ struct vb2_v4l2_buffer {
__u32 field;
struct v4l2_timecode timecode;
__u32 sequence;
+ struct vb2_plane planes[VB2_MAX_PLANES];
};
/*
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 16/35] davinci_vpfe: remove bogus vb2->state check
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (14 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 15/35] vb2: store userspace data in vb2_v4l2_buffer Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 17/35] vb2: drop VB2_BUF_STATE_PREPARED, use bool prepared/synced instead Hans Verkuil
` (18 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
There is no need to check the vb2 state in the buf_prepare
callback: it can never be wrong.
Since VB2_BUF_STATE_PREPARED will be removed in the next patch
we'll remove this unnecessary check (and use of that state) first.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/staging/media/davinci_vpfe/vpfe_video.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 390fc98d07dd..edcb07bf653c 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -1135,10 +1135,6 @@ static int vpfe_buffer_prepare(struct vb2_buffer *vb)
v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev, "vpfe_buffer_prepare\n");
- if (vb->state != VB2_BUF_STATE_ACTIVE &&
- vb->state != VB2_BUF_STATE_PREPARED)
- return 0;
-
/* Initialize buffer */
vb2_set_plane_payload(vb, 0, video->fmt.fmt.pix.sizeimage);
if (vb2_plane_vaddr(vb, 0) &&
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 17/35] vb2: drop VB2_BUF_STATE_PREPARED, use bool prepared/synced instead
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (15 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 16/35] davinci_vpfe: remove bogus vb2->state check Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 18/35] videodev2.h: Add request_fd field to v4l2_buffer Hans Verkuil
` (17 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
The PREPARED state becomes a problem with the request API: a buffer
could be PREPARED but dequeued, or PREPARED and in state IN_REQUEST.
PREPARED is really not a state as such, but more a property of the
buffer. So make new 'prepared' and 'synced' bools instead to remember
whether the buffer is prepared and/or synced or not.
V4L2_BUF_FLAG_PREPARED is only set if the buffer is both synced and
prepared and in the DEQUEUED state.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
.../media/common/videobuf2/videobuf2-core.c | 38 +++++++++++++------
.../media/common/videobuf2/videobuf2-v4l2.c | 16 +++++---
include/media/videobuf2-core.h | 6 ++-
3 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index c25bad134ba3..997673b62afc 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -682,7 +682,7 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory memory,
}
/*
- * Call queue_cancel to clean up any buffers in the PREPARED or
+ * Call queue_cancel to clean up any buffers in the
* QUEUED state which is possible if buffers were prepared or
* queued without ever calling STREAMON.
*/
@@ -921,6 +921,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state)
/* sync buffers */
for (plane = 0; plane < vb->num_planes; ++plane)
call_void_memop(vb, finish, vb->planes[plane].mem_priv);
+ vb->synced = false;
}
spin_lock_irqsave(&q->done_lock, flags);
@@ -1239,6 +1240,7 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
static int __buf_prepare(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb->vb2_queue;
+ enum vb2_buffer_state orig_state = vb->state;
unsigned int plane;
int ret;
@@ -1247,6 +1249,10 @@ static int __buf_prepare(struct vb2_buffer *vb)
return -EIO;
}
+ if (vb->prepared)
+ return 0;
+ WARN_ON(vb->synced);
+
vb->state = VB2_BUF_STATE_PREPARING;
switch (q->memory) {
@@ -1262,11 +1268,12 @@ static int __buf_prepare(struct vb2_buffer *vb)
default:
WARN(1, "Invalid queue type\n");
ret = -EINVAL;
+ break;
}
if (ret) {
dprintk(1, "buffer preparation failed: %d\n", ret);
- vb->state = VB2_BUF_STATE_DEQUEUED;
+ vb->state = orig_state;
return ret;
}
@@ -1274,7 +1281,9 @@ static int __buf_prepare(struct vb2_buffer *vb)
for (plane = 0; plane < vb->num_planes; ++plane)
call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
- vb->state = VB2_BUF_STATE_PREPARED;
+ vb->synced = true;
+ vb->prepared = true;
+ vb->state = orig_state;
return 0;
}
@@ -1290,6 +1299,10 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
vb->state);
return -EINVAL;
}
+ if (vb->prepared) {
+ dprintk(1, "buffer already prepared\n");
+ return -EINVAL;
+ }
ret = __buf_prepare(vb);
if (ret)
@@ -1376,11 +1389,11 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
switch (vb->state) {
case VB2_BUF_STATE_DEQUEUED:
- ret = __buf_prepare(vb);
- if (ret)
- return ret;
- break;
- case VB2_BUF_STATE_PREPARED:
+ if (!vb->prepared) {
+ ret = __buf_prepare(vb);
+ if (ret)
+ return ret;
+ }
break;
case VB2_BUF_STATE_PREPARING:
dprintk(1, "buffer still being prepared\n");
@@ -1606,6 +1619,7 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int *pindex, void *pb,
}
call_void_vb_qop(vb, buf_finish, vb);
+ vb->prepared = false;
if (pindex)
*pindex = vb->index;
@@ -1694,18 +1708,18 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
for (i = 0; i < q->num_buffers; ++i) {
struct vb2_buffer *vb = q->bufs[i];
- if (vb->state == VB2_BUF_STATE_PREPARED ||
- vb->state == VB2_BUF_STATE_QUEUED) {
+ if (vb->synced) {
unsigned int plane;
for (plane = 0; plane < vb->num_planes; ++plane)
call_void_memop(vb, finish,
vb->planes[plane].mem_priv);
+ vb->synced = false;
}
- if (vb->state != VB2_BUF_STATE_DEQUEUED) {
- vb->state = VB2_BUF_STATE_PREPARED;
+ if (vb->prepared) {
call_void_vb_qop(vb, buf_finish, vb);
+ vb->prepared = false;
}
__vb2_dqbuf(vb);
}
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 360dc4e7d413..a677e2c26247 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -352,9 +352,13 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b,
if (ret)
return ret;
- /* Copy relevant information provided by the userspace */
- memset(vbuf->planes, 0, sizeof(vbuf->planes[0]) * vb->num_planes);
- return vb2_fill_vb2_v4l2_buffer(vb, b);
+ if (!vb->prepared) {
+ /* Copy relevant information provided by the userspace */
+ memset(vbuf->planes, 0,
+ sizeof(vbuf->planes[0]) * vb->num_planes);
+ ret = vb2_fill_vb2_v4l2_buffer(vb, b);
+ }
+ return ret;
}
/*
@@ -443,9 +447,6 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb)
case VB2_BUF_STATE_DONE:
b->flags |= V4L2_BUF_FLAG_DONE;
break;
- case VB2_BUF_STATE_PREPARED:
- b->flags |= V4L2_BUF_FLAG_PREPARED;
- break;
case VB2_BUF_STATE_PREPARING:
case VB2_BUF_STATE_DEQUEUED:
case VB2_BUF_STATE_REQUEUEING:
@@ -453,6 +454,9 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb)
break;
}
+ if (vb->state == VB2_BUF_STATE_DEQUEUED && vb->synced && vb->prepared)
+ b->flags |= V4L2_BUF_FLAG_PREPARED;
+
if (vb2_buffer_in_use(q, vb))
b->flags |= V4L2_BUF_FLAG_MAPPED;
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 224c4820a044..5e760d5f280a 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -204,7 +204,6 @@ enum vb2_io_modes {
* enum vb2_buffer_state - current video buffer state.
* @VB2_BUF_STATE_DEQUEUED: buffer under userspace control.
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf.
- * @VB2_BUF_STATE_PREPARED: buffer prepared in videobuf and by the driver.
* @VB2_BUF_STATE_QUEUED: buffer queued in videobuf, but not in driver.
* @VB2_BUF_STATE_REQUEUEING: re-queue a buffer to the driver.
* @VB2_BUF_STATE_ACTIVE: buffer queued in driver and possibly used
@@ -218,7 +217,6 @@ enum vb2_io_modes {
enum vb2_buffer_state {
VB2_BUF_STATE_DEQUEUED,
VB2_BUF_STATE_PREPARING,
- VB2_BUF_STATE_PREPARED,
VB2_BUF_STATE_QUEUED,
VB2_BUF_STATE_REQUEUEING,
VB2_BUF_STATE_ACTIVE,
@@ -250,6 +248,8 @@ struct vb2_buffer {
/* private: internal use only
*
* state: current buffer state; do not change
+ * synced: this buffer has been synced
+ * prepared: this buffer has been prepared
* queued_entry: entry on the queued buffers list, which holds
* all buffers queued from userspace
* done_entry: entry on the list that stores all buffers ready
@@ -257,6 +257,8 @@ struct vb2_buffer {
* vb2_plane: per-plane information; do not change
*/
enum vb2_buffer_state state;
+ bool synced;
+ bool prepared;
struct vb2_plane planes[VB2_MAX_PLANES];
struct list_head queued_entry;
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 18/35] videodev2.h: Add request_fd field to v4l2_buffer
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (16 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 17/35] vb2: drop VB2_BUF_STATE_PREPARED, use bool prepared/synced instead Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 19/35] vb2: add init_buffer buffer op Hans Verkuil
` (16 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
When queuing buffers allow for passing the request that should
be associated with this buffer.
If V4L2_BUF_FLAG_REQUEST_FD is set, then request_fd is used as
the file descriptor.
If a buffer is stored in a request, but not yet queued to the
driver, then V4L2_BUF_FLAG_IN_REQUEST is set.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 +-
drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 ++++++---
drivers/media/v4l2-core/v4l2-ioctl.c | 4 ++--
include/uapi/linux/videodev2.h | 10 +++++++++-
5 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index a677e2c26247..64905d87465c 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -384,7 +384,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb)
b->timecode = vbuf->timecode;
b->sequence = vbuf->sequence;
b->reserved2 = 0;
- b->reserved = 0;
+ b->request_fd = 0;
if (q->is_multiplanar) {
/*
diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c b/drivers/media/usb/cpia2/cpia2_v4l.c
index 99f106b13280..13aee9f67d05 100644
--- a/drivers/media/usb/cpia2/cpia2_v4l.c
+++ b/drivers/media/usb/cpia2/cpia2_v4l.c
@@ -949,7 +949,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, struct v4l2_buffer *buf)
buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
buf->length = cam->frame_size;
buf->reserved2 = 0;
- buf->reserved = 0;
+ buf->request_fd = 0;
memset(&buf->timecode, 0, sizeof(buf->timecode));
DBG("DQBUF #%d status:%d seq:%d length:%d\n", buf->index,
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index dcce86c1fe40..633465d21d04 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -482,7 +482,7 @@ struct v4l2_buffer32 {
} m;
__u32 length;
__u32 reserved2;
- __u32 reserved;
+ __s32 request_fd;
};
static int get_v4l2_plane32(struct v4l2_plane __user *p64,
@@ -581,6 +581,7 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user *p64,
{
u32 type;
u32 length;
+ s32 request_fd;
enum v4l2_memory memory;
struct v4l2_plane32 __user *uplane32;
struct v4l2_plane __user *uplane;
@@ -595,7 +596,9 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user *p64,
get_user(memory, &p32->memory) ||
put_user(memory, &p64->memory) ||
get_user(length, &p32->length) ||
- put_user(length, &p64->length))
+ put_user(length, &p64->length) ||
+ get_user(request_fd, &p32->request_fd) ||
+ put_user(request_fd, &p64->request_fd))
return -EFAULT;
if (V4L2_TYPE_IS_OUTPUT(type))
@@ -699,7 +702,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user *p64,
copy_in_user(&p32->timecode, &p64->timecode, sizeof(p64->timecode)) ||
assign_in_user(&p32->sequence, &p64->sequence) ||
assign_in_user(&p32->reserved2, &p64->reserved2) ||
- assign_in_user(&p32->reserved, &p64->reserved) ||
+ assign_in_user(&p32->request_fd, &p64->request_fd) ||
get_user(length, &p64->length) ||
put_user(length, &p32->length))
return -EFAULT;
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index fd3ea7e504e3..eeae589b44ef 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -437,13 +437,13 @@ static void v4l_print_buffer(const void *arg, bool write_only)
const struct v4l2_plane *plane;
int i;
- pr_cont("%02ld:%02d:%02d.%08ld index=%d, type=%s, flags=0x%08x, field=%s, sequence=%d, memory=%s",
+ pr_cont("%02ld:%02d:%02d.%08ld index=%d, type=%s, request_fd=%d, flags=0x%08x, field=%s, sequence=%d, memory=%s",
p->timestamp.tv_sec / 3600,
(int)(p->timestamp.tv_sec / 60) % 60,
(int)(p->timestamp.tv_sec % 60),
(long)p->timestamp.tv_usec,
p->index,
- prt_names(p->type, v4l2_type_names),
+ prt_names(p->type, v4l2_type_names), p->request_fd,
p->flags, prt_names(p->field, v4l2_field_names),
p->sequence, prt_names(p->memory, v4l2_memory_names));
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 16b53b82496c..1f6c4b52baae 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -910,6 +910,7 @@ struct v4l2_plane {
* @length: size in bytes of the buffer (NOT its payload) for single-plane
* buffers (when type != *_MPLANE); number of elements in the
* planes array for multi-plane buffers
+ * @request_fd: fd of the request that this buffer should use
*
* Contains data exchanged by application and driver using one of the Streaming
* I/O methods.
@@ -934,7 +935,10 @@ struct v4l2_buffer {
} m;
__u32 length;
__u32 reserved2;
- __u32 reserved;
+ union {
+ __s32 request_fd;
+ __u32 reserved;
+ };
};
/* Flags for 'flags' field */
@@ -952,6 +956,8 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_BFRAME 0x00000020
/* Buffer is ready, but the data contained within is corrupted. */
#define V4L2_BUF_FLAG_ERROR 0x00000040
+/* Buffer is added to an unqueued request */
+#define V4L2_BUF_FLAG_IN_REQUEST 0x00000080
/* timecode field is valid */
#define V4L2_BUF_FLAG_TIMECODE 0x00000100
/* Buffer is prepared for queuing */
@@ -970,6 +976,8 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_TSTAMP_SRC_SOE 0x00010000
/* mem2mem encoder/decoder */
#define V4L2_BUF_FLAG_LAST 0x00100000
+/* request_fd is valid */
+#define V4L2_BUF_FLAG_REQUEST_FD 0x00800000
/**
* struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 19/35] vb2: add init_buffer buffer op
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (17 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 18/35] videodev2.h: Add request_fd field to v4l2_buffer Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 20/35] videobuf2-core: embed media_request_object Hans Verkuil
` (15 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
We need to initialize the request_fd field in struct vb2_v4l2_buffer
to -1 instead of the default of 0. So we need to add a new op that
is called when struct vb2_v4l2_buffer is allocated.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/common/videobuf2/videobuf2-core.c | 2 ++
include/media/videobuf2-core.h | 4 ++++
2 files changed, 6 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index 997673b62afc..a9e958df8324 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -356,6 +356,8 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum vb2_memory memory,
vb->planes[plane].length = plane_sizes[plane];
vb->planes[plane].min_length = plane_sizes[plane];
}
+ call_void_bufop(q, init_buffer, vb);
+
q->bufs[vb->index] = vb;
/* Allocate video buffer memory for the MMAP type */
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 5e760d5f280a..cbda3968d018 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -408,6 +408,9 @@ struct vb2_ops {
* @verify_planes_array: Verify that a given user space structure contains
* enough planes for the buffer. This is called
* for each dequeued buffer.
+ * @init_buffer: given a &vb2_buffer initialize the extra data after
+ * struct vb2_buffer.
+ * For V4L2 this is a &struct vb2_v4l2_buffer.
* @fill_user_buffer: given a &vb2_buffer fill in the userspace structure.
* For V4L2 this is a &struct v4l2_buffer.
* @fill_vb2_buffer: given a userspace structure, fill in the &vb2_buffer.
@@ -418,6 +421,7 @@ struct vb2_ops {
*/
struct vb2_buf_ops {
int (*verify_planes_array)(struct vb2_buffer *vb, const void *pb);
+ void (*init_buffer)(struct vb2_buffer *vb);
void (*fill_user_buffer)(struct vb2_buffer *vb, void *pb);
int (*fill_vb2_buffer)(struct vb2_buffer *vb, struct vb2_plane *planes);
void (*copy_timestamp)(struct vb2_buffer *vb, const void *pb);
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 20/35] videobuf2-core: embed media_request_object
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (18 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 19/35] vb2: add init_buffer buffer op Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 21/35] videobuf2-core: integrate with media requests Hans Verkuil
` (14 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Make vb2_buffer a request object.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
include/media/videobuf2-core.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cbda3968d018..df92dcdeabb3 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -17,6 +17,7 @@
#include <linux/poll.h>
#include <linux/dma-buf.h>
#include <linux/bitops.h>
+#include <media/media-request.h>
#define VB2_MAX_FRAME (32)
#define VB2_MAX_PLANES (8)
@@ -236,6 +237,8 @@ struct vb2_queue;
* @num_planes: number of planes in the buffer
* on an internal driver queue.
* @timestamp: frame timestamp in ns.
+ * @req_obj: used to bind this buffer to a request. This
+ * request object has a refcount.
*/
struct vb2_buffer {
struct vb2_queue *vb2_queue;
@@ -244,6 +247,7 @@ struct vb2_buffer {
unsigned int memory;
unsigned int num_planes;
u64 timestamp;
+ struct media_request_object req_obj;
/* private: internal use only
*
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 21/35] videobuf2-core: integrate with media requests
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (19 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 20/35] videobuf2-core: embed media_request_object Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 22/35] videobuf2-v4l2: " Hans Verkuil
` (13 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Buffers can now be prepared or queued for a request.
A buffer is unbound from the request at vb2_buffer_done time or
when the queue is cancelled.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
.../media/common/videobuf2/videobuf2-core.c | 133 +++++++++++++++++-
.../media/common/videobuf2/videobuf2-v4l2.c | 4 +-
drivers/media/dvb-core/dvb_vb2.c | 2 +-
include/media/videobuf2-core.h | 18 ++-
4 files changed, 147 insertions(+), 10 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index a9e958df8324..6d423bc5a1a1 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -499,8 +499,9 @@ static int __vb2_queue_free(struct vb2_queue *q, unsigned int buffers)
pr_info(" buf_init: %u buf_cleanup: %u buf_prepare: %u buf_finish: %u\n",
vb->cnt_buf_init, vb->cnt_buf_cleanup,
vb->cnt_buf_prepare, vb->cnt_buf_finish);
- pr_info(" buf_queue: %u buf_done: %u\n",
- vb->cnt_buf_queue, vb->cnt_buf_done);
+ pr_info(" buf_queue: %u buf_done: %u buf_request_complete: %u\n",
+ vb->cnt_buf_queue, vb->cnt_buf_done,
+ vb->cnt_buf_request_complete);
pr_info(" alloc: %u put: %u prepare: %u finish: %u mmap: %u\n",
vb->cnt_mem_alloc, vb->cnt_mem_put,
vb->cnt_mem_prepare, vb->cnt_mem_finish,
@@ -936,6 +937,14 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state)
vb->state = state;
}
atomic_dec(&q->owned_by_drv_count);
+
+ if (vb->req_obj.req) {
+ /* This is not supported at the moment */
+ WARN_ON(state == VB2_BUF_STATE_REQUEUEING);
+ media_request_object_unbind(&vb->req_obj);
+ media_request_object_put(&vb->req_obj);
+ }
+
spin_unlock_irqrestore(&q->done_lock, flags);
trace_vb2_buf_done(q, vb);
@@ -1290,6 +1299,60 @@ static int __buf_prepare(struct vb2_buffer *vb)
return 0;
}
+static int vb2_req_prepare(struct media_request_object *obj)
+{
+ struct vb2_buffer *vb = container_of(obj, struct vb2_buffer, req_obj);
+ int ret;
+
+ if (WARN_ON(vb->state != VB2_BUF_STATE_IN_REQUEST))
+ return -EINVAL;
+
+ mutex_lock(vb->vb2_queue->lock);
+ ret = __buf_prepare(vb);
+ mutex_unlock(vb->vb2_queue->lock);
+ return ret;
+}
+
+static void __vb2_dqbuf(struct vb2_buffer *vb);
+
+static void vb2_req_unprepare(struct media_request_object *obj)
+{
+ struct vb2_buffer *vb = container_of(obj, struct vb2_buffer, req_obj);
+
+ mutex_lock(vb->vb2_queue->lock);
+ __vb2_dqbuf(vb);
+ vb->state = VB2_BUF_STATE_IN_REQUEST;
+ mutex_unlock(vb->vb2_queue->lock);
+ WARN_ON(!vb->req_obj.req);
+}
+
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct media_request *req);
+
+static void vb2_req_queue(struct media_request_object *obj)
+{
+ struct vb2_buffer *vb = container_of(obj, struct vb2_buffer, req_obj);
+
+ mutex_lock(vb->vb2_queue->lock);
+ vb2_core_qbuf(vb->vb2_queue, vb->index, NULL, NULL);
+ mutex_unlock(vb->vb2_queue->lock);
+}
+
+static void vb2_req_release(struct media_request_object *obj)
+{
+ struct vb2_buffer *vb = container_of(obj, struct vb2_buffer, req_obj);
+
+ if (vb->state == VB2_BUF_STATE_IN_REQUEST)
+ vb->state = VB2_BUF_STATE_DEQUEUED;
+}
+
+static const struct media_request_object_ops vb2_core_req_ops = {
+ .prepare = vb2_req_prepare,
+ .unprepare = vb2_req_unprepare,
+ .queue = vb2_req_queue,
+ .release = vb2_req_release,
+};
+
int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
{
struct vb2_buffer *vb;
@@ -1315,7 +1378,7 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
dprintk(2, "prepare of buffer %d succeeded\n", vb->index);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_GPL(vb2_core_prepare_buf);
@@ -1382,15 +1445,47 @@ static int vb2_start_streaming(struct vb2_queue *q)
return ret;
}
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb)
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct media_request *req)
{
struct vb2_buffer *vb;
int ret;
vb = q->bufs[index];
+ if (req) {
+ int ret;
+
+ if (vb->state != VB2_BUF_STATE_DEQUEUED) {
+ dprintk(1, "buffer %d not in dequeued state\n",
+ vb->index);
+ return -EINVAL;
+ }
+
+ media_request_object_init(&vb->req_obj);
+
+ /* Make sure the request is in a safe state for updating. */
+ ret = media_request_lock_for_update(req);
+ if (ret)
+ return ret;
+ ret = media_request_object_bind(req, &vb2_core_req_ops,
+ q, &vb->req_obj);
+ media_request_unlock_for_update(req);
+ if (ret)
+ return ret;
+
+ vb->state = VB2_BUF_STATE_IN_REQUEST;
+ /* Fill buffer information for the userspace */
+ if (pb)
+ call_void_bufop(q, fill_user_buffer, vb, pb);
+
+ dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
+ return 0;
+ }
+
switch (vb->state) {
case VB2_BUF_STATE_DEQUEUED:
+ case VB2_BUF_STATE_IN_REQUEST:
if (!vb->prepared) {
ret = __buf_prepare(vb);
if (ret)
@@ -1596,6 +1691,11 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
call_void_memop(vb, unmap_dmabuf, vb->planes[i].mem_priv);
vb->planes[i].dbuf_mapped = 0;
}
+ if (vb->req_obj.req) {
+ media_request_object_unbind(&vb->req_obj);
+ media_request_object_put(&vb->req_obj);
+ }
+ call_void_bufop(q, init_buffer, vb);
}
int vb2_core_dqbuf(struct vb2_queue *q, unsigned int *pindex, void *pb,
@@ -1709,6 +1809,25 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
*/
for (i = 0; i < q->num_buffers; ++i) {
struct vb2_buffer *vb = q->bufs[i];
+ struct media_request *req = vb->req_obj.req;
+
+ /*
+ * If a request is associated with this buffer, then
+ * call buf_request_cancel() to give the driver to complete()
+ * related request objects. Otherwise those objects would
+ * never complete.
+ */
+ if (req) {
+ enum media_request_state state;
+ unsigned long flags;
+
+ spin_lock_irqsave(&req->lock, flags);
+ state = req->state;
+ spin_unlock_irqrestore(&req->lock, flags);
+
+ if (state == MEDIA_REQUEST_STATE_QUEUED)
+ call_void_vb_qop(vb, buf_request_complete, vb);
+ }
if (vb->synced) {
unsigned int plane;
@@ -2278,7 +2397,7 @@ static int __vb2_init_fileio(struct vb2_queue *q, int read)
* Queue all buffers.
*/
for (i = 0; i < q->num_buffers; i++) {
- ret = vb2_core_qbuf(q, i, NULL);
+ ret = vb2_core_qbuf(q, i, NULL, NULL);
if (ret)
goto err_reqbufs;
fileio->bufs[i].queued = 1;
@@ -2457,7 +2576,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, char __user *data, size_
if (copy_timestamp)
b->timestamp = ktime_get_ns();
- ret = vb2_core_qbuf(q, index, NULL);
+ ret = vb2_core_qbuf(q, index, NULL, NULL);
dprintk(5, "vb2_dbuf result: %d\n", ret);
if (ret)
return ret;
@@ -2560,7 +2679,7 @@ static int vb2_thread(void *data)
if (copy_timestamp)
vb->timestamp = ktime_get_ns();
if (!threadio->stop)
- ret = vb2_core_qbuf(q, vb->index, NULL);
+ ret = vb2_core_qbuf(q, vb->index, NULL, NULL);
call_void_qop(q, wait_prepare, q);
if (ret || threadio->stop)
break;
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 64905d87465c..ea9db4b3f59a 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -441,6 +441,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb)
case VB2_BUF_STATE_ACTIVE:
b->flags |= V4L2_BUF_FLAG_QUEUED;
break;
+ case VB2_BUF_STATE_IN_REQUEST:
+ break;
case VB2_BUF_STATE_ERROR:
b->flags |= V4L2_BUF_FLAG_ERROR;
/* fall through */
@@ -619,7 +621,7 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
}
ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
- return ret ? ret : vb2_core_qbuf(q, b->index, b);
+ return ret ? ret : vb2_core_qbuf(q, b->index, b, NULL);
}
EXPORT_SYMBOL_GPL(vb2_qbuf);
diff --git a/drivers/media/dvb-core/dvb_vb2.c b/drivers/media/dvb-core/dvb_vb2.c
index da6a8cec7d42..f1e7f0536028 100644
--- a/drivers/media/dvb-core/dvb_vb2.c
+++ b/drivers/media/dvb-core/dvb_vb2.c
@@ -384,7 +384,7 @@ int dvb_vb2_qbuf(struct dvb_vb2_ctx *ctx, struct dmx_buffer *b)
{
int ret;
- ret = vb2_core_qbuf(&ctx->vb_q, b->index, b);
+ ret = vb2_core_qbuf(&ctx->vb_q, b->index, b, NULL);
if (ret) {
dprintk(1, "[%s] index=%d errno=%d\n", ctx->name,
b->index, ret);
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index df92dcdeabb3..8a8d7732d182 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -204,6 +204,7 @@ enum vb2_io_modes {
/**
* enum vb2_buffer_state - current video buffer state.
* @VB2_BUF_STATE_DEQUEUED: buffer under userspace control.
+ * @VB2_BUF_STATE_IN_REQUEST: buffer is queued in media request.
* @VB2_BUF_STATE_PREPARING: buffer is being prepared in videobuf.
* @VB2_BUF_STATE_QUEUED: buffer queued in videobuf, but not in driver.
* @VB2_BUF_STATE_REQUEUEING: re-queue a buffer to the driver.
@@ -217,6 +218,7 @@ enum vb2_io_modes {
*/
enum vb2_buffer_state {
VB2_BUF_STATE_DEQUEUED,
+ VB2_BUF_STATE_IN_REQUEST,
VB2_BUF_STATE_PREPARING,
VB2_BUF_STATE_QUEUED,
VB2_BUF_STATE_REQUEUEING,
@@ -293,6 +295,7 @@ struct vb2_buffer {
u32 cnt_buf_finish;
u32 cnt_buf_cleanup;
u32 cnt_buf_queue;
+ u32 cnt_buf_request_complete;
/* This counts the number of calls to vb2_buffer_done() */
u32 cnt_buf_done;
@@ -386,6 +389,11 @@ struct vb2_buffer {
* ioctl; might be called before @start_streaming callback
* if user pre-queued buffers before calling
* VIDIOC_STREAMON().
+ * @buf_request_complete: a buffer that was never queued to the driver but is
+ * associated with a queued request was canceled.
+ * The driver will have to mark associated objects in the
+ * request as completed; required if requests are
+ * supported.
*/
struct vb2_ops {
int (*queue_setup)(struct vb2_queue *q,
@@ -404,6 +412,8 @@ struct vb2_ops {
void (*stop_streaming)(struct vb2_queue *q);
void (*buf_queue)(struct vb2_buffer *vb);
+
+ void (*buf_request_complete)(struct vb2_buffer *vb);
};
/**
@@ -761,12 +771,17 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
* @index: id number of the buffer
* @pb: buffer structure passed from userspace to
* v4l2_ioctl_ops->vidioc_qbuf handler in driver
+ * @req: pointer to &struct media_request, may be NULL.
*
* Videobuf2 core helper to implement VIDIOC_QBUF() operation. It is called
* internally by VB2 by an API-specific handler, like ``videobuf2-v4l2.h``.
*
* This function:
*
+ * #) If @req is non-NULL, then the buffer will be bound to this
+ * media request and it returns. The buffer will be prepared and
+ * queued to the driver (i.e. the next two steps) when the request
+ * itself is queued.
* #) if necessary, calls &vb2_ops->buf_prepare callback in the driver
* (if provided), in which driver-specific buffer initialization can
* be performed;
@@ -775,7 +790,8 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb);
*
* Return: returns zero on success; an error code otherwise.
*/
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb);
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct media_request *req);
/**
* vb2_core_dqbuf() - Dequeue a buffer to the userspace
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 22/35] videobuf2-v4l2: integrate with media requests
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (20 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 21/35] videobuf2-core: integrate with media requests Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 23/35] videobuf2-core: add request helper functions Hans Verkuil
` (12 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
This implements the V4L2 part of the request support. The main
change is that vb2_qbuf and vb2_prepare_buf now have a new
media_device pointer. This required changes to several drivers
that did not use the vb2_ioctl_qbuf/prepare_buf helper functions.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
.../media/common/videobuf2/videobuf2-core.c | 13 +-
.../media/common/videobuf2/videobuf2-v4l2.c | 112 ++++++++++++++++--
drivers/media/platform/omap3isp/ispvideo.c | 2 +-
.../media/platform/s3c-camif/camif-capture.c | 4 +-
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 4 +-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 4 +-
.../media/platform/soc_camera/soc_camera.c | 4 +-
drivers/media/usb/uvc/uvc_queue.c | 5 +-
drivers/media/usb/uvc/uvc_v4l2.c | 3 +-
drivers/media/usb/uvc/uvcvideo.h | 1 +
drivers/media/v4l2-core/v4l2-mem2mem.c | 7 +-
.../staging/media/davinci_vpfe/vpfe_video.c | 3 +-
drivers/staging/media/omap4iss/iss_video.c | 3 +-
drivers/usb/gadget/function/uvc_queue.c | 2 +-
include/media/videobuf2-v4l2.h | 14 ++-
15 files changed, 149 insertions(+), 32 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index 6d423bc5a1a1..049822bcdd02 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1338,6 +1338,14 @@ static void vb2_req_queue(struct media_request_object *obj)
mutex_unlock(vb->vb2_queue->lock);
}
+static void vb2_req_unbind(struct media_request_object *obj)
+{
+ struct vb2_buffer *vb = container_of(obj, struct vb2_buffer, req_obj);
+
+ if (vb->state == VB2_BUF_STATE_IN_REQUEST)
+ call_void_bufop(vb->vb2_queue, init_buffer, vb);
+}
+
static void vb2_req_release(struct media_request_object *obj)
{
struct vb2_buffer *vb = container_of(obj, struct vb2_buffer, req_obj);
@@ -1350,6 +1358,7 @@ static const struct media_request_object_ops vb2_core_req_ops = {
.prepare = vb2_req_prepare,
.unprepare = vb2_req_unprepare,
.queue = vb2_req_queue,
+ .unbind = vb2_req_unbind,
.release = vb2_req_release,
};
@@ -1476,8 +1485,10 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
vb->state = VB2_BUF_STATE_IN_REQUEST;
/* Fill buffer information for the userspace */
- if (pb)
+ if (pb) {
+ call_void_bufop(q, copy_timestamp, vb, pb);
call_void_bufop(q, fill_user_buffer, vb, pb);
+ }
dprintk(2, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index ea9db4b3f59a..9c652afa62ab 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -25,6 +25,7 @@
#include <linux/kthread.h>
#include <media/v4l2-dev.h>
+#include <media/v4l2-device.h>
#include <media/v4l2-fh.h>
#include <media/v4l2-event.h>
#include <media/v4l2-common.h>
@@ -40,10 +41,12 @@ module_param(debug, int, 0644);
pr_info("vb2-v4l2: %s: " fmt, __func__, ## arg); \
} while (0)
-/* Flags that are set by the vb2 core */
+/* Flags that are set by us */
#define V4L2_BUFFER_MASK_FLAGS (V4L2_BUF_FLAG_MAPPED | V4L2_BUF_FLAG_QUEUED | \
V4L2_BUF_FLAG_DONE | V4L2_BUF_FLAG_ERROR | \
V4L2_BUF_FLAG_PREPARED | \
+ V4L2_BUF_FLAG_IN_REQUEST | \
+ V4L2_BUF_FLAG_REQUEST_FD | \
V4L2_BUF_FLAG_TIMESTAMP_MASK)
/* Output buffer flags that should be passed on to the driver */
#define V4L2_BUFFER_OUT_FLAGS (V4L2_BUF_FLAG_PFRAME | V4L2_BUF_FLAG_BFRAME | \
@@ -118,6 +121,16 @@ static int __verify_length(struct vb2_buffer *vb, const struct v4l2_buffer *b)
return 0;
}
+/*
+ * __init_v4l2_vb2_buffer() - initialize the v4l2_vb2_buffer struct
+ */
+static void __init_v4l2_vb2_buffer(struct vb2_buffer *vb)
+{
+ struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+
+ vbuf->request_fd = -1;
+}
+
static void __copy_timestamp(struct vb2_buffer *vb, const void *pb)
{
const struct v4l2_buffer *b = pb;
@@ -181,6 +194,7 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b
return -EINVAL;
}
vbuf->sequence = 0;
+ vbuf->request_fd = -1;
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
switch (b->memory) {
@@ -318,9 +332,12 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer *b
return 0;
}
-static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b,
- const char *opname)
+static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct media_device *mdev,
+ struct v4l2_buffer *b,
+ const char *opname,
+ struct media_request **p_req)
{
+ struct media_request *req;
struct vb2_v4l2_buffer *vbuf;
struct vb2_buffer *vb;
int ret;
@@ -357,8 +374,60 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b,
memset(vbuf->planes, 0,
sizeof(vbuf->planes[0]) * vb->num_planes);
ret = vb2_fill_vb2_v4l2_buffer(vb, b);
+ if (ret)
+ return ret;
}
- return ret;
+
+ if (!(b->flags & V4L2_BUF_FLAG_REQUEST_FD))
+ return 0;
+
+ /*
+ * For proper locking when queueing a request you need to be able
+ * to lock access to the vb2 queue, so check that there is a lock
+ * that we can use. In addition p_req must be non-NULL.
+ */
+ if (WARN_ON(!q->lock || !p_req))
+ return -EINVAL;
+
+ /*
+ * Make sure this op is implemented by the driver. It's easy to forget
+ * this callback, but is it important when canceling a buffer in a
+ * queued request.
+ */
+ if (WARN_ON(!q->ops->buf_request_complete))
+ return -EINVAL;
+
+ if (vb->state != VB2_BUF_STATE_DEQUEUED) {
+ dprintk(1, "%s: buffer is not in dequeued state\n", opname);
+ return -EINVAL;
+ }
+
+ if (b->request_fd < 0) {
+ dprintk(1, "%s: request_fd < 0\n", opname);
+ return -EINVAL;
+ }
+
+ req = media_request_get_by_fd(mdev, b->request_fd);
+ if (IS_ERR(req)) {
+ dprintk(1, "%s: invalid request_fd\n", opname);
+ return PTR_ERR(req);
+ }
+
+ /*
+ * Early sanity check. This is checked again when the buffer
+ * is bound to the request in vb2_core_qbuf().
+ */
+ if (req->state != MEDIA_REQUEST_STATE_IDLE &&
+ req->state != MEDIA_REQUEST_STATE_UPDATING) {
+ dprintk(1, "%s: request is not idle\n", opname);
+ media_request_put(req);
+ return -EBUSY;
+ }
+
+ *p_req = req;
+ vbuf->request_fd = b->request_fd;
+
+ return 0;
}
/*
@@ -442,6 +511,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb)
b->flags |= V4L2_BUF_FLAG_QUEUED;
break;
case VB2_BUF_STATE_IN_REQUEST:
+ b->flags |= V4L2_BUF_FLAG_IN_REQUEST;
break;
case VB2_BUF_STATE_ERROR:
b->flags |= V4L2_BUF_FLAG_ERROR;
@@ -456,11 +526,17 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb)
break;
}
- if (vb->state == VB2_BUF_STATE_DEQUEUED && vb->synced && vb->prepared)
+ if ((vb->state == VB2_BUF_STATE_DEQUEUED ||
+ vb->state == VB2_BUF_STATE_IN_REQUEST) &&
+ vb->synced && vb->prepared)
b->flags |= V4L2_BUF_FLAG_PREPARED;
if (vb2_buffer_in_use(q, vb))
b->flags |= V4L2_BUF_FLAG_MAPPED;
+ if (vbuf->request_fd >= 0) {
+ b->flags |= V4L2_BUF_FLAG_REQUEST_FD;
+ b->request_fd = vbuf->request_fd;
+ }
if (!q->is_output &&
b->flags & V4L2_BUF_FLAG_DONE &&
@@ -494,6 +570,7 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, struct vb2_plane *planes)
static const struct vb2_buf_ops v4l2_buf_ops = {
.verify_planes_array = __verify_planes_array_core,
+ .init_buffer = __init_v4l2_vb2_buffer,
.fill_user_buffer = __fill_v4l2_buffer,
.fill_vb2_buffer = __fill_vb2_buffer,
.copy_timestamp = __copy_timestamp,
@@ -542,7 +619,8 @@ int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
}
EXPORT_SYMBOL_GPL(vb2_reqbufs);
-int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b)
+int vb2_prepare_buf(struct vb2_queue *q, struct media_device *mdev,
+ struct v4l2_buffer *b)
{
int ret;
@@ -551,7 +629,10 @@ int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b)
return -EBUSY;
}
- ret = vb2_queue_or_prepare_buf(q, b, "prepare_buf");
+ if (b->flags & V4L2_BUF_FLAG_REQUEST_FD)
+ return -EINVAL;
+
+ ret = vb2_queue_or_prepare_buf(q, mdev, b, "prepare_buf", NULL);
return ret ? ret : vb2_core_prepare_buf(q, b->index, b);
}
@@ -611,8 +692,10 @@ int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create)
}
EXPORT_SYMBOL_GPL(vb2_create_bufs);
-int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
+int vb2_qbuf(struct vb2_queue *q, struct media_device *mdev,
+ struct v4l2_buffer *b)
{
+ struct media_request *req = NULL;
int ret;
if (vb2_fileio_is_active(q)) {
@@ -620,8 +703,13 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
return -EBUSY;
}
- ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
- return ret ? ret : vb2_core_qbuf(q, b->index, b, NULL);
+ ret = vb2_queue_or_prepare_buf(q, mdev, b, "qbuf", &req);
+ if (ret)
+ return ret;
+ ret = vb2_core_qbuf(q, b->index, b, req);
+ if (req)
+ media_request_put(req);
+ return ret;
}
EXPORT_SYMBOL_GPL(vb2_qbuf);
@@ -811,7 +899,7 @@ int vb2_ioctl_prepare_buf(struct file *file, void *priv,
if (vb2_queue_is_busy(vdev, file))
return -EBUSY;
- return vb2_prepare_buf(vdev->queue, p);
+ return vb2_prepare_buf(vdev->queue, vdev->v4l2_dev->mdev, p);
}
EXPORT_SYMBOL_GPL(vb2_ioctl_prepare_buf);
@@ -830,7 +918,7 @@ int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p)
if (vb2_queue_is_busy(vdev, file))
return -EBUSY;
- return vb2_qbuf(vdev->queue, p);
+ return vb2_qbuf(vdev->queue, vdev->v4l2_dev->mdev, p);
}
EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf);
diff --git a/drivers/media/platform/omap3isp/ispvideo.c b/drivers/media/platform/omap3isp/ispvideo.c
index 674e7fd3ad99..1de7b6b13f67 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -940,7 +940,7 @@ isp_video_qbuf(struct file *file, void *fh, struct v4l2_buffer *b)
int ret;
mutex_lock(&video->queue_lock);
- ret = vb2_qbuf(&vfh->queue, b);
+ ret = vb2_qbuf(&vfh->queue, video->video.v4l2_dev->mdev, b);
mutex_unlock(&video->queue_lock);
return ret;
diff --git a/drivers/media/platform/s3c-camif/camif-capture.c b/drivers/media/platform/s3c-camif/camif-capture.c
index 9ab8e7ee2e1e..fafb6da3e804 100644
--- a/drivers/media/platform/s3c-camif/camif-capture.c
+++ b/drivers/media/platform/s3c-camif/camif-capture.c
@@ -941,7 +941,7 @@ static int s3c_camif_qbuf(struct file *file, void *priv,
if (vp->owner && vp->owner != priv)
return -EBUSY;
- return vb2_qbuf(&vp->vb_queue, buf);
+ return vb2_qbuf(&vp->vb_queue, vp->vdev.v4l2_dev->mdev, buf);
}
static int s3c_camif_dqbuf(struct file *file, void *priv,
@@ -979,7 +979,7 @@ static int s3c_camif_prepare_buf(struct file *file, void *priv,
struct v4l2_buffer *b)
{
struct camif_vp *vp = video_drvdata(file);
- return vb2_prepare_buf(&vp->vb_queue, b);
+ return vb2_prepare_buf(&vp->vb_queue, vp->vdev.v4l2_dev->mdev, b);
}
static int s3c_camif_g_selection(struct file *file, void *priv,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 6a3cc4f86c5d..fc0b61f1b91d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -632,9 +632,9 @@ static int vidioc_qbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
return -EIO;
}
if (buf->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
- return vb2_qbuf(&ctx->vq_src, buf);
+ return vb2_qbuf(&ctx->vq_src, NULL, buf);
else if (buf->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
- return vb2_qbuf(&ctx->vq_dst, buf);
+ return vb2_qbuf(&ctx->vq_dst, NULL, buf);
return -EINVAL;
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 570f391f2cfd..ec1e47ff7b85 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1621,9 +1621,9 @@ static int vidioc_qbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
mfc_err("Call on QBUF after EOS command\n");
return -EIO;
}
- return vb2_qbuf(&ctx->vq_src, buf);
+ return vb2_qbuf(&ctx->vq_src, NULL, buf);
} else if (buf->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
- return vb2_qbuf(&ctx->vq_dst, buf);
+ return vb2_qbuf(&ctx->vq_dst, NULL, buf);
}
return -EINVAL;
}
diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c
index e6787abc34ae..08adf9a79420 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -394,7 +394,7 @@ static int soc_camera_qbuf(struct file *file, void *priv,
if (icd->streamer != file)
return -EBUSY;
- return vb2_qbuf(&icd->vb2_vidq, p);
+ return vb2_qbuf(&icd->vb2_vidq, NULL, p);
}
static int soc_camera_dqbuf(struct file *file, void *priv,
@@ -430,7 +430,7 @@ static int soc_camera_prepare_buf(struct file *file, void *priv,
{
struct soc_camera_device *icd = file->private_data;
- return vb2_prepare_buf(&icd->vb2_vidq, b);
+ return vb2_prepare_buf(&icd->vb2_vidq, NULL, b);
}
static int soc_camera_expbuf(struct file *file, void *priv,
diff --git a/drivers/media/usb/uvc/uvc_queue.c b/drivers/media/usb/uvc/uvc_queue.c
index fecccb5e7628..8964e16f2b22 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -300,12 +300,13 @@ int uvc_create_buffers(struct uvc_video_queue *queue,
return ret;
}
-int uvc_queue_buffer(struct uvc_video_queue *queue, struct v4l2_buffer *buf)
+int uvc_queue_buffer(struct uvc_video_queue *queue,
+ struct media_device *mdev, struct v4l2_buffer *buf)
{
int ret;
mutex_lock(&queue->mutex);
- ret = vb2_qbuf(&queue->queue, buf);
+ ret = vb2_qbuf(&queue->queue, mdev, buf);
mutex_unlock(&queue->mutex);
return ret;
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index bd32914259ae..3da5fdc002ac 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -751,7 +751,8 @@ static int uvc_ioctl_qbuf(struct file *file, void *fh, struct v4l2_buffer *buf)
if (!uvc_has_privileges(handle))
return -EBUSY;
- return uvc_queue_buffer(&stream->queue, buf);
+ return uvc_queue_buffer(&stream->queue,
+ stream->vdev.v4l2_dev->mdev, buf);
}
static int uvc_ioctl_expbuf(struct file *file, void *fh,
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index be5cf179228b..bc9ed18f043c 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -680,6 +680,7 @@ int uvc_query_buffer(struct uvc_video_queue *queue,
int uvc_create_buffers(struct uvc_video_queue *queue,
struct v4l2_create_buffers *v4l2_cb);
int uvc_queue_buffer(struct uvc_video_queue *queue,
+ struct media_device *mdev,
struct v4l2_buffer *v4l2_buf);
int uvc_export_buffer(struct uvc_video_queue *queue,
struct v4l2_exportbuffer *exp);
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c
index c4f963d96a79..438f1b869319 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -20,6 +20,7 @@
#include <media/videobuf2-v4l2.h>
#include <media/v4l2-mem2mem.h>
#include <media/v4l2-dev.h>
+#include <media/v4l2-device.h>
#include <media/v4l2-fh.h>
#include <media/v4l2-event.h>
@@ -388,11 +389,12 @@ EXPORT_SYMBOL_GPL(v4l2_m2m_querybuf);
int v4l2_m2m_qbuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
struct v4l2_buffer *buf)
{
+ struct video_device *vdev = video_devdata(file);
struct vb2_queue *vq;
int ret;
vq = v4l2_m2m_get_vq(m2m_ctx, buf->type);
- ret = vb2_qbuf(vq, buf);
+ ret = vb2_qbuf(vq, vdev->v4l2_dev->mdev, buf);
if (!ret)
v4l2_m2m_try_schedule(m2m_ctx);
@@ -413,11 +415,12 @@ EXPORT_SYMBOL_GPL(v4l2_m2m_dqbuf);
int v4l2_m2m_prepare_buf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
struct v4l2_buffer *buf)
{
+ struct video_device *vdev = video_devdata(file);
struct vb2_queue *vq;
int ret;
vq = v4l2_m2m_get_vq(m2m_ctx, buf->type);
- ret = vb2_prepare_buf(vq, buf);
+ ret = vb2_prepare_buf(vq, vdev->v4l2_dev->mdev, buf);
if (!ret)
v4l2_m2m_try_schedule(m2m_ctx);
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index edcb07bf653c..1cf70934f441 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -1422,7 +1422,8 @@ static int vpfe_qbuf(struct file *file, void *priv,
return -EACCES;
}
- return vb2_qbuf(&video->buffer_queue, p);
+ return vb2_qbuf(&video->buffer_queue,
+ video->video_dev.v4l2_dev->mdev, p);
}
/*
diff --git a/drivers/staging/media/omap4iss/iss_video.c b/drivers/staging/media/omap4iss/iss_video.c
index a3a83424a926..a35d1004b522 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -805,9 +805,10 @@ iss_video_querybuf(struct file *file, void *fh, struct v4l2_buffer *b)
static int
iss_video_qbuf(struct file *file, void *fh, struct v4l2_buffer *b)
{
+ struct iss_video *video = video_drvdata(file);
struct iss_video_fh *vfh = to_iss_video_fh(fh);
- return vb2_qbuf(&vfh->queue, b);
+ return vb2_qbuf(&vfh->queue, video->video.v4l2_dev->mdev, b);
}
static int
diff --git a/drivers/usb/gadget/function/uvc_queue.c b/drivers/usb/gadget/function/uvc_queue.c
index 9e33d5206d54..f2497cb96abb 100644
--- a/drivers/usb/gadget/function/uvc_queue.c
+++ b/drivers/usb/gadget/function/uvc_queue.c
@@ -166,7 +166,7 @@ int uvcg_queue_buffer(struct uvc_video_queue *queue, struct v4l2_buffer *buf)
unsigned long flags;
int ret;
- ret = vb2_qbuf(&queue->queue, buf);
+ ret = vb2_qbuf(&queue->queue, NULL, buf);
if (ret < 0)
return ret;
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 097bf3e6951d..91a2b3e1a642 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -32,6 +32,7 @@
* &enum v4l2_field.
* @timecode: frame timecode.
* @sequence: sequence count of this frame.
+ * @request_fd: the request_fd associated with this buffer
* @planes: plane information (userptr/fd, length, bytesused, data_offset).
*
* Should contain enough information to be able to cover all the fields
@@ -44,6 +45,7 @@ struct vb2_v4l2_buffer {
__u32 field;
struct v4l2_timecode timecode;
__u32 sequence;
+ __s32 request_fd;
struct vb2_plane planes[VB2_MAX_PLANES];
};
@@ -79,6 +81,7 @@ int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create);
* vb2_prepare_buf() - Pass ownership of a buffer from userspace to the kernel
*
* @q: pointer to &struct vb2_queue with videobuf2 queue.
+ * @mdev: pointer to &struct media_device, may be NULL.
* @b: buffer structure passed from userspace to
* &v4l2_ioctl_ops->vidioc_prepare_buf handler in driver
*
@@ -90,15 +93,19 @@ int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create);
* #) verifies the passed buffer,
* #) calls &vb2_ops->buf_prepare callback in the driver (if provided),
* in which driver-specific buffer initialization can be performed.
+ * #) if @b->request_fd is non-zero and @mdev->ops->req_queue is set,
+ * then bind the prepared buffer to the request.
*
* The return values from this function are intended to be directly returned
* from &v4l2_ioctl_ops->vidioc_prepare_buf handler in driver.
*/
-int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b);
+int vb2_prepare_buf(struct vb2_queue *q, struct media_device *mdev,
+ struct v4l2_buffer *b);
/**
* vb2_qbuf() - Queue a buffer from userspace
* @q: pointer to &struct vb2_queue with videobuf2 queue.
+ * @mdev: pointer to &struct media_device, may be NULL.
* @b: buffer structure passed from userspace to
* &v4l2_ioctl_ops->vidioc_qbuf handler in driver
*
@@ -107,6 +114,8 @@ int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b);
* This function:
*
* #) verifies the passed buffer;
+ * #) if @b->request_fd is non-zero and @mdev->ops->req_queue is set,
+ * then bind the buffer to the request.
* #) if necessary, calls &vb2_ops->buf_prepare callback in the driver
* (if provided), in which driver-specific buffer initialization can
* be performed;
@@ -116,7 +125,8 @@ int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b);
* The return values from this function are intended to be directly returned
* from &v4l2_ioctl_ops->vidioc_qbuf handler in driver.
*/
-int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
+int vb2_qbuf(struct vb2_queue *q, struct media_device *mdev,
+ struct v4l2_buffer *b);
/**
* vb2_expbuf() - Export a buffer as a file descriptor
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 23/35] videobuf2-core: add request helper functions
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (21 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 22/35] videobuf2-v4l2: " Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 24/35] videobuf2-v4l2: add vb2_request_queue/validate helpers Hans Verkuil
` (11 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add a new helper function to tell if a request object is a buffer.
Add a new helper function that returns true if a media_request
contains at least one buffer.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/common/videobuf2/videobuf2-core.c | 17 +++++++++++++++++
include/media/videobuf2-core.h | 15 +++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index 049822bcdd02..697765e70fbe 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1362,6 +1362,23 @@ static const struct media_request_object_ops vb2_core_req_ops = {
.release = vb2_req_release,
};
+bool vb2_request_object_is_buffer(struct media_request_object *obj)
+{
+ return obj->ops == &vb2_core_req_ops;
+}
+EXPORT_SYMBOL_GPL(vb2_request_object_is_buffer);
+
+bool vb2_request_has_buffers(struct media_request *req)
+{
+ struct media_request_object *obj;
+
+ list_for_each_entry(obj, &req->objects, list)
+ if (vb2_request_object_is_buffer(obj))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL_GPL(vb2_request_has_buffers);
+
int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
{
struct vb2_buffer *vb;
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 8a8d7732d182..cad712403d14 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -1168,4 +1168,19 @@ bool vb2_buffer_in_use(struct vb2_queue *q, struct vb2_buffer *vb);
*/
int vb2_verify_memory_type(struct vb2_queue *q,
enum vb2_memory memory, unsigned int type);
+
+/**
+ * vb2_request_object_is_buffer() - return true if the object is a buffer
+ *
+ * @obj: the request object.
+ */
+bool vb2_request_object_is_buffer(struct media_request_object *obj);
+
+/**
+ * vb2_request_has_buffers() - return true if the request contains buffers
+ *
+ * @req: the request.
+ */
+bool vb2_request_has_buffers(struct media_request *req);
+
#endif /* _MEDIA_VIDEOBUF2_CORE_H */
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 24/35] videobuf2-v4l2: add vb2_request_queue/validate helpers
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (22 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 23/35] videobuf2-core: add request helper functions Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 25/35] videobuf2-core: add uses_requests flag Hans Verkuil
` (10 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
The generic vb2_request_validate helper function checks if
there are buffers in the request and if so, prepares (validates)
all objects in the request.
The generic vb2_request_queue helper function queues all buffer
objects in the validated request.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
.../media/common/videobuf2/videobuf2-v4l2.c | 38 +++++++++++++++++++
include/media/videobuf2-v4l2.h | 4 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 9c652afa62ab..499b2ab3d1fa 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -1100,6 +1100,44 @@ void vb2_ops_wait_finish(struct vb2_queue *vq)
}
EXPORT_SYMBOL_GPL(vb2_ops_wait_finish);
+int vb2_request_validate(struct media_request *req)
+{
+ struct media_request_object *obj;
+ int ret = 0;
+
+ if (!vb2_request_has_buffers(req))
+ return -ENOENT;
+
+ list_for_each_entry(obj, &req->objects, list) {
+ if (!obj->ops->prepare)
+ continue;
+
+ ret = obj->ops->prepare(obj);
+ if (ret)
+ break;
+ }
+
+ if (ret) {
+ list_for_each_entry_continue_reverse(obj, &req->objects, list)
+ if (obj->ops->unprepare)
+ obj->ops->unprepare(obj);
+ return ret;
+ }
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_request_validate);
+
+void vb2_request_queue(struct media_request *req)
+{
+ struct media_request_object *obj;
+
+ list_for_each_entry(obj, &req->objects, list) {
+ if (obj->ops->queue)
+ obj->ops->queue(obj);
+ }
+}
+EXPORT_SYMBOL_GPL(vb2_request_queue);
+
MODULE_DESCRIPTION("Driver helper framework for Video for Linux 2");
MODULE_AUTHOR("Pawel Osciak <pawel@osciak.com>, Marek Szyprowski");
MODULE_LICENSE("GPL");
diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
index 91a2b3e1a642..727855463838 100644
--- a/include/media/videobuf2-v4l2.h
+++ b/include/media/videobuf2-v4l2.h
@@ -303,4 +303,8 @@ void vb2_ops_wait_prepare(struct vb2_queue *vq);
*/
void vb2_ops_wait_finish(struct vb2_queue *vq);
+struct media_request;
+int vb2_request_validate(struct media_request *req);
+void vb2_request_queue(struct media_request *req);
+
#endif /* _MEDIA_VIDEOBUF2_V4L2_H */
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 25/35] videobuf2-core: add uses_requests flag
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (23 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 24/35] videobuf2-v4l2: add vb2_request_queue/validate helpers Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 26/35] videobuf2-v4l2: refuse qbuf if queue uses requests Hans Verkuil
` (9 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Set the first time a buffer from a request is queued to vb2.
Cleared when the queue is canceled.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/common/videobuf2/videobuf2-core.c | 2 ++
include/media/videobuf2-core.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index 697765e70fbe..ec76dcb130fe 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1500,6 +1500,7 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
if (ret)
return ret;
+ q->uses_requests = 1;
vb->state = VB2_BUF_STATE_IN_REQUEST;
/* Fill buffer information for the userspace */
if (pb) {
@@ -1813,6 +1814,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
q->start_streaming_called = 0;
q->queued_count = 0;
q->error = 0;
+ q->uses_requests = 0;
/*
* Remove all buffers from videobuf's list...
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cad712403d14..67553180d98f 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -468,6 +468,8 @@ struct vb2_buf_ops {
* @quirk_poll_must_check_waiting_for_buffers: Return %EPOLLERR at poll when QBUF
* has not been called. This is a vb1 idiom that has been adopted
* also by vb2.
+ * @uses_requests: requests are used for this queue. Set to 1 the first time
+ * a request is queued. Set to 0 when the queue is canceled.
* @lock: pointer to a mutex that protects the &struct vb2_queue. The
* driver can set this to a mutex to let the v4l2 core serialize
* the queuing ioctls. If the driver wants to handle locking
@@ -535,6 +537,7 @@ struct vb2_queue {
unsigned fileio_write_immediately:1;
unsigned allow_zero_bytesused:1;
unsigned quirk_poll_must_check_waiting_for_buffers:1;
+ unsigned uses_requests:1;
struct mutex *lock;
void *owner;
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 26/35] videobuf2-v4l2: refuse qbuf if queue uses requests
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (24 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 25/35] videobuf2-core: add uses_requests flag Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 27/35] v4l2-mem2mem: Simplify exiting the function in v4l2_m2m_try_schedule Hans Verkuil
` (8 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Check if the vb2 queue uses requests, and if so refuse to
add buffers that are not part of a request.
We might relax this in the future, but for now just return
-EBUSY in that case.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/common/videobuf2/videobuf2-v4l2.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 499b2ab3d1fa..05004b26a705 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -378,8 +378,13 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct media_device *md
return ret;
}
- if (!(b->flags & V4L2_BUF_FLAG_REQUEST_FD))
+ if (!(b->flags & V4L2_BUF_FLAG_REQUEST_FD)) {
+ if (q->uses_requests) {
+ dprintk(1, "%s: queue uses requests\n", opname);
+ return -EBUSY;
+ }
return 0;
+ }
/*
* For proper locking when queueing a request you need to be able
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 27/35] v4l2-mem2mem: Simplify exiting the function in v4l2_m2m_try_schedule
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (25 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 26/35] videobuf2-v4l2: refuse qbuf if queue uses requests Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 28/35] v4l2-mem2mem: add vb2_m2m_request_queue Hans Verkuil
` (7 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Sakari Ailus
From: Sakari Ailus <sakari.ailus@linux.intel.com>
The v4l2_m2m_try_schedule function acquires and releases multiple
spinlocks; simplify unlocking the job lock by adding a label to unlock the
job lock and exit the function.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 438f1b869319..88f95b78e4d0 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -231,15 +231,13 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
/* If the context is aborted then don't schedule it */
if (m2m_ctx->job_flags & TRANS_ABORT) {
- spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
dprintk("Aborted context\n");
- return;
+ goto out_unlock;
}
if (m2m_ctx->job_flags & TRANS_QUEUED) {
- spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
dprintk("On job queue already\n");
- return;
+ goto out_unlock;
}
spin_lock_irqsave(&m2m_ctx->out_q_ctx.rdy_spinlock, flags_out);
@@ -247,9 +245,8 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
&& !m2m_ctx->out_q_ctx.buffered) {
spin_unlock_irqrestore(&m2m_ctx->out_q_ctx.rdy_spinlock,
flags_out);
- spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
dprintk("No input buffers available\n");
- return;
+ goto out_unlock;
}
spin_lock_irqsave(&m2m_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
if (list_empty(&m2m_ctx->cap_q_ctx.rdy_queue)
@@ -258,18 +255,16 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
flags_cap);
spin_unlock_irqrestore(&m2m_ctx->out_q_ctx.rdy_spinlock,
flags_out);
- spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
dprintk("No output buffers available\n");
- return;
+ goto out_unlock;
}
spin_unlock_irqrestore(&m2m_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
spin_unlock_irqrestore(&m2m_ctx->out_q_ctx.rdy_spinlock, flags_out);
if (m2m_dev->m2m_ops->job_ready
&& (!m2m_dev->m2m_ops->job_ready(m2m_ctx->priv))) {
- spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
dprintk("Driver not ready\n");
- return;
+ goto out_unlock;
}
list_add_tail(&m2m_ctx->queue, &m2m_dev->job_queue);
@@ -278,6 +273,13 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
v4l2_m2m_try_run(m2m_dev);
+
+ return;
+
+out_unlock:
+ spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
+
+ return;
}
EXPORT_SYMBOL_GPL(v4l2_m2m_try_schedule);
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 28/35] v4l2-mem2mem: add vb2_m2m_request_queue
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (26 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 27/35] v4l2-mem2mem: Simplify exiting the function in v4l2_m2m_try_schedule Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 29/35] Documentation: v4l: document request API Hans Verkuil
` (6 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
For mem2mem devices we have to make sure that v4l2_m2m_try_schedule()
is called whenever a request is queued.
We do that by creating a vb2_m2m_request_queue() helper that should
be used instead of the 'normal' vb2_request_queue() helper. The m2m
helper function will call v4l2_m2m_try_schedule() as needed.
In addition we also avoid calling v4l2_m2m_try_schedule() when preparing
or queueing a buffer for a request since that is no longer needed.
Instead this helper function will do that when the request is actually
queued.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 43 +++++++++++++++++++++-----
include/media/v4l2-mem2mem.h | 4 +++
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 88f95b78e4d0..ec0f8924f5c7 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -304,7 +304,7 @@ static void v4l2_m2m_cancel_job(struct v4l2_m2m_ctx *m2m_ctx)
if (m2m_ctx->job_flags & TRANS_RUNNING) {
spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
m2m_dev->m2m_ops->job_abort(m2m_ctx->priv);
- dprintk("m2m_ctx %p running, will wait to complete", m2m_ctx);
+ dprintk("m2m_ctx %p running, will wait to complete\n", m2m_ctx);
wait_event(m2m_ctx->finished,
!(m2m_ctx->job_flags & TRANS_RUNNING));
} else if (m2m_ctx->job_flags & TRANS_QUEUED) {
@@ -396,8 +396,14 @@ int v4l2_m2m_qbuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
int ret;
vq = v4l2_m2m_get_vq(m2m_ctx, buf->type);
+ if (!V4L2_TYPE_IS_OUTPUT(vq->type) &&
+ (buf->flags & V4L2_BUF_FLAG_REQUEST_FD)) {
+ dprintk("%s: requests cannot be used with capture buffers\n",
+ __func__);
+ return -EINVAL;
+ }
ret = vb2_qbuf(vq, vdev->v4l2_dev->mdev, buf);
- if (!ret)
+ if (!ret && !(buf->flags & V4L2_BUF_FLAG_IN_REQUEST))
v4l2_m2m_try_schedule(m2m_ctx);
return ret;
@@ -419,14 +425,9 @@ int v4l2_m2m_prepare_buf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
{
struct video_device *vdev = video_devdata(file);
struct vb2_queue *vq;
- int ret;
vq = v4l2_m2m_get_vq(m2m_ctx, buf->type);
- ret = vb2_prepare_buf(vq, vdev->v4l2_dev->mdev, buf);
- if (!ret)
- v4l2_m2m_try_schedule(m2m_ctx);
-
- return ret;
+ return vb2_prepare_buf(vq, vdev->v4l2_dev->mdev, buf);
}
EXPORT_SYMBOL_GPL(v4l2_m2m_prepare_buf);
@@ -703,6 +704,32 @@ void v4l2_m2m_buf_queue(struct v4l2_m2m_ctx *m2m_ctx,
}
EXPORT_SYMBOL_GPL(v4l2_m2m_buf_queue);
+void vb2_m2m_request_queue(struct media_request *req)
+{
+ struct media_request_object *obj;
+
+ list_for_each_entry(obj, &req->objects, list) {
+ struct v4l2_m2m_ctx *m2m_ctx;
+ struct vb2_buffer *vb;
+
+ if (!obj->ops->queue)
+ continue;
+
+ obj->ops->queue(obj);
+ if (!vb2_request_object_is_buffer(obj))
+ continue;
+
+ vb = container_of(obj, struct vb2_buffer, req_obj);
+ if (WARN_ON(!V4L2_TYPE_IS_OUTPUT(vb->vb2_queue->type)))
+ continue;
+ m2m_ctx = container_of(vb->vb2_queue,
+ struct v4l2_m2m_ctx,
+ out_q_ctx.q);
+ v4l2_m2m_try_schedule(m2m_ctx);
+ }
+}
+EXPORT_SYMBOL_GPL(vb2_m2m_request_queue);
+
/* Videobuf2 ioctl helpers */
int v4l2_m2m_ioctl_reqbufs(struct file *file, void *priv,
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 3d07ba3a8262..f01b3fc13b0e 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -580,6 +580,10 @@ v4l2_m2m_dst_buf_remove_by_idx(struct v4l2_m2m_ctx *m2m_ctx, unsigned int idx)
return v4l2_m2m_buf_remove_by_idx(&m2m_ctx->cap_q_ctx, idx);
}
+/* v4l2 request helper */
+
+void vb2_m2m_request_queue(struct media_request *req);
+
/* v4l2 ioctl helpers */
int v4l2_m2m_ioctl_reqbufs(struct file *file, void *priv,
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 29/35] Documentation: v4l: document request API
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (27 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 28/35] v4l2-mem2mem: add vb2_m2m_request_queue Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-07-03 11:50 ` Mauro Carvalho Chehab
2018-06-04 11:46 ` [PATCHv15 30/35] vim2m: add media device Hans Verkuil
` (5 subsequent siblings)
34 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Alexandre Courbot, Hans Verkuil
From: Alexandre Courbot <acourbot@chromium.org>
Document the request API for V4L2 devices, and amend the documentation
of system calls influenced by it.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
.../media/uapi/mediactl/media-controller.rst | 1 +
.../media/uapi/mediactl/media-funcs.rst | 3 +
.../uapi/mediactl/media-ioc-request-alloc.rst | 71 ++++++
.../uapi/mediactl/media-request-ioc-queue.rst | 50 ++++
.../mediactl/media-request-ioc-reinit.rst | 51 ++++
.../media/uapi/mediactl/request-api.rst | 219 ++++++++++++++++++
Documentation/media/uapi/v4l/buffer.rst | 18 +-
.../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 28 ++-
Documentation/media/uapi/v4l/vidioc-qbuf.rst | 11 +
.../media/videodev2.h.rst.exceptions | 1 +
10 files changed, 447 insertions(+), 6 deletions(-)
create mode 100644 Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
diff --git a/Documentation/media/uapi/mediactl/media-controller.rst b/Documentation/media/uapi/mediactl/media-controller.rst
index 0eea4f9a07d5..66aff38cd499 100644
--- a/Documentation/media/uapi/mediactl/media-controller.rst
+++ b/Documentation/media/uapi/mediactl/media-controller.rst
@@ -21,6 +21,7 @@ Part IV - Media Controller API
media-controller-intro
media-controller-model
media-types
+ request-api
media-funcs
media-header
diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst b/Documentation/media/uapi/mediactl/media-funcs.rst
index 076856501cdb..f4da9b3e17ec 100644
--- a/Documentation/media/uapi/mediactl/media-funcs.rst
+++ b/Documentation/media/uapi/mediactl/media-funcs.rst
@@ -16,3 +16,6 @@ Function Reference
media-ioc-enum-entities
media-ioc-enum-links
media-ioc-setup-link
+ media-ioc-request-alloc
+ media-request-ioc-queue
+ media-request-ioc-reinit
diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
new file mode 100644
index 000000000000..d45a94c9e23c
--- /dev/null
+++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+.. _media_ioc_request_alloc:
+
+*****************************
+ioctl MEDIA_IOC_REQUEST_ALLOC
+*****************************
+
+Name
+====
+
+MEDIA_IOC_REQUEST_ALLOC - Allocate a request
+
+
+Synopsis
+========
+
+.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct media_request_alloc *argp )
+ :name: MEDIA_IOC_REQUEST_ALLOC
+
+
+Arguments
+=========
+
+``fd``
+ File descriptor returned by :ref:`open() <media-func-open>`.
+
+``argp``
+
+
+Description
+===========
+
+If the media device supports :ref:`requests <media-request-api>`, then
+this ioctl can be used to allocate a request. A request is accessed through
+a file descriptor that is returned in struct :c:type:`media_request_alloc`.
+
+If the request was successfully allocated, then the request file descriptor
+can be passed to :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>`,
+:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
+:ref:`ioctl VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and
+:ref:`ioctl VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
+
+In addition, the request can be queued by calling
+:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
+:ref:`MEDIA_REQUEST_IOC_REINIT`.
+
+Finally, the file descriptor can be polled to wait for the request to
+complete.
+
+To free the request the file descriptor has to be closed.
+
+.. c:type:: media_request_alloc
+
+.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
+
+.. flat-table:: struct media_request_alloc
+ :header-rows: 0
+ :stub-columns: 0
+ :widths: 1 1 2
+
+ * - __s32
+ - ``fd``
+ - The file descriptor of the request.
+
+Return Value
+============
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes <gen-errors>` chapter.
diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
new file mode 100644
index 000000000000..d3bac7b70422
--- /dev/null
+++ b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
@@ -0,0 +1,50 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+.. _media_request_ioc_queue:
+
+*****************************
+ioctl MEDIA_REQUEST_IOC_QUEUE
+*****************************
+
+Name
+====
+
+MEDIA_REQUEST_IOC_QUEUE - Queue a request
+
+
+Synopsis
+========
+
+.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_QUEUE )
+ :name: MEDIA_REQUEST_IOC_QUEUE
+
+
+Arguments
+=========
+
+``request_fd``
+ File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
+
+
+Description
+===========
+
+If the media device supports :ref:`requests <media-request-api>`, then
+this request ioctl can be used to queue a previously allocated request.
+
+If the request was successfully queued, then the file descriptor can be
+polled to wait for the request to complete.
+
+If the request was already queued before, then '`EBUSY'` is returned.
+Other errors can be returned if the contents of the request contained
+invalid or inconsistent data.
+
+Return Value
+============
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes <gen-errors>` chapter.
+
+EBUSY
+ The request was already queued.
diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
new file mode 100644
index 000000000000..7cbb7eb5d73e
--- /dev/null
+++ b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
@@ -0,0 +1,51 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+.. _media_request_ioc_reinit:
+
+******************************
+ioctl MEDIA_REQUEST_IOC_REINIT
+******************************
+
+Name
+====
+
+MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
+
+
+Synopsis
+========
+
+.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_REINIT )
+ :name: MEDIA_REQUEST_IOC_REINIT
+
+
+Arguments
+=========
+
+``request_fd``
+ File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
+
+Description
+===========
+
+If the media device supports :ref:`requests <media-request-api>`, then
+this request ioctl can be used to re-initialize a previously allocated
+request.
+
+Re-initializing a request will clear any existing data from the request.
+This avoids having to close() a completed request and allocate a new
+request. Instead the completed request can just be re-initialized and
+it is ready to be used again.
+
+A request can only be re-initialized if it either has not been queued
+yet, or if it was queued and completed.
+
+Return Value
+============
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes <gen-errors>` chapter.
+
+EBUSY
+ The request is queued but not yet completed.
diff --git a/Documentation/media/uapi/mediactl/request-api.rst b/Documentation/media/uapi/mediactl/request-api.rst
new file mode 100644
index 000000000000..4d10f18181a4
--- /dev/null
+++ b/Documentation/media/uapi/mediactl/request-api.rst
@@ -0,0 +1,219 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _media-request-api:
+
+Request API
+===========
+
+The Request API has been designed to allow V4L2 to deal with requirements of
+modern devices (stateless codecs, complex camera pipelines, ...) and APIs
+(Android Codec v2). One such requirement is the ability for devices belonging to
+the same pipeline to reconfigure and collaborate closely on a per-frame basis.
+Another is efficient support of stateless codecs, which need per-frame controls
+to be set synchronously in order to be used efficiently.
+
+Supporting these features without the Request API is not always possible and if
+it is, it is terribly inefficient: user-space would have to flush all activity
+on the media pipeline, reconfigure it for the next frame, queue the buffers to
+be processed with that configuration, and wait until they are all available for
+dequeuing before considering the next frame. This defeats the purpose of having
+buffer queues since in practice only one buffer would be queued at a time.
+
+The Request API allows a specific configuration of the pipeline (media
+controller topology + controls for each media entity) to be associated with
+specific buffers. The parameters are applied by each participating device as
+buffers associated to a request flow in. This allows user-space to schedule
+several tasks ("requests") with different parameters in advance, knowing that
+the parameters will be applied when needed to get the expected result. Control
+values at the time of request completion are also available for reading.
+
+Usage
+=====
+
+The Request API is used on top of standard media controller and V4L2 calls,
+which are augmented with an extra ``request_fd`` parameter. Requests themselves
+are allocated from the supporting media controller node.
+
+Request Allocation
+------------------
+
+User-space allocates requests using :ref:`MEDIA_IOC_REQUEST_ALLOC`
+for the media device node. This returns a file descriptor representing the
+request. Typically, several such requests will be allocated.
+
+Request Preparation
+-------------------
+
+Standard V4L2 ioctls can then receive a request file descriptor to express the
+fact that the ioctl is part of said request, and is not to be applied
+immediately. See :ref:`MEDIA_IOC_REQUEST_ALLOC` for a list of ioctls that
+support this. Controls set with a ``request_fd`` parameter are stored instead
+of being immediately applied, and buffers queued to a request do not enter the
+regular buffer queue until the request itself is queued.
+
+Request Submission
+------------------
+
+Once the parameters and buffers of the request are specified, it can be
+queued by calling :ref:`MEDIA_REQUEST_IOC_QUEUE` on the request FD.
+This will make the buffers associated to the request available to their driver,
+which can then apply the associated controls as buffers are processed. A queued
+request cannot be modified anymore.
+
+If the request contains parameters for multiple entities, individual drivers may
+synchronize so the requested pipeline's topology is applied before the buffers
+are processed. Media controller drivers do a best effort implementation since
+perfect atomicity may not be possible due to hardware limitations.
+
+Once buffers are added to a request for the first time it is no longer possible
+to queue non-request buffers of that buffer type until
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called.
+
+Controls can still be set without a request and are applied immediately,
+regardless of whether a request is in use or not. Setting the same control
+through a request and directly can lead to undefined behavior!
+
+User-space can ``poll()`` a request FD in order to wait until the request
+completes. A request is considered complete once all its associated buffers are
+available for dequeuing and all the associated controls have been updated with
+the values at the time of completion. Note that user-space does not need to wait
+for the request to complete to dequeue its buffers: buffers that are available
+halfway through a request can be dequeued independently of the request's state.
+
+A completed request contains the state of the request at the time of the
+request completion. User-space can query that state by calling
+:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` with the request FD.
+
+Recycling and Destruction
+-------------------------
+
+Finally, completed request can either be discarded or be reused. Calling
+``close()`` on a request FD will make that FD unusable, freeing the request if
+it is not in use by the kernel. That is, if the request is queued and then the
+FD is closed, then it won't be freed until the driver completed the request.
+
+The :ref:`MEDIA_REQUEST_IOC_REINIT` will clear a request's state and make it
+available again. No state is retained by this operation: the request is as
+if it had just been allocated.
+
+Example for a Memory-to-Memory Device
+-------------------------------------
+
+M2M devices are single-node V4L2 devices providing one OUTPUT queue (for
+user-space to provide input buffers) and one CAPTURE queue (to retrieve
+processed data). These devices are commonly used for frame processors or
+stateless codecs.
+
+In this use-case, the request API can be used to associate specific controls to
+be applied by the driver for the OUTPUT buffer, allowing user-space
+to queue many such buffers in advance. It can also take advantage of requests'
+ability to capture the state of controls when the request completes to read back
+information that may be subject to change.
+
+Put into code, after obtaining a request, user-space can assign controls and one
+OUTPUT buffer to it:
+
+.. code-block:: c
+
+ struct v4l2_buffer buf;
+ struct v4l2_ext_controls ctrls;
+ struct media_request_alloc alloc = { 0 };
+ int req_fd;
+ ...
+ ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
+ req_fd = alloc.fd;
+ ...
+ ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
+ ctrls.request_fd = req_fd;
+ ioctl(codec_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
+ ...
+ buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
+ buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
+ buf.request_fd = req_fd;
+ ioctl(codec_fd, VIDIOC_QBUF, &buf);
+
+Note that there is typically no need to use the Request API for CAPTURE buffers
+since there are no per-frame settings to report there.
+
+Once the request is fully prepared, it can be queued to the driver:
+
+.. code-block:: c
+
+ ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
+
+User-space can then either wait for the request to complete by calling poll() on
+its file descriptor, or start dequeuing CAPTURE buffers. Most likely, it will
+want to get CAPTURE buffers as soon as possible and this can be done using a
+regular DQBUF:
+
+.. code-block:: c
+
+ struct v4l2_buffer buf;
+
+ memset(&buf, 0, sizeof(buf));
+ buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ ioctl(codec_fd, VIDIOC_DQBUF, &buf);
+
+Note that this example assumes for simplicity that for every OUTPUT buffer
+there will be one CAPTURE buffer, but this does not have to be the case.
+
+We can then, after ensuring that the request is completed via polling the
+request FD, query control values at the time of its completion via an
+annotated call to G_EXT_CTRLS. This is particularly useful for volatile controls
+for which we want to query values as soon as the capture buffer is produced.
+
+.. code-block:: c
+
+ struct pollfd pfd = { .events = POLLPRI, .fd = request_fd };
+ poll(&pfd, 1, -1);
+ ...
+ ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
+ ctrls.request_fd = req_fd;
+ ioctl(codec_fd, VIDIOC_G_EXT_CTRLS, &ctrls);
+
+Once we don't need the request anymore, we can either recycle it for reuse with
+:ref:`MEDIA_REQUEST_IOC_REINIT`...
+
+.. code-block:: c
+
+ ioctl(req_fd, MEDIA_REQUEST_IOC_REINIT);
+
+... or close its file descriptor to completely dispose of it.
+
+.. code-block:: c
+
+ close(req_fd);
+
+Example for a Simple Capture Device
+-----------------------------------
+
+With a simple capture device, requests can be used to specify controls to apply
+for a given CAPTURE buffer.
+
+.. code-block:: c
+
+ struct v4l2_buffer buf;
+ struct v4l2_ext_controls ctrls;
+ struct media_request_alloc alloc = { 0 };
+ int req_fd;
+ ...
+ ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
+ req_fd = alloc.fd;
+ ...
+ ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
+ ctrls.request_fd = req_fd;
+ ioctl(camera_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
+ ...
+ buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
+ buf.request_fd = req_fd;
+ ioctl(camera_fd, VIDIOC_QBUF, &buf);
+
+Once the request is fully prepared, it can be queued to the driver:
+
+.. code-block:: c
+
+ ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
+
+User-space can then dequeue buffers, wait for the request completion, query
+controls and recycle the request as in the M2M example above.
diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst
index e2c85ddc990b..8059fc0ed520 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -306,10 +306,12 @@ struct v4l2_buffer
- A place holder for future extensions. Drivers and applications
must set this to 0.
* - __u32
- - ``reserved``
+ - ``request_fd``
-
- - A place holder for future extensions. Drivers and applications
- must set this to 0.
+ - The file descriptor of the request to queue the buffer to. If specified
+ and flag ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be
+ queued to that request. This is set by the user when calling
+ :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls.
@@ -514,6 +516,11 @@ Buffer Flags
streaming may continue as normal and the buffer may be reused
normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is
called.
+ * .. _`V4L2-BUF-FLAG-IN-REQUEST`:
+
+ - ``V4L2_BUF_FLAG_IN_REQUEST``
+ - 0x00000080
+ - This buffer is part of a request that hasn't been queued yet.
* .. _`V4L2-BUF-FLAG-KEYFRAME`:
- ``V4L2_BUF_FLAG_KEYFRAME``
@@ -589,6 +596,11 @@ Buffer Flags
the format. Any Any subsequent call to the
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
but return an ``EPIPE`` error code.
+ * .. _`V4L2-BUF-FLAG-REQUEST-FD`:
+
+ - ``V4L2_BUF_FLAG_REQUEST_FD``
+ - 0x00800000
+ - The ``request_fd`` field contains a valid file descriptor.
* .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`:
- ``V4L2_BUF_FLAG_TIMESTAMP_MASK``
diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
index 2011c2b2ee67..3d0e861ad4a1 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
@@ -95,6 +95,22 @@ appropriate. In the first case the new value is set in struct
is inappropriate (e.g. the given menu index is not supported by the menu
control), then this will also result in an ``EINVAL`` error code error.
+If ``request_fd`` is set to a not-yet-queued :ref:`request <media-request-api>`
+file descriptor and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``,
+then the controls are not applied immediately when calling
+:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, but instead are applied by
+the driver for the buffer associated with the same request.
+
+An attempt to call :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` for a
+request that has already been queued will result in an ``EBUSY`` error.
+
+If ``request_fd`` is specified and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``
+during a call to :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, then the
+returned values will be the values currently set for the request (or the
+hardware value if none is set) if the request has not yet completed, or the
+values of the controls at the time of request completion if it has already
+completed.
+
The driver will only set/get these controls if all control values are
correct. This prevents the situation where only some of the controls
were set/get. Only low-level errors (e. g. a failed i2c command) can
@@ -209,8 +225,10 @@ still cause this situation.
- ``which``
- Which value of the control to get/set/try.
``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the
- control and ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
- value of the control.
+ control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
+ value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that
+ these controls have to be retrieved from a request or tried/set for
+ a request.
.. note::
@@ -272,8 +290,12 @@ still cause this situation.
then you can call :ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` to try to discover the
actual control that failed the validation step. Unfortunately,
there is no ``TRY`` equivalent for :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
+ * - __s32
+ - ``request_fd``
+ File descriptor of the request to be used by this operation. Only
+ valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``.
* - __u32
- - ``reserved``\ [2]
+ - ``reserved``\ [1]
- Reserved for future extensions.
Drivers and applications must set the array to zero.
diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
index 9e448a4aa3aa..7ac99be1dd48 100644
--- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
@@ -98,6 +98,17 @@ dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
:ref:`VIDIOC_REQBUFS` ioctl is called, or until the
device is closed.
+The ``request_fd`` field can be used when queuing to specify the file
+descriptor of a :ref:`request <media-request-api>`, if requests are
+in use. Setting it means that the buffer will not be passed to the driver
+until the request itself is queued. Also, the driver will apply any
+settings associated with the request for this buffer. This field will
+be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set.
+
+For :ref:`memory-to-memory devices <codec>` you can specify the
+``request_fd`` only for output buffers, not for capture buffers. Attempting
+to specify this for a capture buffer will result in an ``EINVAL`` error.
+
Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
(capturing) or displayed (output) buffer from the driver's outgoing
queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
index a5cb0a8686ac..5a5a1c772053 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -514,6 +514,7 @@ ignore define V4L2_CTRL_DRIVER_PRIV
ignore define V4L2_CTRL_MAX_DIMS
ignore define V4L2_CTRL_WHICH_CUR_VAL
ignore define V4L2_CTRL_WHICH_DEF_VAL
+ignore define V4L2_CTRL_WHICH_REQUEST_VAL
ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS
ignore define V4L2_CID_MAX_CTRLS
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 29/35] Documentation: v4l: document request API
2018-06-04 11:46 ` [PATCHv15 29/35] Documentation: v4l: document request API Hans Verkuil
@ 2018-07-03 11:50 ` Mauro Carvalho Chehab
2018-07-03 13:02 ` Hans Verkuil
0 siblings, 1 reply; 61+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-03 11:50 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Alexandre Courbot, Hans Verkuil
Em Mon, 4 Jun 2018 13:46:42 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> From: Alexandre Courbot <acourbot@chromium.org>
>
> Document the request API for V4L2 devices, and amend the documentation
> of system calls influenced by it.
I'm starting reviewing the patch series from this patch, as it defines
how the request API is supposed to work. Some of my comments below may
reflect on code changes, in order for the core (and drivers) to be
compliant with the uAPI specified here.
So, I prefer to discuss first the contents of this patch, before start
reviewing the remaining patches.
>
> Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> .../media/uapi/mediactl/media-controller.rst | 1 +
> .../media/uapi/mediactl/media-funcs.rst | 3 +
> .../uapi/mediactl/media-ioc-request-alloc.rst | 71 ++++++
> .../uapi/mediactl/media-request-ioc-queue.rst | 50 ++++
> .../mediactl/media-request-ioc-reinit.rst | 51 ++++
> .../media/uapi/mediactl/request-api.rst | 219 ++++++++++++++++++
> Documentation/media/uapi/v4l/buffer.rst | 18 +-
> .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 28 ++-
> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 11 +
> .../media/videodev2.h.rst.exceptions | 1 +
> 10 files changed, 447 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
> create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
>
> diff --git a/Documentation/media/uapi/mediactl/media-controller.rst b/Documentation/media/uapi/mediactl/media-controller.rst
> index 0eea4f9a07d5..66aff38cd499 100644
> --- a/Documentation/media/uapi/mediactl/media-controller.rst
> +++ b/Documentation/media/uapi/mediactl/media-controller.rst
> @@ -21,6 +21,7 @@ Part IV - Media Controller API
> media-controller-intro
> media-controller-model
> media-types
> + request-api
> media-funcs
> media-header
>
> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst b/Documentation/media/uapi/mediactl/media-funcs.rst
> index 076856501cdb..f4da9b3e17ec 100644
> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
> @@ -16,3 +16,6 @@ Function Reference
> media-ioc-enum-entities
> media-ioc-enum-links
> media-ioc-setup-link
> + media-ioc-request-alloc
> + media-request-ioc-queue
> + media-request-ioc-reinit
> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> new file mode 100644
> index 000000000000..d45a94c9e23c
> --- /dev/null
> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> @@ -0,0 +1,71 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +.. _media_ioc_request_alloc:
> +
> +*****************************
> +ioctl MEDIA_IOC_REQUEST_ALLOC
> +*****************************
> +
> +Name
> +====
> +
> +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
> +
> +
> +Synopsis
> +========
> +
> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct media_request_alloc *argp )
> + :name: MEDIA_IOC_REQUEST_ALLOC
> +
> +
> +Arguments
> +=========
> +
> +``fd``
> + File descriptor returned by :ref:`open() <media-func-open>`.
> +
> +``argp``
> +
> +
> +Description
> +===========
> +
> +If the media device supports :ref:`requests <media-request-api>`, then
> +this ioctl can be used to allocate a request.
Perhaps we should mention that otherwise it would set errno to ENOTTY.
> A request is accessed through
> +a file descriptor that is returned in struct :c:type:`media_request_alloc`.
> +
> +If the request was successfully allocated, then the request file descriptor
> +can be passed to :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>`,
> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
> +:ref:`ioctl VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and
> +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
> +
> +In addition, the request can be queued by calling
> +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
> +:ref:`MEDIA_REQUEST_IOC_REINIT`.
> +
> +Finally, the file descriptor can be polled to wait for the request to
> +complete.
> +
> +To free the request the file descriptor has to be closed.
Hmm... I don't think this is clear enough. After reading this paragraph,
I came back to patch 1, in order to see what's the ioctl to be called
to free the request, only to notice that there's none.
So, I guess what you wanted to say, instead, is that:
"A request will remain allocated until the associated file descriptor is
closed by ::c:func:`close() <req-api-close>` and after the Kernel stops
using the request."
(see below for a discussion about the close() reference)
> +
> +.. c:type:: media_request_alloc
> +
> +.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
> +
> +.. flat-table:: struct media_request_alloc
> + :header-rows: 0
> + :stub-columns: 0
> + :widths: 1 1 2
> +
> + * - __s32
> + - ``fd``
> + - The file descriptor of the request.
> +
> +Return Value
> +============
> +
> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> +appropriately. The generic error codes are described at the
> +:ref:`Generic Error Codes <gen-errors>` chapter.
> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
> new file mode 100644
> index 000000000000..d3bac7b70422
> --- /dev/null
> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
> @@ -0,0 +1,50 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +.. _media_request_ioc_queue:
> +
> +*****************************
> +ioctl MEDIA_REQUEST_IOC_QUEUE
> +*****************************
> +
> +Name
> +====
> +
> +MEDIA_REQUEST_IOC_QUEUE - Queue a request
> +
> +
> +Synopsis
> +========
> +
> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_QUEUE )
> + :name: MEDIA_REQUEST_IOC_QUEUE
> +
> +
> +Arguments
> +=========
> +
> +``request_fd``
> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
> +
> +
> +Description
> +===========
> +
> +If the media device supports :ref:`requests <media-request-api>`, then
> +this request ioctl can be used to queue a previously allocated request.
> +
> +If the request was successfully queued, then the file descriptor can be
> +polled to wait for the request to complete.
> +
> +If the request was already queued before, then '`EBUSY'` is returned.
> +Other errors can be returned if the contents of the request contained
> +invalid or inconsistent data.
Are there any "permanent" return error code that would require the
caller to close the file descriptor?
I mean, if EBUSY is returned, userspace could just wait for a past
QBUF to be handled and call it again, but what happens if some other
error happens (like -ENOMEM)? Would the entire request descriptor be
trashed or just the current QBUF attempt will fail?
> +
> +Return Value
> +============
> +
> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> +appropriately. The generic error codes are described at the
> +:ref:`Generic Error Codes <gen-errors>` chapter.
> +
> +EBUSY
> + The request was already queued.
> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
> new file mode 100644
> index 000000000000..7cbb7eb5d73e
> --- /dev/null
> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
> @@ -0,0 +1,51 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +.. _media_request_ioc_reinit:
> +
> +******************************
> +ioctl MEDIA_REQUEST_IOC_REINIT
> +******************************
> +
> +Name
> +====
> +
> +MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
> +
> +
> +Synopsis
> +========
> +
> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_REINIT )
> + :name: MEDIA_REQUEST_IOC_REINIT
> +
> +
> +Arguments
> +=========
> +
> +``request_fd``
> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
> +
> +Description
> +===========
> +
> +If the media device supports :ref:`requests <media-request-api>`, then
> +this request ioctl can be used to re-initialize a previously allocated
> +request.
> +
> +Re-initializing a request will clear any existing data from the request.
> +This avoids having to close() a completed request and allocate a new
> +request. Instead the completed request can just be re-initialized and
> +it is ready to be used again.
> +
> +A request can only be re-initialized if it either has not been queued
> +yet, or if it was queued and completed.
> +
> +Return Value
> +============
> +
> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> +appropriately. The generic error codes are described at the
> +:ref:`Generic Error Codes <gen-errors>` chapter.
> +
> +EBUSY
> + The request is queued but not yet completed.
Same question here: are there any "permanent" return error code that would
require the caller to close the file descriptor?
> diff --git a/Documentation/media/uapi/mediactl/request-api.rst b/Documentation/media/uapi/mediactl/request-api.rst
> new file mode 100644
> index 000000000000..4d10f18181a4
> --- /dev/null
> +++ b/Documentation/media/uapi/mediactl/request-api.rst
> @@ -0,0 +1,219 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _media-request-api:
> +
> +Request API
> +===========
> +
> +The Request API has been designed to allow V4L2 to deal with requirements of
> +modern devices (stateless codecs, complex camera pipelines, ...) and APIs
> +(Android Codec v2). One such requirement is the ability for devices belonging to
> +the same pipeline to reconfigure and collaborate closely on a per-frame basis.
> +Another is efficient support of stateless codecs, which need per-frame controls
> +to be set synchronously in order to be used efficiently.
> +
> +Supporting these features without the Request API is not always possible and if
> +it is, it is terribly inefficient: user-space would have to flush all activity
> +on the media pipeline, reconfigure it for the next frame, queue the buffers to
> +be processed with that configuration, and wait until they are all available for
> +dequeuing before considering the next frame. This defeats the purpose of having
> +buffer queues since in practice only one buffer would be queued at a time.
> +
> +The Request API allows a specific configuration of the pipeline (media
> +controller topology + controls for each media entity) to be associated with
> +specific buffers. The parameters are applied by each participating device as
> +buffers associated to a request flow in. This allows user-space to schedule
> +several tasks ("requests") with different parameters in advance, knowing that
> +the parameters will be applied when needed to get the expected result. Control
> +values at the time of request completion are also available for reading.
> +
> +Usage
> +=====
> +
> +The Request API is used on top of standard media controller and V4L2 calls,
> +which are augmented with an extra ``request_fd`` parameter. Requests themselves
> +are allocated from the supporting media controller node.
> +
> +Request Allocation
> +------------------
> +
> +User-space allocates requests using :ref:`MEDIA_IOC_REQUEST_ALLOC`
> +for the media device node. This returns a file descriptor representing the
> +request. Typically, several such requests will be allocated.
> +
> +Request Preparation
> +-------------------
> +
> +Standard V4L2 ioctls can then receive a request file descriptor to express the
> +fact that the ioctl is part of said request, and is not to be applied
> +immediately. See :ref:`MEDIA_IOC_REQUEST_ALLOC` for a list of ioctls that
> +support this. Controls set with a ``request_fd`` parameter are stored instead
> +of being immediately applied, and buffers queued to a request do not enter the
> +regular buffer queue until the request itself is queued.
> +
> +Request Submission
> +------------------
> +
> +Once the parameters and buffers of the request are specified, it can be
> +queued by calling :ref:`MEDIA_REQUEST_IOC_QUEUE` on the request FD.
> +This will make the buffers associated to the request available to their driver,
> +which can then apply the associated controls as buffers are processed. A queued
> +request cannot be modified anymore.
What happens if one closes a file descriptor while a request is pending?
Would the close() ops wait until the request to finish? If so, what happens
when FD is opened in non-blocking mode?
> +
> +If the request contains parameters for multiple entities, individual drivers may
> +synchronize so the requested pipeline's topology is applied before the buffers
> +are processed. Media controller drivers do a best effort implementation since
> +perfect atomicity may not be possible due to hardware limitations.
> +
> +Once buffers are added to a request for the first time it is no longer possible
Nitpick: missing comma:
Once buffers are added to a request for the first time,
> +to queue non-request buffers of that buffer type until
> +:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called.
Not even after closing the request fd? My past understanding is that
closing a file descriptor would be enough to free the request.
If that's not the case, and STREAMOFF is indeed required to free the
buffer, please document it also at MEDIA_IOC_REQUEST_ALLOC.
> +
> +Controls can still be set without a request and are applied immediately,
> +regardless of whether a request is in use or not.
> Setting the same control
> +through a request and directly can lead to undefined behavior!
I would place it as a caution note:
.. caution::
Setting the same control through a request and directly can
lead to undefined behavior!
> +
> +User-space can ``poll()`` a request FD in order to wait until the request
Hmm... ``poll`` is probably not what you want here. Same applies to ``close``,
``open``, etc. We actually define syscalls per subsystem (v4l2, dvb, ...), as
the syscall behavior is somewhat dependent on how the dev ops are implemented.
IMO, the best would be to add a page for poll() and close() for request API,
explaining their differences with regards to the "common" behavior.
For example, Documentation/media/uapi/cec/cec-func-close.rst references it
with:
::c:func:`close() <cec-close>`
> +completes. A request is considered complete once all its associated buffers are
> +available for dequeuing and all the associated controls have been updated with
> +the values at the time of completion. Note that user-space does not need to wait
> +for the request to complete to dequeue its buffers: buffers that are available
> +halfway through a request can be dequeued independently of the request's state.
> +
> +A completed request contains the state of the request at the time of the
> +request completion. User-space can query that state by calling
> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` with the request FD.
What happens if one calls VIDIOC_G_EXT_CTRLS after DQBUF but before
the complete request to be handled? Undefined behavior or will it
reflect the control changes applied to that dequeued buffer?
> +
> +Recycling and Destruction
> +-------------------------
> +
> +Finally, completed request can either be discarded or be reused. Calling
> +``close()`` on a request FD will make that FD unusable, freeing the request if
> +it is not in use by the kernel. That is, if the request is queued and then the
> +FD is closed, then it won't be freed until the driver completed the request.
> +
> +The :ref:`MEDIA_REQUEST_IOC_REINIT` will clear a request's state and make it
> +available again. No state is retained by this operation: the request is as
> +if it had just been allocated.
> +
> +Example for a Memory-to-Memory Device
> +-------------------------------------
> +
> +M2M devices are single-node V4L2 devices providing one OUTPUT queue (for
> +user-space to provide input buffers) and one CAPTURE queue (to retrieve
> +processed data). These devices are commonly used for frame processors or
> +stateless codecs.
Hmm... describing what is a M2M device here doesn't sound right. It
should be described elsewhere, and a xref to such description should
be added here instead, pointing to some specific chapter at the V4L2
docs for M2M.
That reminds that I have a series of patches adding a glossary that
needs rework. I'll see if I can respin it this week, in order to allow
adding M2M to the glossary too.
> +
> +In this use-case, the request API can be used to associate specific controls to
> +be applied by the driver for the OUTPUT buffer, allowing user-space
> +to queue many such buffers in advance. It can also take advantage of requests'
> +ability to capture the state of controls when the request completes to read back
> +information that may be subject to change.
> +
> +Put into code, after obtaining a request, user-space can assign controls and one
> +OUTPUT buffer to it:
> +
> +.. code-block:: c
> +
> + struct v4l2_buffer buf;
> + struct v4l2_ext_controls ctrls;
> + struct media_request_alloc alloc = { 0 };
> + int req_fd;
> + ...
> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
> + req_fd = alloc.fd;
> + ...
> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
> + ctrls.request_fd = req_fd;
> + ioctl(codec_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
> + ...
> + buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
> + buf.request_fd = req_fd;
> + ioctl(codec_fd, VIDIOC_QBUF, &buf);
Hmm... I understand that you want an example to be as simple and as
shorter as possible, but I don't like adding a code example without
proper error handling code, as one might just copy-and-paste it
without adding the required error handling.
I would do, at least, something like:
assert (!ioctl(...));
in order to make clearer that errors should be checked, and, on worse
case scenario of a cut-and-paste code, the app will abort if errors
are found, printing some errors.
> +
> +Note that there is typically no need to use the Request API for CAPTURE buffers
> +since there are no per-frame settings to report there.
> +
> +Once the request is fully prepared, it can be queued to the driver:
> +
> +.. code-block:: c
> +
> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
Same here. I would code this as:
.. code-block:: c
rc = ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
if (rc)
perror("MEDIA_REQUEST_IOC_QUEUE");
in order to give a hint about a more realistic error handling code.
(same comments about error handling apply to other examples below)
> +
> +User-space can then either wait for the request to complete by calling poll() on
> +its file descriptor, or start dequeuing CAPTURE buffers. Most likely, it will
> +want to get CAPTURE buffers as soon as possible and this can be done using a
> +regular DQBUF:
> +
> +.. code-block:: c
> +
> + struct v4l2_buffer buf;
> +
> + memset(&buf, 0, sizeof(buf));
> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> + ioctl(codec_fd, VIDIOC_DQBUF, &buf);
> +
> +Note that this example assumes for simplicity that for every OUTPUT buffer
> +there will be one CAPTURE buffer, but this does not have to be the case.
> +
> +We can then, after ensuring that the request is completed via polling the
> +request FD, query control values at the time of its completion via an
> +annotated call to G_EXT_CTRLS. This is particularly useful for volatile controls
> +for which we want to query values as soon as the capture buffer is produced.
> +
> +.. code-block:: c
> +
> + struct pollfd pfd = { .events = POLLPRI, .fd = request_fd };
> + poll(&pfd, 1, -1);
> + ...
> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
> + ctrls.request_fd = req_fd;
> + ioctl(codec_fd, VIDIOC_G_EXT_CTRLS, &ctrls);
> +
> +Once we don't need the request anymore, we can either recycle it for reuse with
> +:ref:`MEDIA_REQUEST_IOC_REINIT`...
> +
> +.. code-block:: c
> +
> + ioctl(req_fd, MEDIA_REQUEST_IOC_REINIT);
> +
> +... or close its file descriptor to completely dispose of it.
> +
> +.. code-block:: c
> +
> + close(req_fd);
> +
> +Example for a Simple Capture Device
> +-----------------------------------
> +
> +With a simple capture device, requests can be used to specify controls to apply
> +for a given CAPTURE buffer.
> +
> +.. code-block:: c
> +
> + struct v4l2_buffer buf;
> + struct v4l2_ext_controls ctrls;
> + struct media_request_alloc alloc = { 0 };
> + int req_fd;
> + ...
> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
> + req_fd = alloc.fd;
> + ...
> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
> + ctrls.request_fd = req_fd;
> + ioctl(camera_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
> + ...
> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
> + buf.request_fd = req_fd;
> + ioctl(camera_fd, VIDIOC_QBUF, &buf);
> +
> +Once the request is fully prepared, it can be queued to the driver:
> +
> +.. code-block:: c
> +
> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
> +
> +User-space can then dequeue buffers, wait for the request completion, query
> +controls and recycle the request as in the M2M example above.
> diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst
> index e2c85ddc990b..8059fc0ed520 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -306,10 +306,12 @@ struct v4l2_buffer
> - A place holder for future extensions. Drivers and applications
> must set this to 0.
> * - __u32
> - - ``reserved``
> + - ``request_fd``
> -
> - - A place holder for future extensions. Drivers and applications
> - must set this to 0.
> + - The file descriptor of the request to queue the buffer to. If specified
> + and flag ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be
> + queued to that request. This is set by the user when calling
> + :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls.
What happens if userspace uses an invalid request_fd is filled here?
>
>
>
> @@ -514,6 +516,11 @@ Buffer Flags
> streaming may continue as normal and the buffer may be reused
> normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is
> called.
> + * .. _`V4L2-BUF-FLAG-IN-REQUEST`:
> +
> + - ``V4L2_BUF_FLAG_IN_REQUEST``
> + - 0x00000080
> + - This buffer is part of a request that hasn't been queued yet.
> * .. _`V4L2-BUF-FLAG-KEYFRAME`:
>
> - ``V4L2_BUF_FLAG_KEYFRAME``
> @@ -589,6 +596,11 @@ Buffer Flags
> the format. Any Any subsequent call to the
> :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
> but return an ``EPIPE`` error code.
> + * .. _`V4L2-BUF-FLAG-REQUEST-FD`:
> +
> + - ``V4L2_BUF_FLAG_REQUEST_FD``
> + - 0x00800000
> + - The ``request_fd`` field contains a valid file descriptor.
> * .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`:
>
> - ``V4L2_BUF_FLAG_TIMESTAMP_MASK``
> diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
> index 2011c2b2ee67..3d0e861ad4a1 100644
> --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
> @@ -95,6 +95,22 @@ appropriate. In the first case the new value is set in struct
> is inappropriate (e.g. the given menu index is not supported by the menu
> control), then this will also result in an ``EINVAL`` error code error.
>
> +If ``request_fd`` is set to a not-yet-queued :ref:`request <media-request-api>`
> +file descriptor and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``,
> +then the controls are not applied immediately when calling
> +:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, but instead are applied by
> +the driver for the buffer associated with the same request.
Same note here: what happens if request_fd is invalid?
> +
> +An attempt to call :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` for a
> +request that has already been queued will result in an ``EBUSY`` error.
> +
> +If ``request_fd`` is specified and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``
> +during a call to :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, then the
> +returned values will be the values currently set for the request (or the
> +hardware value if none is set) if the request has not yet completed, or the
> +values of the controls at the time of request completion if it has already
> +completed.
> +
> The driver will only set/get these controls if all control values are
> correct. This prevents the situation where only some of the controls
> were set/get. Only low-level errors (e. g. a failed i2c command) can
> @@ -209,8 +225,10 @@ still cause this situation.
> - ``which``
> - Which value of the control to get/set/try.
> ``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the
> - control and ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
> - value of the control.
> + control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
> + value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that
> + these controls have to be retrieved from a request or tried/set for
> + a request.
I didn't like the text above, as it assumes that all calls will contain
a request_id. You need either to rewrite it or add two paragraphs, one
describing the "normal" non-req-api case, and the other one for "req-api"
one.
>
> .. note::
>
> @@ -272,8 +290,12 @@ still cause this situation.
> then you can call :ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` to try to discover the
> actual control that failed the validation step. Unfortunately,
> there is no ``TRY`` equivalent for :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
> + * - __s32
> + - ``request_fd``
> + File descriptor of the request to be used by this operation. Only
> + valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``.
> * - __u32
> - - ``reserved``\ [2]
> + - ``reserved``\ [1]
> - Reserved for future extensions.
>
> Drivers and applications must set the array to zero.
> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> index 9e448a4aa3aa..7ac99be1dd48 100644
> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> @@ -98,6 +98,17 @@ dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
> :ref:`VIDIOC_REQBUFS` ioctl is called, or until the
> device is closed.
>
> +The ``request_fd`` field can be used when queuing to specify the file
> +descriptor of a :ref:`request <media-request-api>`, if requests are
> +in use. Setting it means that the buffer will not be passed to the driver
> +until the request itself is queued. Also, the driver will apply any
> +settings associated with the request for this buffer. This field will
> +be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set.
What happens if request_fd is invalid?
> +
> +For :ref:`memory-to-memory devices <codec>` you can specify the
> +``request_fd`` only for output buffers, not for capture buffers. Attempting
> +to specify this for a capture buffer will result in an ``EINVAL`` error.
> +
> Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
> (capturing) or displayed (output) buffer from the driver's outgoing
> queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
> index a5cb0a8686ac..5a5a1c772053 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -514,6 +514,7 @@ ignore define V4L2_CTRL_DRIVER_PRIV
> ignore define V4L2_CTRL_MAX_DIMS
> ignore define V4L2_CTRL_WHICH_CUR_VAL
> ignore define V4L2_CTRL_WHICH_DEF_VAL
> +ignore define V4L2_CTRL_WHICH_REQUEST_VAL
> ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS
> ignore define V4L2_CID_MAX_CTRLS
>
Thanks,
Mauro
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 29/35] Documentation: v4l: document request API
2018-07-03 11:50 ` Mauro Carvalho Chehab
@ 2018-07-03 13:02 ` Hans Verkuil
2018-07-03 14:08 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-07-03 13:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media, Alexandre Courbot, Hans Verkuil
On 03/07/18 13:50, Mauro Carvalho Chehab wrote:
> Em Mon, 4 Jun 2018 13:46:42 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>> From: Alexandre Courbot <acourbot@chromium.org>
>>
>> Document the request API for V4L2 devices, and amend the documentation
>> of system calls influenced by it.
>
> I'm starting reviewing the patch series from this patch, as it defines
> how the request API is supposed to work. Some of my comments below may
> reflect on code changes, in order for the core (and drivers) to be
> compliant with the uAPI specified here.
>
> So, I prefer to discuss first the contents of this patch, before start
> reviewing the remaining patches.
>
>>
>> Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>> ---
>> .../media/uapi/mediactl/media-controller.rst | 1 +
>> .../media/uapi/mediactl/media-funcs.rst | 3 +
>> .../uapi/mediactl/media-ioc-request-alloc.rst | 71 ++++++
>> .../uapi/mediactl/media-request-ioc-queue.rst | 50 ++++
>> .../mediactl/media-request-ioc-reinit.rst | 51 ++++
>> .../media/uapi/mediactl/request-api.rst | 219 ++++++++++++++++++
>> Documentation/media/uapi/v4l/buffer.rst | 18 +-
>> .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 28 ++-
>> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 11 +
>> .../media/videodev2.h.rst.exceptions | 1 +
>> 10 files changed, 447 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>> create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
>>
>> diff --git a/Documentation/media/uapi/mediactl/media-controller.rst b/Documentation/media/uapi/mediactl/media-controller.rst
>> index 0eea4f9a07d5..66aff38cd499 100644
>> --- a/Documentation/media/uapi/mediactl/media-controller.rst
>> +++ b/Documentation/media/uapi/mediactl/media-controller.rst
>> @@ -21,6 +21,7 @@ Part IV - Media Controller API
>> media-controller-intro
>> media-controller-model
>> media-types
>> + request-api
>> media-funcs
>> media-header
>>
>> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst b/Documentation/media/uapi/mediactl/media-funcs.rst
>> index 076856501cdb..f4da9b3e17ec 100644
>> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
>> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
>> @@ -16,3 +16,6 @@ Function Reference
>> media-ioc-enum-entities
>> media-ioc-enum-links
>> media-ioc-setup-link
>> + media-ioc-request-alloc
>> + media-request-ioc-queue
>> + media-request-ioc-reinit
>> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>> new file mode 100644
>> index 000000000000..d45a94c9e23c
>> --- /dev/null
>> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>> @@ -0,0 +1,71 @@
>> +.. SPDX-License-Identifier: GPL-2.0-only
>> +
>> +.. _media_ioc_request_alloc:
>> +
>> +*****************************
>> +ioctl MEDIA_IOC_REQUEST_ALLOC
>> +*****************************
>> +
>> +Name
>> +====
>> +
>> +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
>> +
>> +
>> +Synopsis
>> +========
>> +
>> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct media_request_alloc *argp )
>> + :name: MEDIA_IOC_REQUEST_ALLOC
>> +
>> +
>> +Arguments
>> +=========
>> +
>> +``fd``
>> + File descriptor returned by :ref:`open() <media-func-open>`.
>> +
>> +``argp``
>> +
>> +
>> +Description
>> +===========
>> +
>> +If the media device supports :ref:`requests <media-request-api>`, then
>> +this ioctl can be used to allocate a request.
>
> Perhaps we should mention that otherwise it would set errno to ENOTTY.
Will add.
>
>> A request is accessed through
>> +a file descriptor that is returned in struct :c:type:`media_request_alloc`.
>> +
>> +If the request was successfully allocated, then the request file descriptor
>> +can be passed to :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>`,
>> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
>> +:ref:`ioctl VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and
>> +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
>> +
>> +In addition, the request can be queued by calling
>> +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
>> +:ref:`MEDIA_REQUEST_IOC_REINIT`.
>> +
>> +Finally, the file descriptor can be polled to wait for the request to
>> +complete.
>> +
>> +To free the request the file descriptor has to be closed.
>
> Hmm... I don't think this is clear enough. After reading this paragraph,
> I came back to patch 1, in order to see what's the ioctl to be called
> to free the request, only to notice that there's none.
>
> So, I guess what you wanted to say, instead, is that:
>
> "A request will remain allocated until the associated file descriptor is
> closed by ::c:func:`close() <req-api-close>` and after the Kernel stops
> using the request."
That's a lot clearer.
>
> (see below for a discussion about the close() reference)
>
>> +
>> +.. c:type:: media_request_alloc
>> +
>> +.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
>> +
>> +.. flat-table:: struct media_request_alloc
>> + :header-rows: 0
>> + :stub-columns: 0
>> + :widths: 1 1 2
>> +
>> + * - __s32
>> + - ``fd``
>> + - The file descriptor of the request.
>> +
>> +Return Value
>> +============
>> +
>> +On success 0 is returned, on error -1 and the ``errno`` variable is set
>> +appropriately. The generic error codes are described at the
>> +:ref:`Generic Error Codes <gen-errors>` chapter.
>> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>> new file mode 100644
>> index 000000000000..d3bac7b70422
>> --- /dev/null
>> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>> @@ -0,0 +1,50 @@
>> +.. SPDX-License-Identifier: GPL-2.0-only
>> +
>> +.. _media_request_ioc_queue:
>> +
>> +*****************************
>> +ioctl MEDIA_REQUEST_IOC_QUEUE
>> +*****************************
>> +
>> +Name
>> +====
>> +
>> +MEDIA_REQUEST_IOC_QUEUE - Queue a request
>> +
>> +
>> +Synopsis
>> +========
>> +
>> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_QUEUE )
>> + :name: MEDIA_REQUEST_IOC_QUEUE
>> +
>> +
>> +Arguments
>> +=========
>> +
>> +``request_fd``
>> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
>> +
>> +
>> +Description
>> +===========
>> +
>> +If the media device supports :ref:`requests <media-request-api>`, then
>> +this request ioctl can be used to queue a previously allocated request.
>> +
>> +If the request was successfully queued, then the file descriptor can be
>> +polled to wait for the request to complete.
>> +
>> +If the request was already queued before, then '`EBUSY'` is returned.
>> +Other errors can be returned if the contents of the request contained
>> +invalid or inconsistent data.
>
> Are there any "permanent" return error code that would require the
> caller to close the file descriptor?
>
> I mean, if EBUSY is returned, userspace could just wait for a past
> QBUF to be handled and call it again, but what happens if some other
> error happens (like -ENOMEM)? Would the entire request descriptor be
> trashed or just the current QBUF attempt will fail?
Any error means that the application did something wrong and you would
just exit the application. Errors mean that either the content of the
request couldn't be validated, or (with EBUSY) the request is already in
use (clearly an application bug in that case).
In the case of codecs there is not much you can do wrong, but things
get a lot more complicated when you want to use this with complex
camera pipelines. I expect that we need a new request ioctl in the
future that can return useful error information about what was wrong in
the request.
That is out-of-scope for the codec support, though.
>
>> +
>> +Return Value
>> +============
>> +
>> +On success 0 is returned, on error -1 and the ``errno`` variable is set
>> +appropriately. The generic error codes are described at the
>> +:ref:`Generic Error Codes <gen-errors>` chapter.
>> +
>> +EBUSY
>> + The request was already queued.
>> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>> new file mode 100644
>> index 000000000000..7cbb7eb5d73e
>> --- /dev/null
>> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>> @@ -0,0 +1,51 @@
>> +.. SPDX-License-Identifier: GPL-2.0-only
>> +
>> +.. _media_request_ioc_reinit:
>> +
>> +******************************
>> +ioctl MEDIA_REQUEST_IOC_REINIT
>> +******************************
>> +
>> +Name
>> +====
>> +
>> +MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
>> +
>> +
>> +Synopsis
>> +========
>> +
>> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_REINIT )
>> + :name: MEDIA_REQUEST_IOC_REINIT
>> +
>> +
>> +Arguments
>> +=========
>> +
>> +``request_fd``
>> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
>> +
>> +Description
>> +===========
>> +
>> +If the media device supports :ref:`requests <media-request-api>`, then
>> +this request ioctl can be used to re-initialize a previously allocated
>> +request.
>> +
>> +Re-initializing a request will clear any existing data from the request.
>> +This avoids having to close() a completed request and allocate a new
>> +request. Instead the completed request can just be re-initialized and
>> +it is ready to be used again.
>> +
>> +A request can only be re-initialized if it either has not been queued
>> +yet, or if it was queued and completed.
>> +
>> +Return Value
>> +============
>> +
>> +On success 0 is returned, on error -1 and the ``errno`` variable is set
>> +appropriately. The generic error codes are described at the
>> +:ref:`Generic Error Codes <gen-errors>` chapter.
>> +
>> +EBUSY
>> + The request is queued but not yet completed.
>
> Same question here: are there any "permanent" return error code that would
> require the caller to close the file descriptor?
Same answer really, any error indicates that the application did something
wrong. Strictly speaking you could retry if you get EBUSY, but you really
shouldn't use that and instead poll for the request to be completed.
>
>> diff --git a/Documentation/media/uapi/mediactl/request-api.rst b/Documentation/media/uapi/mediactl/request-api.rst
>> new file mode 100644
>> index 000000000000..4d10f18181a4
>> --- /dev/null
>> +++ b/Documentation/media/uapi/mediactl/request-api.rst
>> @@ -0,0 +1,219 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _media-request-api:
>> +
>> +Request API
>> +===========
>> +
>> +The Request API has been designed to allow V4L2 to deal with requirements of
>> +modern devices (stateless codecs, complex camera pipelines, ...) and APIs
>> +(Android Codec v2). One such requirement is the ability for devices belonging to
>> +the same pipeline to reconfigure and collaborate closely on a per-frame basis.
>> +Another is efficient support of stateless codecs, which need per-frame controls
>> +to be set synchronously in order to be used efficiently.
>> +
>> +Supporting these features without the Request API is not always possible and if
>> +it is, it is terribly inefficient: user-space would have to flush all activity
>> +on the media pipeline, reconfigure it for the next frame, queue the buffers to
>> +be processed with that configuration, and wait until they are all available for
>> +dequeuing before considering the next frame. This defeats the purpose of having
>> +buffer queues since in practice only one buffer would be queued at a time.
>> +
>> +The Request API allows a specific configuration of the pipeline (media
>> +controller topology + controls for each media entity) to be associated with
>> +specific buffers. The parameters are applied by each participating device as
>> +buffers associated to a request flow in. This allows user-space to schedule
>> +several tasks ("requests") with different parameters in advance, knowing that
>> +the parameters will be applied when needed to get the expected result. Control
>> +values at the time of request completion are also available for reading.
>> +
>> +Usage
>> +=====
>> +
>> +The Request API is used on top of standard media controller and V4L2 calls,
>> +which are augmented with an extra ``request_fd`` parameter. Requests themselves
>> +are allocated from the supporting media controller node.
>> +
>> +Request Allocation
>> +------------------
>> +
>> +User-space allocates requests using :ref:`MEDIA_IOC_REQUEST_ALLOC`
>> +for the media device node. This returns a file descriptor representing the
>> +request. Typically, several such requests will be allocated.
>> +
>> +Request Preparation
>> +-------------------
>> +
>> +Standard V4L2 ioctls can then receive a request file descriptor to express the
>> +fact that the ioctl is part of said request, and is not to be applied
>> +immediately. See :ref:`MEDIA_IOC_REQUEST_ALLOC` for a list of ioctls that
>> +support this. Controls set with a ``request_fd`` parameter are stored instead
>> +of being immediately applied, and buffers queued to a request do not enter the
>> +regular buffer queue until the request itself is queued.
>> +
>> +Request Submission
>> +------------------
>> +
>> +Once the parameters and buffers of the request are specified, it can be
>> +queued by calling :ref:`MEDIA_REQUEST_IOC_QUEUE` on the request FD.
>> +This will make the buffers associated to the request available to their driver,
>> +which can then apply the associated controls as buffers are processed. A queued
>> +request cannot be modified anymore.
>
> What happens if one closes a file descriptor while a request is pending?
> Would the close() ops wait until the request to finish? If so, what happens
> when FD is opened in non-blocking mode?
It doesn't block, it just decrements the internal refcount of the request. The
request won't be freed until the request completes. Of course, once it is closed
the application has no way to access the request anymore.
>
>> +
>> +If the request contains parameters for multiple entities, individual drivers may
>> +synchronize so the requested pipeline's topology is applied before the buffers
>> +are processed. Media controller drivers do a best effort implementation since
>> +perfect atomicity may not be possible due to hardware limitations.
>> +
>> +Once buffers are added to a request for the first time it is no longer possible
>
> Nitpick: missing comma:
> Once buffers are added to a request for the first time,
ack
>
>> +to queue non-request buffers of that buffer type until
>> +:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called.
>
> Not even after closing the request fd? My past understanding is that
> closing a file descriptor would be enough to free the request.
No, once you start using requests, you have to keep using it. As mentioned
above, closing the request fd doesn't free the request, unless the request
was already completed.
The problem is that things become very complex when you start mixing requests
and VIDIOC_QBUF. For now (and likely forever) this is prohibited.
>
> If that's not the case, and STREAMOFF is indeed required to free the
> buffer, please document it also at MEDIA_IOC_REQUEST_ALLOC.
This has nothing to do with freeing buffers. It is about whether the
streaming mode: are you using QBUF or requests? Once you start using
requests while streaming, you have to keep doing that until you stop
streaming.
>
>> +
>> +Controls can still be set without a request and are applied immediately,
>> +regardless of whether a request is in use or not.
>
>> Setting the same control
>> +through a request and directly can lead to undefined behavior!
>
> I would place it as a caution note:
>
> .. caution::
>
> Setting the same control through a request and directly can
> lead to undefined behavior!
Right.
>
>> +
>> +User-space can ``poll()`` a request FD in order to wait until the request
>
> Hmm... ``poll`` is probably not what you want here. Same applies to ``close``,
> ``open``, etc. We actually define syscalls per subsystem (v4l2, dvb, ...), as
> the syscall behavior is somewhat dependent on how the dev ops are implemented.
> IMO, the best would be to add a page for poll() and close() for request API,
> explaining their differences with regards to the "common" behavior.
>
> For example, Documentation/media/uapi/cec/cec-func-close.rst references it
> with:
> ::c:func:`close() <cec-close>`
>
OK.
>> +completes. A request is considered complete once all its associated buffers are
>> +available for dequeuing and all the associated controls have been updated with
>> +the values at the time of completion. Note that user-space does not need to wait
>> +for the request to complete to dequeue its buffers: buffers that are available
>> +halfway through a request can be dequeued independently of the request's state.
>> +
>> +A completed request contains the state of the request at the time of the
>> +request completion. User-space can query that state by calling
>> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` with the request FD.
>
> What happens if one calls VIDIOC_G_EXT_CTRLS after DQBUF but before
> the complete request to be handled? Undefined behavior or will it
> reflect the control changes applied to that dequeued buffer?
Good point. It is basically undefined: it can either return the control as
was set by the application for this request, but if the driver also updates
this control before the request is completed it might return that new value
instead.
I think it might be best that EBUSY is returned while the request is in
flight (queued but not yet completed).
>
>> +
>> +Recycling and Destruction
>> +-------------------------
>> +
>> +Finally, completed request can either be discarded or be reused. Calling
>> +``close()`` on a request FD will make that FD unusable, freeing the request if
>> +it is not in use by the kernel. That is, if the request is queued and then the
>> +FD is closed, then it won't be freed until the driver completed the request.
>> +
>> +The :ref:`MEDIA_REQUEST_IOC_REINIT` will clear a request's state and make it
>> +available again. No state is retained by this operation: the request is as
>> +if it had just been allocated.
>> +
>> +Example for a Memory-to-Memory Device
>> +-------------------------------------
>> +
>> +M2M devices are single-node V4L2 devices providing one OUTPUT queue (for
>> +user-space to provide input buffers) and one CAPTURE queue (to retrieve
>> +processed data). These devices are commonly used for frame processors or
>> +stateless codecs.
>
> Hmm... describing what is a M2M device here doesn't sound right. It
> should be described elsewhere, and a xref to such description should
> be added here instead, pointing to some specific chapter at the V4L2
> docs for M2M.
Right.
> That reminds that I have a series of patches adding a glossary that
> needs rework. I'll see if I can respin it this week, in order to allow
> adding M2M to the glossary too.
>
>> +
>> +In this use-case, the request API can be used to associate specific controls to
>> +be applied by the driver for the OUTPUT buffer, allowing user-space
>> +to queue many such buffers in advance. It can also take advantage of requests'
>> +ability to capture the state of controls when the request completes to read back
>> +information that may be subject to change.
>> +
>> +Put into code, after obtaining a request, user-space can assign controls and one
>> +OUTPUT buffer to it:
>> +
>> +.. code-block:: c
>> +
>> + struct v4l2_buffer buf;
>> + struct v4l2_ext_controls ctrls;
>> + struct media_request_alloc alloc = { 0 };
>> + int req_fd;
>> + ...
>> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
>> + req_fd = alloc.fd;
>> + ...
>> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
>> + ctrls.request_fd = req_fd;
>> + ioctl(codec_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
>> + ...
>> + buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
>> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
>> + buf.request_fd = req_fd;
>> + ioctl(codec_fd, VIDIOC_QBUF, &buf);
>
> Hmm... I understand that you want an example to be as simple and as
> shorter as possible, but I don't like adding a code example without
> proper error handling code, as one might just copy-and-paste it
> without adding the required error handling.
>
> I would do, at least, something like:
>
> assert (!ioctl(...));
>
> in order to make clearer that errors should be checked, and, on worse
> case scenario of a cut-and-paste code, the app will abort if errors
> are found, printing some errors.
I can add something along these lines.
>
>> +
>> +Note that there is typically no need to use the Request API for CAPTURE buffers
>> +since there are no per-frame settings to report there.
>> +
>> +Once the request is fully prepared, it can be queued to the driver:
>> +
>> +.. code-block:: c
>> +
>> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
>
> Same here. I would code this as:
>
> .. code-block:: c
>
> rc = ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
> if (rc)
> perror("MEDIA_REQUEST_IOC_QUEUE");
>
> in order to give a hint about a more realistic error handling code.
>
> (same comments about error handling apply to other examples below)
>
>> +
>> +User-space can then either wait for the request to complete by calling poll() on
>> +its file descriptor, or start dequeuing CAPTURE buffers. Most likely, it will
>> +want to get CAPTURE buffers as soon as possible and this can be done using a
>> +regular DQBUF:
>> +
>> +.. code-block:: c
>> +
>> + struct v4l2_buffer buf;
>> +
>> + memset(&buf, 0, sizeof(buf));
>> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>> + ioctl(codec_fd, VIDIOC_DQBUF, &buf);
>> +
>> +Note that this example assumes for simplicity that for every OUTPUT buffer
>> +there will be one CAPTURE buffer, but this does not have to be the case.
>> +
>> +We can then, after ensuring that the request is completed via polling the
>> +request FD, query control values at the time of its completion via an
>> +annotated call to G_EXT_CTRLS. This is particularly useful for volatile controls
>> +for which we want to query values as soon as the capture buffer is produced.
>> +
>> +.. code-block:: c
>> +
>> + struct pollfd pfd = { .events = POLLPRI, .fd = request_fd };
>> + poll(&pfd, 1, -1);
>> + ...
>> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
>> + ctrls.request_fd = req_fd;
>> + ioctl(codec_fd, VIDIOC_G_EXT_CTRLS, &ctrls);
>> +
>> +Once we don't need the request anymore, we can either recycle it for reuse with
>> +:ref:`MEDIA_REQUEST_IOC_REINIT`...
>> +
>> +.. code-block:: c
>> +
>> + ioctl(req_fd, MEDIA_REQUEST_IOC_REINIT);
>> +
>> +... or close its file descriptor to completely dispose of it.
>> +
>> +.. code-block:: c
>> +
>> + close(req_fd);
>> +
>> +Example for a Simple Capture Device
>> +-----------------------------------
>> +
>> +With a simple capture device, requests can be used to specify controls to apply
>> +for a given CAPTURE buffer.
>> +
>> +.. code-block:: c
>> +
>> + struct v4l2_buffer buf;
>> + struct v4l2_ext_controls ctrls;
>> + struct media_request_alloc alloc = { 0 };
>> + int req_fd;
>> + ...
>> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
>> + req_fd = alloc.fd;
>> + ...
>> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
>> + ctrls.request_fd = req_fd;
>> + ioctl(camera_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
>> + ...
>> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
>> + buf.request_fd = req_fd;
>> + ioctl(camera_fd, VIDIOC_QBUF, &buf);
>> +
>> +Once the request is fully prepared, it can be queued to the driver:
>> +
>> +.. code-block:: c
>> +
>> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
>> +
>> +User-space can then dequeue buffers, wait for the request completion, query
>> +controls and recycle the request as in the M2M example above.
>> diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst
>> index e2c85ddc990b..8059fc0ed520 100644
>> --- a/Documentation/media/uapi/v4l/buffer.rst
>> +++ b/Documentation/media/uapi/v4l/buffer.rst
>> @@ -306,10 +306,12 @@ struct v4l2_buffer
>> - A place holder for future extensions. Drivers and applications
>> must set this to 0.
>> * - __u32
>> - - ``reserved``
>> + - ``request_fd``
>> -
>> - - A place holder for future extensions. Drivers and applications
>> - must set this to 0.
>> + - The file descriptor of the request to queue the buffer to. If specified
>> + and flag ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be
>> + queued to that request. This is set by the user when calling
>> + :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls.
>
> What happens if userspace uses an invalid request_fd is filled here?
-EPERM if the driver doesn't support requests at all.
-ENOENT if the driver supports requests, but the fd doesn't map to a valid request.
>
>>
>>
>>
>> @@ -514,6 +516,11 @@ Buffer Flags
>> streaming may continue as normal and the buffer may be reused
>> normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is
>> called.
>> + * .. _`V4L2-BUF-FLAG-IN-REQUEST`:
>> +
>> + - ``V4L2_BUF_FLAG_IN_REQUEST``
>> + - 0x00000080
>> + - This buffer is part of a request that hasn't been queued yet.
>> * .. _`V4L2-BUF-FLAG-KEYFRAME`:
>>
>> - ``V4L2_BUF_FLAG_KEYFRAME``
>> @@ -589,6 +596,11 @@ Buffer Flags
>> the format. Any Any subsequent call to the
>> :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
>> but return an ``EPIPE`` error code.
>> + * .. _`V4L2-BUF-FLAG-REQUEST-FD`:
>> +
>> + - ``V4L2_BUF_FLAG_REQUEST_FD``
>> + - 0x00800000
>> + - The ``request_fd`` field contains a valid file descriptor.
>> * .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`:
>>
>> - ``V4L2_BUF_FLAG_TIMESTAMP_MASK``
>> diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
>> index 2011c2b2ee67..3d0e861ad4a1 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
>> @@ -95,6 +95,22 @@ appropriate. In the first case the new value is set in struct
>> is inappropriate (e.g. the given menu index is not supported by the menu
>> control), then this will also result in an ``EINVAL`` error code error.
>>
>> +If ``request_fd`` is set to a not-yet-queued :ref:`request <media-request-api>`
>> +file descriptor and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``,
>> +then the controls are not applied immediately when calling
>> +:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, but instead are applied by
>> +the driver for the buffer associated with the same request.
>
> Same note here: what happens if request_fd is invalid?
Same answer.
>
>> +
>> +An attempt to call :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` for a
>> +request that has already been queued will result in an ``EBUSY`` error.
>> +
>> +If ``request_fd`` is specified and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``
>> +during a call to :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, then the
>> +returned values will be the values currently set for the request (or the
>> +hardware value if none is set) if the request has not yet completed, or the
>> +values of the controls at the time of request completion if it has already
>> +completed.
>> +
>> The driver will only set/get these controls if all control values are
>> correct. This prevents the situation where only some of the controls
>> were set/get. Only low-level errors (e. g. a failed i2c command) can
>> @@ -209,8 +225,10 @@ still cause this situation.
>> - ``which``
>> - Which value of the control to get/set/try.
>> ``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the
>> - control and ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
>> - value of the control.
>> + control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
>> + value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that
>> + these controls have to be retrieved from a request or tried/set for
>> + a request.
>
> I didn't like the text above, as it assumes that all calls will contain
> a request_id. You need either to rewrite it or add two paragraphs, one
> describing the "normal" non-req-api case, and the other one for "req-api"
> one.
OK
>
>>
>> .. note::
>>
>> @@ -272,8 +290,12 @@ still cause this situation.
>> then you can call :ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` to try to discover the
>> actual control that failed the validation step. Unfortunately,
>> there is no ``TRY`` equivalent for :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
>> + * - __s32
>> + - ``request_fd``
>> + File descriptor of the request to be used by this operation. Only
>> + valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``.
>> * - __u32
>> - - ``reserved``\ [2]
>> + - ``reserved``\ [1]
>> - Reserved for future extensions.
>>
>> Drivers and applications must set the array to zero.
>> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> index 9e448a4aa3aa..7ac99be1dd48 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> @@ -98,6 +98,17 @@ dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
>> :ref:`VIDIOC_REQBUFS` ioctl is called, or until the
>> device is closed.
>>
>> +The ``request_fd`` field can be used when queuing to specify the file
>> +descriptor of a :ref:`request <media-request-api>`, if requests are
>> +in use. Setting it means that the buffer will not be passed to the driver
>> +until the request itself is queued. Also, the driver will apply any
>> +settings associated with the request for this buffer. This field will
>> +be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set.
>
> What happens if request_fd is invalid?
>
>> +
>> +For :ref:`memory-to-memory devices <codec>` you can specify the
>> +``request_fd`` only for output buffers, not for capture buffers. Attempting
>> +to specify this for a capture buffer will result in an ``EINVAL`` error.
>> +
>> Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
>> (capturing) or displayed (output) buffer from the driver's outgoing
>> queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
>> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
>> index a5cb0a8686ac..5a5a1c772053 100644
>> --- a/Documentation/media/videodev2.h.rst.exceptions
>> +++ b/Documentation/media/videodev2.h.rst.exceptions
>> @@ -514,6 +514,7 @@ ignore define V4L2_CTRL_DRIVER_PRIV
>> ignore define V4L2_CTRL_MAX_DIMS
>> ignore define V4L2_CTRL_WHICH_CUR_VAL
>> ignore define V4L2_CTRL_WHICH_DEF_VAL
>> +ignore define V4L2_CTRL_WHICH_REQUEST_VAL
>> ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS
>> ignore define V4L2_CID_MAX_CTRLS
>>
>
>
>
> Thanks,
> Mauro
>
Regards,
Hans
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 29/35] Documentation: v4l: document request API
2018-07-03 13:02 ` Hans Verkuil
@ 2018-07-03 14:08 ` Mauro Carvalho Chehab
2018-07-03 14:22 ` Hans Verkuil
0 siblings, 1 reply; 61+ messages in thread
From: Mauro Carvalho Chehab @ 2018-07-03 14:08 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Alexandre Courbot, Hans Verkuil
Em Tue, 3 Jul 2018 15:02:05 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 03/07/18 13:50, Mauro Carvalho Chehab wrote:
> > Em Mon, 4 Jun 2018 13:46:42 +0200
> > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >
> >> From: Alexandre Courbot <acourbot@chromium.org>
> >>
> >> Document the request API for V4L2 devices, and amend the documentation
> >> of system calls influenced by it.
> >
> > I'm starting reviewing the patch series from this patch, as it defines
> > how the request API is supposed to work. Some of my comments below may
> > reflect on code changes, in order for the core (and drivers) to be
> > compliant with the uAPI specified here.
> >
> > So, I prefer to discuss first the contents of this patch, before start
> > reviewing the remaining patches.
> >
> >>
> >> Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
> >> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> >> ---
> >> .../media/uapi/mediactl/media-controller.rst | 1 +
> >> .../media/uapi/mediactl/media-funcs.rst | 3 +
> >> .../uapi/mediactl/media-ioc-request-alloc.rst | 71 ++++++
> >> .../uapi/mediactl/media-request-ioc-queue.rst | 50 ++++
> >> .../mediactl/media-request-ioc-reinit.rst | 51 ++++
> >> .../media/uapi/mediactl/request-api.rst | 219 ++++++++++++++++++
> >> Documentation/media/uapi/v4l/buffer.rst | 18 +-
> >> .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 28 ++-
> >> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 11 +
> >> .../media/videodev2.h.rst.exceptions | 1 +
> >> 10 files changed, 447 insertions(+), 6 deletions(-)
> >> create mode 100644 Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> >> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
> >> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
> >> create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
> >>
> >> diff --git a/Documentation/media/uapi/mediactl/media-controller.rst b/Documentation/media/uapi/mediactl/media-controller.rst
> >> index 0eea4f9a07d5..66aff38cd499 100644
> >> --- a/Documentation/media/uapi/mediactl/media-controller.rst
> >> +++ b/Documentation/media/uapi/mediactl/media-controller.rst
> >> @@ -21,6 +21,7 @@ Part IV - Media Controller API
> >> media-controller-intro
> >> media-controller-model
> >> media-types
> >> + request-api
> >> media-funcs
> >> media-header
> >>
> >> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst b/Documentation/media/uapi/mediactl/media-funcs.rst
> >> index 076856501cdb..f4da9b3e17ec 100644
> >> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
> >> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
> >> @@ -16,3 +16,6 @@ Function Reference
> >> media-ioc-enum-entities
> >> media-ioc-enum-links
> >> media-ioc-setup-link
> >> + media-ioc-request-alloc
> >> + media-request-ioc-queue
> >> + media-request-ioc-reinit
> >> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> >> new file mode 100644
> >> index 000000000000..d45a94c9e23c
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
> >> @@ -0,0 +1,71 @@
> >> +.. SPDX-License-Identifier: GPL-2.0-only
> >> +
> >> +.. _media_ioc_request_alloc:
> >> +
> >> +*****************************
> >> +ioctl MEDIA_IOC_REQUEST_ALLOC
> >> +*****************************
> >> +
> >> +Name
> >> +====
> >> +
> >> +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
> >> +
> >> +
> >> +Synopsis
> >> +========
> >> +
> >> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct media_request_alloc *argp )
> >> + :name: MEDIA_IOC_REQUEST_ALLOC
> >> +
> >> +
> >> +Arguments
> >> +=========
> >> +
> >> +``fd``
> >> + File descriptor returned by :ref:`open() <media-func-open>`.
> >> +
> >> +``argp``
> >> +
> >> +
> >> +Description
> >> +===========
> >> +
> >> +If the media device supports :ref:`requests <media-request-api>`, then
> >> +this ioctl can be used to allocate a request.
> >
> > Perhaps we should mention that otherwise it would set errno to ENOTTY.
>
> Will add.
>
> >
> >> A request is accessed through
> >> +a file descriptor that is returned in struct :c:type:`media_request_alloc`.
> >> +
> >> +If the request was successfully allocated, then the request file descriptor
> >> +can be passed to :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>`,
> >> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
> >> +:ref:`ioctl VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and
> >> +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
> >> +
> >> +In addition, the request can be queued by calling
> >> +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
> >> +:ref:`MEDIA_REQUEST_IOC_REINIT`.
> >> +
> >> +Finally, the file descriptor can be polled to wait for the request to
> >> +complete.
> >> +
> >> +To free the request the file descriptor has to be closed.
> >
> > Hmm... I don't think this is clear enough. After reading this paragraph,
> > I came back to patch 1, in order to see what's the ioctl to be called
> > to free the request, only to notice that there's none.
> >
> > So, I guess what you wanted to say, instead, is that:
> >
> > "A request will remain allocated until the associated file descriptor is
> > closed by ::c:func:`close() <req-api-close>` and after the Kernel stops
> > using the request."
>
> That's a lot clearer.
>
> >
> > (see below for a discussion about the close() reference)
> >
> >> +
> >> +.. c:type:: media_request_alloc
> >> +
> >> +.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
> >> +
> >> +.. flat-table:: struct media_request_alloc
> >> + :header-rows: 0
> >> + :stub-columns: 0
> >> + :widths: 1 1 2
> >> +
> >> + * - __s32
> >> + - ``fd``
> >> + - The file descriptor of the request.
> >> +
> >> +Return Value
> >> +============
> >> +
> >> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> >> +appropriately. The generic error codes are described at the
> >> +:ref:`Generic Error Codes <gen-errors>` chapter.
> >> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
> >> new file mode 100644
> >> index 000000000000..d3bac7b70422
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
> >> @@ -0,0 +1,50 @@
> >> +.. SPDX-License-Identifier: GPL-2.0-only
> >> +
> >> +.. _media_request_ioc_queue:
> >> +
> >> +*****************************
> >> +ioctl MEDIA_REQUEST_IOC_QUEUE
> >> +*****************************
> >> +
> >> +Name
> >> +====
> >> +
> >> +MEDIA_REQUEST_IOC_QUEUE - Queue a request
> >> +
> >> +
> >> +Synopsis
> >> +========
> >> +
> >> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_QUEUE )
> >> + :name: MEDIA_REQUEST_IOC_QUEUE
> >> +
> >> +
> >> +Arguments
> >> +=========
> >> +
> >> +``request_fd``
> >> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
> >> +
> >> +
> >> +Description
> >> +===========
> >> +
> >> +If the media device supports :ref:`requests <media-request-api>`, then
> >> +this request ioctl can be used to queue a previously allocated request.
> >> +
> >> +If the request was successfully queued, then the file descriptor can be
> >> +polled to wait for the request to complete.
> >> +
> >> +If the request was already queued before, then '`EBUSY'` is returned.
> >> +Other errors can be returned if the contents of the request contained
> >> +invalid or inconsistent data.
> >
> > Are there any "permanent" return error code that would require the
> > caller to close the file descriptor?
> >
> > I mean, if EBUSY is returned, userspace could just wait for a past
> > QBUF to be handled and call it again, but what happens if some other
> > error happens (like -ENOMEM)? Would the entire request descriptor be
> > trashed or just the current QBUF attempt will fail?
Just to be clear about that: I expect that the questions I asked are
somehow answered inside the documentation, in order to
be a guideline for both Kernel and userspace app developers. So, once
we reach an agreement about the expected behavior, please add it
to the documentation patch.
> Any error means that the application did something wrong and you would
> just exit the application. Errors mean that either the content of the
> request couldn't be validated, or (with EBUSY) the request is already in
> use (clearly an application bug in that case).
>
> In the case of codecs there is not much you can do wrong,
So, IMHO, it makes sense to document what errors could be generated
with the current implementation, as the above description sounded
too vague to me. Is it just EINVAL errors?
> but things
> get a lot more complicated when you want to use this with complex
> camera pipelines. I expect that we need a new request ioctl in the
> future that can return useful error information about what was wrong in
> the request.
>
> That is out-of-scope for the codec support, though.
Yes.
>
> >
> >> +
> >> +Return Value
> >> +============
> >> +
> >> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> >> +appropriately. The generic error codes are described at the
> >> +:ref:`Generic Error Codes <gen-errors>` chapter.
> >> +
> >> +EBUSY
> >> + The request was already queued.
> >> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
> >> new file mode 100644
> >> index 000000000000..7cbb7eb5d73e
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
> >> @@ -0,0 +1,51 @@
> >> +.. SPDX-License-Identifier: GPL-2.0-only
> >> +
> >> +.. _media_request_ioc_reinit:
> >> +
> >> +******************************
> >> +ioctl MEDIA_REQUEST_IOC_REINIT
> >> +******************************
> >> +
> >> +Name
> >> +====
> >> +
> >> +MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
> >> +
> >> +
> >> +Synopsis
> >> +========
> >> +
> >> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_REINIT )
> >> + :name: MEDIA_REQUEST_IOC_REINIT
> >> +
> >> +
> >> +Arguments
> >> +=========
> >> +
> >> +``request_fd``
> >> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
> >> +
> >> +Description
> >> +===========
> >> +
> >> +If the media device supports :ref:`requests <media-request-api>`, then
> >> +this request ioctl can be used to re-initialize a previously allocated
> >> +request.
> >> +
> >> +Re-initializing a request will clear any existing data from the request.
> >> +This avoids having to close() a completed request and allocate a new
> >> +request. Instead the completed request can just be re-initialized and
> >> +it is ready to be used again.
> >> +
> >> +A request can only be re-initialized if it either has not been queued
> >> +yet, or if it was queued and completed.
> >> +
> >> +Return Value
> >> +============
> >> +
> >> +On success 0 is returned, on error -1 and the ``errno`` variable is set
> >> +appropriately. The generic error codes are described at the
> >> +:ref:`Generic Error Codes <gen-errors>` chapter.
> >> +
> >> +EBUSY
> >> + The request is queued but not yet completed.
> >
> > Same question here: are there any "permanent" return error code that would
> > require the caller to close the file descriptor?
>
> Same answer really, any error indicates that the application did something
> wrong.
I suspect that, in this case, it could be also a Kernel problem (for
instance, lack of memory). IMHO, it is also worth to mention what errors
can happen here.
> Strictly speaking you could retry if you get EBUSY, but you really
> shouldn't use that and instead poll for the request to be completed.
Yeah, sure, but an application could be smart enough to "survive"
in case of failures. I can see a lot of scenarios where apps will
try to keep alive despite any errors, like on industrial cameras.
After watching some speeches in Japan for automotive Linux[1], I can
even think on some scenarios that can be really critical to be
error-pruned. For example, imagine that a camera is used by some
auto-driver system inside a car. Stopping the application can
cause severe injuries to people.
[1] Before someone asks me, no, I'm not aware of any real use cases
for the request API on auto-pilot car systems. Just doing a
little of speculation here about possible future usage scenarios.
The thing is that request API may lead into some complex and
hard to identify issues, on both Kernel and userspace. So, better
to make sure that the documentation (and implementation) will
have, as much as possible, a deterministic behavior.
> >
> >> diff --git a/Documentation/media/uapi/mediactl/request-api.rst b/Documentation/media/uapi/mediactl/request-api.rst
> >> new file mode 100644
> >> index 000000000000..4d10f18181a4
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/mediactl/request-api.rst
> >> @@ -0,0 +1,219 @@
> >> +.. -*- coding: utf-8; mode: rst -*-
> >> +
> >> +.. _media-request-api:
> >> +
> >> +Request API
> >> +===========
> >> +
> >> +The Request API has been designed to allow V4L2 to deal with requirements of
> >> +modern devices (stateless codecs, complex camera pipelines, ...) and APIs
> >> +(Android Codec v2). One such requirement is the ability for devices belonging to
> >> +the same pipeline to reconfigure and collaborate closely on a per-frame basis.
> >> +Another is efficient support of stateless codecs, which need per-frame controls
> >> +to be set synchronously in order to be used efficiently.
> >> +
> >> +Supporting these features without the Request API is not always possible and if
> >> +it is, it is terribly inefficient: user-space would have to flush all activity
> >> +on the media pipeline, reconfigure it for the next frame, queue the buffers to
> >> +be processed with that configuration, and wait until they are all available for
> >> +dequeuing before considering the next frame. This defeats the purpose of having
> >> +buffer queues since in practice only one buffer would be queued at a time.
> >> +
> >> +The Request API allows a specific configuration of the pipeline (media
> >> +controller topology + controls for each media entity) to be associated with
> >> +specific buffers. The parameters are applied by each participating device as
> >> +buffers associated to a request flow in. This allows user-space to schedule
> >> +several tasks ("requests") with different parameters in advance, knowing that
> >> +the parameters will be applied when needed to get the expected result. Control
> >> +values at the time of request completion are also available for reading.
> >> +
> >> +Usage
> >> +=====
> >> +
> >> +The Request API is used on top of standard media controller and V4L2 calls,
> >> +which are augmented with an extra ``request_fd`` parameter. Requests themselves
> >> +are allocated from the supporting media controller node.
> >> +
> >> +Request Allocation
> >> +------------------
> >> +
> >> +User-space allocates requests using :ref:`MEDIA_IOC_REQUEST_ALLOC`
> >> +for the media device node. This returns a file descriptor representing the
> >> +request. Typically, several such requests will be allocated.
> >> +
> >> +Request Preparation
> >> +-------------------
> >> +
> >> +Standard V4L2 ioctls can then receive a request file descriptor to express the
> >> +fact that the ioctl is part of said request, and is not to be applied
> >> +immediately. See :ref:`MEDIA_IOC_REQUEST_ALLOC` for a list of ioctls that
> >> +support this. Controls set with a ``request_fd`` parameter are stored instead
> >> +of being immediately applied, and buffers queued to a request do not enter the
> >> +regular buffer queue until the request itself is queued.
> >> +
> >> +Request Submission
> >> +------------------
> >> +
> >> +Once the parameters and buffers of the request are specified, it can be
> >> +queued by calling :ref:`MEDIA_REQUEST_IOC_QUEUE` on the request FD.
> >> +This will make the buffers associated to the request available to their driver,
> >> +which can then apply the associated controls as buffers are processed. A queued
> >> +request cannot be modified anymore.
> >
> > What happens if one closes a file descriptor while a request is pending?
> > Would the close() ops wait until the request to finish? If so, what happens
> > when FD is opened in non-blocking mode?
>
> It doesn't block, it just decrements the internal refcount of the request. The
> request won't be freed until the request completes. Of course, once it is closed
> the application has no way to access the request anymore.
Ok. Please document it at the close() documentation for the request API.
>
> >
> >> +
> >> +If the request contains parameters for multiple entities, individual drivers may
> >> +synchronize so the requested pipeline's topology is applied before the buffers
> >> +are processed. Media controller drivers do a best effort implementation since
> >> +perfect atomicity may not be possible due to hardware limitations.
> >> +
> >> +Once buffers are added to a request for the first time it is no longer possible
> >
> > Nitpick: missing comma:
> > Once buffers are added to a request for the first time,
>
> ack
>
> >
> >> +to queue non-request buffers of that buffer type until
> >> +:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called.
> >
> > Not even after closing the request fd? My past understanding is that
> > closing a file descriptor would be enough to free the request.
>
> No, once you start using requests, you have to keep using it. As mentioned
> above, closing the request fd doesn't free the request, unless the request
> was already completed.
>
> The problem is that things become very complex when you start mixing requests
> and VIDIOC_QBUF. For now (and likely forever) this is prohibited.
>
> >
> > If that's not the case, and STREAMOFF is indeed required to free the
> > buffer, please document it also at MEDIA_IOC_REQUEST_ALLOC.
>
> This has nothing to do with freeing buffers. It is about whether the
> streaming mode: are you using QBUF or requests? Once you start using
> requests while streaming, you have to keep doing that until you stop
> streaming.
I might have missed it, but I don't remember any part of the docs
saying that it is forbidden to mix request/non-request QBUFs.
Ok, after re-reading what's written there, one might understand that,
but, I had a different understanding the first time I read, as
"a request" made me thing that a buffer number would be sticked
forever to a certain request_id.
After your comments, I guess that what it is intended to be said
is, instead, something similar to:
"It is forbidden to have some VIDIOC_QBUF calls with the request_id
filled with other VIDIOC_QBUF calls without it.
So, if the first successful call to a VIDIOC_QBUF after start
streaming has request_id filled, all other calls should also
have it filed, otherwise -EBUSY will be returned."
For coherency, I would also add (and enforce):
"The reverse is also true: if the first successful call after start
streaming to a VIDIOC_QBUF without request_id fields is used, any
attempt to queue a buffer with it filled will return -EBUSY."
As probably the behavior of having the first "n" buffers without
request, with controls being changed in runtime, followed by all
others with request could produce unexpected behavior, specially
if buffers are delivered out of order.
> >
> >> +
> >> +Controls can still be set without a request and are applied immediately,
> >> +regardless of whether a request is in use or not.
> >
> >> Setting the same control
> >> +through a request and directly can lead to undefined behavior!
> >
> > I would place it as a caution note:
> >
> > .. caution::
> >
> > Setting the same control through a request and directly can
> > lead to undefined behavior!
>
> Right.
>
> >
> >> +
> >> +User-space can ``poll()`` a request FD in order to wait until the request
> >
> > Hmm... ``poll`` is probably not what you want here. Same applies to ``close``,
> > ``open``, etc. We actually define syscalls per subsystem (v4l2, dvb, ...), as
> > the syscall behavior is somewhat dependent on how the dev ops are implemented.
> > IMO, the best would be to add a page for poll() and close() for request API,
> > explaining their differences with regards to the "common" behavior.
> >
> > For example, Documentation/media/uapi/cec/cec-func-close.rst references it
> > with:
> > ::c:func:`close() <cec-close>`
> >
>
> OK.
>
> >> +completes. A request is considered complete once all its associated buffers are
> >> +available for dequeuing and all the associated controls have been updated with
> >> +the values at the time of completion. Note that user-space does not need to wait
> >> +for the request to complete to dequeue its buffers: buffers that are available
> >> +halfway through a request can be dequeued independently of the request's state.
> >> +
> >> +A completed request contains the state of the request at the time of the
> >> +request completion. User-space can query that state by calling
> >> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` with the request FD.
> >
> > What happens if one calls VIDIOC_G_EXT_CTRLS after DQBUF but before
> > the complete request to be handled? Undefined behavior or will it
> > reflect the control changes applied to that dequeued buffer?
>
> Good point. It is basically undefined: it can either return the control as
> was set by the application for this request, but if the driver also updates
> this control before the request is completed it might return that new value
> instead.
>
> I think it might be best that EBUSY is returned while the request is in
> flight (queued but not yet completed).
Makes sense to me. Please document it (and be sure implementation will
follow the docs).
>
> >
> >> +
> >> +Recycling and Destruction
> >> +-------------------------
> >> +
> >> +Finally, completed request can either be discarded or be reused. Calling
> >> +``close()`` on a request FD will make that FD unusable, freeing the request if
> >> +it is not in use by the kernel. That is, if the request is queued and then the
> >> +FD is closed, then it won't be freed until the driver completed the request.
> >> +
> >> +The :ref:`MEDIA_REQUEST_IOC_REINIT` will clear a request's state and make it
> >> +available again. No state is retained by this operation: the request is as
> >> +if it had just been allocated.
> >> +
> >> +Example for a Memory-to-Memory Device
> >> +-------------------------------------
> >> +
> >> +M2M devices are single-node V4L2 devices providing one OUTPUT queue (for
> >> +user-space to provide input buffers) and one CAPTURE queue (to retrieve
> >> +processed data). These devices are commonly used for frame processors or
> >> +stateless codecs.
> >
> > Hmm... describing what is a M2M device here doesn't sound right. It
> > should be described elsewhere, and a xref to such description should
> > be added here instead, pointing to some specific chapter at the V4L2
> > docs for M2M.
>
> Right.
>
> > That reminds that I have a series of patches adding a glossary that
> > needs rework. I'll see if I can respin it this week, in order to allow
> > adding M2M to the glossary too.
> >
> >> +
> >> +In this use-case, the request API can be used to associate specific controls to
> >> +be applied by the driver for the OUTPUT buffer, allowing user-space
> >> +to queue many such buffers in advance. It can also take advantage of requests'
> >> +ability to capture the state of controls when the request completes to read back
> >> +information that may be subject to change.
> >> +
> >> +Put into code, after obtaining a request, user-space can assign controls and one
> >> +OUTPUT buffer to it:
> >> +
> >> +.. code-block:: c
> >> +
> >> + struct v4l2_buffer buf;
> >> + struct v4l2_ext_controls ctrls;
> >> + struct media_request_alloc alloc = { 0 };
> >> + int req_fd;
> >> + ...
> >> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
> >> + req_fd = alloc.fd;
> >> + ...
> >> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
> >> + ctrls.request_fd = req_fd;
> >> + ioctl(codec_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
> >> + ...
> >> + buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> >> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
> >> + buf.request_fd = req_fd;
> >> + ioctl(codec_fd, VIDIOC_QBUF, &buf);
> >
> > Hmm... I understand that you want an example to be as simple and as
> > shorter as possible, but I don't like adding a code example without
> > proper error handling code, as one might just copy-and-paste it
> > without adding the required error handling.
> >
> > I would do, at least, something like:
> >
> > assert (!ioctl(...));
> >
> > in order to make clearer that errors should be checked, and, on worse
> > case scenario of a cut-and-paste code, the app will abort if errors
> > are found, printing some errors.
>
> I can add something along these lines.
>
> >
> >> +
> >> +Note that there is typically no need to use the Request API for CAPTURE buffers
> >> +since there are no per-frame settings to report there.
> >> +
> >> +Once the request is fully prepared, it can be queued to the driver:
> >> +
> >> +.. code-block:: c
> >> +
> >> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
> >
> > Same here. I would code this as:
> >
> > .. code-block:: c
> >
> > rc = ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
> > if (rc)
> > perror("MEDIA_REQUEST_IOC_QUEUE");
> >
> > in order to give a hint about a more realistic error handling code.
> >
> > (same comments about error handling apply to other examples below)
> >
> >> +
> >> +User-space can then either wait for the request to complete by calling poll() on
> >> +its file descriptor, or start dequeuing CAPTURE buffers. Most likely, it will
> >> +want to get CAPTURE buffers as soon as possible and this can be done using a
> >> +regular DQBUF:
> >> +
> >> +.. code-block:: c
> >> +
> >> + struct v4l2_buffer buf;
> >> +
> >> + memset(&buf, 0, sizeof(buf));
> >> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> >> + ioctl(codec_fd, VIDIOC_DQBUF, &buf);
> >> +
> >> +Note that this example assumes for simplicity that for every OUTPUT buffer
> >> +there will be one CAPTURE buffer, but this does not have to be the case.
> >> +
> >> +We can then, after ensuring that the request is completed via polling the
> >> +request FD, query control values at the time of its completion via an
> >> +annotated call to G_EXT_CTRLS. This is particularly useful for volatile controls
> >> +for which we want to query values as soon as the capture buffer is produced.
> >> +
> >> +.. code-block:: c
> >> +
> >> + struct pollfd pfd = { .events = POLLPRI, .fd = request_fd };
> >> + poll(&pfd, 1, -1);
> >> + ...
> >> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
> >> + ctrls.request_fd = req_fd;
> >> + ioctl(codec_fd, VIDIOC_G_EXT_CTRLS, &ctrls);
> >> +
> >> +Once we don't need the request anymore, we can either recycle it for reuse with
> >> +:ref:`MEDIA_REQUEST_IOC_REINIT`...
> >> +
> >> +.. code-block:: c
> >> +
> >> + ioctl(req_fd, MEDIA_REQUEST_IOC_REINIT);
> >> +
> >> +... or close its file descriptor to completely dispose of it.
> >> +
> >> +.. code-block:: c
> >> +
> >> + close(req_fd);
> >> +
> >> +Example for a Simple Capture Device
> >> +-----------------------------------
> >> +
> >> +With a simple capture device, requests can be used to specify controls to apply
> >> +for a given CAPTURE buffer.
> >> +
> >> +.. code-block:: c
> >> +
> >> + struct v4l2_buffer buf;
> >> + struct v4l2_ext_controls ctrls;
> >> + struct media_request_alloc alloc = { 0 };
> >> + int req_fd;
> >> + ...
> >> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
> >> + req_fd = alloc.fd;
> >> + ...
> >> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
> >> + ctrls.request_fd = req_fd;
> >> + ioctl(camera_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
> >> + ...
> >> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> >> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
> >> + buf.request_fd = req_fd;
> >> + ioctl(camera_fd, VIDIOC_QBUF, &buf);
> >> +
> >> +Once the request is fully prepared, it can be queued to the driver:
> >> +
> >> +.. code-block:: c
> >> +
> >> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
> >> +
> >> +User-space can then dequeue buffers, wait for the request completion, query
> >> +controls and recycle the request as in the M2M example above.
> >> diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst
> >> index e2c85ddc990b..8059fc0ed520 100644
> >> --- a/Documentation/media/uapi/v4l/buffer.rst
> >> +++ b/Documentation/media/uapi/v4l/buffer.rst
> >> @@ -306,10 +306,12 @@ struct v4l2_buffer
> >> - A place holder for future extensions. Drivers and applications
> >> must set this to 0.
> >> * - __u32
> >> - - ``reserved``
> >> + - ``request_fd``
> >> -
> >> - - A place holder for future extensions. Drivers and applications
> >> - must set this to 0.
> >> + - The file descriptor of the request to queue the buffer to. If specified
> >> + and flag ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be
> >> + queued to that request. This is set by the user when calling
> >> + :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls.
> >
> > What happens if userspace uses an invalid request_fd is filled here?
>
> -EPERM if the driver doesn't support requests at all.
> -ENOENT if the driver supports requests, but the fd doesn't map to a valid request.
Ok. Please document it, as it can help app developers to debug issues
there.
>
> >
> >>
> >>
> >>
> >> @@ -514,6 +516,11 @@ Buffer Flags
> >> streaming may continue as normal and the buffer may be reused
> >> normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is
> >> called.
> >> + * .. _`V4L2-BUF-FLAG-IN-REQUEST`:
> >> +
> >> + - ``V4L2_BUF_FLAG_IN_REQUEST``
> >> + - 0x00000080
> >> + - This buffer is part of a request that hasn't been queued yet.
> >> * .. _`V4L2-BUF-FLAG-KEYFRAME`:
> >>
> >> - ``V4L2_BUF_FLAG_KEYFRAME``
> >> @@ -589,6 +596,11 @@ Buffer Flags
> >> the format. Any Any subsequent call to the
> >> :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
> >> but return an ``EPIPE`` error code.
> >> + * .. _`V4L2-BUF-FLAG-REQUEST-FD`:
> >> +
> >> + - ``V4L2_BUF_FLAG_REQUEST_FD``
> >> + - 0x00800000
> >> + - The ``request_fd`` field contains a valid file descriptor.
> >> * .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`:
> >>
> >> - ``V4L2_BUF_FLAG_TIMESTAMP_MASK``
> >> diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
> >> index 2011c2b2ee67..3d0e861ad4a1 100644
> >> --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
> >> +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
> >> @@ -95,6 +95,22 @@ appropriate. In the first case the new value is set in struct
> >> is inappropriate (e.g. the given menu index is not supported by the menu
> >> control), then this will also result in an ``EINVAL`` error code error.
> >>
> >> +If ``request_fd`` is set to a not-yet-queued :ref:`request <media-request-api>`
> >> +file descriptor and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``,
> >> +then the controls are not applied immediately when calling
> >> +:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, but instead are applied by
> >> +the driver for the buffer associated with the same request.
> >
> > Same note here: what happens if request_fd is invalid?
>
> Same answer.
Ok. Please document.
>
> >
> >> +
> >> +An attempt to call :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` for a
> >> +request that has already been queued will result in an ``EBUSY`` error.
> >> +
> >> +If ``request_fd`` is specified and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``
> >> +during a call to :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, then the
> >> +returned values will be the values currently set for the request (or the
> >> +hardware value if none is set) if the request has not yet completed, or the
> >> +values of the controls at the time of request completion if it has already
> >> +completed.
> >> +
> >> The driver will only set/get these controls if all control values are
> >> correct. This prevents the situation where only some of the controls
> >> were set/get. Only low-level errors (e. g. a failed i2c command) can
> >> @@ -209,8 +225,10 @@ still cause this situation.
> >> - ``which``
> >> - Which value of the control to get/set/try.
> >> ``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the
> >> - control and ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
> >> - value of the control.
> >> + control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
> >> + value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that
> >> + these controls have to be retrieved from a request or tried/set for
> >> + a request.
> >
> > I didn't like the text above, as it assumes that all calls will contain
> > a request_id. You need either to rewrite it or add two paragraphs, one
> > describing the "normal" non-req-api case, and the other one for "req-api"
> > one.
>
> OK
>
> >
> >>
> >> .. note::
> >>
> >> @@ -272,8 +290,12 @@ still cause this situation.
> >> then you can call :ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` to try to discover the
> >> actual control that failed the validation step. Unfortunately,
> >> there is no ``TRY`` equivalent for :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
> >> + * - __s32
> >> + - ``request_fd``
> >> + File descriptor of the request to be used by this operation. Only
> >> + valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``.
> >> * - __u32
> >> - - ``reserved``\ [2]
> >> + - ``reserved``\ [1]
> >> - Reserved for future extensions.
> >>
> >> Drivers and applications must set the array to zero.
> >> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> index 9e448a4aa3aa..7ac99be1dd48 100644
> >> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> @@ -98,6 +98,17 @@ dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
> >> :ref:`VIDIOC_REQBUFS` ioctl is called, or until the
> >> device is closed.
> >>
> >> +The ``request_fd`` field can be used when queuing to specify the file
> >> +descriptor of a :ref:`request <media-request-api>`, if requests are
> >> +in use. Setting it means that the buffer will not be passed to the driver
> >> +until the request itself is queued. Also, the driver will apply any
> >> +settings associated with the request for this buffer. This field will
> >> +be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set.
> >
> > What happens if request_fd is invalid?
> >
> >> +
> >> +For :ref:`memory-to-memory devices <codec>` you can specify the
> >> +``request_fd`` only for output buffers, not for capture buffers. Attempting
> >> +to specify this for a capture buffer will result in an ``EINVAL`` error.
> >> +
> >> Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
> >> (capturing) or displayed (output) buffer from the driver's outgoing
> >> queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
> >> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
> >> index a5cb0a8686ac..5a5a1c772053 100644
> >> --- a/Documentation/media/videodev2.h.rst.exceptions
> >> +++ b/Documentation/media/videodev2.h.rst.exceptions
> >> @@ -514,6 +514,7 @@ ignore define V4L2_CTRL_DRIVER_PRIV
> >> ignore define V4L2_CTRL_MAX_DIMS
> >> ignore define V4L2_CTRL_WHICH_CUR_VAL
> >> ignore define V4L2_CTRL_WHICH_DEF_VAL
> >> +ignore define V4L2_CTRL_WHICH_REQUEST_VAL
> >> ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS
> >> ignore define V4L2_CID_MAX_CTRLS
> >>
> >
> >
> >
> > Thanks,
> > Mauro
> >
>
> Regards,
>
> Hans
Thanks,
Mauro
^ permalink raw reply [flat|nested] 61+ messages in thread* Re: [PATCHv15 29/35] Documentation: v4l: document request API
2018-07-03 14:08 ` Mauro Carvalho Chehab
@ 2018-07-03 14:22 ` Hans Verkuil
0 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-07-03 14:22 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media, Alexandre Courbot, Hans Verkuil
On 03/07/18 16:08, Mauro Carvalho Chehab wrote:
> Em Tue, 3 Jul 2018 15:02:05 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
>> On 03/07/18 13:50, Mauro Carvalho Chehab wrote:
>>> Em Mon, 4 Jun 2018 13:46:42 +0200
>>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>>
>>>> From: Alexandre Courbot <acourbot@chromium.org>
>>>>
>>>> Document the request API for V4L2 devices, and amend the documentation
>>>> of system calls influenced by it.
>>>
>>> I'm starting reviewing the patch series from this patch, as it defines
>>> how the request API is supposed to work. Some of my comments below may
>>> reflect on code changes, in order for the core (and drivers) to be
>>> compliant with the uAPI specified here.
>>>
>>> So, I prefer to discuss first the contents of this patch, before start
>>> reviewing the remaining patches.
>>>
>>>>
>>>> Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
>>>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>>>> ---
>>>> .../media/uapi/mediactl/media-controller.rst | 1 +
>>>> .../media/uapi/mediactl/media-funcs.rst | 3 +
>>>> .../uapi/mediactl/media-ioc-request-alloc.rst | 71 ++++++
>>>> .../uapi/mediactl/media-request-ioc-queue.rst | 50 ++++
>>>> .../mediactl/media-request-ioc-reinit.rst | 51 ++++
>>>> .../media/uapi/mediactl/request-api.rst | 219 ++++++++++++++++++
>>>> Documentation/media/uapi/v4l/buffer.rst | 18 +-
>>>> .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 28 ++-
>>>> Documentation/media/uapi/v4l/vidioc-qbuf.rst | 11 +
>>>> .../media/videodev2.h.rst.exceptions | 1 +
>>>> 10 files changed, 447 insertions(+), 6 deletions(-)
>>>> create mode 100644 Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>>>> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>>>> create mode 100644 Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>>>> create mode 100644 Documentation/media/uapi/mediactl/request-api.rst
>>>>
>>>> diff --git a/Documentation/media/uapi/mediactl/media-controller.rst b/Documentation/media/uapi/mediactl/media-controller.rst
>>>> index 0eea4f9a07d5..66aff38cd499 100644
>>>> --- a/Documentation/media/uapi/mediactl/media-controller.rst
>>>> +++ b/Documentation/media/uapi/mediactl/media-controller.rst
>>>> @@ -21,6 +21,7 @@ Part IV - Media Controller API
>>>> media-controller-intro
>>>> media-controller-model
>>>> media-types
>>>> + request-api
>>>> media-funcs
>>>> media-header
>>>>
>>>> diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst b/Documentation/media/uapi/mediactl/media-funcs.rst
>>>> index 076856501cdb..f4da9b3e17ec 100644
>>>> --- a/Documentation/media/uapi/mediactl/media-funcs.rst
>>>> +++ b/Documentation/media/uapi/mediactl/media-funcs.rst
>>>> @@ -16,3 +16,6 @@ Function Reference
>>>> media-ioc-enum-entities
>>>> media-ioc-enum-links
>>>> media-ioc-setup-link
>>>> + media-ioc-request-alloc
>>>> + media-request-ioc-queue
>>>> + media-request-ioc-reinit
>>>> diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>>>> new file mode 100644
>>>> index 000000000000..d45a94c9e23c
>>>> --- /dev/null
>>>> +++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
>>>> @@ -0,0 +1,71 @@
>>>> +.. SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +.. _media_ioc_request_alloc:
>>>> +
>>>> +*****************************
>>>> +ioctl MEDIA_IOC_REQUEST_ALLOC
>>>> +*****************************
>>>> +
>>>> +Name
>>>> +====
>>>> +
>>>> +MEDIA_IOC_REQUEST_ALLOC - Allocate a request
>>>> +
>>>> +
>>>> +Synopsis
>>>> +========
>>>> +
>>>> +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_ALLOC, struct media_request_alloc *argp )
>>>> + :name: MEDIA_IOC_REQUEST_ALLOC
>>>> +
>>>> +
>>>> +Arguments
>>>> +=========
>>>> +
>>>> +``fd``
>>>> + File descriptor returned by :ref:`open() <media-func-open>`.
>>>> +
>>>> +``argp``
>>>> +
>>>> +
>>>> +Description
>>>> +===========
>>>> +
>>>> +If the media device supports :ref:`requests <media-request-api>`, then
>>>> +this ioctl can be used to allocate a request.
>>>
>>> Perhaps we should mention that otherwise it would set errno to ENOTTY.
>>
>> Will add.
>>
>>>
>>>> A request is accessed through
>>>> +a file descriptor that is returned in struct :c:type:`media_request_alloc`.
>>>> +
>>>> +If the request was successfully allocated, then the request file descriptor
>>>> +can be passed to :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>`,
>>>> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
>>>> +:ref:`ioctl VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and
>>>> +:ref:`ioctl VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
>>>> +
>>>> +In addition, the request can be queued by calling
>>>> +:ref:`MEDIA_REQUEST_IOC_QUEUE` and re-initialized by calling
>>>> +:ref:`MEDIA_REQUEST_IOC_REINIT`.
>>>> +
>>>> +Finally, the file descriptor can be polled to wait for the request to
>>>> +complete.
>>>> +
>>>> +To free the request the file descriptor has to be closed.
>>>
>>> Hmm... I don't think this is clear enough. After reading this paragraph,
>>> I came back to patch 1, in order to see what's the ioctl to be called
>>> to free the request, only to notice that there's none.
>>>
>>> So, I guess what you wanted to say, instead, is that:
>>>
>>> "A request will remain allocated until the associated file descriptor is
>>> closed by ::c:func:`close() <req-api-close>` and after the Kernel stops
>>> using the request."
>>
>> That's a lot clearer.
>>
>>>
>>> (see below for a discussion about the close() reference)
>>>
>>>> +
>>>> +.. c:type:: media_request_alloc
>>>> +
>>>> +.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
>>>> +
>>>> +.. flat-table:: struct media_request_alloc
>>>> + :header-rows: 0
>>>> + :stub-columns: 0
>>>> + :widths: 1 1 2
>>>> +
>>>> + * - __s32
>>>> + - ``fd``
>>>> + - The file descriptor of the request.
>>>> +
>>>> +Return Value
>>>> +============
>>>> +
>>>> +On success 0 is returned, on error -1 and the ``errno`` variable is set
>>>> +appropriately. The generic error codes are described at the
>>>> +:ref:`Generic Error Codes <gen-errors>` chapter.
>>>> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>>>> new file mode 100644
>>>> index 000000000000..d3bac7b70422
>>>> --- /dev/null
>>>> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
>>>> @@ -0,0 +1,50 @@
>>>> +.. SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +.. _media_request_ioc_queue:
>>>> +
>>>> +*****************************
>>>> +ioctl MEDIA_REQUEST_IOC_QUEUE
>>>> +*****************************
>>>> +
>>>> +Name
>>>> +====
>>>> +
>>>> +MEDIA_REQUEST_IOC_QUEUE - Queue a request
>>>> +
>>>> +
>>>> +Synopsis
>>>> +========
>>>> +
>>>> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_QUEUE )
>>>> + :name: MEDIA_REQUEST_IOC_QUEUE
>>>> +
>>>> +
>>>> +Arguments
>>>> +=========
>>>> +
>>>> +``request_fd``
>>>> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
>>>> +
>>>> +
>>>> +Description
>>>> +===========
>>>> +
>>>> +If the media device supports :ref:`requests <media-request-api>`, then
>>>> +this request ioctl can be used to queue a previously allocated request.
>>>> +
>>>> +If the request was successfully queued, then the file descriptor can be
>>>> +polled to wait for the request to complete.
>>>> +
>>>> +If the request was already queued before, then '`EBUSY'` is returned.
>>>> +Other errors can be returned if the contents of the request contained
>>>> +invalid or inconsistent data.
>>>
>>> Are there any "permanent" return error code that would require the
>>> caller to close the file descriptor?
>>>
>>> I mean, if EBUSY is returned, userspace could just wait for a past
>>> QBUF to be handled and call it again, but what happens if some other
>>> error happens (like -ENOMEM)? Would the entire request descriptor be
>>> trashed or just the current QBUF attempt will fail?
>
> Just to be clear about that: I expect that the questions I asked are
> somehow answered inside the documentation, in order to
> be a guideline for both Kernel and userspace app developers. So, once
> we reach an agreement about the expected behavior, please add it
> to the documentation patch.
Of course.
>
>> Any error means that the application did something wrong and you would
>> just exit the application. Errors mean that either the content of the
>> request couldn't be validated, or (with EBUSY) the request is already in
>> use (clearly an application bug in that case).
>>
>> In the case of codecs there is not much you can do wrong,
>
> So, IMHO, it makes sense to document what errors could be generated
> with the current implementation, as the above description sounded
> too vague to me. Is it just EINVAL errors?
In principle it can be anything since drivers can check and return errors
as well. In the case of codecs it is basically the same errors that
S_EXT_CTRLS and QBUF can return, since that's what happens internally.
It's validating the request before queueing it, so you can get all sorts
of errors.
>
>> but things
>> get a lot more complicated when you want to use this with complex
>> camera pipelines. I expect that we need a new request ioctl in the
>> future that can return useful error information about what was wrong in
>> the request.
>>
>> That is out-of-scope for the codec support, though.
>
> Yes.
>
>>
>>>
>>>> +
>>>> +Return Value
>>>> +============
>>>> +
>>>> +On success 0 is returned, on error -1 and the ``errno`` variable is set
>>>> +appropriately. The generic error codes are described at the
>>>> +:ref:`Generic Error Codes <gen-errors>` chapter.
>>>> +
>>>> +EBUSY
>>>> + The request was already queued.
>>>> diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>>>> new file mode 100644
>>>> index 000000000000..7cbb7eb5d73e
>>>> --- /dev/null
>>>> +++ b/Documentation/media/uapi/mediactl/media-request-ioc-reinit.rst
>>>> @@ -0,0 +1,51 @@
>>>> +.. SPDX-License-Identifier: GPL-2.0-only
>>>> +
>>>> +.. _media_request_ioc_reinit:
>>>> +
>>>> +******************************
>>>> +ioctl MEDIA_REQUEST_IOC_REINIT
>>>> +******************************
>>>> +
>>>> +Name
>>>> +====
>>>> +
>>>> +MEDIA_REQUEST_IOC_REINIT - Re-initialize a request
>>>> +
>>>> +
>>>> +Synopsis
>>>> +========
>>>> +
>>>> +.. c:function:: int ioctl( int request_fd, MEDIA_REQUEST_IOC_REINIT )
>>>> + :name: MEDIA_REQUEST_IOC_REINIT
>>>> +
>>>> +
>>>> +Arguments
>>>> +=========
>>>> +
>>>> +``request_fd``
>>>> + File descriptor returned by :ref:`MEDIA_IOC_REQUEST_ALLOC`.
>>>> +
>>>> +Description
>>>> +===========
>>>> +
>>>> +If the media device supports :ref:`requests <media-request-api>`, then
>>>> +this request ioctl can be used to re-initialize a previously allocated
>>>> +request.
>>>> +
>>>> +Re-initializing a request will clear any existing data from the request.
>>>> +This avoids having to close() a completed request and allocate a new
>>>> +request. Instead the completed request can just be re-initialized and
>>>> +it is ready to be used again.
>>>> +
>>>> +A request can only be re-initialized if it either has not been queued
>>>> +yet, or if it was queued and completed.
>>>> +
>>>> +Return Value
>>>> +============
>>>> +
>>>> +On success 0 is returned, on error -1 and the ``errno`` variable is set
>>>> +appropriately. The generic error codes are described at the
>>>> +:ref:`Generic Error Codes <gen-errors>` chapter.
>>>> +
>>>> +EBUSY
>>>> + The request is queued but not yet completed.
>>>
>>> Same question here: are there any "permanent" return error code that would
>>> require the caller to close the file descriptor?
>>
>> Same answer really, any error indicates that the application did something
>> wrong.
>
> I suspect that, in this case, it could be also a Kernel problem (for
> instance, lack of memory). IMHO, it is also worth to mention what errors
> can happen here.
For reinit it should be possible to come up with a precise list of errors.
>
>> Strictly speaking you could retry if you get EBUSY, but you really
>> shouldn't use that and instead poll for the request to be completed.
>
> Yeah, sure, but an application could be smart enough to "survive"
> in case of failures. I can see a lot of scenarios where apps will
> try to keep alive despite any errors, like on industrial cameras.
>
> After watching some speeches in Japan for automotive Linux[1], I can
> even think on some scenarios that can be really critical to be
> error-pruned. For example, imagine that a camera is used by some
> auto-driver system inside a car. Stopping the application can
> cause severe injuries to people.
I would expect apps to stop streaming and restart streaming in case of
an unexpected error. Note that once a request is successfully queued,
it cannot fail: if any errors happen when the driver applies the contents
of the request, then the driver will have to handle that gracefully.
>
> [1] Before someone asks me, no, I'm not aware of any real use cases
> for the request API on auto-pilot car systems. Just doing a
> little of speculation here about possible future usage scenarios.
>
> The thing is that request API may lead into some complex and
> hard to identify issues, on both Kernel and userspace. So, better
> to make sure that the documentation (and implementation) will
> have, as much as possible, a deterministic behavior.
>
>>>
>>>> diff --git a/Documentation/media/uapi/mediactl/request-api.rst b/Documentation/media/uapi/mediactl/request-api.rst
>>>> new file mode 100644
>>>> index 000000000000..4d10f18181a4
>>>> --- /dev/null
>>>> +++ b/Documentation/media/uapi/mediactl/request-api.rst
>>>> @@ -0,0 +1,219 @@
>>>> +.. -*- coding: utf-8; mode: rst -*-
>>>> +
>>>> +.. _media-request-api:
>>>> +
>>>> +Request API
>>>> +===========
>>>> +
>>>> +The Request API has been designed to allow V4L2 to deal with requirements of
>>>> +modern devices (stateless codecs, complex camera pipelines, ...) and APIs
>>>> +(Android Codec v2). One such requirement is the ability for devices belonging to
>>>> +the same pipeline to reconfigure and collaborate closely on a per-frame basis.
>>>> +Another is efficient support of stateless codecs, which need per-frame controls
>>>> +to be set synchronously in order to be used efficiently.
>>>> +
>>>> +Supporting these features without the Request API is not always possible and if
>>>> +it is, it is terribly inefficient: user-space would have to flush all activity
>>>> +on the media pipeline, reconfigure it for the next frame, queue the buffers to
>>>> +be processed with that configuration, and wait until they are all available for
>>>> +dequeuing before considering the next frame. This defeats the purpose of having
>>>> +buffer queues since in practice only one buffer would be queued at a time.
>>>> +
>>>> +The Request API allows a specific configuration of the pipeline (media
>>>> +controller topology + controls for each media entity) to be associated with
>>>> +specific buffers. The parameters are applied by each participating device as
>>>> +buffers associated to a request flow in. This allows user-space to schedule
>>>> +several tasks ("requests") with different parameters in advance, knowing that
>>>> +the parameters will be applied when needed to get the expected result. Control
>>>> +values at the time of request completion are also available for reading.
>>>> +
>>>> +Usage
>>>> +=====
>>>> +
>>>> +The Request API is used on top of standard media controller and V4L2 calls,
>>>> +which are augmented with an extra ``request_fd`` parameter. Requests themselves
>>>> +are allocated from the supporting media controller node.
>>>> +
>>>> +Request Allocation
>>>> +------------------
>>>> +
>>>> +User-space allocates requests using :ref:`MEDIA_IOC_REQUEST_ALLOC`
>>>> +for the media device node. This returns a file descriptor representing the
>>>> +request. Typically, several such requests will be allocated.
>>>> +
>>>> +Request Preparation
>>>> +-------------------
>>>> +
>>>> +Standard V4L2 ioctls can then receive a request file descriptor to express the
>>>> +fact that the ioctl is part of said request, and is not to be applied
>>>> +immediately. See :ref:`MEDIA_IOC_REQUEST_ALLOC` for a list of ioctls that
>>>> +support this. Controls set with a ``request_fd`` parameter are stored instead
>>>> +of being immediately applied, and buffers queued to a request do not enter the
>>>> +regular buffer queue until the request itself is queued.
>>>> +
>>>> +Request Submission
>>>> +------------------
>>>> +
>>>> +Once the parameters and buffers of the request are specified, it can be
>>>> +queued by calling :ref:`MEDIA_REQUEST_IOC_QUEUE` on the request FD.
>>>> +This will make the buffers associated to the request available to their driver,
>>>> +which can then apply the associated controls as buffers are processed. A queued
>>>> +request cannot be modified anymore.
>>>
>>> What happens if one closes a file descriptor while a request is pending?
>>> Would the close() ops wait until the request to finish? If so, what happens
>>> when FD is opened in non-blocking mode?
>>
>> It doesn't block, it just decrements the internal refcount of the request. The
>> request won't be freed until the request completes. Of course, once it is closed
>> the application has no way to access the request anymore.
>
> Ok. Please document it at the close() documentation for the request API.
>
>>
>>>
>>>> +
>>>> +If the request contains parameters for multiple entities, individual drivers may
>>>> +synchronize so the requested pipeline's topology is applied before the buffers
>>>> +are processed. Media controller drivers do a best effort implementation since
>>>> +perfect atomicity may not be possible due to hardware limitations.
>>>> +
>>>> +Once buffers are added to a request for the first time it is no longer possible
>>>
>>> Nitpick: missing comma:
>>> Once buffers are added to a request for the first time,
>>
>> ack
>>
>>>
>>>> +to queue non-request buffers of that buffer type until
>>>> +:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called.
>>>
>>> Not even after closing the request fd? My past understanding is that
>>> closing a file descriptor would be enough to free the request.
>>
>> No, once you start using requests, you have to keep using it. As mentioned
>> above, closing the request fd doesn't free the request, unless the request
>> was already completed.
>>
>> The problem is that things become very complex when you start mixing requests
>> and VIDIOC_QBUF. For now (and likely forever) this is prohibited.
>>
>>>
>>> If that's not the case, and STREAMOFF is indeed required to free the
>>> buffer, please document it also at MEDIA_IOC_REQUEST_ALLOC.
>>
>> This has nothing to do with freeing buffers. It is about whether the
>> streaming mode: are you using QBUF or requests? Once you start using
>> requests while streaming, you have to keep doing that until you stop
>> streaming.
>
>
> I might have missed it, but I don't remember any part of the docs
> saying that it is forbidden to mix request/non-request QBUFs.
It was a late change, so it probably isn't as well documented as it should.
>
> Ok, after re-reading what's written there, one might understand that,
> but, I had a different understanding the first time I read, as
> "a request" made me thing that a buffer number would be sticked
> forever to a certain request_id.
>
> After your comments, I guess that what it is intended to be said
> is, instead, something similar to:
>
> "It is forbidden to have some VIDIOC_QBUF calls with the request_id
> filled with other VIDIOC_QBUF calls without it.
>
> So, if the first successful call to a VIDIOC_QBUF after start
> streaming has request_id filled, all other calls should also
> have it filed, otherwise -EBUSY will be returned."
>
> For coherency, I would also add (and enforce):
>
> "The reverse is also true: if the first successful call after start
> streaming to a VIDIOC_QBUF without request_id fields is used, any
> attempt to queue a buffer with it filled will return -EBUSY."
>
> As probably the behavior of having the first "n" buffers without
> request, with controls being changed in runtime, followed by all
> others with request could produce unexpected behavior, specially
> if buffers are delivered out of order.
I think that makes a lot of sense. I don't do that now (e.g. you can
start with VIDIOC_QBUF, then switch to using requests later), but
that is hard to explain, and really, why would you want to do that?
I'll make that change.
>
>>>
>>>> +
>>>> +Controls can still be set without a request and are applied immediately,
>>>> +regardless of whether a request is in use or not.
>>>
>>>> Setting the same control
>>>> +through a request and directly can lead to undefined behavior!
>>>
>>> I would place it as a caution note:
>>>
>>> .. caution::
>>>
>>> Setting the same control through a request and directly can
>>> lead to undefined behavior!
>>
>> Right.
>>
>>>
>>>> +
>>>> +User-space can ``poll()`` a request FD in order to wait until the request
>>>
>>> Hmm... ``poll`` is probably not what you want here. Same applies to ``close``,
>>> ``open``, etc. We actually define syscalls per subsystem (v4l2, dvb, ...), as
>>> the syscall behavior is somewhat dependent on how the dev ops are implemented.
>>> IMO, the best would be to add a page for poll() and close() for request API,
>>> explaining their differences with regards to the "common" behavior.
>>>
>>> For example, Documentation/media/uapi/cec/cec-func-close.rst references it
>>> with:
>>> ::c:func:`close() <cec-close>`
>>>
>>
>> OK.
>>
>>>> +completes. A request is considered complete once all its associated buffers are
>>>> +available for dequeuing and all the associated controls have been updated with
>>>> +the values at the time of completion. Note that user-space does not need to wait
>>>> +for the request to complete to dequeue its buffers: buffers that are available
>>>> +halfway through a request can be dequeued independently of the request's state.
>>>> +
>>>> +A completed request contains the state of the request at the time of the
>>>> +request completion. User-space can query that state by calling
>>>> +:ref:`ioctl VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` with the request FD.
>>>
>>> What happens if one calls VIDIOC_G_EXT_CTRLS after DQBUF but before
>>> the complete request to be handled? Undefined behavior or will it
>>> reflect the control changes applied to that dequeued buffer?
>>
>> Good point. It is basically undefined: it can either return the control as
>> was set by the application for this request, but if the driver also updates
>> this control before the request is completed it might return that new value
>> instead.
>>
>> I think it might be best that EBUSY is returned while the request is in
>> flight (queued but not yet completed).
>
> Makes sense to me. Please document it (and be sure implementation will
> follow the docs).
>
>>
>>>
>>>> +
>>>> +Recycling and Destruction
>>>> +-------------------------
>>>> +
>>>> +Finally, completed request can either be discarded or be reused. Calling
>>>> +``close()`` on a request FD will make that FD unusable, freeing the request if
>>>> +it is not in use by the kernel. That is, if the request is queued and then the
>>>> +FD is closed, then it won't be freed until the driver completed the request.
>>>> +
>>>> +The :ref:`MEDIA_REQUEST_IOC_REINIT` will clear a request's state and make it
>>>> +available again. No state is retained by this operation: the request is as
>>>> +if it had just been allocated.
>>>> +
>>>> +Example for a Memory-to-Memory Device
>>>> +-------------------------------------
>>>> +
>>>> +M2M devices are single-node V4L2 devices providing one OUTPUT queue (for
>>>> +user-space to provide input buffers) and one CAPTURE queue (to retrieve
>>>> +processed data). These devices are commonly used for frame processors or
>>>> +stateless codecs.
>>>
>>> Hmm... describing what is a M2M device here doesn't sound right. It
>>> should be described elsewhere, and a xref to such description should
>>> be added here instead, pointing to some specific chapter at the V4L2
>>> docs for M2M.
>>
>> Right.
>>
>>> That reminds that I have a series of patches adding a glossary that
>>> needs rework. I'll see if I can respin it this week, in order to allow
>>> adding M2M to the glossary too.
>>>
>>>> +
>>>> +In this use-case, the request API can be used to associate specific controls to
>>>> +be applied by the driver for the OUTPUT buffer, allowing user-space
>>>> +to queue many such buffers in advance. It can also take advantage of requests'
>>>> +ability to capture the state of controls when the request completes to read back
>>>> +information that may be subject to change.
>>>> +
>>>> +Put into code, after obtaining a request, user-space can assign controls and one
>>>> +OUTPUT buffer to it:
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + struct v4l2_buffer buf;
>>>> + struct v4l2_ext_controls ctrls;
>>>> + struct media_request_alloc alloc = { 0 };
>>>> + int req_fd;
>>>> + ...
>>>> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
>>>> + req_fd = alloc.fd;
>>>> + ...
>>>> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
>>>> + ctrls.request_fd = req_fd;
>>>> + ioctl(codec_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
>>>> + ...
>>>> + buf.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
>>>> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
>>>> + buf.request_fd = req_fd;
>>>> + ioctl(codec_fd, VIDIOC_QBUF, &buf);
>>>
>>> Hmm... I understand that you want an example to be as simple and as
>>> shorter as possible, but I don't like adding a code example without
>>> proper error handling code, as one might just copy-and-paste it
>>> without adding the required error handling.
>>>
>>> I would do, at least, something like:
>>>
>>> assert (!ioctl(...));
>>>
>>> in order to make clearer that errors should be checked, and, on worse
>>> case scenario of a cut-and-paste code, the app will abort if errors
>>> are found, printing some errors.
>>
>> I can add something along these lines.
>>
>>>
>>>> +
>>>> +Note that there is typically no need to use the Request API for CAPTURE buffers
>>>> +since there are no per-frame settings to report there.
>>>> +
>>>> +Once the request is fully prepared, it can be queued to the driver:
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
>>>
>>> Same here. I would code this as:
>>>
>>> .. code-block:: c
>>>
>>> rc = ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
>>> if (rc)
>>> perror("MEDIA_REQUEST_IOC_QUEUE");
>>>
>>> in order to give a hint about a more realistic error handling code.
>>>
>>> (same comments about error handling apply to other examples below)
>>>
>>>> +
>>>> +User-space can then either wait for the request to complete by calling poll() on
>>>> +its file descriptor, or start dequeuing CAPTURE buffers. Most likely, it will
>>>> +want to get CAPTURE buffers as soon as possible and this can be done using a
>>>> +regular DQBUF:
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + struct v4l2_buffer buf;
>>>> +
>>>> + memset(&buf, 0, sizeof(buf));
>>>> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>>> + ioctl(codec_fd, VIDIOC_DQBUF, &buf);
>>>> +
>>>> +Note that this example assumes for simplicity that for every OUTPUT buffer
>>>> +there will be one CAPTURE buffer, but this does not have to be the case.
>>>> +
>>>> +We can then, after ensuring that the request is completed via polling the
>>>> +request FD, query control values at the time of its completion via an
>>>> +annotated call to G_EXT_CTRLS. This is particularly useful for volatile controls
>>>> +for which we want to query values as soon as the capture buffer is produced.
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + struct pollfd pfd = { .events = POLLPRI, .fd = request_fd };
>>>> + poll(&pfd, 1, -1);
>>>> + ...
>>>> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
>>>> + ctrls.request_fd = req_fd;
>>>> + ioctl(codec_fd, VIDIOC_G_EXT_CTRLS, &ctrls);
>>>> +
>>>> +Once we don't need the request anymore, we can either recycle it for reuse with
>>>> +:ref:`MEDIA_REQUEST_IOC_REINIT`...
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + ioctl(req_fd, MEDIA_REQUEST_IOC_REINIT);
>>>> +
>>>> +... or close its file descriptor to completely dispose of it.
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + close(req_fd);
>>>> +
>>>> +Example for a Simple Capture Device
>>>> +-----------------------------------
>>>> +
>>>> +With a simple capture device, requests can be used to specify controls to apply
>>>> +for a given CAPTURE buffer.
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + struct v4l2_buffer buf;
>>>> + struct v4l2_ext_controls ctrls;
>>>> + struct media_request_alloc alloc = { 0 };
>>>> + int req_fd;
>>>> + ...
>>>> + ioctl(media_fd, MEDIA_IOC_REQUEST_ALLOC, &alloc);
>>>> + req_fd = alloc.fd;
>>>> + ...
>>>> + ctrls.which = V4L2_CTRL_WHICH_REQUEST_VAL;
>>>> + ctrls.request_fd = req_fd;
>>>> + ioctl(camera_fd, VIDIOC_S_EXT_CTRLS, &ctrls);
>>>> + ...
>>>> + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>>> + buf.flags |= V4L2_BUF_FLAG_REQUEST_FD;
>>>> + buf.request_fd = req_fd;
>>>> + ioctl(camera_fd, VIDIOC_QBUF, &buf);
>>>> +
>>>> +Once the request is fully prepared, it can be queued to the driver:
>>>> +
>>>> +.. code-block:: c
>>>> +
>>>> + ioctl(req_fd, MEDIA_REQUEST_IOC_QUEUE);
>>>> +
>>>> +User-space can then dequeue buffers, wait for the request completion, query
>>>> +controls and recycle the request as in the M2M example above.
>>>> diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst
>>>> index e2c85ddc990b..8059fc0ed520 100644
>>>> --- a/Documentation/media/uapi/v4l/buffer.rst
>>>> +++ b/Documentation/media/uapi/v4l/buffer.rst
>>>> @@ -306,10 +306,12 @@ struct v4l2_buffer
>>>> - A place holder for future extensions. Drivers and applications
>>>> must set this to 0.
>>>> * - __u32
>>>> - - ``reserved``
>>>> + - ``request_fd``
>>>> -
>>>> - - A place holder for future extensions. Drivers and applications
>>>> - must set this to 0.
>>>> + - The file descriptor of the request to queue the buffer to. If specified
>>>> + and flag ``V4L2_BUF_FLAG_REQUEST_FD`` is set, then the buffer will be
>>>> + queued to that request. This is set by the user when calling
>>>> + :ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls.
>>>
>>> What happens if userspace uses an invalid request_fd is filled here?
>>
>> -EPERM if the driver doesn't support requests at all.
>> -ENOENT if the driver supports requests, but the fd doesn't map to a valid request.
>
> Ok. Please document it, as it can help app developers to debug issues
> there.
>
>>
>>>
>>>>
>>>>
>>>>
>>>> @@ -514,6 +516,11 @@ Buffer Flags
>>>> streaming may continue as normal and the buffer may be reused
>>>> normally. Drivers set this flag when the ``VIDIOC_DQBUF`` ioctl is
>>>> called.
>>>> + * .. _`V4L2-BUF-FLAG-IN-REQUEST`:
>>>> +
>>>> + - ``V4L2_BUF_FLAG_IN_REQUEST``
>>>> + - 0x00000080
>>>> + - This buffer is part of a request that hasn't been queued yet.
>>>> * .. _`V4L2-BUF-FLAG-KEYFRAME`:
>>>>
>>>> - ``V4L2_BUF_FLAG_KEYFRAME``
>>>> @@ -589,6 +596,11 @@ Buffer Flags
>>>> the format. Any Any subsequent call to the
>>>> :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
>>>> but return an ``EPIPE`` error code.
>>>> + * .. _`V4L2-BUF-FLAG-REQUEST-FD`:
>>>> +
>>>> + - ``V4L2_BUF_FLAG_REQUEST_FD``
>>>> + - 0x00800000
>>>> + - The ``request_fd`` field contains a valid file descriptor.
>>>> * .. _`V4L2-BUF-FLAG-TIMESTAMP-MASK`:
>>>>
>>>> - ``V4L2_BUF_FLAG_TIMESTAMP_MASK``
>>>> diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
>>>> index 2011c2b2ee67..3d0e861ad4a1 100644
>>>> --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
>>>> +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
>>>> @@ -95,6 +95,22 @@ appropriate. In the first case the new value is set in struct
>>>> is inappropriate (e.g. the given menu index is not supported by the menu
>>>> control), then this will also result in an ``EINVAL`` error code error.
>>>>
>>>> +If ``request_fd`` is set to a not-yet-queued :ref:`request <media-request-api>`
>>>> +file descriptor and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``,
>>>> +then the controls are not applied immediately when calling
>>>> +:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, but instead are applied by
>>>> +the driver for the buffer associated with the same request.
>>>
>>> Same note here: what happens if request_fd is invalid?
>>
>> Same answer.
>
> Ok. Please document.
>
>>
>>>
>>>> +
>>>> +An attempt to call :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` for a
>>>> +request that has already been queued will result in an ``EBUSY`` error.
>>>> +
>>>> +If ``request_fd`` is specified and ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``
>>>> +during a call to :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, then the
>>>> +returned values will be the values currently set for the request (or the
>>>> +hardware value if none is set) if the request has not yet completed, or the
>>>> +values of the controls at the time of request completion if it has already
>>>> +completed.
>>>> +
>>>> The driver will only set/get these controls if all control values are
>>>> correct. This prevents the situation where only some of the controls
>>>> were set/get. Only low-level errors (e. g. a failed i2c command) can
>>>> @@ -209,8 +225,10 @@ still cause this situation.
>>>> - ``which``
>>>> - Which value of the control to get/set/try.
>>>> ``V4L2_CTRL_WHICH_CUR_VAL`` will return the current value of the
>>>> - control and ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
>>>> - value of the control.
>>>> + control, ``V4L2_CTRL_WHICH_DEF_VAL`` will return the default
>>>> + value of the control and ``V4L2_CTRL_WHICH_REQUEST_VAL`` indicates that
>>>> + these controls have to be retrieved from a request or tried/set for
>>>> + a request.
>>>
>>> I didn't like the text above, as it assumes that all calls will contain
>>> a request_id. You need either to rewrite it or add two paragraphs, one
>>> describing the "normal" non-req-api case, and the other one for "req-api"
>>> one.
>>
>> OK
>>
>>>
>>>>
>>>> .. note::
>>>>
>>>> @@ -272,8 +290,12 @@ still cause this situation.
>>>> then you can call :ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` to try to discover the
>>>> actual control that failed the validation step. Unfortunately,
>>>> there is no ``TRY`` equivalent for :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`.
>>>> + * - __s32
>>>> + - ``request_fd``
>>>> + File descriptor of the request to be used by this operation. Only
>>>> + valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``.
>>>> * - __u32
>>>> - - ``reserved``\ [2]
>>>> + - ``reserved``\ [1]
>>>> - Reserved for future extensions.
>>>>
>>>> Drivers and applications must set the array to zero.
>>>> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>>>> index 9e448a4aa3aa..7ac99be1dd48 100644
>>>> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>>>> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>>>> @@ -98,6 +98,17 @@ dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
>>>> :ref:`VIDIOC_REQBUFS` ioctl is called, or until the
>>>> device is closed.
>>>>
>>>> +The ``request_fd`` field can be used when queuing to specify the file
>>>> +descriptor of a :ref:`request <media-request-api>`, if requests are
>>>> +in use. Setting it means that the buffer will not be passed to the driver
>>>> +until the request itself is queued. Also, the driver will apply any
>>>> +settings associated with the request for this buffer. This field will
>>>> +be ignored unless the ``V4L2_BUF_FLAG_REQUEST_FD`` flag is set.
>>>
>>> What happens if request_fd is invalid?
>>>
>>>> +
>>>> +For :ref:`memory-to-memory devices <codec>` you can specify the
>>>> +``request_fd`` only for output buffers, not for capture buffers. Attempting
>>>> +to specify this for a capture buffer will result in an ``EINVAL`` error.
>>>> +
>>>> Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled
>>>> (capturing) or displayed (output) buffer from the driver's outgoing
>>>> queue. They just set the ``type``, ``memory`` and ``reserved`` fields of
>>>> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
>>>> index a5cb0a8686ac..5a5a1c772053 100644
>>>> --- a/Documentation/media/videodev2.h.rst.exceptions
>>>> +++ b/Documentation/media/videodev2.h.rst.exceptions
>>>> @@ -514,6 +514,7 @@ ignore define V4L2_CTRL_DRIVER_PRIV
>>>> ignore define V4L2_CTRL_MAX_DIMS
>>>> ignore define V4L2_CTRL_WHICH_CUR_VAL
>>>> ignore define V4L2_CTRL_WHICH_DEF_VAL
>>>> +ignore define V4L2_CTRL_WHICH_REQUEST_VAL
>>>> ignore define V4L2_OUT_CAP_CUSTOM_TIMINGS
>>>> ignore
Regards,
Hans
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 30/35] vim2m: add media device
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (28 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 29/35] Documentation: v4l: document request API Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 31/35] vim2m: use workqueue Hans Verkuil
` (4 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Request API requires a media node. Add one to the vim2m driver so we can
use requests with it.
This probably needs a bit more work to correctly represent m2m
hardware in the media topology.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/platform/vim2m.c | 42 ++++++++++++++++++++++++++++++----
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index 065483e62db4..9be4da3b8577 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -140,6 +140,10 @@ static struct vim2m_fmt *find_format(struct v4l2_format *f)
struct vim2m_dev {
struct v4l2_device v4l2_dev;
struct video_device vfd;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device mdev;
+ struct media_pad pad[2];
+#endif
atomic_t num_inst;
struct mutex dev_mutex;
@@ -1000,11 +1004,6 @@ static int vim2m_probe(struct platform_device *pdev)
return -ENOMEM;
spin_lock_init(&dev->irqlock);
-
- ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
- if (ret)
- return ret;
-
atomic_set(&dev->num_inst, 0);
mutex_init(&dev->dev_mutex);
@@ -1013,6 +1012,22 @@ static int vim2m_probe(struct platform_device *pdev)
vfd->lock = &dev->dev_mutex;
vfd->v4l2_dev = &dev->v4l2_dev;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->mdev.dev = &pdev->dev;
+ strlcpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model));
+ media_device_init(&dev->mdev);
+ dev->v4l2_dev.mdev = &dev->mdev;
+ dev->pad[0].flags = MEDIA_PAD_FL_SINK;
+ dev->pad[1].flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&vfd->entity, 2, dev->pad);
+ if (ret)
+ return ret;
+#endif
+
+ ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev);
+ if (ret)
+ goto unreg_media;
+
ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
if (ret) {
v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
@@ -1034,6 +1049,13 @@ static int vim2m_probe(struct platform_device *pdev)
goto err_m2m;
}
+#ifdef CONFIG_MEDIA_CONTROLLER
+ /* Register the media device node */
+ ret = media_device_register(&dev->mdev);
+ if (ret)
+ goto err_m2m;
+#endif
+
return 0;
err_m2m:
@@ -1041,6 +1063,10 @@ static int vim2m_probe(struct platform_device *pdev)
video_unregister_device(&dev->vfd);
unreg_dev:
v4l2_device_unregister(&dev->v4l2_dev);
+unreg_media:
+#ifdef CONFIG_MEDIA_CONTROLLER
+ media_device_unregister(&dev->mdev);
+#endif
return ret;
}
@@ -1050,6 +1076,12 @@ static int vim2m_remove(struct platform_device *pdev)
struct vim2m_dev *dev = platform_get_drvdata(pdev);
v4l2_info(&dev->v4l2_dev, "Removing " MEM2MEM_NAME);
+
+#ifdef CONFIG_MEDIA_CONTROLLER
+ media_device_unregister(&dev->mdev);
+ media_device_cleanup(&dev->mdev);
+#endif
+
v4l2_m2m_release(dev->m2m_dev);
del_timer_sync(&dev->timer);
video_unregister_device(&dev->vfd);
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 31/35] vim2m: use workqueue
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (29 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 30/35] vim2m: add media device Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 32/35] vim2m: support requests Hans Verkuil
` (3 subsequent siblings)
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
v4l2_ctrl uses mutexes, so we can't setup a ctrl_handler in
interrupt context. Switch to a workqueue instead and drop the timer.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/platform/vim2m.c | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index 9be4da3b8577..5cb077294734 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -3,7 +3,8 @@
*
* This is a virtual device driver for testing mem-to-mem videobuf framework.
* It simulates a device that uses memory buffers for both source and
- * destination, processes the data and issues an "irq" (simulated by a timer).
+ * destination, processes the data and issues an "irq" (simulated by a delayed
+ * workqueue).
* The device is capable of multi-instance, multi-buffer-per-transaction
* operation (via the mem2mem framework).
*
@@ -19,7 +20,6 @@
#include <linux/module.h>
#include <linux/delay.h>
#include <linux/fs.h>
-#include <linux/timer.h>
#include <linux/sched.h>
#include <linux/slab.h>
@@ -149,7 +149,7 @@ struct vim2m_dev {
struct mutex dev_mutex;
spinlock_t irqlock;
- struct timer_list timer;
+ struct delayed_work work_run;
struct v4l2_m2m_dev *m2m_dev;
};
@@ -337,12 +337,6 @@ static int device_process(struct vim2m_ctx *ctx,
return 0;
}
-static void schedule_irq(struct vim2m_dev *dev, int msec_timeout)
-{
- dprintk(dev, "Scheduling a simulated irq\n");
- mod_timer(&dev->timer, jiffies + msecs_to_jiffies(msec_timeout));
-}
-
/*
* mem2mem callbacks
*/
@@ -388,13 +382,14 @@ static void device_run(void *priv)
device_process(ctx, src_buf, dst_buf);
- /* Run a timer, which simulates a hardware irq */
- schedule_irq(dev, ctx->transtime);
+ /* Run delayed work, which simulates a hardware irq */
+ schedule_delayed_work(&dev->work_run, msecs_to_jiffies(ctx->transtime));
}
-static void device_isr(struct timer_list *t)
+static void device_work(struct work_struct *w)
{
- struct vim2m_dev *vim2m_dev = from_timer(vim2m_dev, t, timer);
+ struct vim2m_dev *vim2m_dev =
+ container_of(w, struct vim2m_dev, work_run.work);
struct vim2m_ctx *curr_ctx;
struct vb2_v4l2_buffer *src_vb, *dst_vb;
unsigned long flags;
@@ -806,6 +801,7 @@ static void vim2m_stop_streaming(struct vb2_queue *q)
struct vb2_v4l2_buffer *vbuf;
unsigned long flags;
+ flush_scheduled_work();
for (;;) {
if (V4L2_TYPE_IS_OUTPUT(q->type))
vbuf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
@@ -1011,6 +1007,7 @@ static int vim2m_probe(struct platform_device *pdev)
vfd = &dev->vfd;
vfd->lock = &dev->dev_mutex;
vfd->v4l2_dev = &dev->v4l2_dev;
+ INIT_DELAYED_WORK(&dev->work_run, device_work);
#ifdef CONFIG_MEDIA_CONTROLLER
dev->mdev.dev = &pdev->dev;
@@ -1039,7 +1036,6 @@ static int vim2m_probe(struct platform_device *pdev)
v4l2_info(&dev->v4l2_dev,
"Device registered as /dev/video%d\n", vfd->num);
- timer_setup(&dev->timer, device_isr, 0);
platform_set_drvdata(pdev, dev);
dev->m2m_dev = v4l2_m2m_init(&m2m_ops);
@@ -1083,7 +1079,6 @@ static int vim2m_remove(struct platform_device *pdev)
#endif
v4l2_m2m_release(dev->m2m_dev);
- del_timer_sync(&dev->timer);
video_unregister_device(&dev->vfd);
v4l2_device_unregister(&dev->v4l2_dev);
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 32/35] vim2m: support requests
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (30 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 31/35] vim2m: use workqueue Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 17:15 ` Ezequiel Garcia
2018-06-04 11:46 ` [PATCHv15 33/35] vivid: add mc Hans Verkuil
` (2 subsequent siblings)
34 siblings, 1 reply; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add support for requests to vim2m.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/platform/vim2m.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index 5cb077294734..1efc8033320f 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -380,8 +380,18 @@ static void device_run(void *priv)
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+ /* Apply request controls if needed */
+ if (src_buf->vb2_buf.req_obj.req)
+ v4l2_ctrl_request_setup(src_buf->vb2_buf.req_obj.req,
+ &ctx->hdl);
+
device_process(ctx, src_buf, dst_buf);
+ /* Complete request controls if needed */
+ if (src_buf->vb2_buf.req_obj.req)
+ v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req,
+ &ctx->hdl);
+
/* Run delayed work, which simulates a hardware irq */
schedule_delayed_work(&dev->work_run, msecs_to_jiffies(ctx->transtime));
}
@@ -809,12 +819,21 @@ static void vim2m_stop_streaming(struct vb2_queue *q)
vbuf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
if (vbuf == NULL)
return;
+ v4l2_ctrl_request_complete(vbuf->vb2_buf.req_obj.req,
+ &ctx->hdl);
spin_lock_irqsave(&ctx->dev->irqlock, flags);
v4l2_m2m_buf_done(vbuf, VB2_BUF_STATE_ERROR);
spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
}
}
+static void vim2m_buf_request_complete(struct vb2_buffer *vb)
+{
+ struct vim2m_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+
+ v4l2_ctrl_request_complete(vb->req_obj.req, &ctx->hdl);
+}
+
static const struct vb2_ops vim2m_qops = {
.queue_setup = vim2m_queue_setup,
.buf_prepare = vim2m_buf_prepare,
@@ -823,6 +842,7 @@ static const struct vb2_ops vim2m_qops = {
.stop_streaming = vim2m_stop_streaming,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
+ .buf_request_complete = vim2m_buf_request_complete,
};
static int queue_init(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_vq)
@@ -989,6 +1009,11 @@ static const struct v4l2_m2m_ops m2m_ops = {
.job_abort = job_abort,
};
+static const struct media_device_ops m2m_media_ops = {
+ .req_validate = vb2_request_validate,
+ .req_queue = vb2_m2m_request_queue,
+};
+
static int vim2m_probe(struct platform_device *pdev)
{
struct vim2m_dev *dev;
@@ -1013,6 +1038,7 @@ static int vim2m_probe(struct platform_device *pdev)
dev->mdev.dev = &pdev->dev;
strlcpy(dev->mdev.model, "vim2m", sizeof(dev->mdev.model));
media_device_init(&dev->mdev);
+ dev->mdev.ops = &m2m_media_ops;
dev->v4l2_dev.mdev = &dev->mdev;
dev->pad[0].flags = MEDIA_PAD_FL_SINK;
dev->pad[1].flags = MEDIA_PAD_FL_SOURCE;
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* Re: [PATCHv15 32/35] vim2m: support requests
2018-06-04 11:46 ` [PATCHv15 32/35] vim2m: support requests Hans Verkuil
@ 2018-06-04 17:15 ` Ezequiel Garcia
0 siblings, 0 replies; 61+ messages in thread
From: Ezequiel Garcia @ 2018-06-04 17:15 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Hans Verkuil
On 4 June 2018 at 08:46, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> Add support for requests to vim2m.
>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> drivers/media/platform/vim2m.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
> index 5cb077294734..1efc8033320f 100644
> --- a/drivers/media/platform/vim2m.c
> +++ b/drivers/media/platform/vim2m.c
> @@ -380,8 +380,18 @@ static void device_run(void *priv)
> src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
>
> + /* Apply request controls if needed */
> + if (src_buf->vb2_buf.req_obj.req)
Nit: it seems we don't need this check?
> + v4l2_ctrl_request_setup(src_buf->vb2_buf.req_obj.req,
> + &ctx->hdl);
> +
> device_process(ctx, src_buf, dst_buf);
>
> + /* Complete request controls if needed */
> + if (src_buf->vb2_buf.req_obj.req)
Ditto.
> + v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req,
> + &ctx->hdl);
> +
> /* Run delayed work, which simulates a hardware irq */
> schedule_delayed_work(&dev->work_run, msecs_to_jiffies(ctx->transtime));
> }
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCHv15 33/35] vivid: add mc
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (31 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 32/35] vim2m: support requests Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 34/35] vivid: add request support Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 35/35] RFC: media-requests: add debugfs node Hans Verkuil
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add support for the media_device to vivid. This is a prerequisite
for request support.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/platform/vivid/vivid-core.c | 61 +++++++++++++++++++++++
drivers/media/platform/vivid/vivid-core.h | 8 +++
2 files changed, 69 insertions(+)
diff --git a/drivers/media/platform/vivid/vivid-core.c b/drivers/media/platform/vivid/vivid-core.c
index 82ec216f2ad8..69386b26d5dd 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -657,6 +657,15 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
dev->inst = inst;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->v4l2_dev.mdev = &dev->mdev;
+
+ /* Initialize media device */
+ strlcpy(dev->mdev.model, VIVID_MODULE_NAME, sizeof(dev->mdev.model));
+ dev->mdev.dev = &pdev->dev;
+ media_device_init(&dev->mdev);
+#endif
+
/* register v4l2_device */
snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name),
"%s-%03d", VIVID_MODULE_NAME, inst);
@@ -1173,6 +1182,13 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
vfd->lock = &dev->mutex;
video_set_drvdata(vfd, dev);
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->vid_cap_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(&vfd->entity, 1, &dev->vid_cap_pad);
+ if (ret)
+ goto unreg_dev;
+#endif
+
#ifdef CONFIG_VIDEO_VIVID_CEC
if (in_type_counter[HDMI]) {
struct cec_adapter *adap;
@@ -1225,6 +1241,13 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
vfd->lock = &dev->mutex;
video_set_drvdata(vfd, dev);
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->vid_out_pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&vfd->entity, 1, &dev->vid_out_pad);
+ if (ret)
+ goto unreg_dev;
+#endif
+
#ifdef CONFIG_VIDEO_VIVID_CEC
for (i = 0; i < dev->num_outputs; i++) {
struct cec_adapter *adap;
@@ -1274,6 +1297,13 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
vfd->tvnorms = tvnorms_cap;
video_set_drvdata(vfd, dev);
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->vbi_cap_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(&vfd->entity, 1, &dev->vbi_cap_pad);
+ if (ret)
+ goto unreg_dev;
+#endif
+
ret = video_register_device(vfd, VFL_TYPE_VBI, vbi_cap_nr[inst]);
if (ret < 0)
goto unreg_dev;
@@ -1299,6 +1329,13 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
vfd->tvnorms = tvnorms_out;
video_set_drvdata(vfd, dev);
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->vbi_out_pad.flags = MEDIA_PAD_FL_SOURCE;
+ ret = media_entity_pads_init(&vfd->entity, 1, &dev->vbi_out_pad);
+ if (ret)
+ goto unreg_dev;
+#endif
+
ret = video_register_device(vfd, VFL_TYPE_VBI, vbi_out_nr[inst]);
if (ret < 0)
goto unreg_dev;
@@ -1322,6 +1359,13 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
vfd->lock = &dev->mutex;
video_set_drvdata(vfd, dev);
+#ifdef CONFIG_MEDIA_CONTROLLER
+ dev->sdr_cap_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(&vfd->entity, 1, &dev->sdr_cap_pad);
+ if (ret)
+ goto unreg_dev;
+#endif
+
ret = video_register_device(vfd, VFL_TYPE_SDR, sdr_cap_nr[inst]);
if (ret < 0)
goto unreg_dev;
@@ -1368,12 +1412,25 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
video_device_node_name(vfd));
}
+#ifdef CONFIG_MEDIA_CONTROLLER
+ /* Register the media device */
+ ret = media_device_register(&dev->mdev);
+ if (ret) {
+ dev_err(dev->mdev.dev,
+ "media device register failed (err=%d)\n", ret);
+ goto unreg_dev;
+ }
+#endif
+
/* Now that everything is fine, let's add it to device list */
vivid_devs[inst] = dev;
return 0;
unreg_dev:
+#ifdef CONFIG_MEDIA_CONTROLLER
+ media_device_unregister(&dev->mdev);
+#endif
video_unregister_device(&dev->radio_tx_dev);
video_unregister_device(&dev->radio_rx_dev);
video_unregister_device(&dev->sdr_cap_dev);
@@ -1444,6 +1501,10 @@ static int vivid_remove(struct platform_device *pdev)
if (!dev)
continue;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ media_device_unregister(&dev->mdev);
+#endif
+
if (dev->has_vid_cap) {
v4l2_info(&dev->v4l2_dev, "unregistering %s\n",
video_device_node_name(&dev->vid_cap_dev));
diff --git a/drivers/media/platform/vivid/vivid-core.h b/drivers/media/platform/vivid/vivid-core.h
index 477c80a4d44c..6ccd1f5c1d91 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -136,6 +136,14 @@ struct vivid_cec_work {
struct vivid_dev {
unsigned inst;
struct v4l2_device v4l2_dev;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device mdev;
+ struct media_pad vid_cap_pad;
+ struct media_pad vid_out_pad;
+ struct media_pad vbi_cap_pad;
+ struct media_pad vbi_out_pad;
+ struct media_pad sdr_cap_pad;
+#endif
struct v4l2_ctrl_handler ctrl_hdl_user_gen;
struct v4l2_ctrl_handler ctrl_hdl_user_vid;
struct v4l2_ctrl_handler ctrl_hdl_user_aud;
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 34/35] vivid: add request support
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (32 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 33/35] vivid: add mc Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
2018-06-04 11:46 ` [PATCHv15 35/35] RFC: media-requests: add debugfs node Hans Verkuil
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Add support for requests to vivid.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/platform/vivid/vivid-core.c | 8 ++++++++
drivers/media/platform/vivid/vivid-kthread-cap.c | 12 ++++++++++++
drivers/media/platform/vivid/vivid-kthread-out.c | 12 ++++++++++++
drivers/media/platform/vivid/vivid-sdr-cap.c | 16 ++++++++++++++++
drivers/media/platform/vivid/vivid-vbi-cap.c | 10 ++++++++++
drivers/media/platform/vivid/vivid-vbi-out.c | 10 ++++++++++
drivers/media/platform/vivid/vivid-vid-cap.c | 10 ++++++++++
drivers/media/platform/vivid/vivid-vid-out.c | 10 ++++++++++
8 files changed, 88 insertions(+)
diff --git a/drivers/media/platform/vivid/vivid-core.c b/drivers/media/platform/vivid/vivid-core.c
index 69386b26d5dd..a84c7e37c22b 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -627,6 +627,13 @@ static void vivid_dev_release(struct v4l2_device *v4l2_dev)
kfree(dev);
}
+#ifdef CONFIG_MEDIA_CONTROLLER
+static const struct media_device_ops vivid_media_ops = {
+ .req_validate = vb2_request_validate,
+ .req_queue = vb2_request_queue,
+};
+#endif
+
static int vivid_create_instance(struct platform_device *pdev, int inst)
{
static const struct v4l2_dv_timings def_dv_timings =
@@ -664,6 +671,7 @@ static int vivid_create_instance(struct platform_device *pdev, int inst)
strlcpy(dev->mdev.model, VIVID_MODULE_NAME, sizeof(dev->mdev.model));
dev->mdev.dev = &pdev->dev;
media_device_init(&dev->mdev);
+ dev->mdev.ops = &vivid_media_ops;
#endif
/* register v4l2_device */
diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c b/drivers/media/platform/vivid/vivid-kthread-cap.c
index 3fdb280c36ca..c192b4b1b9de 100644
--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -703,6 +703,8 @@ static void vivid_thread_vid_cap_tick(struct vivid_dev *dev, int dropped_bufs)
goto update_mv;
if (vid_cap_buf) {
+ v4l2_ctrl_request_setup(vid_cap_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_cap);
/* Fill buffer */
vivid_fillbuff(dev, vid_cap_buf);
dprintk(dev, 1, "filled buffer %d\n",
@@ -713,6 +715,8 @@ static void vivid_thread_vid_cap_tick(struct vivid_dev *dev, int dropped_bufs)
dev->fb_cap.fmt.pixelformat == dev->fmt_cap->fourcc)
vivid_overlay(dev, vid_cap_buf);
+ v4l2_ctrl_request_complete(vid_cap_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_cap);
vb2_buffer_done(&vid_cap_buf->vb.vb2_buf, dev->dqbuf_error ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
dprintk(dev, 2, "vid_cap buffer %d done\n",
@@ -720,10 +724,14 @@ static void vivid_thread_vid_cap_tick(struct vivid_dev *dev, int dropped_bufs)
}
if (vbi_cap_buf) {
+ v4l2_ctrl_request_setup(vbi_cap_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_cap);
if (dev->stream_sliced_vbi_cap)
vivid_sliced_vbi_cap_process(dev, vbi_cap_buf);
else
vivid_raw_vbi_cap_process(dev, vbi_cap_buf);
+ v4l2_ctrl_request_complete(vbi_cap_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_cap);
vb2_buffer_done(&vbi_cap_buf->vb.vb2_buf, dev->dqbuf_error ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
dprintk(dev, 2, "vbi_cap %d done\n",
@@ -891,6 +899,8 @@ void vivid_stop_generating_vid_cap(struct vivid_dev *dev, bool *pstreaming)
buf = list_entry(dev->vid_cap_active.next,
struct vivid_buffer, list);
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_cap);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
dprintk(dev, 2, "vid_cap buffer %d done\n",
buf->vb.vb2_buf.index);
@@ -904,6 +914,8 @@ void vivid_stop_generating_vid_cap(struct vivid_dev *dev, bool *pstreaming)
buf = list_entry(dev->vbi_cap_active.next,
struct vivid_buffer, list);
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_cap);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
dprintk(dev, 2, "vbi_cap buffer %d done\n",
buf->vb.vb2_buf.index);
diff --git a/drivers/media/platform/vivid/vivid-kthread-out.c b/drivers/media/platform/vivid/vivid-kthread-out.c
index 9981e7548019..5a14810eeb69 100644
--- a/drivers/media/platform/vivid/vivid-kthread-out.c
+++ b/drivers/media/platform/vivid/vivid-kthread-out.c
@@ -75,6 +75,10 @@ static void vivid_thread_vid_out_tick(struct vivid_dev *dev)
return;
if (vid_out_buf) {
+ v4l2_ctrl_request_setup(vid_out_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_out);
+ v4l2_ctrl_request_complete(vid_out_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_out);
vid_out_buf->vb.sequence = dev->vid_out_seq_count;
if (dev->field_out == V4L2_FIELD_ALTERNATE) {
/*
@@ -92,6 +96,10 @@ static void vivid_thread_vid_out_tick(struct vivid_dev *dev)
}
if (vbi_out_buf) {
+ v4l2_ctrl_request_setup(vbi_out_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_out);
+ v4l2_ctrl_request_complete(vbi_out_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_out);
if (dev->stream_sliced_vbi_out)
vivid_sliced_vbi_out_process(dev, vbi_out_buf);
@@ -262,6 +270,8 @@ void vivid_stop_generating_vid_out(struct vivid_dev *dev, bool *pstreaming)
buf = list_entry(dev->vid_out_active.next,
struct vivid_buffer, list);
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_out);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
dprintk(dev, 2, "vid_out buffer %d done\n",
buf->vb.vb2_buf.index);
@@ -275,6 +285,8 @@ void vivid_stop_generating_vid_out(struct vivid_dev *dev, bool *pstreaming)
buf = list_entry(dev->vbi_out_active.next,
struct vivid_buffer, list);
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_out);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
dprintk(dev, 2, "vbi_out buffer %d done\n",
buf->vb.vb2_buf.index);
diff --git a/drivers/media/platform/vivid/vivid-sdr-cap.c b/drivers/media/platform/vivid/vivid-sdr-cap.c
index cfb7cb4d37a8..76cf8810a974 100644
--- a/drivers/media/platform/vivid/vivid-sdr-cap.c
+++ b/drivers/media/platform/vivid/vivid-sdr-cap.c
@@ -102,6 +102,10 @@ static void vivid_thread_sdr_cap_tick(struct vivid_dev *dev)
if (sdr_cap_buf) {
sdr_cap_buf->vb.sequence = dev->sdr_cap_seq_count;
+ v4l2_ctrl_request_setup(sdr_cap_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_sdr_cap);
+ v4l2_ctrl_request_complete(sdr_cap_buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_sdr_cap);
vivid_sdr_cap_process(dev, sdr_cap_buf);
sdr_cap_buf->vb.vb2_buf.timestamp =
ktime_get_ns() + dev->time_wrap_offset;
@@ -272,6 +276,8 @@ static int sdr_cap_start_streaming(struct vb2_queue *vq, unsigned count)
list_for_each_entry_safe(buf, tmp, &dev->sdr_cap_active, list) {
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_sdr_cap);
vb2_buffer_done(&buf->vb.vb2_buf,
VB2_BUF_STATE_QUEUED);
}
@@ -293,6 +299,8 @@ static void sdr_cap_stop_streaming(struct vb2_queue *vq)
buf = list_entry(dev->sdr_cap_active.next,
struct vivid_buffer, list);
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_sdr_cap);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
}
@@ -303,12 +311,20 @@ static void sdr_cap_stop_streaming(struct vb2_queue *vq)
mutex_lock(&dev->mutex);
}
+static void sdr_cap_buf_request_complete(struct vb2_buffer *vb)
+{
+ struct vivid_dev *dev = vb2_get_drv_priv(vb->vb2_queue);
+
+ v4l2_ctrl_request_complete(vb->req_obj.req, &dev->ctrl_hdl_sdr_cap);
+}
+
const struct vb2_ops vivid_sdr_cap_qops = {
.queue_setup = sdr_cap_queue_setup,
.buf_prepare = sdr_cap_buf_prepare,
.buf_queue = sdr_cap_buf_queue,
.start_streaming = sdr_cap_start_streaming,
.stop_streaming = sdr_cap_stop_streaming,
+ .buf_request_complete = sdr_cap_buf_request_complete,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
diff --git a/drivers/media/platform/vivid/vivid-vbi-cap.c b/drivers/media/platform/vivid/vivid-vbi-cap.c
index 92a852955173..903cebeb5ce5 100644
--- a/drivers/media/platform/vivid/vivid-vbi-cap.c
+++ b/drivers/media/platform/vivid/vivid-vbi-cap.c
@@ -204,6 +204,8 @@ static int vbi_cap_start_streaming(struct vb2_queue *vq, unsigned count)
list_for_each_entry_safe(buf, tmp, &dev->vbi_cap_active, list) {
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_cap);
vb2_buffer_done(&buf->vb.vb2_buf,
VB2_BUF_STATE_QUEUED);
}
@@ -220,12 +222,20 @@ static void vbi_cap_stop_streaming(struct vb2_queue *vq)
vivid_stop_generating_vid_cap(dev, &dev->vbi_cap_streaming);
}
+static void vbi_cap_buf_request_complete(struct vb2_buffer *vb)
+{
+ struct vivid_dev *dev = vb2_get_drv_priv(vb->vb2_queue);
+
+ v4l2_ctrl_request_complete(vb->req_obj.req, &dev->ctrl_hdl_vbi_cap);
+}
+
const struct vb2_ops vivid_vbi_cap_qops = {
.queue_setup = vbi_cap_queue_setup,
.buf_prepare = vbi_cap_buf_prepare,
.buf_queue = vbi_cap_buf_queue,
.start_streaming = vbi_cap_start_streaming,
.stop_streaming = vbi_cap_stop_streaming,
+ .buf_request_complete = vbi_cap_buf_request_complete,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
diff --git a/drivers/media/platform/vivid/vivid-vbi-out.c b/drivers/media/platform/vivid/vivid-vbi-out.c
index 69486c130a7e..9357c07e30d6 100644
--- a/drivers/media/platform/vivid/vivid-vbi-out.c
+++ b/drivers/media/platform/vivid/vivid-vbi-out.c
@@ -96,6 +96,8 @@ static int vbi_out_start_streaming(struct vb2_queue *vq, unsigned count)
list_for_each_entry_safe(buf, tmp, &dev->vbi_out_active, list) {
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vbi_out);
vb2_buffer_done(&buf->vb.vb2_buf,
VB2_BUF_STATE_QUEUED);
}
@@ -115,12 +117,20 @@ static void vbi_out_stop_streaming(struct vb2_queue *vq)
dev->vbi_out_have_cc[1] = false;
}
+static void vbi_out_buf_request_complete(struct vb2_buffer *vb)
+{
+ struct vivid_dev *dev = vb2_get_drv_priv(vb->vb2_queue);
+
+ v4l2_ctrl_request_complete(vb->req_obj.req, &dev->ctrl_hdl_vbi_out);
+}
+
const struct vb2_ops vivid_vbi_out_qops = {
.queue_setup = vbi_out_queue_setup,
.buf_prepare = vbi_out_buf_prepare,
.buf_queue = vbi_out_buf_queue,
.start_streaming = vbi_out_start_streaming,
.stop_streaming = vbi_out_stop_streaming,
+ .buf_request_complete = vbi_out_buf_request_complete,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c b/drivers/media/platform/vivid/vivid-vid-cap.c
index 1599159f2574..b2aad441a071 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -240,6 +240,8 @@ static int vid_cap_start_streaming(struct vb2_queue *vq, unsigned count)
list_for_each_entry_safe(buf, tmp, &dev->vid_cap_active, list) {
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_cap);
vb2_buffer_done(&buf->vb.vb2_buf,
VB2_BUF_STATE_QUEUED);
}
@@ -257,6 +259,13 @@ static void vid_cap_stop_streaming(struct vb2_queue *vq)
dev->can_loop_video = false;
}
+static void vid_cap_buf_request_complete(struct vb2_buffer *vb)
+{
+ struct vivid_dev *dev = vb2_get_drv_priv(vb->vb2_queue);
+
+ v4l2_ctrl_request_complete(vb->req_obj.req, &dev->ctrl_hdl_vid_cap);
+}
+
const struct vb2_ops vivid_vid_cap_qops = {
.queue_setup = vid_cap_queue_setup,
.buf_prepare = vid_cap_buf_prepare,
@@ -264,6 +273,7 @@ const struct vb2_ops vivid_vid_cap_qops = {
.buf_queue = vid_cap_buf_queue,
.start_streaming = vid_cap_start_streaming,
.stop_streaming = vid_cap_stop_streaming,
+ .buf_request_complete = vid_cap_buf_request_complete,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
diff --git a/drivers/media/platform/vivid/vivid-vid-out.c b/drivers/media/platform/vivid/vivid-vid-out.c
index 51fec66d8d45..423a67133f28 100644
--- a/drivers/media/platform/vivid/vivid-vid-out.c
+++ b/drivers/media/platform/vivid/vivid-vid-out.c
@@ -162,6 +162,8 @@ static int vid_out_start_streaming(struct vb2_queue *vq, unsigned count)
list_for_each_entry_safe(buf, tmp, &dev->vid_out_active, list) {
list_del(&buf->list);
+ v4l2_ctrl_request_complete(buf->vb.vb2_buf.req_obj.req,
+ &dev->ctrl_hdl_vid_out);
vb2_buffer_done(&buf->vb.vb2_buf,
VB2_BUF_STATE_QUEUED);
}
@@ -179,12 +181,20 @@ static void vid_out_stop_streaming(struct vb2_queue *vq)
dev->can_loop_video = false;
}
+static void vid_out_buf_request_complete(struct vb2_buffer *vb)
+{
+ struct vivid_dev *dev = vb2_get_drv_priv(vb->vb2_queue);
+
+ v4l2_ctrl_request_complete(vb->req_obj.req, &dev->ctrl_hdl_vid_out);
+}
+
const struct vb2_ops vivid_vid_out_qops = {
.queue_setup = vid_out_queue_setup,
.buf_prepare = vid_out_buf_prepare,
.buf_queue = vid_out_buf_queue,
.start_streaming = vid_out_start_streaming,
.stop_streaming = vid_out_stop_streaming,
+ .buf_request_complete = vid_out_buf_request_complete,
.wait_prepare = vb2_ops_wait_prepare,
.wait_finish = vb2_ops_wait_finish,
};
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread* [PATCHv15 35/35] RFC: media-requests: add debugfs node
2018-06-04 11:46 [PATCHv15 00/35] Request API Hans Verkuil
` (33 preceding siblings ...)
2018-06-04 11:46 ` [PATCHv15 34/35] vivid: add request support Hans Verkuil
@ 2018-06-04 11:46 ` Hans Verkuil
34 siblings, 0 replies; 61+ messages in thread
From: Hans Verkuil @ 2018-06-04 11:46 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil
From: Hans Verkuil <hans.verkuil@cisco.com>
Keep track of the number of requests and request objects of a media
device. Helps to verify that all request-related memory is freed.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
drivers/media/media-device.c | 41 +++++++++++++++++++++++++++++++++++
drivers/media/media-devnode.c | 17 +++++++++++++++
drivers/media/media-request.c | 5 +++++
include/media/media-device.h | 13 +++++++++--
include/media/media-devnode.h | 4 ++++
include/media/media-request.h | 2 ++
6 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 1119c1058e73..cefa822f505f 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -681,6 +681,23 @@ void media_device_unregister_entity(struct media_entity *entity)
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
+#ifdef CONFIG_DEBUG_FS
+/*
+ * Log the state of media requests.
+ * Very useful for debugging.
+ */
+static int media_device_requests(struct seq_file *file, void *priv)
+{
+ struct media_device *dev = dev_get_drvdata(file->private);
+
+ seq_printf(file, "number of requests: %d\n",
+ atomic_read(&dev->num_requests));
+ seq_printf(file, "number of request objects: %d\n",
+ atomic_read(&dev->num_request_objects));
+ return 0;
+}
+#endif
+
/**
* media_device_init() - initialize a media device
* @mdev: The media device
@@ -703,6 +720,9 @@ void media_device_init(struct media_device *mdev)
mutex_init(&mdev->graph_mutex);
ida_init(&mdev->entity_internal_idx);
+ atomic_set(&mdev->num_requests, 0);
+ atomic_set(&mdev->num_request_objects, 0);
+
dev_dbg(mdev->dev, "Media device initialized\n");
}
EXPORT_SYMBOL_GPL(media_device_init);
@@ -754,6 +774,26 @@ int __must_check __media_device_register(struct media_device *mdev,
dev_dbg(mdev->dev, "Media device registered\n");
+#ifdef CONFIG_DEBUG_FS
+ if (!media_top_dir)
+ return 0;
+
+ mdev->media_dir = debugfs_create_dir(dev_name(&devnode->dev),
+ media_top_dir);
+ if (IS_ERR_OR_NULL(mdev->media_dir)) {
+ dev_warn(mdev->dev, "Failed to create debugfs dir\n");
+ return 0;
+ }
+ mdev->requests_file = debugfs_create_devm_seqfile(&devnode->dev,
+ "requests", mdev->media_dir, media_device_requests);
+ if (IS_ERR_OR_NULL(mdev->requests_file)) {
+ dev_warn(mdev->dev, "Failed to create requests file\n");
+ debugfs_remove_recursive(mdev->media_dir);
+ mdev->media_dir = NULL;
+ return 0;
+ }
+#endif
+
return 0;
}
EXPORT_SYMBOL_GPL(__media_device_register);
@@ -831,6 +871,7 @@ void media_device_unregister(struct media_device *mdev)
dev_dbg(mdev->dev, "Media device unregistered\n");
+ debugfs_remove_recursive(mdev->media_dir);
device_remove_file(&mdev->devnode->dev, &dev_attr_model);
media_devnode_unregister(mdev->devnode);
/* devnode free is handled in media_devnode_*() */
diff --git a/drivers/media/media-devnode.c b/drivers/media/media-devnode.c
index 6b87a721dc49..4358ed22f208 100644
--- a/drivers/media/media-devnode.c
+++ b/drivers/media/media-devnode.c
@@ -53,6 +53,12 @@ static dev_t media_dev_t;
static DEFINE_MUTEX(media_devnode_lock);
static DECLARE_BITMAP(media_devnode_nums, MEDIA_NUM_DEVICES);
+/*
+ * debugfs
+ */
+struct dentry *media_top_dir;
+
+
/* Called when the last user of the media device exits. */
static void media_devnode_release(struct device *cd)
{
@@ -259,6 +265,8 @@ int __must_check media_devnode_register(struct media_device *mdev,
goto cdev_add_error;
}
+ dev_set_drvdata(&devnode->dev, mdev);
+
/* Part 4: Activate this minor. The char device can now be used. */
set_bit(MEDIA_FLAG_REGISTERED, &devnode->flags);
@@ -310,6 +318,14 @@ static int __init media_devnode_init(void)
return ret;
}
+#ifdef CONFIG_DEBUG_FS
+ media_top_dir = debugfs_create_dir("media", NULL);
+ if (IS_ERR_OR_NULL(media_top_dir)) {
+ pr_warn("Failed to create debugfs media dir\n");
+ media_top_dir = NULL;
+ }
+#endif
+
ret = bus_register(&media_bus_type);
if (ret < 0) {
unregister_chrdev_region(media_dev_t, MEDIA_NUM_DEVICES);
@@ -322,6 +338,7 @@ static int __init media_devnode_init(void)
static void __exit media_devnode_exit(void)
{
+ debugfs_remove_recursive(media_top_dir);
bus_unregister(&media_bus_type);
unregister_chrdev_region(media_dev_t, MEDIA_NUM_DEVICES);
}
diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
index 6b9a4fc0248b..86b574cc350a 100644
--- a/drivers/media/media-request.c
+++ b/drivers/media/media-request.c
@@ -72,6 +72,7 @@ static void media_request_release(struct kref *kref)
mdev->ops->req_free(req);
else
kfree(req);
+ atomic_dec(&mdev->num_requests);
}
void media_request_put(struct media_request *req)
@@ -316,6 +317,7 @@ int media_request_alloc(struct media_device *mdev,
get_task_comm(comm, current);
snprintf(req->debug_str, sizeof(req->debug_str), "%s:%d",
comm, fd);
+ atomic_inc(&mdev->num_requests);
dev_dbg(mdev->dev, "request: allocated %s\n", req->debug_str);
fd_install(fd, filp);
@@ -340,6 +342,7 @@ static void media_request_object_release(struct kref *kref)
if (req)
media_request_object_unbind(obj);
obj->ops->release(obj);
+ atomic_dec(&obj->mdev->num_request_objects);
}
struct media_request_object *
@@ -403,10 +406,12 @@ int media_request_object_bind(struct media_request *req,
obj->req = req;
obj->ops = ops;
obj->priv = priv;
+ obj->mdev = req->mdev;
list_add_tail(&obj->list, &req->objects);
req->num_incomplete_objects++;
ret = 0;
+ atomic_inc(&obj->mdev->num_request_objects);
unlock:
spin_unlock_irqrestore(&req->lock, flags);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index cf52a74bada9..2070acc2a2bb 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -21,6 +21,7 @@
#include <linux/list.h>
#include <linux/mutex.h>
+#include <linux/atomic.h>
#include <media/media-devnode.h>
#include <media/media-entity.h>
@@ -108,8 +109,10 @@ struct media_device_ops {
* guarantee exclusive access to the state of the device on
* the tip of the request queue.
* @ops: Operation handler callbacks
- * @req_queue_mutex: Serialise the MEDIA_REQUEST_IOC_QUEUE ioctl w.r.t.
- * other operations that stop or start streaming.
+ * @num_requests: number of associated requests
+ * @num_request_objects: number of associated request objects
+ * @media_dir: DebugFS media directory
+ * @requests_file: DebugFS requests file
*
* This structure represents an abstract high-level media device. It allows easy
* access to entities and provides basic media device-level support. The
@@ -182,6 +185,12 @@ struct media_device {
const struct media_device_ops *ops;
struct mutex req_queue_mutex;
+ atomic_t num_requests;
+ atomic_t num_request_objects;
+
+ /* debugfs */
+ struct dentry *media_dir;
+ struct dentry *requests_file;
};
/* We don't need to include pci.h or usb.h here */
diff --git a/include/media/media-devnode.h b/include/media/media-devnode.h
index dc2f64e1b08f..984b62b634d3 100644
--- a/include/media/media-devnode.h
+++ b/include/media/media-devnode.h
@@ -28,9 +28,13 @@
#include <linux/fs.h>
#include <linux/device.h>
#include <linux/cdev.h>
+#include <linux/debugfs.h>
struct media_device;
+/* DebugFS top-level media directory */
+extern struct dentry *media_top_dir;
+
/*
* Flag to mark the media_devnode struct as registered. Drivers must not touch
* this flag directly, it will be set and cleared by media_devnode_register and
diff --git a/include/media/media-request.h b/include/media/media-request.h
index 2b458d4d8a65..ba025cb336f6 100644
--- a/include/media/media-request.h
+++ b/include/media/media-request.h
@@ -209,6 +209,7 @@ struct media_request_object_ops {
* struct media_request_object - An opaque object that belongs to a media
* request
*
+ * @mdev: Media device this object belongs to
* @ops: object's operations
* @priv: object's priv pointer
* @req: the request this object belongs to (can be NULL)
@@ -220,6 +221,7 @@ struct media_request_object_ops {
* another struct that contains the actual data for this request object.
*/
struct media_request_object {
+ struct media_device *mdev;
const struct media_request_object_ops *ops;
void *priv;
struct media_request *req;
--
2.17.0
^ permalink raw reply related [flat|nested] 61+ messages in thread