- 24 Sep, 2018 5 commits
-
-
Paul Kocialkowski authored
This introduces support for the Sunxi tiled NV12 format, where each component of the YUV frame is divided into macroblocks. Hence, the size of each plane requires specific alignment. The pixels inside each macroblock are coded in linear order (line after line from top to bottom). This tiled NV12 format is used by the video engine on Allwinner platforms: it is the default format for decoded frames (and the only one available in the oldest supported platforms). Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Paul Kocialkowski authored
Stateless video decoding engines require both the MPEG-2 slices and associated metadata from the video stream in order to decode frames. This introduces definitions for a new pixel format, describing buffers with MPEG-2 slice data, as well as control structure sfor passing the frame metadata to drivers. This is based on work from both Florent Revest and Hugues Fruchet. Signed-off-by:
-
Paul Kocialkowski authored
The helper indicating whether buffers are associated with the request is reworked and renamed to return the number of associated buffer objects. This is useful for drivers that need to check how many buffers are in the request to validate it. Existing users of the helper don't need particular adaptation since the meaning of zero/non-zero remains consistent. Signed-off-by:
Paul Kocialkowski <contact@paulk.fr> Signed-off-by:
-
Hans Verkuil authored
Fix this smatch error: drivers/media/v4l2-core/v4l2-ctrls.c:2971 v4l2_ctrl_request_clone() error: uninitialized symbol 'err'. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Hans Verkuil authored
Fix this sparse warning: drivers/media/v4l2-core/v4l2-compat-ioctl32.c:256: warning: Function parameter or member 'capabilities' not described in 'v4l2_create_buffers32' Signed-off-by:
-
- 11 Sep, 2018 10 commits
-
-
Hans Verkuil authored
Various clarifications and readability improvements based on Laurent Pinchart's review of the documentation. Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Acked-by:
-
Hans Verkuil authored
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 authored
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 authored
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 authored
Add helper functions to prevent a completed request from being re-inited while it is being accessed. Signed-off-by:
-
Hans Verkuil authored
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 <hansverk@cisco.com> Reviewed-by:
-
Hans Verkuil authored
VIDIOC_REQBUFS and VIDIOC_CREATE_BUFFERS will return capabilities telling userspace what the given buffer type is capable of. Signed-off-by:
-
Hans Verkuil authored
Document that V4L2_BUF_FLAG_REQUEST_FD should only be used with VIDIOC_QBUF and cleared otherwise. Signed-off-by:
-
Hans Verkuil authored
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 authored
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:
-
- 31 Aug, 2018 25 commits
-
-
Hans Verkuil authored
Add support for requests to vivid. Signed-off-by:
-
Hans Verkuil authored
Add support for the media_device to vivid. This is a prerequisite for request support. Signed-off-by:
-
Hans Verkuil authored
Add support for requests to vim2m. Signed-off-by:
-
Hans Verkuil authored
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 authored
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 authored
Check if the vb2 queue uses requests, and if so refuse to add buffers that are not part of a request. Also check for the reverse: a vb2 queue did not use requests, and an attempt was made to queue a buffer to a request. We might relax this in the future, but for now just return -EPERM in that case. Signed-off-by:
-
Hans Verkuil authored
Set the first time a buffer from a request is queued to vb2 (uses_requests) or directly queued (uses_qbuf). Cleared when the queue is canceled. Signed-off-by:
-
Hans Verkuil authored
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 authored
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 authored
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 authored
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 authored
Make vb2_buffer a request object. Signed-off-by:
-
Hans Verkuil authored
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 authored
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 authored
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 authored
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 authored
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 authored
Replace 'if' statements by a switch in __fill_vb2_buffer() in preparation of the next patch. No other changes. Signed-off-by:
-
Hans Verkuil authored
Move the __fill_v4l2_buffer() to before the vb2_queue_or_prepare_buf() function to prepare for the next two patches. No other changes. Signed-off-by:
-
Hans Verkuil authored
If a driver needs to find/inspect the controls set in a request then it can use these functions. E.g. to check if a required control is set in a request use this in the req_validate() implementation: int res = -EINVAL; hdl = v4l2_ctrl_request_hdl_find(req, parent_hdl); if (hdl) { if (v4l2_ctrl_request_hdl_ctrl_find(hdl, ctrl_id)) res = 0; v4l2_ctrl_request_hdl_put(hdl); } return res; Signed-off-by: -
Hans Verkuil authored
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 authored
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 authored
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 authored
To store request data the handler_new_ref() allocates memory for it if needed. Signed-off-by:
-
Hans Verkuil authored
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:
Alexandre Courbot <acourbot@chromium.org> Reviewed-by:
-
