From: Hans Verkuil <hverkuil@xs4all.nl>
To: Sakari Ailus <sakari.ailus@linux.intel.com>, linux-media@vger.kernel.org
Cc: pawel@osciak.com, m.szyprowski@samsung.com,
kyungmin.park@samsung.com, sumit.semwal@linaro.org,
robdclark@gmail.com, daniel.vetter@ffwll.ch, labbott@redhat.com
Subject: Re: [RFC RESEND 04/11] v4l: Unify cache management hint buffer flags
Date: Fri, 11 Sep 2015 18:26:54 +0200 [thread overview]
Message-ID: <55F300CE.5060204@xs4all.nl> (raw)
In-Reply-To: <1441972234-8643-5-git-send-email-sakari.ailus@linux.intel.com>
On 09/11/2015 01:50 PM, Sakari Ailus wrote:
> 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/DocBook/media/v4l/io.xml | 25 +++++++++++--------------
> include/trace/events/v4l2.h | 3 +--
> include/uapi/linux/videodev2.h | 7 +++++--
> 3 files changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
> index 7bbc2a4..4facd63 100644
> --- a/Documentation/DocBook/media/v4l/io.xml
> +++ b/Documentation/DocBook/media/v4l/io.xml
> @@ -1112,21 +1112,18 @@ application. Drivers set or clear this flag when the
> linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called.</entry>
> </row>
> <row>
> - <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
> + <entry><constant>V4L2_BUF_FLAG_NO_CACHE_SYNC</constant></entry>
> <entry>0x00000800</entry>
> - <entry>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.
> -</entry>
> - </row>
> - <row>
> - <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
> - <entry>0x00001000</entry>
> - <entry>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.</entry>
> + <entry>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 <link linkend="vidioc-qbuf">VIDIOC_DQBUF</link>
> + and <link linkend="vidioc-qbuf">VIDIOC_QBUF</link> IOCTLs.
> + The flag has no effect on some devices / architectures.
> + </entry>
> </row>
> <row>
> <entry><constant>V4L2_BUF_FLAG_LAST</constant></entry>
> diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h
> index dbf017b..4cee91d 100644
> --- a/include/trace/events/v4l2.h
> +++ b/include/trace/events/v4l2.h
> @@ -78,8 +78,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 3228fbe..8d85aac 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -875,8 +875,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
>
next prev parent reply other threads:[~2015-09-11 16:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 11:50 [RFC RESEND 00/11] vb2: Handle user cache hints, allow drivers to choose cache coherency Sakari Ailus
2015-09-11 11:50 ` [RFC RESEND 01/11] vb2: Rename confusingly named internal buffer preparation functions Sakari Ailus
2015-09-11 15:57 ` Hans Verkuil
2016-12-15 15:40 ` Laurent Pinchart
2015-09-11 11:50 ` [RFC RESEND 02/11] vb2: Move buffer cache synchronisation to prepare from queue Sakari Ailus
2015-09-11 16:11 ` Hans Verkuil
2015-09-11 11:50 ` [RFC RESEND 03/11] vb2: Move cache synchronisation from buffer done to dqbuf handler Sakari Ailus
2015-09-11 16:25 ` Hans Verkuil
2015-09-15 7:51 ` Sakari Ailus
2016-12-15 23:47 ` Laurent Pinchart
2015-09-11 11:50 ` [RFC RESEND 04/11] v4l: Unify cache management hint buffer flags Sakari Ailus
2015-09-11 16:26 ` Hans Verkuil [this message]
2015-09-11 16:44 ` Hans Verkuil
2016-12-15 20:15 ` Laurent Pinchart
2016-12-17 0:35 ` Sakari Ailus
2015-09-11 11:50 ` [RFC RESEND 05/11] v4l2-core: Don't sync cache for a buffer if so requested Sakari Ailus
2015-09-11 17:12 ` Hans Verkuil
2015-09-15 8:22 ` Sakari Ailus
2015-09-15 9:06 ` Hans Verkuil
2016-12-15 20:37 ` Laurent Pinchart
2016-12-17 0:36 ` Sakari Ailus
2015-09-11 11:50 ` [RFC RESEND 06/11] vb2: Improve struct vb2_mem_ops documentation; alloc and put are for MMAP Sakari Ailus
2015-09-11 17:13 ` Hans Verkuil
2016-12-15 20:50 ` Laurent Pinchart
2015-09-11 11:50 ` [RFC RESEND 07/11] vb2: dma-contig: Remove redundant sgt_base field Sakari Ailus
2015-09-11 17:28 ` Hans Verkuil
2015-09-15 8:26 ` Sakari Ailus
2016-12-15 21:08 ` Laurent Pinchart
2016-12-17 0:40 ` Sakari Ailus
2015-09-11 11:50 ` [RFC RESEND 08/11] vb2: dma-contig: Move vb2_dc_get_base_sgt() up Sakari Ailus
2016-12-15 21:12 ` Laurent Pinchart
2015-09-11 11:50 ` [RFC RESEND 09/11] vb2: dma-contig: Don't warn on failure in obtaining scatterlist Sakari Ailus
2016-12-15 21:13 ` Laurent Pinchart
2015-09-11 11:50 ` [RFC RESEND 10/11] vb2: dma-contig: Let drivers decide DMA attrs of MMAP and USERPTR bufs Sakari Ailus
2016-12-15 21:40 ` Laurent Pinchart
2015-09-11 11:50 ` [RFC RESEND 11/11] vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs Sakari Ailus
2016-12-15 21:57 ` Laurent Pinchart
2016-12-17 0:50 ` 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=55F300CE.5060204@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=daniel.vetter@ffwll.ch \
--cc=kyungmin.park@samsung.com \
--cc=labbott@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pawel@osciak.com \
--cc=robdclark@gmail.com \
--cc=sakari.ailus@linux.intel.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.