summaryrefslogtreecommitdiff
path: root/Documentation/media/uapi/mediactl/request-api.rst
diff options
context:
space:
mode:
authorHans Verkuil <hans.verkuil@cisco.com>2018-09-01 07:29:14 -0400
committerMauro Carvalho Chehab <mchehab+samsung@kernel.org>2018-09-11 09:57:29 -0400
commit15cd442e79e2a60a725ee5501e4ffb537698c802 (patch)
tree3a4b0356ca704fe66095ffeca6b9dc9a4be8c512 /Documentation/media/uapi/mediactl/request-api.rst
parentffda0b4c2481b2a0faf634abccb1da0d0ba4eddb (diff)
media: media-request: EPERM -> EACCES/EBUSY
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 <hans.verkuil@cisco.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Diffstat (limited to 'Documentation/media/uapi/mediactl/request-api.rst')
-rw-r--r--Documentation/media/uapi/mediactl/request-api.rst4
1 files changed, 2 insertions, 2 deletions
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 <codec>` 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 <VIDIOC_STREAMON>` is called or the device is
:ref:`closed <func-close>`. 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,