brcm2708: update to latest patches from the RPi foundation

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>

1 files changed, 76 insertions, 0 deletions

diff --git a/target/linux/brcm2708/patches-4.19/950-0282-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch b/target/linux/brcm2708/patches-4.19/950-0282-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch
new file mode 100644
index 0000000000..de40adf6f3
--- /dev/null
+++ b/target/linux/brcm2708/patches-4.19/950-0282-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch
@@ -0,0 +1,76 @@
+From b326f198daeac021ba83802b5e4502f8b22c1604 Mon Sep 17 00:00:00 2001
+From: John Sheu <sheu@chromium.org>
+Date: Thu, 15 Oct 2015 18:05:25 +0900
+Subject: [PATCH 282/725] 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
+@@ -554,20 +554,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);
+@@ -679,16 +665,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