On Tue, Nov 16, 2021 at 05:02:25PM +0100, Daniel Vetter wrote:
On Mon, Nov 15, 2021 at 02:57:37PM +0000, Paul Cercueil wrote:And cameras (maybe they're included in "whatever" ?).
Le lun., nov. 15 2021 at 15:37:16 +0100, Daniel Vetter a écrit :
On Mon, Nov 15, 2021 at 02:19:10PM +0000, Paul Cercueil wrote:
Hi Jonathan,Why dma-buf? dma-buf looks like something super generic and useful, until
This patchset introduces a new userspace interface based on DMABUF
objects, to complement the existing fileio based API.
The advantage of this DMABUF based interface vs. the fileio
interface, is that it avoids an extra copy of the data between the
kernel and userspace. This is particularly userful for high-speed
devices which produce several megabytes or even gigabytes of data per
The first few patches [01/15] to [03/15] are not really related, but
allow to reduce the size of the patches that introduce the new API.
Patch [04/15] to [06/15] enables write() support to the buffer-dma
implementation of the buffer API, to continue the work done by
Patches [07/15] to [12/15] introduce the new DMABUF based API.
Patches [13/15] and [14/15] add support for cyclic buffers, only through
the new API. A cyclic buffer will be repeated on the output until the
buffer is disabled.
Patch [15/15] adds documentation about the new API.
For now, the API allows you to alloc DMABUF objects and mmap() them
read or write the samples. It does not yet allow to import DMABUFs
parented to other subsystems, but that should eventually be possible
once it's wired.
This patchset is inspired by the "mmap interface" that was previously
submitted by Alexandru Ardelean and Lars-Peter Clausen, so it would be
great if I could get a review from you guys. Alexandru's commit was
signed with his @analog.com address but he doesn't work at ADI anymore,
so I believe I'll need him to sign with a new email.
you realize that there's a metric ton of gpu/accelerator bagage piled in.
So unless buffer sharing with a gpu/video/accel/whatever device is the
Not GUP please. That brings another set of issues, especially whenHm is that code merged already in upstream already?goal here, and it's just for a convenient way to get at buffer handles,Good question. The first reason is that a somewhat similar API was intented
this doesn't sound like a good idea.
before, but refused upstream as it was kind of re-inventing the wheel.
The second reason, is that we want to be able to share buffers too, not with
gpu/video but with the network (zctap) and in the future with USB
I know that dma-buf looks really generic, but like I said if there's no
need ever to interface with any of the gpu buffer sharing it might be
better to use something else (like get_user_pages maybe, would that work?).
dealing with DMA, we've suffered enough from the USERPTR support in V4L2
to avoid repeating this. Let's make dma-buf better instead.