From: "Ruhl, Michael J" <michael.j.ruhl@intel.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
"christian.koenig@amd.com" <christian.koenig@amd.com>,
"airlied@redhat.com" <airlied@redhat.com>,
"daniel@ffwll.ch" <daniel@ffwll.ch>,
"maarten.lankhorst@linux.intel.com"
<maarten.lankhorst@linux.intel.com>,
"mripard@kernel.org" <mripard@kernel.org>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"hdegoede@redhat.com" <hdegoede@redhat.com>,
"sean@poorly.run" <sean@poorly.run>,
"eric@anholt.net" <eric@anholt.net>,
"sam@ravnborg.org" <sam@ravnborg.org>
Cc: "linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>
Subject: RE: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations
Date: Fri, 8 Jan 2021 16:12:25 +0000 [thread overview]
Message-ID: <39d9d40bf6284ef29c777776f9f2b5a3@intel.com> (raw)
In-Reply-To: <20210108094340.15290-2-tzimmermann@suse.de>
>-----Original Message-----
>From: dri-devel <dri-devel-bounces@lists.freedesktop.org> On Behalf Of
>Thomas Zimmermann
>Sent: Friday, January 8, 2021 4:43 AM
>To: sumit.semwal@linaro.org; christian.koenig@amd.com;
>airlied@redhat.com; daniel@ffwll.ch; maarten.lankhorst@linux.intel.com;
>mripard@kernel.org; kraxel@redhat.com; hdegoede@redhat.com;
>sean@poorly.run; eric@anholt.net; sam@ravnborg.org
>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>; dri-devel@lists.freedesktop.org;
>virtualization@lists.linux-foundation.org; linaro-mm-sig@lists.linaro.org;
>Thomas Zimmermann <tzimmermann@suse.de>; linux-
>media@vger.kernel.org
>Subject: [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local
>operations
>
>The existing dma-buf calls dma_buf_vmap() and dma_buf_vunmap() are
>allowed to pin the buffer or acquire the buffer's reservation object
>lock.
>
>This is a problem for callers that only require a short-term mapping
>of the buffer without the pinning, or callers that have special locking
>requirements. These may suffer from unnecessary overhead or interfere
>with regular pin operations.
>
>The new interfaces dma_buf_vmap_local(), dma_buf_vunmapo_local(), and
>their rsp callbacks in struct dma_buf_ops provide an alternative without
>pinning or reservation locking. Callers are responsible for these
>operations.
>
>v4:
> * update documentation (Daniel)
>
>Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>---
> drivers/dma-buf/dma-buf.c | 81
>+++++++++++++++++++++++++++++++++++++++
> include/linux/dma-buf.h | 34 ++++++++++++++++
> 2 files changed, 115 insertions(+)
>
>diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>index b8465243eca2..01f9c74d97fa 100644
>--- a/drivers/dma-buf/dma-buf.c
>+++ b/drivers/dma-buf/dma-buf.c
>@@ -1295,6 +1295,87 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
>struct dma_buf_map *map)
> }
> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>
>+/**
>+ * dma_buf_vmap_local - Create virtual mapping for the buffer object into
>kernel
>+ * address space.
>+ * @dmabuf: [in] buffer to vmap
>+ * @map: [out] returns the vmap pointer
>+ *
>+ * Unlike dma_buf_vmap() this is a short term mapping and will not pin
>+ * the buffer. The struct dma_resv for the @dmabuf must be locked until
>+ * dma_buf_vunmap_local() is called.
>+ *
>+ * Returns:
>+ * 0 on success, or a negative errno code otherwise.
>+ */
>+int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>*map)
>+{
>+ struct dma_buf_map ptr;
>+ int ret = 0;
>+
>+ dma_buf_map_clear(map);
>+
>+ if (WARN_ON(!dmabuf))
>+ return -EINVAL;
>+
>+ dma_resv_assert_held(dmabuf->resv);
>+
>+ if (!dmabuf->ops->vmap_local)
>+ return -EINVAL;
You are clearing the map, and then doing the above checks.
Is it ok to change the map info and then exit on error?
Mike
>+ mutex_lock(&dmabuf->lock);
>+ if (dmabuf->vmapping_counter) {
>+ dmabuf->vmapping_counter++;
>+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>+ *map = dmabuf->vmap_ptr;
>+ goto out_unlock;
>+ }
>+
>+ BUG_ON(dma_buf_map_is_set(&dmabuf->vmap_ptr));
>+
>+ ret = dmabuf->ops->vmap_local(dmabuf, &ptr);
>+ if (WARN_ON_ONCE(ret))
>+ goto out_unlock;
>+
>+ dmabuf->vmap_ptr = ptr;
>+ dmabuf->vmapping_counter = 1;
>+
>+ *map = dmabuf->vmap_ptr;
>+
>+out_unlock:
>+ mutex_unlock(&dmabuf->lock);
>+ return ret;
>+}
>+EXPORT_SYMBOL_GPL(dma_buf_vmap_local);
>+
>+/**
>+ * dma_buf_vunmap_local - Unmap a vmap obtained by
>dma_buf_vmap_local.
>+ * @dmabuf: [in] buffer to vunmap
>+ * @map: [in] vmap pointer to vunmap
>+ *
>+ * Release a mapping established with dma_buf_vmap_local().
>+ */
>+void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>dma_buf_map *map)
>+{
>+ if (WARN_ON(!dmabuf))
>+ return;
>+
>+ dma_resv_assert_held(dmabuf->resv);
>+
>+ BUG_ON(dma_buf_map_is_null(&dmabuf->vmap_ptr));
>+ BUG_ON(dmabuf->vmapping_counter == 0);
>+ BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map));
>+
>+ mutex_lock(&dmabuf->lock);
>+ if (--dmabuf->vmapping_counter == 0) {
>+ if (dmabuf->ops->vunmap_local)
>+ dmabuf->ops->vunmap_local(dmabuf, map);
>+ dma_buf_map_clear(&dmabuf->vmap_ptr);
>+ }
>+ mutex_unlock(&dmabuf->lock);
>+}
>+EXPORT_SYMBOL_GPL(dma_buf_vunmap_local);
>+
> #ifdef CONFIG_DEBUG_FS
> static int dma_buf_debug_show(struct seq_file *s, void *unused)
> {
>diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>index 628681bf6c99..aeed754b5467 100644
>--- a/include/linux/dma-buf.h
>+++ b/include/linux/dma-buf.h
>@@ -264,6 +264,38 @@ struct dma_buf_ops {
>
> int (*vmap)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map
>*map);
>+
>+ /**
>+ * @vmap_local:
>+ *
>+ * Creates a virtual mapping for the buffer into kernel address space.
>+ *
>+ * This callback establishes short-term mappings for situations where
>+ * callers only use the buffer for a bounded amount of time; such as
>+ * updates to the framebuffer or reading back contained information.
>+ * In contrast to the regular @vmap callback, vmap_local does never
>pin
>+ * the buffer to a specific domain or acquire the buffer's reservation
>+ * lock.
>+ *
>+ * This is called with the &dma_buf.resv object locked. Callers must
>hold
>+ * the lock until after removing the mapping with @vunmap_local.
>+ *
>+ * This callback is optional.
>+ *
>+ * Returns:
>+ *
>+ * 0 on success or a negative error code on failure.
>+ */
>+ int (*vmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>*map);
>+
>+ /**
>+ * @vunmap_local:
>+ *
>+ * Removes a virtual mapping that was established by @vmap_local.
>+ *
>+ * This callback is optional.
>+ */
>+ void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map
>*map);
> };
>
> /**
>@@ -501,4 +533,6 @@ int dma_buf_mmap(struct dma_buf *, struct
>vm_area_struct *,
> unsigned long);
> int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map
>*map);
>+int dma_buf_vmap_local(struct dma_buf *dmabuf, struct dma_buf_map
>*map);
>+void dma_buf_vunmap_local(struct dma_buf *dmabuf, struct
>dma_buf_map *map);
> #endif /* __DMA_BUF_H__ */
>--
>2.29.2
>
>_______________________________________________
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-01-08 16:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 9:43 [PATCH v4 00/13] drm: Support short-term vmap via vmap_local Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 01/13] dma-buf: Add vmap_local and vnumap_local operations Thomas Zimmermann
2021-01-08 16:12 ` Ruhl, Michael J [this message]
2021-01-12 7:45 ` Thomas Zimmermann
2021-01-14 14:39 ` Ruhl, Michael J
2021-01-08 9:43 ` [PATCH v4 02/13] drm/gem: Create infrastructure for GEM vmap_local Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 03/13] drm/cma-helper: Provide a vmap function for short-term mappings Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 04/13] drm/shmem-helper: " Thomas Zimmermann
2021-01-11 16:50 ` Daniel Vetter
2021-01-12 13:11 ` Thomas Zimmermann
2021-01-12 14:16 ` Daniel Vetter
2021-01-27 12:08 ` Thomas Zimmermann
2021-02-02 14:11 ` Daniel Vetter
2021-01-08 9:43 ` [PATCH v4 05/13] drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling Thomas Zimmermann
2021-01-11 16:53 ` Daniel Vetter
2021-01-11 16:58 ` Daniel Vetter
2021-01-08 9:43 ` [PATCH v4 06/13] drm/cirrus: " Thomas Zimmermann
2021-01-11 17:00 ` Daniel Vetter
2021-01-11 17:03 ` Daniel Vetter
2021-01-08 9:43 ` [PATCH v4 07/13] drm/gm12u320: " Thomas Zimmermann
2021-01-11 17:01 ` Daniel Vetter
2021-01-08 9:43 ` [PATCH v4 08/13] drm/udl: " Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 09/13] drm/vram-helper: Provide a vmap function for short-term mappings Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 10/13] drm/ast: Use drm_gem_vram_vmap_local() in cursor update Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 11/13] drm/vboxvideo: " Thomas Zimmermann
2021-01-11 17:06 ` Daniel Vetter
2021-01-12 7:54 ` Thomas Zimmermann
2021-01-12 9:17 ` Daniel Vetter
2021-01-12 9:53 ` Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 12/13] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker Thomas Zimmermann
2021-01-08 9:43 ` [PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap, vunmap}() Thomas Zimmermann
2021-01-11 16:52 ` [PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap,vunmap}() Daniel Vetter
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=39d9d40bf6284ef29c777776f9f2b5a3@intel.com \
--to=michael.j.ruhl@intel.com \
--cc=airlied@redhat.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=eric@anholt.net \
--cc=hdegoede@redhat.com \
--cc=kraxel@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sam@ravnborg.org \
--cc=sean@poorly.run \
--cc=sumit.semwal@linaro.org \
--cc=tzimmermann@suse.de \
--cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).