On Tue, Feb 11, 2020 at 04:43:26PM +0100, Christian König wrote:
> When non-imported BOs are resurrected for delayed delete we replace
> the dma_resv object to allow for easy reclaiming of the resources.
> 
> v2: move that to ttm_bo_individualize_resv
> v3: add a comment to explain what's going on
> 
> Signed-off-by: Christian König <christian.koe...@amd.com>
> Reviewed-by: xinhui pan <xinhui....@amd.com>
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index bfc42a9e4fb4..8174603d390f 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -393,6 +393,18 @@ static int ttm_bo_individualize_resv(struct 
> ttm_buffer_object *bo)
>  
>       r = dma_resv_copy_fences(&bo->base._resv, bo->base.resv);
>       dma_resv_unlock(&bo->base._resv);
> +     if (r)
> +             return r;
> +
> +     if (bo->type != ttm_bo_type_sg) {
> +             /* This works because the BO is about to be destroyed and nobody
> +              * reference it any more. The only tricky case is the trylock on
> +              * the resv object while holding the lru_lock.
> +              */

I'm foolish enough to believe this is correct :-)

Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>

> +             spin_lock(&ttm_bo_glob.lru_lock);
> +             bo->base.resv = &bo->base._resv;
> +             spin_unlock(&ttm_bo_glob.lru_lock);
> +     }
>  
>       return r;
>  }
> @@ -724,7 +736,7 @@ static bool ttm_bo_evict_swapout_allowable(struct 
> ttm_buffer_object *bo,
>  
>       if (bo->base.resv == ctx->resv) {
>               dma_resv_assert_held(bo->base.resv);
> -             if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT || bo->deleted)
> +             if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT)
>                       ret = true;
>               *locked = false;
>               if (busy)
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to