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

[Koenig, Christian]

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.

Christian.

> -Daniel
>
>> Christian.
>>
>>