about mmap dma-buf and sync

[Tiago Vignatti]

On 08/25/2015 06:30 AM, Thomas Hellstrom wrote:
> On 08/25/2015 11:02 AM, Daniel Vetter wrote:
>> I really feel like any kind of multi-range flush interface is feature
>> bloat, and if we do it then we should only do it later on when there's a
>> clear need for it.
>
> IMO all the use-cases so far that wanted to do this have been 2D
> updates. and having only a 1D sync will most probably scare people away
> from this interface.
>
>> Afaiui dma-buf mmap will mostly be used for up/downloads, which means
>> there will be some explicit copy involved somewhere anyway. So similar to
>> userptr usage. And for those most often you just slurp in a linear block
>> and then let the blitter rearrange it, at least on i915.
>>
>> Also thus far the consensus was that dma-buf doesn't care/know about
>> content layout, adding strides/bytes/whatever does bend this quite a bit.
>
> I think with a 2D interface, the stride only applies to the sync
> operation itself and is only a parameter for that sync operation.
> Whether we should have multiple regions or not is not a big deal for me,
> but I think at least a 2D sync is crucial.

Right now only omap, ion and udl-fb make use of begin{,end}_cpu_access() 
dma-buf interface, but it's curious that none uses those 1-d parameters 
(start and len). So in that sense it seems that the tendency is to 
feature bloat the API if we do the 2-d additions.

OTOH we're talking about a different usage of dma-buf right now, so the 
driver might actually start to use in fact that API. That said, I 
thought it was somewhat simple to turn the common code into 2-d, cause, 
as I pointed in the other email, we'd be pushing the whole 
responsibility of dealing with the regions and so on to the driver 
implementors.

Thomas, any comments in the dma_buf_begin_cpu_access() new API I showed? 
Maybe I should just clean up here the draft and sent it to the ML :)

Tiago