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

[Koenig, Christian]

Am 22.05.19 um 13:29 schrieb Daniel Vetter:
> [SNIP]
> Forgot to add: Iirc it was buffer sharing between i915 and amdgpu that
> hits this. Can't say for sure since intel-gfx isn't cc'ed on this
> version, so our CI hasn't picked this up.

I've changed this so that when exporter/importer disagree on dynamic 
handling we always cache the sgt during the attachment process.

Going to CC intel-gfx on the next version.

> -Daniel
>
>>>>> +            struct sg_table *sgt;
>>>>> +
>>>>> +            sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
>>>> And unfortunately the non-dynamic, i.e. legacy/current code importer is
>>>> also the one which uses other flags than DMA_BIDIRECTIONAL. At least on
>>>> ARM, and that's the only place where this matters because there the dma
>>>> api might do cache flushing.
>>> Well the only implementer for now is amdgpu, and amdgpu always requires
>>> a coherent bidirectional mapping.
>>>
>>> So this won't be a problem unless the ARM drivers start to implement
>>> dynamic DMA-buf handling themselves or start to talk to amdgpu (which
>>> wouldn't have worked before anyway).
>> Hm, feels a bit evil. I just heard a some soc people tell me that drm
>> isn't cool because it likes to ignore soc at the expensive of x86.
>>
>> Otoh I don't see a way out either, and maybe this will be motivation
>> enough to make the dma-api cache management a bit more explicit. Not
>> that I expect much change there ...

Actually it's not evil at all, see those exporters/importers could 
implement the callbacks for dynamic handling as well and the problem of 
the caching wouldn't appear either.

Christian.

>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch