diff options
Diffstat (limited to 'target/linux/brcm2708/patches-4.19/950-0285-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch')
| -rw-r--r-- | target/linux/brcm2708/patches-4.19/950-0285-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/target/linux/brcm2708/patches-4.19/950-0285-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch b/target/linux/brcm2708/patches-4.19/950-0285-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch new file mode 100644 index 0000000000..df13c3b87c --- /dev/null +++ b/target/linux/brcm2708/patches-4.19/950-0285-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch @@ -0,0 +1,76 @@ +From 0f4f3fca8bb1e8283d5342d63e6758f6ac16d68d Mon Sep 17 00:00:00 2001 +From: John Sheu <sheu@chromium.org> +Date: Thu, 15 Oct 2015 18:05:25 +0900 +Subject: [PATCH 285/703] media: vb2: Allow reqbufs(0) with "in use" MMAP + buffers + +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. + +Signed-off-by: John Sheu <sheu@chromium.org> +Reviewed-by: Pawel Osciak <posciak@chromium.org> +Reviewed-by: Tomasz Figa <tfiga@chromium.org> +Signed-off-by: Tomasz Figa <tfiga@chromium.org> +--- + .../media/common/videobuf2/videobuf2-core.c | 23 ------------------- + 1 file changed, 23 deletions(-) + +--- a/drivers/media/common/videobuf2/videobuf2-core.c ++++ b/drivers/media/common/videobuf2/videobuf2-core.c +@@ -550,20 +550,6 @@ bool vb2_buffer_in_use(struct vb2_queue + } + EXPORT_SYMBOL(vb2_buffer_in_use); + +-/* +- * __buffers_in_use() - return true if any buffers on the queue are in use and +- * the queue cannot be freed (by the means of REQBUFS(0)) call +- */ +-static bool __buffers_in_use(struct vb2_queue *q) +-{ +- unsigned int buffer; +- for (buffer = 0; buffer < q->num_buffers; ++buffer) { +- if (vb2_buffer_in_use(q, q->bufs[buffer])) +- return true; +- } +- return false; +-} +- + void vb2_core_querybuf(struct vb2_queue *q, unsigned int index, void *pb) + { + call_void_bufop(q, fill_user_buffer, q->bufs[index], pb); +@@ -675,16 +661,7 @@ int vb2_core_reqbufs(struct vb2_queue *q + + if (*count == 0 || q->num_buffers != 0 || + (q->memory != VB2_MEMORY_UNKNOWN && q->memory != memory)) { +- /* +- * We already have buffers allocated, so first check if they +- * 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; +- } + + /* + * Call queue_cancel to clean up any buffers in the PREPARED or |