[PATCH 22/26] dma-buf: add enum dma_resv_usage

[Daniel Vetter]

On Mon, Nov 29, 2021 at 01:19:11PM +0100, Christian König wrote:
> Am 25.11.21 um 16:59 schrieb Daniel Vetter:
> > [SNIP]
> > > + *
> > > + * For example when asking for WRITE fences then the KERNEL fences are returned
> > > + * as well. Similar when asked for READ fences then both WRITE and KERNEL
> > > + * fences are returned as well.
> > > + */
> > > +enum dma_resv_usage {
> > > +	/**
> > > +	 * @DMA_RESV_USAGE_KERNEL: For in kernel memory management only.
> > > +	 *
> > > +	 * This should only be used for things like copying or clearing memory
> > > +	 * with a DMA hardware engine for the purpose of kernel memory
> > > +	 * management.
> > > +	 *
> > > +         * Drivers *always* need to wait for those fences before accessing the
> > > +	 * resource protected by the dma_resv object. The only exception for
> > > +	 * that is when the resource is known to be locked down in place by
> > > +	 * pinning it previously.
> > Should dma_buf_pin also do the wait for kernel fences? I think that would
> > also ba e bit clearer semantics in the dma-buf patch which does these
> > waits for us.
> > 
> > Or should dma_buf_pin be pipelined and it's up to callers to wait? For kms
> > that's definitely the semantics we want, but it's a bit playing with fire
> > situation, so maybe dma-buf should get the more idiot proof semantics?
> 
> Yeah, good question. I've already added a wait after mapping an attachment
> for static importers.
> 
> But for dynamic importers I'm not sure what we want to do. On the one hand
> waiting for moves to finish is certainly the more defensive approach on the
> other hand when you have a dynamic importer you absolutely need to handle
> those dependencies correctly anyway.

Hm yeah only doing it for non-dynamic attachments sounds fine to me (with
kerneldoc in dma_buf_pin() ofc).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch