All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org, posciak@chromium.org,
	m.szyprowski@samsung.com, kyungmin.park@samsung.com,
	hverkuil@xs4all.nl, sumit.semwal@linaro.org, robdclark@gmail.com,
	daniel.vetter@ffwll.ch, labbott@redhat.com,
	laurent.pinchart@ideasonboard.com
Subject: [RFC v4 04/18] v4l: Unify cache management hint buffer flags
Date: Mon,  8 May 2017 18:03:16 +0300	[thread overview]
Message-ID: <1494255810-12672-5-git-send-email-sakari.ailus@linux.intel.com> (raw)
In-Reply-To: <1494255810-12672-1-git-send-email-sakari.ailus@linux.intel.com>

The V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and V4L2_BUF_FLAG_NO_CACHE_CLEAN
buffer flags are currently not used by the kernel. Replace the definitions
by a single V4L2_BUF_FLAG_NO_CACHE_SYNC flag to be used by further
patches.

Different cache architectures should not be visible to the user space
which can make no meaningful use of the differences anyway. In case a
device can make use of non-coherent memory accesses, the necessary cache
operations depend on the CPU architecture and the buffer type, not the
requests of the user. The cache operation itself may be skipped on the
user's request which was the purpose of the two flags.

On ARM the invalidate and clean are separate operations whereas on
x86(-64) the two are a single operation (flush). Whether the hardware uses
the buffer for reading (V4L2_BUF_TYPE_*_OUTPUT*) or writing
(V4L2_BUF_TYPE_*CAPTURE*) already defines the required cache operation
(clean and invalidate, respectively). No user input is required.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 Documentation/media/uapi/v4l/buffer.rst            | 24 ++++++++--------------
 .../media/uapi/v4l/vidioc-prepare-buf.rst          |  5 ++---
 include/trace/events/v4l2.h                        |  3 +--
 include/uapi/linux/videodev2.h                     |  7 +++++--
 4 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/Documentation/media/uapi/v4l/buffer.rst b/Documentation/media/uapi/v4l/buffer.rst
index ae6ee73..9eb42bd 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -559,23 +559,17 @@ Buffer Flags
 	:ref:`VIDIOC_PREPARE_BUF <VIDIOC_QBUF>`,
 	:ref:`VIDIOC_QBUF` or
 	:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called.
-    * .. _`V4L2-BUF-FLAG-NO-CACHE-INVALIDATE`:
+    * .. _`V4L2-BUF-FLAG-NO-CACHE-SYNC`:
 
-      - ``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE``
+      - ``V4L2_BUF_FLAG_NO_CACHE_SYNC``
       - 0x00000800
-      - Caches do not have to be invalidated for this buffer. Typically
-	applications shall use this flag if the data captured in the
-	buffer is not going to be touched by the CPU, instead the buffer
-	will, probably, be passed on to a DMA-capable hardware unit for
-	further processing or output.
-    * .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`:
-
-      - ``V4L2_BUF_FLAG_NO_CACHE_CLEAN``
-      - 0x00001000
-      - Caches do not have to be cleaned for this buffer. Typically
-	applications shall use this flag for output buffers if the data in
-	this buffer has not been created by the CPU but by some
-	DMA-capable unit, in which case caches have not been used.
+      - Do not perform CPU cache synchronisation operations when the buffer is
+	queued or dequeued. The user is responsible for the correct use of
+	this flag. It should be only used when the buffer is not accessed
+	using the CPU, e.g. the buffer is written to by a hardware block and
+	then read by another one, in which case the flag should be set in both
+	:ref:`VIDIOC_QBUF` and :ref:`VIDIOC_DQBUF` ioctls. This flag has no
+	effect on some devices / architectures.
     * .. _`V4L2-BUF-FLAG-LAST`:
 
       - ``V4L2_BUF_FLAG_LAST``
diff --git a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
index bdcfd9f..80aeb7e 100644
--- a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
@@ -36,9 +36,8 @@ pass ownership of the buffer to the driver before actually enqueuing it,
 using the :ref:`VIDIOC_QBUF` ioctl, and to prepare it for future I/O. Such
 preparations may include cache invalidation or cleaning. Performing them
 in advance saves time during the actual I/O. In case such cache
-operations are not required, the application can use one of
-``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE`` and
-``V4L2_BUF_FLAG_NO_CACHE_CLEAN`` flags to skip the respective step.
+operations are not required, the application can use the
+``V4L2_BUF_FLAG_NO_CACHE_SYNC`` flag to skip the cache synchronization step.
 
 The struct :c:type:`v4l2_buffer` structure is specified in
 :ref:`buffer`.
diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h
index b3a85b3..3d5897d 100644
--- a/include/trace/events/v4l2.h
+++ b/include/trace/events/v4l2.h
@@ -81,8 +81,7 @@ SHOW_FIELD
 		{ V4L2_BUF_FLAG_ERROR,		     "ERROR" },		      \
 		{ V4L2_BUF_FLAG_TIMECODE,	     "TIMECODE" },	      \
 		{ V4L2_BUF_FLAG_PREPARED,	     "PREPARED" },	      \
-		{ V4L2_BUF_FLAG_NO_CACHE_INVALIDATE, "NO_CACHE_INVALIDATE" }, \
-		{ V4L2_BUF_FLAG_NO_CACHE_CLEAN,	     "NO_CACHE_CLEAN" },      \
+		{ V4L2_BUF_FLAG_NO_CACHE_SYNC,	     "NO_CACHE_SYNC" },	      \
 		{ V4L2_BUF_FLAG_TIMESTAMP_MASK,	     "TIMESTAMP_MASK" },      \
 		{ V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN,   "TIMESTAMP_UNKNOWN" },   \
 		{ V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC, "TIMESTAMP_MONOTONIC" }, \
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 2b8feb8..2e046bb 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -939,8 +939,11 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_TIMECODE			0x00000100
 /* Buffer is prepared for queuing */
 #define V4L2_BUF_FLAG_PREPARED			0x00000400
-/* Cache handling flags */
-#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE	0x00000800
+/* Cache sync hint */
+#define V4L2_BUF_FLAG_NO_CACHE_SYNC		0x00000800
+/* DEPRECATED. THIS WILL BE REMOVED IN THE FUTURE! */
+#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE	V4L2_BUF_FLAG_NO_CACHE_SYNC
+/* DEPRECATED. THIS WILL BE REMOVED IN THE FUTURE! */
 #define V4L2_BUF_FLAG_NO_CACHE_CLEAN		0x00001000
 /* Timestamp type */
 #define V4L2_BUF_FLAG_TIMESTAMP_MASK		0x0000e000
-- 
2.7.4

  parent reply	other threads:[~2017-05-08 15:04 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-08 15:03 [RFC v4 00/18] vb2: Handle user cache hints, allow drivers to choose cache coherency Sakari Ailus
2017-05-08 15:03 ` [RFC v4 01/18] vb2: Rename confusingly named internal buffer preparation functions Sakari Ailus
2017-05-08 15:03 ` [RFC v4 02/18] vb2: Move buffer cache synchronisation to prepare from queue Sakari Ailus
2017-05-08 15:03   ` Sakari Ailus
2017-05-08 15:03 ` [RFC v4 03/18] vb2: Move cache synchronisation from buffer done to dqbuf handler Sakari Ailus
2018-10-05  4:34   ` Tomasz Figa
2018-10-05  4:34     ` Tomasz Figa
2017-05-08 15:03 ` Sakari Ailus [this message]
2017-05-08 15:03 ` [RFC v4 05/18] vb2: Anticipate queue specific DMA attributes for USERPTR buffers Sakari Ailus
2017-05-08 15:03 ` [RFC v4 06/18] vb2: dma-contig: Assign DMA attrs for a buffer unconditionally Sakari Ailus
2017-05-08 15:03 ` [RFC v4 07/18] vb2: dma-contig: Remove redundant sgt_base field Sakari Ailus
2017-05-10 10:13   ` Tomasz Figa
2017-05-10 10:13     ` Tomasz Figa
2017-05-08 15:03 ` [RFC v4 08/18] vb2: dma-contig: Don't warn on failure in obtaining scatterlist Sakari Ailus
2017-05-08 15:03   ` Sakari Ailus
2017-05-08 15:03 ` [RFC v4 09/18] vb2: dma-contig: Allocate sgt as part of struct vb2_dc_buf Sakari Ailus
2017-05-08 15:03 ` [RFC v4 10/18] vb2: dma-contig: Fix DMA attribute and cache management Sakari Ailus
2017-05-08 15:03   ` Sakari Ailus
2017-05-10 10:32   ` Tomasz Figa
2017-05-23 12:07     ` Sakari Ailus
2017-05-23 12:07       ` Sakari Ailus
2017-05-08 15:03 ` [RFC v4 11/18] vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs Sakari Ailus
2017-05-08 15:03 ` [RFC v4 12/18] vb2: dma-sg: Let drivers decide DMA attrs of MMAP and USERPTR bufs Sakari Ailus
2017-05-08 15:03 ` [RFC v4 13/18] vb2: Don't sync cache for a buffer if so requested Sakari Ailus
2017-05-10 11:00   ` Tomasz Figa
2017-05-23 12:35     ` Sakari Ailus
2017-05-08 15:03 ` [RFC v4 14/18] vb2: Improve struct vb2_mem_ops documentation; alloc and put are for MMAP Sakari Ailus
2017-05-08 15:03 ` [RFC v4 15/18] vb2: Dma direction is always DMA_TO_DEVICE in buffer preparation Sakari Ailus
2017-05-08 15:03 ` [RFC v4 16/18] vb2: Do sync plane cache only for CAPTURE buffers in finish memop Sakari Ailus
2017-05-08 15:03 ` [RFC v4 17/18] docs-rst: Document precise V4L2_BUF_FLAG_NO_CACHE_SYNC flag behaviour Sakari Ailus
2017-05-08 15:03 ` [RFC v4 18/18] v4l: Use non-consistent DMA mappings for hardware that deserves it Sakari Ailus
2017-06-07 17:13 ` [RFC v4 00/18] vb2: Handle user cache hints, allow drivers to choose cache coherency Mauro Carvalho Chehab
2017-06-07 20:56   ` Sakari Ailus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1494255810-12672-5-git-send-email-sakari.ailus@linux.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=kyungmin.park@samsung.com \
    --cc=labbott@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=posciak@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.