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
---
.../uapi/mediactl/media-request-ioc-queue.rst | 9 -
.../media/uapi/mediactl/request-api.rst| 4 ++--
Documentation/media/uapi/v4l/buffer.rst| 2 +-
.../media/uapi/v4l/vidioc-g-ext-ctrls.rst | 9 -
Documentation/media/uapi/v4l/vidioc-qbuf.rst | 18 ++
.../media/common/videobuf2/videobuf2-core.c| 2 +-
.../media/common/videobuf2/videobuf2-v4l2.c| 9 ++---
drivers/media/media-request.c | 4 ++--
include/media/media-request.h | 6 +++---
9 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
index d4f8119e0643..dbf635ae9b2b 100644
--- a/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
+++ b/Documentation/media/uapi/mediactl/media-request-ioc-queue.rst
@@ -49,7 +49,7 @@ exception is the ``EIO`` error which signals a fatal error
that requires
the application to stop streaming to reset the hardware state.
It is not allowed to mix queuing requests with queuing buffers directly
-(without a request). ``EPERM`` will be returned if the first buffer was
+(without a request). ``EBUSY`` will be returned if the first buffer was
queued directly and you next try to queue a request, or vice versa.
A request must contain at least one buffer, otherwise this ioctl will
@@ -63,10 +63,9 @@ appropriately. The generic error codes are described at the
:ref:`Generic Error Codes ` chapter.
EBUSY
-The request was already queued.
-EPERM
-The application queued the first buffer directly, but later attempted
-to use a request. It is not permitted to mix the two APIs.
+The request was already queued or the application queued the first
+buffer directly, but later attempted 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
diff --git a/Documentation/media/uapi/mediactl/request-api.rst
b/Documentation/media/uapi/mediactl/request-api.rst
index 0b9da58b01e3..aeb8d00934a4 100644
--- a/Documentation/media/uapi/mediactl/request-api.rst
+++ b/Documentation/media/uapi/mediactl/request-api.rst
@@ -64,7 +64,7 @@ request cannot be modified anymore.
.. caution::
For :ref:`memory-to-memory devices ` you can use requests only for
output buffers, not for capture buffers. Attempting to add a capture buffer
- to a request will result in an ``EPERM`` error.
+ to a request will result in an ``EACCES`` error.
If the request contains parameters for multiple entities, individual drivers
may
synchronize so the requested pipeline's topology is applied before the buffers
@@ -77,7 +77,7 @@ perfect atomicity may not be possible due to hardware
limitations.
whichever method is used first locks this in place until
:ref:`VIDIOC_STREAMOFF ` is called or the device is
:ref:`closed `. Attempts to directly queue a buffer when earlier
- a buffer was queued via a request or vice versa will result in an ``EPERM``
+ a buffer was queued via a request or vice versa will result in an ``EBUSY``
error.
Controls can still be set without a request and are applied immediately,
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
