brcm2708: add linux 4.19 support

Boot tested on Raspberry Pi B+ (BCM2708) and Raspberry Pi 2 (BCM2709)

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

1 files changed, 130 insertions, 0 deletions

diff --git a/target/linux/brcm2708/patches-4.19/950-0699-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch b/target/linux/brcm2708/patches-4.19/950-0699-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch
new file mode 100644
index 0000000000..0ee04e6c29
--- /dev/null
+++ b/target/linux/brcm2708/patches-4.19/950-0699-media-vb2-Allow-reqbufs-0-with-in-use-MMAP-buffers.patch
@@ -0,0 +1,130 @@
+From b0102490b31330eb694a7956e1874e172ad07ec1 Mon Sep 17 00:00:00 2001
+From: John Sheu <sheu@chromium.org>
+Date: Thu, 15 Nov 2018 10:57:16 -0500
+Subject: [PATCH 699/703] 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
+@@ -680,11 +680,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