[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

[Rob Clark]

On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit :
>> > For that matter, wouldn't it be useful to support exporting a userptr
>> > buffer at some point in the future?
>>
>> Shouldn't USERPTR usage be discouraged once we get dma-buf support ?
>
> USERPTR, where available, is currently the only way to perform zero-copy from
> kernel to userspace. READWRITE does not support zero-copy at all. MMAP only
> supports zero-copy if userspace knows a boundary on the number of concurrent
> buffers *and* the device can deal with that number of buffers; in general,
> MMAP requires memory copying.

hmm, this sounds like the problem is device pre-allocating buffers?
Anyways, last time I looked, the vb2 core supported changing dmabuf fd
each time you QBUF, in a similar way to what you can do w/ userptr.
So that seems to get you the advantages you miss w/ mmap without the
pitfalls of userptr.

> I am not sure DMABUF even supports transmitting data efficiently to userspace.
> In my understanding, it's meant for transmitting data between DSP's bypassing
> userspace entirely, in other words the exact opposite of what USERBUF does.

well, dmabuf's can be mmap'd.. so it is more a matter of where the
buffer gets allocated, malloc() or from some driver (v4l2 or other).
There are a *ton* of ways userspace allocated memory can go badly,
esp. if the hw has special requirements about memory (GFP_DMA32 in a
system w/ PAE/LPAE, certain ranges of memory, certain alignment of
memory, etc).

BR,
-R

> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis