From: Daniel Vetter Date: Wed, 19 May 2021 08:24:09 +0000 (+0200) Subject: drm/ttm: Explain why ttm_bo_add_move_fence uses a shared slot X-Git-Tag: accepted/tizen/unified/20230118.172025~6402^2~28^2~354 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=6d0a12c734c302eead11366856aecdae54a401e8;p=platform%2Fkernel%2Flinux-rpi.git drm/ttm: Explain why ttm_bo_add_move_fence uses a shared slot Motivated because I got confused and Christian confirmed why this works. I think this is non-obvious enough that it merits a slightly longer comment. Acked-by: Huang Rui Reviewed-by: Christian König Cc: Christian König Cc: Christian Koenig Cc: Huang Rui Cc: Thomas Hellström Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210519082409.672016-1-daniel.vetter@ffwll.ch --- diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index ca1b098..51a94fd 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -682,7 +682,9 @@ int ttm_mem_evict_first(struct ttm_device *bdev, } /* - * Add the last move fence to the BO and reserve a new shared slot. + * Add the last move fence to the BO and reserve a new shared slot. We only use + * a shared slot to avoid unecessary sync and rely on the subsequent bo move to + * either stall or use an exclusive fence respectively set bo->moving. */ static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo, struct ttm_resource_manager *man,