[PATCH 1/6] dma-buf: add dynamic DMA-buf handling v13

[Daniel Vetter]

On Fri, Jul 19, 2019 at 09:14:05AM +0000, Koenig, Christian wrote:
> Am 19.07.19 um 10:57 schrieb Daniel Vetter:
> > On Tue, Jul 16, 2019 at 04:21:53PM +0200, Christian König wrote:
> >> Am 26.06.19 um 14:29 schrieb Daniel Vetter:
> >>> On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> >>> [SNIP]
> >>> Also I looked at CI results and stuff, I guess you indeed didn't break the
> >>> world because Chris Wilson has faught back struct_mutex far enough by now.
> >>>
> >>> Other issue is that since 2 weeks or so our CI started filtering all
> >>> lockdep splats, so you need to dig into results yourself.
> >>>
> >>> btw on that, I think in the end the reservation_obj locking will at best
> >>> be consistent between amdgpu and i915: I just remembered that all other
> >>> ttm drivers have the mmap_sem vs resv_obj locking the wrong way round, and
> >>> the trylock in ttm_bo_fault. So that part alone is hopeless, but I guess
> >>> since radeon.ko is abandonware no one will ever fix that.
> >>>
> >>> So I think in the end it boils down to whether that's good enough to land
> >>> it, or not.
> >> Well can you give me an rb then? I mean at some point I have to push it to
> >> drm-misc-next.
> > Well my mail here preceeded the entire amdkfd eviction_fence discussion.
> > With that I'm not sure anymore, since we don't really need two approaches
> > of the same thing. And if the plan is to move amdkfd over from the
> > eviction_fence trick to using the invalidate callback here, then I think
> > we might need some clarifications on what exactly that means.
> 
> Mhm, I thought that this was orthogonal. I mean the invalidation 
> callback for a buffer are independent from how the driver is going to 
> use it in the end.
> 
> Or do you mean that we could use fences and save us from adding just 
> another mechanism for the same signaling thing?
> 
> That could of course work, but I had the impression that you are not 
> very in favor of that.

It won't, since you can either use the fence as the invalidate callback,
or as a fence (for implicit sync). But not both.

But I also don't think it's a good idea to have 2 invalidation mechanisms,
and since we do have one merged in-tree already would be good to proof
that the new one is up to the existing challenge.

For context: I spend way too much time reading ttm, amdgpu/kfd and i915-gem
code and my overall impression is that everyone's just running around in
opposite directions and it's one huge hairball of a mess. With a pretty
even distribution of equally "eek this is horrible" but also "wow this is
much better than what the other driver does". So that's why I'm even more
on the "are we sure this is the right thing" train.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch