[Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
daniel at ffwll.ch
Tue Jun 25 07:40:27 UTC 2019
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
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 ...
Software Engineer, Intel Corporation
More information about the amd-gfx