cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Sun Sep 2 05:00:10 CEST 2018
media-tree git hash:d842a7cf938b6e0f8a1aa9f1aec0476c9a599310
media_build git hash: 27f99df152c7e5ae155c6e7888e12234eaa0fc25
v4l-utils git hash: f44f00e8b4ac6e9aa05bac8953e3fcc89e1fe198
edid-decode git hash: b2da1516df3cc2756bfe8d1fa06d7bf2562ba1f4
gcc version:i686-linux-gcc (GCC) 8.1.0
sparse version: 0.5.2
smatch version: 0.5.1
host hardware: x86_64
host os:4.18.5-marune
linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-i686: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
Check COMPILE_TEST: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: ERRORS
linux-2.6.37.6-x86_64: ERRORS
linux-2.6.38.8-i686: ERRORS
linux-2.6.38.8-x86_64: ERRORS
linux-2.6.39.4-i686: ERRORS
linux-2.6.39.4-x86_64: ERRORS
linux-3.0.101-i686: ERRORS
linux-3.0.101-x86_64: ERRORS
linux-3.0.101/arch/x86/include/asm/fixmap.h:217:1: error: expected '=', ',',
';', 'asm' or '__attribute__' before '{' token
linux-3.1.10-i686: ERRORS
linux-3.1.10-x86_64: ERRORS
linux-3.2.102-i686: ERRORS
linux-3.2.102-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.3.8/arch/x86/include/asm/compat.h:172:2: error: expected
specifier-qualifier-list before 'compat_size_t'
linux-3.4.113-i686: ERRORS
linux-3.4.113-x86_64: ERRORS
linux-3.5.7-i686: ERRORS
linux-3.5.7-x86_64: ERRORS
linux-3.6.11-i686: ERRORS
linux-3.6.11-x86_64: ERRORS
linux-3.7.10-i686: ERRORS
linux-3.7.10-x86_64: ERRORS
linux-3.8.13-i686: ERRORS
linux-3.8.13-x86_64: ERRORS
linux-3.9.11-i686: ERRORS
linux-3.9.11-x86_64: ERRORS
linux-3.10.108-i686: ERRORS
linux-3.10.108-x86_64: ERRORS
linux-3.11.10-i686: ERRORS
linux-3.11.10-x86_64: ERRORS
linux-3.12.74-i686: ERRORS
linux-3.12.74/arch/x86/include/asm/paravirt.h:127:1: error: expected '=', ',',
';', 'asm' or '__attribute__' before '{' token
linux-3.12.74-x86_64: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.79-i686: ERRORS
linux-3.14.79-x86_64: ERRORS
linux-3.14.79/arch/x86/include/asm/preempt.h:6,
linux-3.15.10-i686: ERRORS
linux-3.15.10-x86_64: ERRORS
linux-3.15.10/arch/x86/include/asm/processor.h:432:1: note: in expansion of
macro 'DECLARE_PER_CPU_FIRST'
linux-3.16.57-i686: ERRORS
linux-3.16.57-x86_64: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.119-i686: ERRORS
linux-3.18.119-x86_64: ERRORS
linux-3.19.8-i686: ERRORS
linux-3.19.8-x86_64: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.52-i686: ERRORS
linux-4.1.52-x86_64: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-i686: ERRORS
linux-4.3.6-x86_64: ERRORS
linux-4.4.152-i686: ERRORS
linux-4.4.152-x86_64: ERRORS
linux-4.5.7-i686: ERRORS
linux-4.5.7-x86_64: ERRORS
linux-4.6.7-i686: ERRORS
linux-4.6.7-x86_64: ERRORS
linux-4.7.10-i686: ERRORS
linux-4.7.10-x86_64: ERRORS
linux-4.8.17-i686: ERRORS
linux-4.8.17-x86_64: ERRORS
linux-4.9.124-i686: ERRORS
linux-4.9.124-x86_64: ERRORS
linux-4.10.17-i686: ERRORS
linux-4.10.17-x86_64: ERRORS
linux-4.11.12-i686: ERRORS
linux-4.11.12-x86_64: ERRORS
linux-4.12.14-i686: ERRORS
linux-4.12.14-x86_64: ERRORS
linux-4.13.16-i686: ERRORS
linux-4.13.16-x86_64: ERRORS
linux-4.14.67-i686: ERRORS
linux-4.14.67-x86_64: ERRORS
linux-4.15.18-i686: ERRORS
linux-4.15.18-x86_64: ERRORS
linux-4.16.18-i686: ERRORS
linux-4.16.18-x86_64: ERRORS
linux-4.17.19-i686: ERRORS
linux-4.17.19-x86_64: ERRORS
linux-4.18.5-i686: ERRORS
linux-4.18.5-x86_64: ERRORS
linux-4.19-rc1-i686: OK
linux-4.19-rc1-x86_64: OK
apps: OK
specified for parameter 'make_bad_inode'
specified for parameter '__bad_size_call_parameter'
specified for parameter 'hrtimer_try_to_cancel'
specified for parameter 'hrtimer_try_to_cancel'
specifier-qualifier-list before 'atomic_long_t'
specified for parameter 'io_schedule_timeout'
specified for parameter 'init_bsp_APIC'
specified for parameter 'capable_wrt_inode_uidgid'
specified for parameter 'do_getitimer'
specified for parameter 'do_getitimer'
specifiers or '...' before 'atomic_long_t'
specifiers or '...' before 'atomic_long_t'
specifiers or '...' before 'atomic64_t'
specifiers or '...' before 'atomic64_t'
specifiers or '...' before 'atomic64_t'
specifiers or '...' before 'atomic64_t'
specified for parameter 'Elf64_Half'
specified for parameter '__page_ref_mod'
spec-git: ERRORS
sparse: WARNINGS
Detailed results are available here:
http://www.xs4all.nl/~hverkuil/logs/Sunday.log
Full logs are available here:
http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2
The Media Infrastructure API from this daily build is here:
http://www.xs4all.nl/~hverkuil/spec/index.html
[GIT PULL FOR v4.20] Various fixes/enhancements
The following changes since commit d842a7cf938b6e0f8a1aa9f1aec0476c9a599310: media: adv7842: enable reduced fps detection (2018-08-31 10:03:51 -0400) are available in the Git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.20a for you to fetch changes up to 8ce385273afa4ce9f48e26ed6a7811bf678137ed: vicodec: fix sparse warning (2018-09-01 14:59:20 +0200) Hans Verkuil (7): mediactl/*.rst: document argp v4l2-tpg: show either Y'CbCr or HSV encoding v4l2-tpg: add Z16 support cec-func-poll.rst/func-poll.rst: update EINVAL description vicodec: fix wrong sizeimage videodev2.h.rst.exceptions: add V4L2_DV_FL_CAN_DETECT_REDUCED_FPS vicodec: fix sparse warning Documentation/media/uapi/cec/cec-func-poll.rst| 3 ++- Documentation/media/uapi/mediactl/media-ioc-device-info.rst | 1 + Documentation/media/uapi/mediactl/media-ioc-enum-entities.rst | 1 + Documentation/media/uapi/mediactl/media-ioc-enum-links.rst| 1 + Documentation/media/uapi/mediactl/media-ioc-g-topology.rst| 1 + Documentation/media/uapi/mediactl/media-ioc-setup-link.rst| 1 + Documentation/media/uapi/v4l/func-poll.rst| 3 ++- Documentation/media/videodev2.h.rst.exceptions| 1 + drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 11 +-- drivers/media/platform/vicodec/vicodec-core.c | 18 +++--- 10 files changed, 30 insertions(+), 11 deletions(-)
[PATCH] vicodec: fix sparse warning
drivers/media/platform/vicodec/vicodec-core.c:160:25: warning: variable 'q_out'
set but not used [-Wunused-but-set-variable]
It's indeed not used, and it can be removed.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/vicodec-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index 47e9ad0941ab..11385d44e500 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -157,12 +157,11 @@ static int device_process(struct vicodec_ctx *ctx,
struct vb2_v4l2_buffer *out_vb)
{
struct vicodec_dev *dev = ctx->dev;
- struct vicodec_q_data *q_out, *q_cap;
+ struct vicodec_q_data *q_cap;
struct v4l2_fwht_state *state = >state;
u8 *p_in, *p_out;
int ret;
- q_out = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
q_cap = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
if (ctx->is_enc)
p_in = vb2_plane_vaddr(_vb->vb2_buf, 0);
--
2.18.0
[PATCH] videodev2.h.rst.exceptions: add V4L2_DV_FL_CAN_DETECT_REDUCED_FPS
This fixes a documentation warning: Documentation/output/videodev2.h.rst:6: WARNING: undefined label: v4l2-dv-fl-can-detect-reduced-fps (if the link has no caption the label must precede a section header) Signed-off-by: Hans Verkuil --- Documentation/media/videodev2.h.rst.exceptions | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions index ca9f0edc579e..63fa131729c0 100644 --- a/Documentation/media/videodev2.h.rst.exceptions +++ b/Documentation/media/videodev2.h.rst.exceptions @@ -278,6 +278,7 @@ replace define V4L2_DV_BT_STD_SDI dv-bt-standards replace define V4L2_DV_FL_REDUCED_BLANKING dv-bt-standards replace define V4L2_DV_FL_CAN_REDUCE_FPS dv-bt-standards +replace define V4L2_DV_FL_CAN_DETECT_REDUCED_FPS dv-bt-standards replace define V4L2_DV_FL_REDUCED_FPS dv-bt-standards replace define V4L2_DV_FL_HALF_LINE dv-bt-standards replace define V4L2_DV_FL_IS_CE_VIDEO dv-bt-standards -- 2.18.0
[PATCHv3 09/10] media-request: EPERM -> EACCES/EBUSY
From: Hans Verkuil If requests are not supported by the driver, then return EACCES, not EPERM. If you attempt to mix queueing buffers directly and using requests, then EBUSY is returned instead of EPERM: once a specific queueing mode has been chosen the queue is 'busy' if you attempt the other mode (i.e. direct queueing vs via a request). Signed-off-by: Hans Verkuil --- Documentation/media/uapi/v4l/buffer.rst| 2 +- .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 9 - Documentation/media/uapi/v4l/vidioc-qbuf.rst | 14 -- drivers/media/common/videobuf2/videobuf2-core.c| 2 +- drivers/media/common/videobuf2/videobuf2-v4l2.c| 9 ++--- drivers/media/media-request.c | 4 ++-- 6 files changed, 22 insertions(+), 18 deletions(-) diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index 1865cd5b9d3c..58a6d7d336e6 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -314,7 +314,7 @@ struct v4l2_buffer :ref:`ioctl VIDIOC_QBUF ` and ignored by other ioctls. Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls other than :ref:`VIDIOC_QBUF `. - If the device does not support requests, then ``EPERM`` will be returned. + If the device does not support requests, then ``EACCES`` will be returned. If requests are supported but an invalid request file descriptor is given, then ``EINVAL`` will be returned. diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst index ad8908ce3095..54a999df5aec 100644 --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst @@ -100,7 +100,7 @@ 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 `, but instead are applied by the driver for the buffer associated with the same request. -If the device does not support requests, then ``EPERM`` will be returned. +If the device does not support requests, then ``EACCES`` will be returned. If requests are supported but an invalid request file descriptor is given, then ``EINVAL`` will be returned. @@ -233,7 +233,7 @@ still cause this situation. these controls have to be retrieved from a request or tried/set for a request. In the latter case the ``request_fd`` field contains the file descriptor of the request that should be used. If the device - does not support requests, then ``EPERM`` will be returned. + does not support requests, then ``EACCES`` will be returned. .. note:: @@ -299,7 +299,7 @@ still cause this situation. - ``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``. - If the device does not support requests, then ``EPERM`` will be returned. + If the device does not support requests, then ``EACCES`` will be returned. If requests are supported but an invalid request file descriptor is given, then ``EINVAL`` will be returned. * - __u32 @@ -408,6 +408,5 @@ EACCES control, or to get a control from a request that has not yet been completed. -EPERM -The ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the +Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the device does not support requests. diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst index 7bff69c15452..6b1e7a67cbe5 100644 --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst @@ -104,7 +104,7 @@ 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. -If the device does not support requests, then ``EPERM`` will be returned. +If the device does not support requests, then ``EACCES`` will be returned. If requests are supported but an invalid request file descriptor is given, then ``EINVAL`` will be returned. @@ -175,9 +175,11 @@ EPIPE codecs if a buffer with the ``V4L2_BUF_FLAG_LAST`` was already dequeued and no new buffers are expected to become available. -EPERM +EACCES The ``V4L2_BUF_FLAG_REQUEST_FD`` flag was set but the device does not -support requests. Or the first buffer was queued via a request, but -the application now tries to queue it directly, or vice versa (it is -not permitted to mix the two APIs). Or an attempt is made to queue a -CAPTURE buffer to a request for a :ref:`memory-to-memory
[PATCHv3 06/10] media-request: add media_request_(un)lock_for_access
From: Hans Verkuil
Add helper functions to prevent a completed request from being
re-inited while it is being accessed.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomasz Figa
---
drivers/media/media-request.c | 10 +++
include/media/media-request.h | 56 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
index 4cee67e6657e..414197645e09 100644
--- a/drivers/media/media-request.c
+++ b/drivers/media/media-request.c
@@ -43,6 +43,7 @@ static void media_request_clean(struct media_request *req)
/* Just a sanity check. No other code path is allowed to change this. */
WARN_ON(req->state != MEDIA_REQUEST_STATE_CLEANING);
WARN_ON(req->updating_count);
+ WARN_ON(req->access_count);
list_for_each_entry_safe(obj, obj_safe, >objects, list) {
media_request_object_unbind(obj);
@@ -50,6 +51,7 @@ static void media_request_clean(struct media_request *req)
}
req->updating_count = 0;
+ req->access_count = 0;
WARN_ON(req->num_incomplete_objects);
req->num_incomplete_objects = 0;
wake_up_interruptible_all(>poll_wait);
@@ -198,6 +200,13 @@ static long media_request_ioctl_reinit(struct
media_request *req)
spin_unlock_irqrestore(>lock, flags);
return -EBUSY;
}
+ if (req->access_count) {
+ dev_dbg(mdev->dev,
+ "request: %s is being accessed, cannot reinit\n",
+ req->debug_str);
+ spin_unlock_irqrestore(>lock, flags);
+ return -EBUSY;
+ }
req->state = MEDIA_REQUEST_STATE_CLEANING;
spin_unlock_irqrestore(>lock, flags);
@@ -313,6 +322,7 @@ int media_request_alloc(struct media_device *mdev, int
*alloc_fd)
spin_lock_init(>lock);
init_waitqueue_head(>poll_wait);
req->updating_count = 0;
+ req->access_count = 0;
*alloc_fd = fd;
diff --git a/include/media/media-request.h b/include/media/media-request.h
index ac02019c1d77..d8c8db89dbde 100644
--- a/include/media/media-request.h
+++ b/include/media/media-request.h
@@ -53,6 +53,7 @@ struct media_request_object;
* @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
+ * @access_count: count the number of request accesses 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
@@ -64,6 +65,7 @@ struct media_request {
char debug_str[TASK_COMM_LEN + 11];
enum media_request_state state;
unsigned int updating_count;
+ unsigned int access_count;
struct list_head objects;
unsigned int num_incomplete_objects;
struct wait_queue_head poll_wait;
@@ -72,6 +74,50 @@ struct media_request {
#ifdef CONFIG_MEDIA_CONTROLLER
+/**
+ * media_request_lock_for_access - Lock the request to access its objects
+ *
+ * @req: The media request
+ *
+ * Use before accessing a completed request. A reference to the request must
+ * be held during the access. This usually takes place automatically through
+ * a file handle. Use @media_request_unlock_for_access when done.
+ */
+static inline int __must_check
+media_request_lock_for_access(struct media_request *req)
+{
+ unsigned long flags;
+ int ret = -EBUSY;
+
+ spin_lock_irqsave(>lock, flags);
+ if (req->state == MEDIA_REQUEST_STATE_COMPLETE) {
+ req->access_count++;
+ ret = 0;
+ }
+ spin_unlock_irqrestore(>lock, flags);
+
+ return ret;
+}
+
+/**
+ * media_request_unlock_for_access - Unlock a request previously locked for
+ * access
+ *
+ * @req: The media request
+ *
+ * Unlock a request that has previously been locked using
+ * @media_request_lock_for_access.
+ */
+static inline void media_request_unlock_for_access(struct media_request *req)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+ if (!WARN_ON(!req->access_count))
+ req->access_count--;
+ spin_unlock_irqrestore(>lock, flags);
+}
+
/**
* media_request_lock_for_update - Lock the request for updating its objects
*
@@ -333,6 +379,16 @@ void media_request_object_complete(struct
media_request_object *obj);
#else
+static inline int __must_check
+media_request_lock_for_access(struct media_request *req)
+{
+ return -EINVAL;
+}
+
+static inline void media_request_unlock_for_access(struct media_request *req)
+{
+}
+
static inline int __must_check
media_request_lock_for_update(struct media_request *req)
{
--
2.18.0
[PATCHv3 03/10] buffer.rst: only set V4L2_BUF_FLAG_REQUEST_FD for QBUF
From: Hans Verkuil Document that V4L2_BUF_FLAG_REQUEST_FD should only be used with VIDIOC_QBUF and cleared otherwise. Signed-off-by: Hans Verkuil Reviewed-by: Tomasz Figa --- Documentation/media/uapi/v4l/buffer.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index 35c2fadd10de..1865cd5b9d3c 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -312,6 +312,8 @@ struct v4l2_buffer 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 ` and ignored by other ioctls. + Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls + other than :ref:`VIDIOC_QBUF `. If the device does not support requests, then ``EPERM`` will be returned. If requests are supported but an invalid request file descriptor is given, then ``EINVAL`` will be returned. -- 2.18.0
[PATCHv3 05/10] vb2: set reqbufs/create_bufs capabilities
From: Hans Verkuil
Set the capabilities field of v4l2_requestbuffers and v4l2_create_buffers.
The various mapping modes were easy, but for signaling the request capability
a new 'supports_requests' bitfield was added to videobuf2-core.h (and set in
vim2m and vivid). Drivers have to set this bitfield for any queue where
requests are supported.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomasz Figa
---
.../media/common/videobuf2/videobuf2-v4l2.c | 19 ++-
drivers/media/platform/vim2m.c| 1 +
drivers/media/platform/vivid/vivid-core.c | 5 +
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +++-
drivers/media/v4l2-core/v4l2-ioctl.c | 4 ++--
include/media/videobuf2-core.h| 2 ++
6 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index a70df16d68f1..2caaabd50532 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -384,7 +384,7 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q,
struct media_device *md
return -EPERM;
}
return 0;
- } else if (q->uses_qbuf) {
+ } else if (q->uses_qbuf || !q->supports_requests) {
dprintk(1, "%s: queue does not use requests\n", opname);
return -EPERM;
}
@@ -619,10 +619,24 @@ int vb2_querybuf(struct vb2_queue *q, struct v4l2_buffer
*b)
}
EXPORT_SYMBOL(vb2_querybuf);
+static void fill_buf_caps(struct vb2_queue *q, u32 *caps)
+{
+ *caps = 0;
+ if (q->io_modes & VB2_MMAP)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_MMAP;
+ if (q->io_modes & VB2_USERPTR)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_USERPTR;
+ if (q->io_modes & VB2_DMABUF)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_DMABUF;
+ if (q->supports_requests)
+ *caps |= V4L2_BUF_CAP_SUPPORTS_REQUESTS;
+}
+
int vb2_reqbufs(struct vb2_queue *q, struct v4l2_requestbuffers *req)
{
int ret = vb2_verify_memory_type(q, req->memory, req->type);
+ fill_buf_caps(q, >capabilities);
return ret ? ret : vb2_core_reqbufs(q, req->memory, >count);
}
EXPORT_SYMBOL_GPL(vb2_reqbufs);
@@ -654,6 +668,7 @@ int vb2_create_bufs(struct vb2_queue *q, struct
v4l2_create_buffers *create)
int ret = vb2_verify_memory_type(q, create->memory, f->type);
unsigned i;
+ fill_buf_caps(q, >capabilities);
create->index = q->num_buffers;
if (create->count == 0)
return ret != -EBUSY ? ret : 0;
@@ -861,6 +876,7 @@ int vb2_ioctl_reqbufs(struct file *file, void *priv,
struct video_device *vdev = video_devdata(file);
int res = vb2_verify_memory_type(vdev->queue, p->memory, p->type);
+ fill_buf_caps(vdev->queue, >capabilities);
if (res)
return res;
if (vb2_queue_is_busy(vdev, file))
@@ -882,6 +898,7 @@ int vb2_ioctl_create_bufs(struct file *file, void *priv,
p->format.type);
p->index = vdev->queue->num_buffers;
+ fill_buf_caps(vdev->queue, >capabilities);
/*
* If count == 0, then just check if memory and type are valid.
* Any -EBUSY result from vb2_verify_memory_type can be mapped to 0.
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index 5423f0dd0821..40fbb1e429af 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -855,6 +855,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *ds
src_vq->mem_ops = _vmalloc_memops;
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock = >dev->dev_mutex;
+ src_vq->supports_requests = true;
ret = vb2_queue_init(src_vq);
if (ret)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index 3f6f5cbe1b60..e7f1394832fe 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -1077,6 +1077,7 @@ static int vivid_create_instance(struct platform_device
*pdev, int inst)
q->min_buffers_needed = 2;
q->lock = >mutex;
q->dev = dev->v4l2_dev.dev;
+ q->supports_requests = true;
ret = vb2_queue_init(q);
if (ret)
@@ -1097,6 +1098,7 @@ static int vivid_create_instance(struct platform_device
*pdev, int inst)
q->min_buffers_needed = 2;
q->lock = >mutex;
q->dev = dev->v4l2_dev.dev;
+ q->supports_requests = true;
ret = vb2_queue_init(q);
if (ret)
@@ -1117,6 +1119,7 @@ static int vivid_create_instance(struct platform_device
*pdev, int inst)
q->min_buffers_needed = 2;
[PATCHv3 00/10] Post-v18: Request API updates
From: Hans Verkuil Hi all, This patch series sits on top of the request_api topic branch in the media_tree. It makes some final (?) changes as discussed in: https://www.mail-archive.com/linux-media@vger.kernel.org/msg134419.html and: https://www.spinics.net/lists/linux-media/msg138596.html The combined v18 patches + this series is available here: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=reqv18-1 Updated v4l-utils for this is available here: https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=request Userspace visible changes: - Invalid request_fd values now return -EINVAL instead of -ENOENT. - It is no longer possible to use VIDIOC_G_EXT_CTRLS for requests that are not completed. -EACCES is returned in that case. - Attempting to use requests if requests are not supported by the driver will result in -EACCES instead of -EPERM. - Attempting to mix direct QBUF with queueing buffers via a request will result in -EBUSY instead of -EPERM. The only patch that was changed is patch 09/10 (except for fixing a typo in the commit message of patch 07/10). Driver visible changes (important for the cedrus driver!): Drivers should set the new vb2_queue 'supports_request' bitfield to 1 if a vb2_queue can support requests. Otherwise the queue cannot be used with requests. This bitfield is also used to fill in the new capabilities field in struct v4l2_requestbuffers and v4l2_create_buffers. Changes since v2: - Fix typo in commit message of patch 07/10: why -> when - Attempting to mix direct QBUF with queueing buffers via a request will result in -EBUSY instead of -EPERM. - Replaced -EPERM with -EBUSY in videobuf2-core.c that was missed in v1. Changes since v1: - Updated patch 4/10 to explain how to query the capabilities with REQBUFS/CREATE_BUFS with a minimum of side-effects (requested by Tomasz). - Added patches 6-10: 6: Sakari found a corner case: when accessing a request the request has to be protected from being re-inited. New media_request_(un)lock_for_access helpers are added for this. 7: use these helpers in g_ext_ctrls. 8: make s/try_ext_ctrls more robust by keeping the request references until we're fully done setting/trying the controls. 9: Change two more EPERM's to EACCES. EPERM suggests that you can fix it by changing permissions somehow, but in this case the driver simply doesn't support requests at all. 10: Update the request documentation based on Laurent's comments: https://www.spinics.net/lists/linux-media/msg139152.html To do: split off the V4L2 specifics into a V4L2 specific rst file. But this will take more time and is for later. Regards, Hans Hans Verkuil (10): media-request: return -EINVAL for invalid request_fds v4l2-ctrls: return -EACCES if request wasn't completed buffer.rst: only set V4L2_BUF_FLAG_REQUEST_FD for QBUF videodev2.h: add new capabilities for buffer types vb2: set reqbufs/create_bufs capabilities media-request: add media_request_(un)lock_for_access v4l2-ctrls: use media_request_(un)lock_for_access v4l2-ctrls: improve media_request_(un)lock_for_update media-request: EPERM -> EACCES/EBUSY media-request: update documentation .../uapi/mediactl/media-ioc-request-alloc.rst | 3 +- .../uapi/mediactl/media-request-ioc-queue.rst | 7 +-- .../media/uapi/mediactl/request-api.rst | 51 + .../uapi/mediactl/request-func-close.rst | 1 + .../media/uapi/mediactl/request-func-poll.rst | 2 +- Documentation/media/uapi/v4l/buffer.rst | 22 +--- .../media/uapi/v4l/vidioc-create-bufs.rst | 14 - .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 48 Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 +- .../media/uapi/v4l/vidioc-reqbufs.rst | 42 +- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../media/common/videobuf2/videobuf2-v4l2.c | 24 +++- drivers/media/media-request.c | 20 +-- drivers/media/platform/vim2m.c| 1 + drivers/media/platform/vivid/vivid-core.c | 5 ++ drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 +- drivers/media/v4l2-core/v4l2-ctrls.c | 32 +++ drivers/media/v4l2-core/v4l2-ioctl.c | 4 +- include/media/media-request.h | 56 +++ include/media/videobuf2-core.h| 2 + include/uapi/linux/videodev2.h| 13 - 21 files changed, 283 insertions(+), 101 deletions(-) -- 2.18.0
[PATCHv3 10/10] media-request: update documentation
From: Hans Verkuil
Various clarifications and readability improvements based on
Laurent Pinchart's review of the documentation.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomasz Figa
---
.../uapi/mediactl/media-ioc-request-alloc.rst | 3 +-
.../uapi/mediactl/media-request-ioc-queue.rst | 7 +--
.../media/uapi/mediactl/request-api.rst | 51 +++
.../uapi/mediactl/request-func-close.rst | 1 +
.../media/uapi/mediactl/request-func-poll.rst | 2 +-
Documentation/media/uapi/v4l/buffer.rst | 14 +++--
.../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 5 +-
Documentation/media/uapi/v4l/vidioc-qbuf.rst | 5 +-
8 files changed, 52 insertions(+), 36 deletions(-)
diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
index 34434e2b3918..0f8b31874002 100644
--- a/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
+++ b/Documentation/media/uapi/mediactl/media-ioc-request-alloc.rst
@@ -52,7 +52,8 @@ for the request to complete.
The request will remain allocated until all the file descriptors associated
with it are closed by :ref:`close() ` and the driver no
-longer uses the request internally.
+longer uses the request internally. See also
+:ref:`here ` for more information.
Return Value
diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
index d4f8119e0643..3bf1c2e492eb 100644
--- a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
+++ b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
@@ -40,9 +40,6 @@ Other errors can be returned if the contents of the request
contained
invalid or inconsistent data, see the next section for a list of
common error codes. On error both the request and driver state are unchanged.
-Typically if you get an error here, then that means that the application
-did something wrong and you have to fix the application.
-
Once a request is queued, then the driver is required to gracefully handle
errors that occur when the request is applied to the hardware. The
exception is the ``EIO`` error which signals a fatal error that requires
@@ -69,8 +66,8 @@ EPERM
to use a request. It is not permitted to mix the two APIs.
ENOENT
The request did not contain any buffers. All requests are required
-to have at least one buffer. This can also be returned if required
-controls are missing.
+to have at least one buffer. This can also be returned if some required
+configuration is missing in the request.
ENOMEM
Out of memory when allocating internal data structures for this
request.
diff --git a/Documentation/media/uapi/mediactl/request-api.rst
b/Documentation/media/uapi/mediactl/request-api.rst
index 0b9da58b01e3..1ac42749e564 100644
--- a/Documentation/media/uapi/mediactl/request-api.rst
+++ b/Documentation/media/uapi/mediactl/request-api.rst
@@ -12,6 +12,9 @@ the same pipeline to reconfigure and collaborate closely on a
per-frame basis.
Another is support of stateless codecs, which require controls to be applied
to specific frames (aka 'per-frame controls') in order to be used efficiently.
+While the initial use-case was V4L2, it can be extended to other subsystems
+as well, as long as they use the media controller.
+
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
@@ -20,19 +23,23 @@ 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.
+controller topology + configuration for each media entity) to be associated
with
+specific buffers. This allows user-space to schedule several tasks ("requests")
+with different configurations in advance, knowing that the configuration will
be
+applied when needed to get the expected result. Configuration 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.
+The Request API extends the
[PATCHv3 04/10] videodev2.h: add new capabilities for buffer types
From: Hans Verkuil
VIDIOC_REQBUFS and VIDIOC_CREATE_BUFFERS will return capabilities
telling userspace what the given buffer type is capable of.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomasz Figa
---
.../media/uapi/v4l/vidioc-create-bufs.rst | 14 ++-
.../media/uapi/v4l/vidioc-reqbufs.rst | 42 ++-
include/uapi/linux/videodev2.h| 13 +-
3 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-create-bufs.rst
b/Documentation/media/uapi/v4l/vidioc-create-bufs.rst
index a39e18d69511..eadf6f757fbf 100644
--- a/Documentation/media/uapi/v4l/vidioc-create-bufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-create-bufs.rst
@@ -102,7 +102,19 @@ than the number requested.
- ``format``
- Filled in by the application, preserved by the driver.
* - __u32
- - ``reserved``\ [8]
+ - ``capabilities``
+ - Set by the driver. If 0, then the driver doesn't support
+capabilities. In that case all you know is that the driver is
+ guaranteed to support ``V4L2_MEMORY_MMAP`` and *might* support
+ other :c:type:`v4l2_memory` types. It will not support any others
+ capabilities. See :ref:`here ` for a list of the
+ capabilities.
+
+ If you want to just query the capabilities without making any
+ other changes, then set ``count`` to 0, ``memory`` to
+ ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type.
+* - __u32
+ - ``reserved``\ [7]
- A place holder for future extensions. Drivers and applications
must set the array to zero.
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index 316f52c8a310..d40c60e8 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -88,10 +88,50 @@ any DMA in progress, an implicit
``V4L2_MEMORY_DMABUF`` or ``V4L2_MEMORY_USERPTR``. See
:c:type:`v4l2_memory`.
* - __u32
- - ``reserved``\ [2]
+ - ``capabilities``
+ - Set by the driver. If 0, then the driver doesn't support
+capabilities. In that case all you know is that the driver is
+ guaranteed to support ``V4L2_MEMORY_MMAP`` and *might* support
+ other :c:type:`v4l2_memory` types. It will not support any others
+ capabilities.
+
+ If you want to query the capabilities with a minimum of side-effects,
+ then this can be called with ``count`` set to 0, ``memory`` set to
+ ``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will
+ free any previously allocated buffers, so this is typically something
+ that will be done at the start of the application.
+* - __u32
+ - ``reserved``\ [1]
- A place holder for future extensions. Drivers and applications
must set the array to zero.
+.. tabularcolumns:: |p{6.1cm}|p{2.2cm}|p{8.7cm}|
+
+.. _v4l2-buf-capabilities:
+.. _V4L2-BUF-CAP-SUPPORTS-MMAP:
+.. _V4L2-BUF-CAP-SUPPORTS-USERPTR:
+.. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
+.. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
+
+.. cssclass:: longtable
+
+.. flat-table:: V4L2 Buffer Capabilities Flags
+:header-rows: 0
+:stub-columns: 0
+:widths: 3 1 4
+
+* - ``V4L2_BUF_CAP_SUPPORTS_MMAP``
+ - 0x0001
+ - This buffer type supports the ``V4L2_MEMORY_MMAP`` streaming mode.
+* - ``V4L2_BUF_CAP_SUPPORTS_USERPTR``
+ - 0x0002
+ - This buffer type supports the ``V4L2_MEMORY_USERPTR`` streaming mode.
+* - ``V4L2_BUF_CAP_SUPPORTS_DMABUF``
+ - 0x0004
+ - This buffer type supports the ``V4L2_MEMORY_DMABUF`` streaming mode.
+* - ``V4L2_BUF_CAP_SUPPORTS_REQUESTS``
+ - 0x0008
+ - This buffer type supports :ref:`requests `.
Return Value
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2350151ce4ea..55d45a387dd2 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -856,9 +856,16 @@ struct v4l2_requestbuffers {
__u32 count;
__u32 type; /* enum v4l2_buf_type */
__u32 memory; /* enum v4l2_memory */
- __u32 reserved[2];
+ __u32 capabilities;
+ __u32 reserved[1];
};
+/* capabilities for struct v4l2_requestbuffers and v4l2_create_buffers */
+#define V4L2_BUF_CAP_SUPPORTS_MMAP (1 << 0)
+#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
+#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
+#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+
/**
* struct v4l2_plane - plane info for multi-planar buffers
* @bytesused: number of bytes occupied by data in the plane (payload)
@@ -2319,6 +2326,7 @@ struct v4l2_dbg_chip_info {
* return: number of created buffers
* @memory:enum v4l2_memory;
[PATCH v2 1/2] media: ov2680: don't register the v4l2 subdevice before checking chip ID
The driver registers the v4l2 subdevice before attempting to power on the
chip and checking its ID. This means that a media device driver that it's
waiting for this subdevice to be bound, will prematurely expose its media
device node to userspace because if something goes wrong the media entity
will be cleaned up again on the ov2680 probe function.
This also simplifies the probe function error path since no initialization
is made before attempting to enable the resources or checking the chip ID.
Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Just move ov2680_check_id() before ov2680_v4l2_init() - Suggested by Sakari.
drivers/media/i2c/ov2680.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c
index f753a1c333ef..3ccd584568fb 100644
--- a/drivers/media/i2c/ov2680.c
+++ b/drivers/media/i2c/ov2680.c
@@ -1088,26 +1088,20 @@ static int ov2680_probe(struct i2c_client *client)
mutex_init(>lock);
- ret = ov2680_v4l2_init(sensor);
+ ret = ov2680_check_id(sensor);
if (ret < 0)
goto lock_destroy;
- ret = ov2680_check_id(sensor);
+ ret = ov2680_v4l2_init(sensor);
if (ret < 0)
- goto error_cleanup;
+ goto lock_destroy;
dev_info(dev, "ov2680 init correctly\n");
return 0;
-error_cleanup:
- dev_err(dev, "ov2680 init fail: %d\n", ret);
-
- media_entity_cleanup(>sd.entity);
- v4l2_async_unregister_subdev(>sd);
- v4l2_ctrl_handler_free(>ctrls.handler);
-
lock_destroy:
+ dev_err(dev, "ov2680 init fail: %d\n", ret);
mutex_destroy(>lock);
return ret;
--
2.17.1
[PATCHv3 01/10] media-request: return -EINVAL for invalid request_fds
From: Hans Verkuil Instead of returning -ENOENT when a request_fd was not found (VIDIOC_QBUF and VIDIOC_G/S/TRY_EXT_CTRLS), we now return -EINVAL. This is in line with what we do when invalid dmabuf fds are passed to e.g. VIDIOC_QBUF. Also document that EINVAL is returned for invalid m.fd values, we never documented that. Signed-off-by: Hans Verkuil Reviewed-by: Tomasz Figa --- Documentation/media/uapi/v4l/buffer.rst| 4 ++-- .../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 18 -- Documentation/media/uapi/v4l/vidioc-qbuf.rst | 12 +--- drivers/media/media-request.c | 6 -- 4 files changed, 19 insertions(+), 21 deletions(-) diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst index dd0065a95ea0..35c2fadd10de 100644 --- a/Documentation/media/uapi/v4l/buffer.rst +++ b/Documentation/media/uapi/v4l/buffer.rst @@ -313,8 +313,8 @@ struct v4l2_buffer queued to that request. This is set by the user when calling :ref:`ioctl VIDIOC_QBUF ` and ignored by other ioctls. If the device does not support requests, then ``EPERM`` will be returned. - If requests are supported but an invalid request FD is given, then - ``ENOENT`` will be returned. + If requests are supported but an invalid request file descriptor is + given, then ``EINVAL`` will be returned. diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst index 771fd1161277..9c56a9b6e98a 100644 --- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst @@ -101,8 +101,8 @@ then the controls are not applied immediately when calling :ref:`VIDIOC_S_EXT_CTRLS `, but instead are applied by the driver for the buffer associated with the same request. If the device does not support requests, then ``EPERM`` will be returned. -If requests are supported but an invalid request FD is given, then -``ENOENT`` will be returned. +If requests are supported but an invalid request file descriptor is given, +then ``EINVAL`` will be returned. An attempt to call :ref:`VIDIOC_S_EXT_CTRLS ` for a request that has already been queued will result in an ``EBUSY`` error. @@ -301,8 +301,8 @@ still cause this situation. - File descriptor of the request to be used by this operation. Only valid if ``which`` is set to ``V4L2_CTRL_WHICH_REQUEST_VAL``. If the device does not support requests, then ``EPERM`` will be returned. - If requests are supported but an invalid request FD is given, then - ``ENOENT`` will be returned. + If requests are supported but an invalid request file descriptor is + given, then ``EINVAL`` will be returned. * - __u32 - ``reserved``\ [1] - Reserved for future extensions. @@ -378,11 +378,13 @@ appropriately. The generic error codes are described at the EINVAL The struct :c:type:`v4l2_ext_control` ``id`` is -invalid, the struct :c:type:`v4l2_ext_controls` +invalid, or the struct :c:type:`v4l2_ext_controls` ``which`` is invalid, or the struct :c:type:`v4l2_ext_control` ``value`` was inappropriate (e.g. the given menu index is not supported by the -driver). This error code is also returned by the +driver), or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` +but the given ``request_fd`` was invalid. +This error code is also returned by the :ref:`VIDIOC_S_EXT_CTRLS ` and :ref:`VIDIOC_TRY_EXT_CTRLS ` ioctls if two or more control values are in conflict. @@ -409,7 +411,3 @@ EACCES EPERM The ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the device does not support requests. - -ENOENT -The ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the -the given ``request_fd`` was invalid. diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst b/Documentation/media/uapi/v4l/vidioc-qbuf.rst index 0e415f2551b2..7bff69c15452 100644 --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst @@ -105,8 +105,8 @@ 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. If the device does not support requests, then ``EPERM`` will be returned. -If requests are supported but an invalid request FD is given, then -``ENOENT`` will be returned. +If requests are supported but an invalid request file descriptor is given, +then ``EINVAL`` will be returned. .. caution:: It is not allowed to mix queuing requests with queuing buffers directly. @@ -152,7 +152,9 @@ EAGAIN EINVAL The buffer ``type`` is not supported, or the ``index`` is out of bounds, or no buffers have been allocated yet, or the ``userptr`` or -``length`` are
[PATCHv3 08/10] v4l2-ctrls: improve media_request_(un)lock_for_update
From: Hans Verkuil
The request reference count was decreased again once a reference to the
request object was taken. Postpone this until we finished using the object.
In theory I think it is possible that the request_fd can be closed by
the application from another thread. In that case when request_put is
called the whole request would be freed.
It's highly unlikely, but let's just be safe and fix this potential
race condition.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomasz Figa
---
drivers/media/v4l2-core/v4l2-ctrls.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index cc266a4a6e88..95d065d54308 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3657,10 +3657,9 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh,
}
obj = v4l2_ctrls_find_req_obj(hdl, req, set);
- /* Reference to the request held through obj */
- media_request_put(req);
if (IS_ERR(obj)) {
media_request_unlock_for_update(req);
+ media_request_put(req);
return PTR_ERR(obj);
}
hdl = container_of(obj, struct v4l2_ctrl_handler,
@@ -3670,8 +3669,9 @@ static int try_set_ext_ctrls(struct v4l2_fh *fh,
ret = try_set_ext_ctrls_common(fh, hdl, cs, set);
if (obj) {
- media_request_unlock_for_update(obj->req);
+ media_request_unlock_for_update(req);
media_request_object_put(obj);
+ media_request_put(req);
}
return ret;
--
2.18.0
[PATCHv3 02/10] v4l2-ctrls: return -EACCES if request wasn't completed
From: Hans Verkuil
For now (this might be relaxed in the future) we do not allow getting
controls from a request that isn't completed. In that case we return
-EACCES. Update the documentation accordingly.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomasz Figa
---
.../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 18 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 5 ++---
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
index 9c56a9b6e98a..ad8908ce3095 100644
--- a/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
+++ b/Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst
@@ -107,13 +107,12 @@ then ``EINVAL`` will be returned.
An attempt to call :ref:`VIDIOC_S_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 `, 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 been queued, or the
-values of the controls at the time of request completion if it has already
-completed. Attempting to get controls while the request has been queued but
-not yet completed 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 `, then it will return the
+values of the controls at the time of request completion.
+If the request is not yet completed, then this will result in an
+``EACCES`` error.
The driver will only set/get these controls if all control values are
correct. This prevents the situation where only some of the controls
@@ -405,8 +404,9 @@ ENOSPC
and this error code is returned.
EACCES
-Attempt to try or set a read-only control or to get a write-only
-control.
+Attempt to try or set a read-only control, or to get a write-only
+control, or to get a control from a request that has not yet been
+completed.
EPERM
The ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index a197b60183f5..ccaf3068de6d 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3301,10 +3301,9 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
struct media_device *mdev,
if (IS_ERR(req))
return PTR_ERR(req);
- if (req->state != MEDIA_REQUEST_STATE_IDLE &&
- req->state != MEDIA_REQUEST_STATE_COMPLETE) {
+ if (req->state != MEDIA_REQUEST_STATE_COMPLETE) {
media_request_put(req);
- return -EBUSY;
+ return -EACCES;
}
obj = v4l2_ctrls_find_req_obj(hdl, req, false);
--
2.18.0
[PATCHv3 07/10] v4l2-ctrls: use media_request_(un)lock_for_access
From: Hans Verkuil
When getting control values from a completed request, we have
to protect the request against being re-inited when it is
being accessed by calling media_request_(un)lock_for_access.
Signed-off-by: Hans Verkuil
Reviewed-by: Tomasz Figa
---
drivers/media/v4l2-core/v4l2-ctrls.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index ccaf3068de6d..cc266a4a6e88 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -3289,11 +3289,10 @@ 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;
+ struct media_request *req = NULL;
int ret;
if (cs->which == V4L2_CTRL_WHICH_REQUEST_VAL) {
- struct media_request *req;
-
if (!mdev || cs->request_fd < 0)
return -EINVAL;
@@ -3306,11 +3305,18 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
struct media_device *mdev,
return -EACCES;
}
+ ret = media_request_lock_for_access(req);
+ if (ret) {
+ media_request_put(req);
+ return ret;
+ }
+
obj = v4l2_ctrls_find_req_obj(hdl, req, false);
- /* Reference to the request held through obj */
- media_request_put(req);
- if (IS_ERR(obj))
+ if (IS_ERR(obj)) {
+ media_request_unlock_for_access(req);
+ media_request_put(req);
return PTR_ERR(obj);
+ }
hdl = container_of(obj, struct v4l2_ctrl_handler,
req_obj);
@@ -3318,8 +3324,11 @@ int v4l2_g_ext_ctrls(struct v4l2_ctrl_handler *hdl,
struct media_device *mdev,
ret = v4l2_g_ext_ctrls_common(hdl, cs);
- if (obj)
+ if (obj) {
+ media_request_unlock_for_access(req);
media_request_object_put(obj);
+ media_request_put(req);
+ }
return ret;
}
EXPORT_SYMBOL(v4l2_g_ext_ctrls);
--
2.18.0
[PATCH] vicodec: fix wrong sizeimage
The initial sizeimage for the compressed decoder output was wrong.
The size of the output was incorrectly used to calculate the image
size, that should have been the size of the capture.
Rework the code to fix this.
Signed-off-by: Hans Verkuil
---
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index fdd77441a47b..47e9ad0941ab 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -1186,23 +1186,28 @@ static int vicodec_open(struct file *file)
ctx->q_data[V4L2_M2M_SRC].height = 720;
size = 1280 * 720 * ctx->q_data[V4L2_M2M_SRC].info->sizeimage_mult /
ctx->q_data[V4L2_M2M_SRC].info->sizeimage_div;
- ctx->q_data[V4L2_M2M_SRC].sizeimage = size;
+ if (ctx->is_enc)
+ ctx->q_data[V4L2_M2M_SRC].sizeimage = size;
+ else
+ ctx->q_data[V4L2_M2M_SRC].sizeimage =
+ size + sizeof(struct fwht_cframe_hdr);
ctx->q_data[V4L2_M2M_DST] = ctx->q_data[V4L2_M2M_SRC];
ctx->q_data[V4L2_M2M_DST].info =
ctx->is_enc ? _fwht : v4l2_fwht_get_pixfmt(0);
size = 1280 * 720 * ctx->q_data[V4L2_M2M_DST].info->sizeimage_mult /
ctx->q_data[V4L2_M2M_DST].info->sizeimage_div;
- ctx->q_data[V4L2_M2M_DST].sizeimage = size;
+ if (ctx->is_enc)
+ ctx->q_data[V4L2_M2M_DST].sizeimage =
+ size + sizeof(struct fwht_cframe_hdr);
+ else
+ ctx->q_data[V4L2_M2M_DST].sizeimage = size;
ctx->state.colorspace = V4L2_COLORSPACE_REC709;
- size += sizeof(struct fwht_cframe_hdr);
if (ctx->is_enc) {
- ctx->q_data[V4L2_M2M_DST].sizeimage = size;
ctx->fh.m2m_ctx = v4l2_m2m_ctx_init(dev->enc_dev, ctx,
_init);
ctx->lock = >enc_lock;
} else {
- ctx->q_data[V4L2_M2M_SRC].sizeimage = size;
ctx->fh.m2m_ctx = v4l2_m2m_ctx_init(dev->dec_dev, ctx,
_init);
ctx->lock = >dec_lock;
Re: [PATCH] media: ov2680: register the v4l2 subdev async at the end of probe
Hi Sakari,
Thanks for the feedback.
On 09/01/2018 01:46 PM, Sakari Ailus wrote:
> Hi Javier,
>
> On Fri, Aug 31, 2018 at 05:19:06PM +0200, Javier Martinez Canillas wrote:
>> The driver registers the subdev async in the middle of the probe function
>> but this has to be done at the very end of the probe function to prevent
>> registering a device whose probe function could fail (i.e: the clock and
>> regulators enable can fail, the I2C transfers could return errors, etc).
>>
>> It could also lead to a media device driver that is waiting to bound the
>> v4l2 subdevice to incorrectly expose its media device to userspace, since
>> the subdev is registered but later its media entity is cleaned up on error.
>>
>> Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver")
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>>
>> drivers/media/i2c/ov2680.c | 9 -
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c
>> index f753a1c333ef..2ef920a17278 100644
>> --- a/drivers/media/i2c/ov2680.c
>> +++ b/drivers/media/i2c/ov2680.c
>> @@ -983,10 +983,6 @@ static int ov2680_v4l2_init(struct ov2680_dev *sensor)
>>
>> sensor->sd.ctrl_handler = hdl;
>>
>> -ret = v4l2_async_register_subdev(>sd);
>> -if (ret < 0)
>> -goto cleanup_entity;
>> -
>> return 0;
>>
>> cleanup_entity:
>> @@ -1096,6 +1092,10 @@ static int ov2680_probe(struct i2c_client *client)
>> if (ret < 0)
>> goto error_cleanup;
>
> How about instead moving ov2680_check_id() call earlier in probe()? That
> would seem to be a better fix: the driver should check the device is around
> before registering anything.
>
Yes, that would work too. We can't move it too early though since it has to
be after the DT was parsed, the regulator, clocks and gpio looked up, etc.
But moving ov2680_check_id() before ov2680_v4l2_init() would work indeed,
in that case ov2680_v4l2_init() should be renamed to ov2680_v4l2_register()
I think to make it clear that the function not only does initialization but
also register the v4l2 subdevice.
I'll post a v2 doing what you suggest.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Re: [PATCH v2] media: ov5640: do not change mode if format or frame interval is unchanged
On Thu, Aug 16, 2018 at 09:56:13AM +, Hugues FRUCHET wrote: > Hi all, > > Please ignore this v2, the v1 was merged. > I've just pushed a new patch which fixes the regression observed, see: > https://www.mail-archive.com/linux-media@vger.kernel.org/msg134413.html > > Sorry for inconvenience. No worries; thanks for the fix! -- Sakari Ailus e-mail: sakari.ai...@iki.fi
