From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: daniel.vetter@ffwll.ch,
"Christian König" <christian.koenig@amd.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 21/23] dma-buf: wait for map to complete for static attachments
Date: Tue, 29 Mar 2022 17:56:45 +0200 [thread overview]
Message-ID: <YkMsPUuyXU2bB3ma@phenom.ffwll.local> (raw)
In-Reply-To: <20220321135856.1331-21-christian.koenig@amd.com>
On Mon, Mar 21, 2022 at 02:58:54PM +0100, Christian König wrote:
> We have previously done that in the individual drivers but it is
> more defensive to move that into the common code.
>
> Dynamic attachments should wait for map operations to complete by themselves.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
You could perhaps ditch the call to i915_gem_object_wait_migration() in
the i915 dma-buf code too with this, but that entire thing is a bit a mess
and totally different. So I guess we'll leave that.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/dma-buf/dma-buf.c | 18 +++++++++++++++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14 +-------------
> drivers/gpu/drm/nouveau/nouveau_prime.c | 17 +----------------
> drivers/gpu/drm/radeon/radeon_prime.c | 16 +++-------------
> 4 files changed, 20 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 528983d3ba64..d3dd602c4753 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -660,12 +660,24 @@ static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach,
> enum dma_data_direction direction)
> {
> struct sg_table *sg_table;
> + signed long ret;
>
> sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> + if (IS_ERR_OR_NULL(sg_table))
> + return sg_table;
> +
> + if (!dma_buf_attachment_is_dynamic(attach)) {
> + ret = dma_resv_wait_timeout(attach->dmabuf->resv,
> + DMA_RESV_USAGE_KERNEL, true,
> + MAX_SCHEDULE_TIMEOUT);
> + if (ret < 0) {
> + attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
> + direction);
> + return ERR_PTR(ret);
> + }
> + }
>
> - if (!IS_ERR_OR_NULL(sg_table))
> - mangle_sg_table(sg_table);
> -
> + mangle_sg_table(sg_table);
> return sg_table;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 579adfafe4d0..782cbca37538 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -102,21 +102,9 @@ static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
> {
> struct drm_gem_object *obj = attach->dmabuf->priv;
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> - int r;
>
> /* pin buffer into GTT */
> - r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> - if (r)
> - return r;
> -
> - if (bo->tbo.moving) {
> - r = dma_fence_wait(bo->tbo.moving, true);
> - if (r) {
> - amdgpu_bo_unpin(bo);
> - return r;
> - }
> - }
> - return 0;
> + return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> }
>
> /**
> diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c b/drivers/gpu/drm/nouveau/nouveau_prime.c
> index 60019d0532fc..347488685f74 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_prime.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
> @@ -93,22 +93,7 @@ int nouveau_gem_prime_pin(struct drm_gem_object *obj)
> if (ret)
> return -EINVAL;
>
> - ret = ttm_bo_reserve(&nvbo->bo, false, false, NULL);
> - if (ret)
> - goto error;
> -
> - if (nvbo->bo.moving)
> - ret = dma_fence_wait(nvbo->bo.moving, true);
> -
> - ttm_bo_unreserve(&nvbo->bo);
> - if (ret)
> - goto error;
> -
> - return ret;
> -
> -error:
> - nouveau_bo_unpin(nvbo);
> - return ret;
> + return 0;
> }
>
> void nouveau_gem_prime_unpin(struct drm_gem_object *obj)
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c b/drivers/gpu/drm/radeon/radeon_prime.c
> index 4a90807351e7..42a87948e28c 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -77,19 +77,9 @@ int radeon_gem_prime_pin(struct drm_gem_object *obj)
>
> /* pin buffer into GTT */
> ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
> - if (unlikely(ret))
> - goto error;
> -
> - if (bo->tbo.moving) {
> - ret = dma_fence_wait(bo->tbo.moving, false);
> - if (unlikely(ret)) {
> - radeon_bo_unpin(bo);
> - goto error;
> - }
> - }
> -
> - bo->prime_shared_count++;
> -error:
> + if (likely(ret == 0))
> + bo->prime_shared_count++;
> +
> radeon_bo_unreserve(bo);
> return ret;
> }
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2022-03-29 15:56 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 13:58 [PATCH 01/23] dma-buf: add dma_resv_replace_fences v2 Christian König
2022-03-21 13:58 ` [PATCH 02/23] dma-buf: finally make the dma_resv_list private v2 Christian König
2022-03-21 13:58 ` [PATCH 03/23] dma-buf: add dma_resv_get_singleton v2 Christian König
2022-04-01 8:21 ` Christian König
2022-04-01 15:57 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 04/23] RDMA: use dma_resv_wait() instead of extracting the fence Christian König
2022-03-21 13:58 ` Christian König
2022-03-23 13:22 ` Daniel Vetter
2022-03-23 13:22 ` Daniel Vetter
2022-03-23 16:32 ` Jason Gunthorpe
2022-03-23 16:32 ` Jason Gunthorpe
2022-03-23 17:34 ` Daniel Vetter
2022-03-23 17:34 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 05/23] drm/etnaviv: stop using dma_resv_excl_fence Christian König
2022-03-23 15:58 ` Lucas Stach
2022-03-21 13:58 ` [Nouveau] [PATCH 06/23] drm/nouveau: " Christian König
2022-03-21 13:58 ` Christian König
2022-04-03 15:59 ` [Nouveau] " Christian König
2022-04-03 15:59 ` Christian König
2022-04-04 11:47 ` [Nouveau] " Karol Herbst
2022-04-04 11:47 ` Karol Herbst
2022-04-05 7:25 ` [Nouveau] " Christian König
2022-04-05 7:25 ` Christian König
2022-03-21 13:58 ` [PATCH 07/23] drm/vmwgfx: " Christian König
2022-03-21 14:02 ` Zack Rusin
2022-03-21 14:12 ` Christian König
2022-03-21 15:11 ` Zack Rusin
2022-03-22 7:13 ` Christian König
2022-03-22 12:40 ` Zack Rusin
2022-03-21 13:58 ` [PATCH 08/23] drm/radeon: " Christian König
2022-03-21 13:58 ` [PATCH 09/23] drm/amdgpu: use dma_resv_for_each_fence for CS workaround Christian König
2022-03-21 13:58 ` [PATCH 10/23] dma-buf: finally make dma_resv_excl_fence private v2 Christian König
2022-03-23 13:36 ` Daniel Vetter
2022-04-05 7:58 ` Christian König
2022-03-21 13:58 ` [PATCH 11/23] dma-buf: drop the DAG approach for the dma_resv object v2 Christian König
2022-03-23 13:40 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 12/23] dma-buf/drivers: make reserving a shared slot mandatory v3 Christian König
2022-03-28 17:14 ` Daniel Vetter
2022-03-31 12:07 ` Christian König
2022-03-31 16:42 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 13/23] drm/atomic-helper: support more than one write fence in drm_gem_plane_helper_prepare_fb Christian König
2022-03-21 13:58 ` [Nouveau] [PATCH 14/23] drm/nouveau: support more than one write fence in fenv50_wndw_prepare_fb Christian König
2022-03-21 13:58 ` Christian König
2022-03-21 13:58 ` [PATCH 15/23] drm/amdgpu: use dma_resv_get_singleton in amdgpu_pasid_free_cb Christian König
2022-03-21 13:58 ` [PATCH 16/23] dma-buf: add enum dma_resv_usage v3 Christian König
2022-03-29 15:24 ` Daniel Vetter
2022-04-04 1:13 ` Bas Nieuwenhuizen
2022-03-21 13:58 ` [PATCH 17/23] dma-buf: specify usage while adding fences to dma_resv obj v5 Christian König
2022-03-29 15:43 ` Daniel Vetter
2022-04-01 15:01 ` Christian König
2022-04-01 16:16 ` Daniel Vetter
2022-04-02 22:16 ` Bas Nieuwenhuizen
2022-04-03 17:48 ` Christian König
2022-03-21 13:58 ` [PATCH 18/23] drm/amdgpu: remove dma_resv workaround Christian König
2022-03-29 15:47 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 19/23] dma-buf: add DMA_RESV_USAGE_KERNEL v2 Christian König
2022-03-29 15:53 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 20/23] dma-buf: add DMA_RESV_USAGE_BOOKKEEP v2 Christian König
2022-03-29 16:06 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 21/23] dma-buf: wait for map to complete for static attachments Christian König
2022-03-29 15:56 ` Daniel Vetter [this message]
2022-03-21 13:58 ` [Intel-gfx] [PATCH 22/23] drm/i915: drop bo->moving dependency Christian König
2022-03-21 13:58 ` Christian König
2022-03-29 15:57 ` [Intel-gfx] " Daniel Vetter
2022-03-29 15:57 ` Daniel Vetter
2022-03-21 13:58 ` [PATCH 23/23] drm/ttm: remove bo->moving Christian König
2022-03-29 16:02 ` Daniel Vetter
2022-04-05 9:25 ` Christian König
2022-04-05 12:51 ` Daniel Vetter
2022-03-21 14:03 ` [PATCH 01/23] dma-buf: add dma_resv_replace_fences v2 Christian König
2022-03-23 13:09 ` Daniel Vetter
2022-03-23 15:55 ` Felix Kuehling
2022-03-23 15:57 ` Christian König
-- strict thread matches above, loose matches on Subject: below --
2022-02-11 12:49 completely rework the dma_resv semantic Christian König
2022-02-11 12:50 ` [PATCH 21/23] dma-buf: wait for map to complete for static attachments Christian König
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=YkMsPUuyXU2bB3ma@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.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.