All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: sumit.semwal@linaro.org, christian.koenig@amd.com, afd@ti.com,
	corbet@lwn.net, benjamin.gaignard@linaro.org,
	lmark@codeaurora.org, labbott@redhat.com, Brian.Starkey@arm.com,
	john.stultz@linaro.org, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, airlied@linux.ie, daniel@ffwll.ch,
	l.stach@pengutronix.de, linux+etnaviv@armlinux.org.uk,
	christian.gmeiner@gmail.com, jani.nikula@linux.intel.com,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	thierry.reding@gmail.com, jonathanh@nvidia.com, pawel@osciak.com,
	m.szyprowski@samsung.com, kyungmin.park@samsung.com,
	tfiga@chromium.org, mchehab@kernel.org, matthew.auld@intel.com,
	robin.murphy@arm.com, thomas.hellstrom@intel.com,
	sam@ravnborg.org, kraxel@redhat.com, arnd@arndb.de,
	gregkh@linuxfoundation.org
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-doc@vger.kernel.org,
	etnaviv@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-tegra@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: [PATCH v3 4/4] dma-buf: Document struct dma_buf_map
Date: Fri, 25 Sep 2020 13:56:01 +0200	[thread overview]
Message-ID: <20200925115601.23955-5-tzimmermann@suse.de> (raw)
In-Reply-To: <20200925115601.23955-1-tzimmermann@suse.de>

This patch adds struct dma_buf_map and its helpers to the documentation. A
short tutorial is included.

v3:
	* update documentation in a separate patch
	* expand docs (Daniel)
	* carry-over acks from patch 1

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 Documentation/driver-api/dma-buf.rst |  9 ++++
 include/linux/dma-buf-map.h          | 72 ++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 13ea0cc0a3fa..6dbcc4714b0b 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -115,6 +115,15 @@ Kernel Functions and Structures Reference
 .. kernel-doc:: include/linux/dma-buf.h
    :internal:
 
+Buffer Mapping Helpers
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+   :doc: overview
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+   :internal:
+
 Reservation Objects
 -------------------
 
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index c173a4abf4ba..fd1aba545fdf 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -8,6 +8,78 @@
 
 #include <linux/io.h>
 
+/**
+ * DOC: overview
+ *
+ * Calling dma-buf's vmap operation returns a pointer to the buffer's memory.
+ * Depending on the location of the buffer, users may have to access it with
+ * I/O operations or memory load/store operations. For example, copying to
+ * system memory could be done with memcpy(), copying to I/O memory would be
+ * done with memcpy_toio().
+ *
+ * .. code-block:: c
+ *
+ *	void *vaddr = ...; // pointer to system memory
+ *	memcpy(vaddr, src, len);
+ *
+ *	void *vaddr_iomem = ...; // pointer to I/O memory
+ *	memcpy_toio(vaddr, _iomem, src, len);
+ *
+ * When using dma-buf's vmap operation, the returned pointer is encoded as
+ * :c:type:`struct dma_buf_map <dma_buf_map>`.
+ * :c:type:`struct dma_buf_map <dma_buf_map>` stores the buffer's address in
+ * system or I/O memory and a flag that signals the required method of
+ * accessing the buffer. Use the returned instance and the helper functions
+ * to access the buffer's memory in the correct way.
+ *
+ * Open-coding access to :c:type:`struct dma_buf_map <dma_buf_map>` is
+ * considered bad style. Rather then accessing its fields directly, use one
+ * of the provided helper functions, or implement your own. For example,
+ * instances of :c:type:`struct dma_buf_map <dma_buf_map>` can be initialized
+ * statically with DMA_BUF_MAP_INIT_VADDR(), or at runtime with
+ * dma_buf_map_set_vaddr(). These helpers will set an address in system memory.
+ *
+ * .. code-block:: c
+ *
+ *	struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(0xdeadbeaf);
+ *
+ *	dma_buf_map_set_vaddr(&map. 0xdeadbeaf);
+ *
+ * Test if a mapping is valid with either dma_buf_map_is_set() or
+ * dma_buf_map_is_null().
+ *
+ * .. code-block:: c
+ *
+ *	if (dma_buf_map_is_set(&map) != dma_buf_map_is_null(&map))
+ *		// always true
+ *
+ * Instances of :c:type:`struct dma_buf_map <dma_buf_map>` can be compared
+ * for equality with dma_buf_map_is_equal(). Mappings the point to different
+ * memory spaces, system or I/O, are never equal. That's even true if both
+ * spaces are located in the same address space, both mappings contain the
+ * same address value, or both mappings refer to NULL.
+ *
+ * .. code-block:: c
+ *
+ *	struct dma_buf_map sys_map; // refers to system memory
+ *	struct dma_buf_map io_map; // refers to I/O memory
+ *
+ *	if (dma_buf_map_is_equal(&sys_map, &io_map))
+ *		// always false
+ *
+ * Instances of struct dma_buf_map do not have to be cleaned up, but
+ * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
+ * always refer to system memory.
+ *
+ * The type :c:type:`struct dma_buf_map <dma_buf_map>` and its helpers are
+ * actually independent from the dma-buf infrastructure. When sharing buffers
+ * among devices, drivers have to know the location of the memory to access
+ * the buffers in a safe way. :c:type:`struct dma_buf_map <dma_buf_map>`
+ * solves this problem for dma-buf and its users. If other drivers or
+ * sub-systems require similar functionality, the type could be generalized
+ * and moved to a more prominent header file.
+ */
+
 /**
  * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
  * @vaddr_iomem:	The buffer's address if in I/O memory
-- 
2.28.0


WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: sumit.semwal@linaro.org, christian.koenig@amd.com, afd@ti.com,
	corbet@lwn.net, benjamin.gaignard@linaro.org,
	lmark@codeaurora.org, labbott@redhat.com, Brian.Starkey@arm.com,
	john.stultz@linaro.org, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, airlied@linux.ie, daniel@ffwll.ch,
	l.stach@pengutronix.de, linux+etnaviv@armlinux.org.uk,
	christian.gmeiner@gmail.com, jani.nikula@linux.intel.com,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	thierry.reding@gmail.com, jonathanh@nvidia.com, pawel@osciak.com,
	m.szyprowski@samsung.com, kyungmin.park@samsung.com,
	tfiga@chromium.org, mchehab@kernel.org, matthew.auld@intel.com,
	robin.murphy@arm.com, thomas.hellstrom@intel.com,
	sam@ravnborg.org, kraxel@redhat.com, arnd@arndb.de,
	gregkh@linuxfoundation.org
Cc: linux-doc@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, etnaviv@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-tegra@vger.kernel.org, linux-media@vger.kernel.org
Subject: [PATCH v3 4/4] dma-buf: Document struct dma_buf_map
Date: Fri, 25 Sep 2020 13:56:01 +0200	[thread overview]
Message-ID: <20200925115601.23955-5-tzimmermann@suse.de> (raw)
In-Reply-To: <20200925115601.23955-1-tzimmermann@suse.de>

This patch adds struct dma_buf_map and its helpers to the documentation. A
short tutorial is included.

v3:
	* update documentation in a separate patch
	* expand docs (Daniel)
	* carry-over acks from patch 1

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 Documentation/driver-api/dma-buf.rst |  9 ++++
 include/linux/dma-buf-map.h          | 72 ++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 13ea0cc0a3fa..6dbcc4714b0b 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -115,6 +115,15 @@ Kernel Functions and Structures Reference
 .. kernel-doc:: include/linux/dma-buf.h
    :internal:
 
+Buffer Mapping Helpers
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+   :doc: overview
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+   :internal:
+
 Reservation Objects
 -------------------
 
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index c173a4abf4ba..fd1aba545fdf 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -8,6 +8,78 @@
 
 #include <linux/io.h>
 
+/**
+ * DOC: overview
+ *
+ * Calling dma-buf's vmap operation returns a pointer to the buffer's memory.
+ * Depending on the location of the buffer, users may have to access it with
+ * I/O operations or memory load/store operations. For example, copying to
+ * system memory could be done with memcpy(), copying to I/O memory would be
+ * done with memcpy_toio().
+ *
+ * .. code-block:: c
+ *
+ *	void *vaddr = ...; // pointer to system memory
+ *	memcpy(vaddr, src, len);
+ *
+ *	void *vaddr_iomem = ...; // pointer to I/O memory
+ *	memcpy_toio(vaddr, _iomem, src, len);
+ *
+ * When using dma-buf's vmap operation, the returned pointer is encoded as
+ * :c:type:`struct dma_buf_map <dma_buf_map>`.
+ * :c:type:`struct dma_buf_map <dma_buf_map>` stores the buffer's address in
+ * system or I/O memory and a flag that signals the required method of
+ * accessing the buffer. Use the returned instance and the helper functions
+ * to access the buffer's memory in the correct way.
+ *
+ * Open-coding access to :c:type:`struct dma_buf_map <dma_buf_map>` is
+ * considered bad style. Rather then accessing its fields directly, use one
+ * of the provided helper functions, or implement your own. For example,
+ * instances of :c:type:`struct dma_buf_map <dma_buf_map>` can be initialized
+ * statically with DMA_BUF_MAP_INIT_VADDR(), or at runtime with
+ * dma_buf_map_set_vaddr(). These helpers will set an address in system memory.
+ *
+ * .. code-block:: c
+ *
+ *	struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(0xdeadbeaf);
+ *
+ *	dma_buf_map_set_vaddr(&map. 0xdeadbeaf);
+ *
+ * Test if a mapping is valid with either dma_buf_map_is_set() or
+ * dma_buf_map_is_null().
+ *
+ * .. code-block:: c
+ *
+ *	if (dma_buf_map_is_set(&map) != dma_buf_map_is_null(&map))
+ *		// always true
+ *
+ * Instances of :c:type:`struct dma_buf_map <dma_buf_map>` can be compared
+ * for equality with dma_buf_map_is_equal(). Mappings the point to different
+ * memory spaces, system or I/O, are never equal. That's even true if both
+ * spaces are located in the same address space, both mappings contain the
+ * same address value, or both mappings refer to NULL.
+ *
+ * .. code-block:: c
+ *
+ *	struct dma_buf_map sys_map; // refers to system memory
+ *	struct dma_buf_map io_map; // refers to I/O memory
+ *
+ *	if (dma_buf_map_is_equal(&sys_map, &io_map))
+ *		// always false
+ *
+ * Instances of struct dma_buf_map do not have to be cleaned up, but
+ * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
+ * always refer to system memory.
+ *
+ * The type :c:type:`struct dma_buf_map <dma_buf_map>` and its helpers are
+ * actually independent from the dma-buf infrastructure. When sharing buffers
+ * among devices, drivers have to know the location of the memory to access
+ * the buffers in a safe way. :c:type:`struct dma_buf_map <dma_buf_map>`
+ * solves this problem for dma-buf and its users. If other drivers or
+ * sub-systems require similar functionality, the type could be generalized
+ * and moved to a more prominent header file.
+ */
+
 /**
  * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
  * @vaddr_iomem:	The buffer's address if in I/O memory
-- 
2.28.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Zimmermann <tzimmermann@suse.de>
To: sumit.semwal@linaro.org, christian.koenig@amd.com, afd@ti.com,
	corbet@lwn.net, benjamin.gaignard@linaro.org,
	lmark@codeaurora.org, labbott@redhat.com, Brian.Starkey@arm.com,
	john.stultz@linaro.org, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, airlied@linux.ie, daniel@ffwll.ch,
	l.stach@pengutronix.de, linux+etnaviv@armlinux.org.uk,
	christian.gmeiner@gmail.com, jani.nikula@linux.intel.com,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	thierry.reding@gmail.com, jonathanh@nvidia.com, pawel@osciak.com,
	m.szyprowski@samsung.com, kyungmin.park@samsung.com,
	tfiga@chromium.org, mchehab@kernel.org, matthew.auld@intel.com,
	robin.murphy@arm.com, thomas.hellstrom@intel.com,
	sam@ravnborg.org, kraxel@redhat.com, arnd@arndb.de,
	gregkh@linuxfoundation.org
Cc: linux-doc@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, etnaviv@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-tegra@vger.kernel.org, linux-media@vger.kernel.org
Subject: [Intel-gfx] [PATCH v3 4/4] dma-buf: Document struct dma_buf_map
Date: Fri, 25 Sep 2020 13:56:01 +0200	[thread overview]
Message-ID: <20200925115601.23955-5-tzimmermann@suse.de> (raw)
In-Reply-To: <20200925115601.23955-1-tzimmermann@suse.de>

This patch adds struct dma_buf_map and its helpers to the documentation. A
short tutorial is included.

v3:
	* update documentation in a separate patch
	* expand docs (Daniel)
	* carry-over acks from patch 1

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
---
 Documentation/driver-api/dma-buf.rst |  9 ++++
 include/linux/dma-buf-map.h          | 72 ++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst
index 13ea0cc0a3fa..6dbcc4714b0b 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -115,6 +115,15 @@ Kernel Functions and Structures Reference
 .. kernel-doc:: include/linux/dma-buf.h
    :internal:
 
+Buffer Mapping Helpers
+~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+   :doc: overview
+
+.. kernel-doc:: include/linux/dma-buf-map.h
+   :internal:
+
 Reservation Objects
 -------------------
 
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index c173a4abf4ba..fd1aba545fdf 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -8,6 +8,78 @@
 
 #include <linux/io.h>
 
+/**
+ * DOC: overview
+ *
+ * Calling dma-buf's vmap operation returns a pointer to the buffer's memory.
+ * Depending on the location of the buffer, users may have to access it with
+ * I/O operations or memory load/store operations. For example, copying to
+ * system memory could be done with memcpy(), copying to I/O memory would be
+ * done with memcpy_toio().
+ *
+ * .. code-block:: c
+ *
+ *	void *vaddr = ...; // pointer to system memory
+ *	memcpy(vaddr, src, len);
+ *
+ *	void *vaddr_iomem = ...; // pointer to I/O memory
+ *	memcpy_toio(vaddr, _iomem, src, len);
+ *
+ * When using dma-buf's vmap operation, the returned pointer is encoded as
+ * :c:type:`struct dma_buf_map <dma_buf_map>`.
+ * :c:type:`struct dma_buf_map <dma_buf_map>` stores the buffer's address in
+ * system or I/O memory and a flag that signals the required method of
+ * accessing the buffer. Use the returned instance and the helper functions
+ * to access the buffer's memory in the correct way.
+ *
+ * Open-coding access to :c:type:`struct dma_buf_map <dma_buf_map>` is
+ * considered bad style. Rather then accessing its fields directly, use one
+ * of the provided helper functions, or implement your own. For example,
+ * instances of :c:type:`struct dma_buf_map <dma_buf_map>` can be initialized
+ * statically with DMA_BUF_MAP_INIT_VADDR(), or at runtime with
+ * dma_buf_map_set_vaddr(). These helpers will set an address in system memory.
+ *
+ * .. code-block:: c
+ *
+ *	struct dma_buf_map map = DMA_BUF_MAP_INIT_VADDR(0xdeadbeaf);
+ *
+ *	dma_buf_map_set_vaddr(&map. 0xdeadbeaf);
+ *
+ * Test if a mapping is valid with either dma_buf_map_is_set() or
+ * dma_buf_map_is_null().
+ *
+ * .. code-block:: c
+ *
+ *	if (dma_buf_map_is_set(&map) != dma_buf_map_is_null(&map))
+ *		// always true
+ *
+ * Instances of :c:type:`struct dma_buf_map <dma_buf_map>` can be compared
+ * for equality with dma_buf_map_is_equal(). Mappings the point to different
+ * memory spaces, system or I/O, are never equal. That's even true if both
+ * spaces are located in the same address space, both mappings contain the
+ * same address value, or both mappings refer to NULL.
+ *
+ * .. code-block:: c
+ *
+ *	struct dma_buf_map sys_map; // refers to system memory
+ *	struct dma_buf_map io_map; // refers to I/O memory
+ *
+ *	if (dma_buf_map_is_equal(&sys_map, &io_map))
+ *		// always false
+ *
+ * Instances of struct dma_buf_map do not have to be cleaned up, but
+ * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
+ * always refer to system memory.
+ *
+ * The type :c:type:`struct dma_buf_map <dma_buf_map>` and its helpers are
+ * actually independent from the dma-buf infrastructure. When sharing buffers
+ * among devices, drivers have to know the location of the memory to access
+ * the buffers in a safe way. :c:type:`struct dma_buf_map <dma_buf_map>`
+ * solves this problem for dma-buf and its users. If other drivers or
+ * sub-systems require similar functionality, the type could be generalized
+ * and moved to a more prominent header file.
+ */
+
 /**
  * struct dma_buf_map - Pointer to vmap'ed dma-buf memory.
  * @vaddr_iomem:	The buffer's address if in I/O memory
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-09-25 11:56 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 11:55 [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory Thomas Zimmermann
2020-09-25 11:55 ` [Intel-gfx] " Thomas Zimmermann
2020-09-25 11:55 ` Thomas Zimmermann
2020-09-25 11:55 ` [PATCH v3 1/4] dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr Thomas Zimmermann
2020-09-25 11:55   ` [Intel-gfx] " Thomas Zimmermann
2020-09-25 11:55   ` Thomas Zimmermann
2020-09-25 11:55 ` [PATCH v3 2/4] dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces Thomas Zimmermann
2020-09-25 11:55   ` [Intel-gfx] " Thomas Zimmermann
2020-09-25 11:55   ` Thomas Zimmermann
2020-09-25 11:56 ` [PATCH v3 3/4] dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces Thomas Zimmermann
2020-09-25 11:56   ` [Intel-gfx] " Thomas Zimmermann
2020-09-25 11:56   ` Thomas Zimmermann
2020-09-25 11:56 ` Thomas Zimmermann [this message]
2020-09-25 11:56   ` [Intel-gfx] [PATCH v3 4/4] dma-buf: Document struct dma_buf_map Thomas Zimmermann
2020-09-25 11:56   ` Thomas Zimmermann
2020-09-25 12:07 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-buf: Flag vmap'ed memory as system or I/O memory (rev3) Patchwork
2020-09-25 12:09 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-09-25 12:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-09-25 16:53 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-09-25 18:57 ` [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory Tomasz Figa
2020-09-25 18:57   ` [Intel-gfx] " Tomasz Figa
2020-09-25 18:57   ` Tomasz Figa
2020-09-26  7:13 ` Sam Ravnborg
2020-09-26  7:13   ` [Intel-gfx] " Sam Ravnborg
2020-09-26  7:13   ` Sam Ravnborg
2020-09-27 18:36   ` Thomas Zimmermann
2020-09-27 18:36     ` [Intel-gfx] " Thomas Zimmermann
2020-09-27 18:36     ` Thomas Zimmermann
2020-09-27 19:16     ` Sam Ravnborg
2020-09-27 19:16       ` [Intel-gfx] " Sam Ravnborg
2020-09-27 19:16       ` Sam Ravnborg
2020-09-28  6:50       ` Christian König
2020-09-28  6:50         ` [Intel-gfx] " Christian König
2020-09-28  6:50         ` Christian König
2020-09-28  7:37         ` Thomas Zimmermann
2020-09-28  7:37           ` [Intel-gfx] " Thomas Zimmermann
2020-09-28  7:37           ` Thomas Zimmermann
2020-09-28 11:22           ` Christian König
2020-09-28 11:22             ` [Intel-gfx] " Christian König
2020-09-28 11:22             ` Christian König
2020-09-29  9:14             ` Daniel Vetter
2020-09-29  9:14               ` [Intel-gfx] " Daniel Vetter
2020-09-29  9:14               ` Daniel Vetter
2020-09-29 11:09               ` Christian König
2020-09-29 11:09                 ` [Intel-gfx] " Christian König
2020-09-29 11:09                 ` Christian König
2020-09-29 11:14                 ` Thomas Zimmermann
2020-09-29 11:14                   ` [Intel-gfx] " Thomas Zimmermann
2020-09-29 11:14                   ` Thomas Zimmermann

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=20200925115601.23955-5-tzimmermann@suse.de \
    --to=tzimmermann@suse.de \
    --cc=Brian.Starkey@arm.com \
    --cc=afd@ti.com \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=benjamin.gaignard@linaro.org \
    --cc=christian.gmeiner@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=etnaviv@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=jonathanh@nvidia.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kraxel@redhat.com \
    --cc=kyungmin.park@samsung.com \
    --cc=l.stach@pengutronix.de \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux+etnaviv@armlinux.org.uk \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lmark@codeaurora.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=mchehab@kernel.org \
    --cc=mripard@kernel.org \
    --cc=pawel@osciak.com \
    --cc=robin.murphy@arm.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sam@ravnborg.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tfiga@chromium.org \
    --cc=thierry.reding@gmail.com \
    --cc=thomas.hellstrom@intel.com \
    /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.