On Mon, May 17, 2021 at 04:11:27PM +0200, Christian König wrote: > Add usage flags for shared fences and improve the documentation. > > This allows driver to better specify what shared fences > are doing with the resource. > > Signed-off-by: Christian König <christian.koenig@xxxxxxx> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index 16b869d9b1d6..c9bbc4630afc 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -700,7 +700,7 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo, > return ret; > } > > - dma_resv_add_shared_fence(bo->base.resv, fence); > + dma_resv_add_shared(bo->base.resv, fence, DMA_RESV_USAGE_RW); Entirely aside, but I ended up scratching my head a lot for why exactly this here is a shared fence, and why that's ok. Since just looking at this it seems like waiting for the memory allocation to actually be owned by this driver is optional. Is this ok because the next thing we'll do is a move, which will then set the exclusive fence here. Which will then wait on the shared one here, so it doesn't matter? Or well, allows us to pipeline the eviction of ttm_man against whatever might be currently keeping the bo busy in it's current place? Might be good candidate to explain this in a comment or something like that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
