[Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10

[Daniel Vetter]

On Tue, Jun 25, 2019 at 07:20:12AM +0000, Koenig, Christian wrote:
> Am 24.06.19 um 16:41 schrieb Daniel Vetter:
> > On Mon, Jun 24, 2019 at 03:58:00PM +0200, Christian König wrote:
> >> Am 24.06.19 um 13:23 schrieb Koenig, Christian:
> >>> Am 21.06.19 um 18:27 schrieb Daniel Vetter:
> >>>
> >>>> So I pondered a few ideas while working out:
> >>>>
> >>>> 1) We drop this filtering. Importer needs to keep track of all its
> >>>> mappings and filter out invalidates that aren't for that specific importer
> >>>> (either because already invalidated, or not yet mapped, or whatever).
> >>>> Feels fragile.
> >>>>
> >>>> [SNIP]
> >>> [SNIP]
> >>>
> >>> I will take a moment and look into #1 as well, but I still don't see the
> >>> need to change anything.
> >> That turned out much cleaner than I thought it would be. Essentially it is
> >> only a single extra line of code in amdgpu.
> >>
> >> Going to send that out as a patch set in a minute.
> > Yeah I mean kinda expected that because:
> > - everything's protected with ww_mutex anyway
> > - importer needs to keep track of mappings anways
> > So really all it needs to do is not be stupid and add the mapping it just
> > created to its tracking while still holding the ww_mutex. Similar on
> > invalidate/unmap.
> >
> > With that all we need is a huge note in the docs that importers need to
> > keep track of their mappings and dtrt (with all the examples here spelled
> > out in the appropriate kerneldoc). And then I'm happy :-)
> 
> Should I also rename the invalidate callback into move_notify? Would 
> kind of make sense since we are not necessary directly invalidating 
> mappings.

Hm maybe. I'll review the entire pile and probably reply with a docs patch
anyway. It would help in making it clear you get the callback even when
there's no mapping to invalidate for you ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch