From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: sumit.semwal@linaro.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 05/12] dma-buf: add explicit buffer pinning
Date: Wed, 17 Apr 2019 16:20:02 +0200 [thread overview]
Message-ID: <20190417142002.GE13337@phenom.ffwll.local> (raw)
In-Reply-To: <20190416183841.1577-6-christian.koenig@amd.com>
On Tue, Apr 16, 2019 at 08:38:34PM +0200, Christian König wrote:
> Add optional explicit pinning callbacks instead of implicitly assume the
> exporter pins the buffer when a mapping is created.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
Don't we need this together with the invalidate callback and the dynamic
stuff? Also I'm assuming that pin/unpin is pretty much required for
dynamic bo, so could we look at these callbacks instead of the dynamic
flag you add in patch 1.
I'm assuming following rules hold:
no pin/upin from exporter:
dma-buf is not dynamic, and pinned for the duration of map/unmap. I'm
not 100% sure whether really everyone wants the mapping to be cached for
the entire attachment, only drm_prime does that. And that's not the only
dma-buf importer.
pin/unpin calls are noops.
pin/unpin exist in the exporter, but importer has not provided an
invalidate callback:
We map at attach time, and we also have to pin, since the importer can't
handle the buffer disappearing, at attach time. We unmap/unpin at detach.
pin/unpin from exporter, invalidate from importer:
Full dynamic mapping. We assume the importer will do caching, attach
fences as needed, and pin the underlying bo when it needs it it
permanently, without attaching fences (i.e. the scanout case).
Assuming I'm not terribly off with my understanding, then I think it'd be
best to introduce the entire new dma-buf api in the first patch, and flesh
it out later. Instead of spread over a few patches. Plus the above (maybe
prettier) as a nice kerneldoc overview comment for how dynamic dma-buf is
supposed to work really.
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 39 +++++++++++++++++++++++++++++++++++++++
> include/linux/dma-buf.h | 37 +++++++++++++++++++++++++++++++------
> 2 files changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index a3738fab3927..f23ff8355505 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -630,6 +630,41 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
> }
> EXPORT_SYMBOL_GPL(dma_buf_detach);
>
> +/**
> + * dma_buf_pin - Lock down the DMA-buf
> + *
> + * @dmabuf: [in] DMA-buf to lock down.
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int dma_buf_pin(struct dma_buf *dmabuf)
> +{
> + int ret = 0;
> +
> + reservation_object_assert_held(dmabuf->resv);
> +
> + if (dmabuf->ops->pin)
> + ret = dmabuf->ops->pin(dmabuf);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_pin);
> +
> +/**
> + * dma_buf_unpin - Remove lock from DMA-buf
> + *
> + * @dmabuf: [in] DMA-buf to unlock.
> + */
> +void dma_buf_unpin(struct dma_buf *dmabuf)
> +{
> + reservation_object_assert_held(dmabuf->resv);
> +
> + if (dmabuf->ops->unpin)
> + dmabuf->ops->unpin(dmabuf);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
> +
> /**
> * dma_buf_map_attachment_locked - Maps the buffer into _device_ address space
> * with the reservation lock held. Is a wrapper for map_dma_buf() of the
> @@ -666,6 +701,8 @@ dma_buf_map_attachment_locked(struct dma_buf_attachment *attach,
> */
> if (attach->invalidate)
> list_del(&attach->node);
> + else
> + dma_buf_pin(attach->dmabuf);
> sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> if (attach->invalidate)
> list_add(&attach->node, &attach->dmabuf->attachments);
> @@ -735,6 +772,8 @@ void dma_buf_unmap_attachment_locked(struct dma_buf_attachment *attach,
>
> attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
> direction);
> + if (!attach->invalidate)
> + dma_buf_unpin(attach->dmabuf);
> }
> EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index ece4638359a8..a615b74e5894 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -100,14 +100,40 @@ struct dma_buf_ops {
> */
> void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
>
> + /**
> + * @pin_dma_buf:
> + *
> + * This is called by dma_buf_pin and lets the exporter know that an
> + * importer assumes that the DMA-buf can't be invalidated any more.
> + *
> + * This is called with the dmabuf->resv object locked.
> + *
> + * This callback is optional.
> + *
> + * Returns:
> + *
> + * 0 on success, negative error code on failure.
> + */
> + int (*pin)(struct dma_buf *);
> +
> + /**
> + * @unpin_dma_buf:
> + *
> + * This is called by dma_buf_unpin and lets the exporter know that an
> + * importer doesn't need to the DMA-buf to stay were it is any more.
> + *
> + * This is called with the dmabuf->resv object locked.
> + *
> + * This callback is optional.
> + */
> + void (*unpin)(struct dma_buf *);
> +
> /**
> * @map_dma_buf:
> *
> * This is called by dma_buf_map_attachment() and is used to map a
> * shared &dma_buf into device address space, and it is mandatory. It
> - * can only be called if @attach has been called successfully. This
> - * essentially pins the DMA buffer into place, and it cannot be moved
> - * any more
> + * can only be called if @attach has been called successfully.
> *
> * This call may sleep, e.g. when the backing storage first needs to be
> * allocated, or moved to a location suitable for all currently attached
> @@ -148,9 +174,6 @@ struct dma_buf_ops {
> *
> * This is called by dma_buf_unmap_attachment() and should unmap and
> * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
> - * It should also unpin the backing storage if this is the last mapping
> - * of the DMA buffer, it the exporter supports backing storage
> - * migration.
> *
> * This is always called with the dmabuf->resv object locked when
> * no_sgt_cache is true.
> @@ -442,6 +465,8 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
> struct dma_buf *dma_buf_get(int fd);
> void dma_buf_put(struct dma_buf *dmabuf);
>
> +int dma_buf_pin(struct dma_buf *dmabuf);
> +void dma_buf_unpin(struct dma_buf *dmabuf);
> struct sg_table *dma_buf_map_attachment_locked(struct dma_buf_attachment *,
> enum dma_data_direction);
> struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
> --
> 2.17.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2019-04-17 14:20 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 18:38 dynamic DMA-buf sharing between devices Christian König
2019-04-16 18:38 ` [PATCH 01/12] dma-buf: add dynamic caching of sg_table Christian König
2019-04-16 18:38 ` [PATCH 02/12] dma-buf: add dma_buf_(un)map_attachment_locked variants v3 Christian König
2019-05-27 10:56 ` Christian König
2019-04-16 18:38 ` [PATCH 03/12] dma-buf: lock the reservation object during (un)map_dma_buf v3 Christian König
2019-04-17 14:08 ` Daniel Vetter
2019-04-17 14:14 ` Christian König
2019-04-17 14:26 ` Daniel Vetter
2019-04-17 17:10 ` Christian König
2019-04-16 18:38 ` [PATCH 04/12] dma-buf: add optional invalidate_mappings callback v5 Christian König
2019-04-17 14:01 ` Daniel Vetter
2019-04-17 14:33 ` Daniel Vetter
2019-04-17 19:07 ` Daniel Vetter
2019-04-17 19:13 ` Christian König
2019-04-18 8:08 ` Daniel Vetter
2019-04-18 8:28 ` Koenig, Christian
2019-04-18 8:40 ` Daniel Vetter
2019-04-16 18:38 ` [PATCH 05/12] dma-buf: add explicit buffer pinning Christian König
2019-04-17 14:20 ` Daniel Vetter [this message]
2019-04-17 14:30 ` Daniel Vetter
2019-04-17 14:40 ` Daniel Vetter
2019-04-17 19:05 ` Daniel Vetter
2019-04-19 19:05 ` Alex Deucher
2019-04-16 18:38 ` [PATCH 06/12] drm: remove prime sg_table caching Christian König
2019-04-16 18:38 ` [PATCH 07/12] drm/ttm: remove the backing store if no placement is given Christian König
2019-04-16 18:38 ` [PATCH 08/12] drm/ttm: use the parent resv for ghost objects Christian König
2019-04-16 18:38 ` [PATCH 09/12] drm/amdgpu: add independent DMA-buf export v3 Christian König
2019-04-16 18:38 ` [PATCH 10/12] drm/amdgpu: add independent DMA-buf import v4 Christian König
2019-04-16 18:38 ` [PATCH 11/12] drm/amdgpu: add DMA-buf pin/unpin implementation Christian König
2019-04-16 18:38 ` [PATCH 12/12] drm/amdgpu: add DMA-buf invalidation callback v2 Christian König
2019-04-17 13:52 ` dynamic DMA-buf sharing between devices Chunming Zhou
2019-04-17 13:59 ` Christian König
2019-04-17 14:14 ` Chunming Zhou
2019-04-18 9:13 ` Daniel Vetter
2019-04-18 10:57 ` Christian König
2019-04-27 0:01 ` [PATCH 01/12] dma-buf: add dynamic caching of sg_table Liam Mark
2019-05-22 16:17 ` Sumit Semwal
2019-05-22 17:27 ` Christian König
2019-05-22 18:30 ` Daniel Vetter
2019-05-23 11:21 ` Koenig, Christian
2019-05-23 11:30 ` Daniel Vetter
2019-05-23 11:32 ` 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=20190417142002.GE13337@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox