diff options
Diffstat (limited to 'target/linux/brcm2708/patches-4.19/950-0604-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch')
| -rw-r--r-- | target/linux/brcm2708/patches-4.19/950-0604-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch | 130 |
1 files changed, 130 insertions, 0 deletions
diff --git a/target/linux/brcm2708/patches-4.19/950-0604-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch b/target/linux/brcm2708/patches-4.19/950-0604-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch new file mode 100644 index 0000000000..755ca34440 --- /dev/null +++ b/target/linux/brcm2708/patches-4.19/950-0604-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch @@ -0,0 +1,130 @@ +From 16cf378051d7fff6772a7acaecbacddec7822330 Mon Sep 17 00:00:00 2001 +From: John Sheu <sheu@chromium.org> +Date: Thu, 15 Nov 2018 10:57:16 -0500 +Subject: [PATCH] media: vb2: Allow reqbufs(0) with "in use" MMAP + buffers + +Upstream commit d644cca50f366cd109845ae92e37c09ed79adf81 + +Videobuf2 presently does not allow VIDIOC_REQBUFS to destroy outstanding +buffers if the queue is of type V4L2_MEMORY_MMAP, and if the buffers are +considered "in use". This is different behavior than for other memory +types and prevents us from deallocating buffers in following two cases: + +1) There are outstanding mmap()ed views on the buffer. However even if + we put the buffer in reqbufs(0), there will be remaining references, + due to vma .open/close() adjusting vb2 buffer refcount appropriately. + This means that the buffer will be in fact freed only when the last + mmap()ed view is unmapped. + +2) Buffer has been exported as a DMABUF. Refcount of the vb2 buffer + is managed properly by VB2 DMABUF ops, i.e. incremented on DMABUF + get and decremented on DMABUF release. This means that the buffer + will be alive until all importers release it. + +Considering both cases above, there does not seem to be any need to +prevent reqbufs(0) operation, because buffer lifetime is already +properly managed by both mmap() and DMABUF code paths. Let's remove it +and allow userspace freeing the queue (and potentially allocating a new +one) even though old buffers might be still in processing. + +To let userspace know that the kernel now supports orphaning buffers +that are still in use, add a new V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS +to be set by reqbufs and create_bufs. + +[p.zabel@pengutronix.de: added V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, + updated documentation, and added back debug message] + +Signed-off-by: John Sheu <sheu@chromium.org> +Reviewed-by: Pawel Osciak <posciak@chromium.org> +Signed-off-by: Tomasz Figa <tfiga@chromium.org> +Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> +Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> +Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> +[hverkuil-cisco@xs4all.nl: added V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS ref] +Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> +--- + Documentation/media/uapi/v4l/vidioc-reqbufs.rst | 17 ++++++++++++++--- + drivers/media/common/videobuf2/videobuf2-core.c | 8 +++----- + drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 +- + include/uapi/linux/videodev2.h | 1 + + 4 files changed, 19 insertions(+), 9 deletions(-) + +--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst ++++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst +@@ -59,9 +59,14 @@ When the I/O method is not supported the + code. + + Applications can call :ref:`VIDIOC_REQBUFS` again to change the number of +-buffers, however this cannot succeed when any buffers are still mapped. +-A ``count`` value of zero frees all buffers, after aborting or finishing +-any DMA in progress, an implicit ++buffers. Note that if any buffers are still mapped or exported via DMABUF, ++then :ref:`VIDIOC_REQBUFS` can only succeed if the ++``V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS`` capability is set. Otherwise ++:ref:`VIDIOC_REQBUFS` will return the ``EBUSY`` error code. ++If ``V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS`` is set, then these buffers are ++orphaned and will be freed when they are unmapped or when the exported DMABUF ++fds are closed. A ``count`` value of zero frees or orphans all buffers, after ++aborting or finishing any DMA in progress, an implicit + :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>`. + + +@@ -112,6 +117,7 @@ any DMA in progress, an implicit + .. _V4L2-BUF-CAP-SUPPORTS-USERPTR: + .. _V4L2-BUF-CAP-SUPPORTS-DMABUF: + .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS: ++.. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS: + + .. cssclass:: longtable + +@@ -132,6 +138,11 @@ any DMA in progress, an implicit + * - ``V4L2_BUF_CAP_SUPPORTS_REQUESTS`` + - 0x00000008 + - This buffer type supports :ref:`requests <media-request-api>`. ++ * - ``V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS`` ++ - 0x00000010 ++ - The kernel allows calling :ref:`VIDIOC_REQBUFS` while buffers are still ++ mapped or exported via DMABUF. These orphaned buffers will be freed ++ when they are unmapped or when the exported DMABUF fds are closed. + + Return Value + ============ +--- a/drivers/media/common/videobuf2/videobuf2-core.c ++++ b/drivers/media/common/videobuf2/videobuf2-core.c +@@ -684,11 +684,9 @@ int vb2_core_reqbufs(struct vb2_queue *q + * are not in use and can be freed. + */ + mutex_lock(&q->mmap_lock); +- if (q->memory == VB2_MEMORY_MMAP && __buffers_in_use(q)) { +- mutex_unlock(&q->mmap_lock); +- dprintk(1, "memory in use, cannot free\n"); +- return -EBUSY; +- } ++ if (debug && q->memory == VB2_MEMORY_MMAP && ++ __buffers_in_use(q)) ++ dprintk(1, "memory in use, orphaning buffers\n"); + + /* + * Call queue_cancel to clean up any buffers in the PREPARED or +--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c ++++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c +@@ -484,7 +484,7 @@ EXPORT_SYMBOL(vb2_querybuf); + + static void fill_buf_caps(struct vb2_queue *q, u32 *caps) + { +- *caps = 0; ++ *caps = V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS; + if (q->io_modes & VB2_MMAP) + *caps |= V4L2_BUF_CAP_SUPPORTS_MMAP; + if (q->io_modes & VB2_USERPTR) +--- a/include/uapi/linux/videodev2.h ++++ b/include/uapi/linux/videodev2.h +@@ -881,6 +881,7 @@ struct v4l2_requestbuffers { + #define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1) + #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2) + #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3) ++#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4) + + /** + * struct v4l2_plane - plane info for multi-planar buffers |