LWN: Comments on "DMA buffer sharing in 3.3"

DMA buffer sharing in 3.3

RErrabolu — Wed, 16 Dec 2020 18:12:20 +0000

One question that is not very clear to me is what is considered DMA buffer. Could some one clarify which scheme is operational upon using DMA-BUF Api's.

Scheme 1:
device-mem -> Camera -> buffer-one-sysmem
buffer-one-sysmem -> CPU -> buffer-two-sysmem
buffer-two-sysmem -> Render -> device-mem

Scheme 2:
device-mem -> Camera -> buffer-common-sysmem
buffer-common-sysmem -> Render -> device-mem

Scheme 3:
device-mem -> Camera -> Render -> device-mem

I suspect scheme 2. Can someone comment.

Changing usernames

corbet — Fri, 13 Jan 2012 03:01:44 +0000

Send us a note at lwn@lwn.net if you would like to change your account name; we can make that happen.

DMA buffer sharing in 3.3

robclark — Fri, 13 Jan 2012 02:55:25 +0000

TI very kindly provides LWN subscription to employees, but I've no idea how to change my username to something other than my AID ;-)

DMA buffer sharing in 3.3

jzbiciak — Fri, 13 Jan 2012 00:06:48 +0000

Not related to the article really... I think this is the first time I've noticed an AID here on LWN. :-)

(I'm also a TIer, but I'm here out of personal interest.)

DMA buffer sharing in 3.3

robclark — Thu, 12 Jan 2012 16:48:30 +0000

just a very minor correction: attach()/detach() are not really for reference counting, that is handled with dma_buf_get()/dma_buf_put() (under the hood it is using 'struct file *' refcnting). Driver writers adding support for dmabuf should be sure to do a dma_buf_get() in their ioctl for importing the dmabuf, and keep the 'struct dma_buf *' ptr, rather than holding on to the file descriptor (int).

The attach()/detach() is really just advisory to the exporting driver to help it know the constraints of potentially multiple different devices that would be sharing the buffer. For example, a camera and encoder might share a single buffer w/ display/gpu.