Commit 15cd442e authored by Hans Verkuil's avatar Hans Verkuil Committed by Mauro Carvalho Chehab
Browse files

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: default avatarHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: default avatarTomasz Figa <tfiga@chromium.org>
Acked-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
parent ffda0b4c

Documentation/media/uapi/mediactl/media-request-ioc-queue.rst

+4 −5
Original line number Diff line number Diff line
@@ -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 <gen-errors>` 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

Documentation/media/uapi/mediactl/request-api.rst

+2 −2
Original line number Diff line number Diff line
@@ -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,

Documentation/media/uapi/v4l/buffer.rst

+1 −1
Original line number Diff line number Diff line
@@ -314,7 +314,7 @@ struct v4l2_buffer 
	:ref:`ioctl VIDIOC_QBUF <VIDIOC_QBUF>` and ignored by other ioctls.

	Applications should not set ``V4L2_BUF_FLAG_REQUEST_FD`` for any ioctls

	other than :ref:`VIDIOC_QBUF <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.

Documentation/media/uapi/v4l/vidioc-g-ext-ctrls.rst

+4 −5
Original line number Diff line number Diff line
@@ -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 <VIDIOC_G_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.

Documentation/media/uapi/v4l/vidioc-qbuf.rst

+10 −8
Original line number Diff line number Diff line
@@ -104,18 +104,18 @@ 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.



.. caution::

   It is not allowed to mix queuing requests with queuing buffers directly.

   ``EPERM`` will be returned if the first buffer was queued directly and

   ``EBUSY`` will be returned if the first buffer was queued directly and

   then the application tries to queue a request, or vice versa.



   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 ``EPERM`` error.

   to specify this for a capture buffer will result in an ``EACCES`` error.



Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled

(capturing) or displayed (output) buffer from the driver's outgoing
@@ -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 device <codec>`.
 
    support requests for the given buffer type.



EBUSY

    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).

CRA Git | Maintained and supported by SUSTech CRA and CCSE