From hverkuil@xs4all.nl Wed Aug 22 10:48:55 2012 From: Hans Verkuil To: linaro-mm-sig@lists.linaro.org Subject: Re: [Linaro-mm-sig] [PATCHv8 02/26] Documentation: media: description of DMABUF importing in V4L2 Date: Wed, 22 Aug 2012 12:47:36 +0200 Message-ID: <201208221247.36471.hverkuil@xs4all.nl> In-Reply-To: <1344958496-9373-3-git-send-email-t.stanislaws@samsung.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8235234365777843425==" --===============8235234365777843425== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue August 14 2012 17:34:32 Tomasz Stanislawski wrote: > This patch adds description and usage examples for importing > DMABUF file descriptor in V4L2. >=20 > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Kyungmin Park > CC: linux-doc(a)vger.kernel.org > --- > Documentation/DocBook/media/v4l/compat.xml | 4 + > Documentation/DocBook/media/v4l/io.xml | 180 ++++++++++++++++= ++++ > .../DocBook/media/v4l/vidioc-create-bufs.xml | 3 +- > Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 15 ++ > Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 ++--- > 5 files changed, 226 insertions(+), 23 deletions(-) >=20 > diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/Doc= Book/media/v4l/compat.xml > index 98e8d08..ff45330 100644 > --- a/Documentation/DocBook/media/v4l/compat.xml > +++ b/Documentation/DocBook/media/v4l/compat.xml > @@ -2605,6 +2605,10 @@ ioctls. > > Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; = ioctl. > > + > + Importing DMABUF file descriptors as a new IO method described > + in . > + > > > =20 > diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook= /media/v4l/io.xml > index 1885cc0..98253ee 100644 > --- a/Documentation/DocBook/media/v4l/io.xml > +++ b/Documentation/DocBook/media/v4l/io.xml > @@ -472,6 +472,163 @@ rest should be evident. > > > =20 > +
> + Streaming I/O (DMA buffer importing) > + > + > + Experimental > + This is an experimental > + interface and may change in the future. > + > + > +The DMABUF framework provides a generic mean for sharing buffers bet= ween s/mean/method/ > + multiple devices. Device drivers that support DMABUF can export a DMA buf= fer > +to userspace as a file descriptor (known as the exporter role), import a D= MA > +buffer from userspace using a file descriptor previously exported for a > +different or the same device (known as the importer role), or both. This > +section describes the DMABUF importer role API in V4L2. > + > +Input and output devices support the streaming I/O method when the > +V4L2_CAP_STREAMING flag in the > +capabilities field of &v4l2-capability; returne= d by > +the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through > +DMABUF file descriptors is supported is determined by calling the > +&VIDIOC-REQBUFS; ioctl with the memory type set to > +V4L2_MEMORY_DMABUF. > + > + This I/O method is dedicated for sharing DMA buffers between V4L= and > +other APIs. Buffers (planes) are allocated by a driver on behalf of the > +application, and exported to the application as file descriptors using an = API > +specific to the allocator driver. Only those file descriptor are exchange= d, > +these files and meta-information are passed in &v4l2-buffer; (or in This sentence doesn't work well. It's unclear what is meant by 'these files'.= Do you mean 'these file descriptors'? > +&v4l2-plane; in the multi-planar API case). The driver must be switched i= nto > +DMABUF I/O mode by calling the &VIDIOC-REQBUFS; with the desired buffer ty= pe. > +No buffers (planes) are allocated beforehand, consequently they are not in= dexed > +and cannot be queried like mapped buffers with the > +VIDIOC_QUERYBUF ioctl. I disagree with that. Userptr buffers can use QUERYBUF just fine. Even for the userptr you still have to fill in the buffer index when calling QBUF. So I see no reason why you couldn't use QUERYBUF in the DMABUF case. The only difference is that the fd field is undefined (set to -1 perhaps?) if the buff= fer isn't queued. QUERYBUF can be very useful for debugging, for example to see what the status is of each buffer and how many are queued. > + > + > + Initiating streaming I/O with DMABUF file descriptors > + > + > +&v4l2-requestbuffers; reqbuf; > + > +memset (&reqbuf, 0, sizeof (reqbuf)); > +reqbuf.type =3D V4L2_BUF_TYPE_VIDEO_CAPTURE; > +reqbuf.memory =3D V4L2_MEMORY_DMABUF; > +reqbuf.count =3D 1; > + > +if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) =3D=3D -1) { > + if (errno =3D=3D EINVAL) > + printf ("Video capturing or DMABUF streaming is not supported\n"); > + else > + perror ("VIDIOC_REQBUFS"); > + > + exit (EXIT_FAILURE); Let's stick to the kernel coding style, so no ' ' before '(' in function call= s. Same for the other program examples below. > +} > + > + > + > + Buffer (plane) file descriptor is passed on the fly with the s/Buffer/The buffer/ > +&VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be 'Can be', 'should be' or 'must be'? Does it ever make sense to have the same fd for different planes? Do we have restrictions on this in the userptr case? > +associated with a different DMABUF descriptor. Although buffers are common= ly > +cycled, applications can pass a different DMABUF descriptor at each > +VIDIOC_QBUF call. > + > + > + Queueing DMABUF using single plane API > + > + > +int buffer_queue(int v4lfd, int index, int dmafd) > +{ > + &v4l2-buffer; buf; > + > + memset(&buf, 0, sizeof buf); > + buf.type =3D V4L2_BUF_TYPE_VIDEO_CAPTURE; > + buf.memory =3D V4L2_MEMORY_DMABUF; > + buf.index =3D index; > + buf.m.fd =3D dmafd; > + > + if (ioctl (v4lfd, &VIDIOC-QBUF;, &buf) =3D=3D -1) { > + perror ("VIDIOC_QBUF"); > + return -1; > + } > + > + return 0; > +} > + > + > + > + > + Queueing DMABUF using multi plane API > + > + > +int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes) > +{ > + &v4l2-buffer; buf; > + &v4l2-plane; planes[VIDEO_MAX_PLANES]; > + int i; > + > + memset(&buf, 0, sizeof buf); > + buf.type =3D V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; > + buf.memory =3D V4L2_MEMORY_DMABUF; > + buf.index =3D index; > + buf.m.planes =3D planes; > + buf.length =3D n_planes; > + > + memset(&planes, 0, sizeof planes); > + > + for (i =3D 0; i < n_planes; ++i) > + buf.m.planes[i].m.fd =3D dmafd[i]; > + > + if (ioctl (v4lfd, &VIDIOC-QBUF;, &buf) =3D=3D -1) { > + perror ("VIDIOC_QBUF"); > + return -1; > + } > + > + return 0; > +} > + > + > + > + Filled or displayed buffers are dequeued with the > +&VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any > +time between the completion of the DMA and this ioctl. The memory is > +also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or > +when the device is closed. > + > + For capturing applications it is customary to enqueue a > +number of empty buffers, to start capturing and enter the read loop. > +Here the application waits until a filled buffer can be dequeued, and > +re-enqueues the buffer when the data is no longer needed. Output > +applications fill and enqueue buffers, when enough buffers are stacked > +up output is started. In the write loop, when the application > +runs out of free buffers it must wait until an empty buffer can be > +dequeued and reused. Two methods exist to suspend execution of the > +application until one or more buffers can be dequeued. By default > +VIDIOC_DQBUF blocks when no buffer is in the > +outgoing queue. When the O_NONBLOCK flag was > +given to the &func-open; function, VIDIOC_DQBUF > +returns immediately with an &EAGAIN; when no buffer is available. The > +&func-select; or &func-poll; function are always available. s/function/functions/ > + > + To start and stop capturing or output applications call the > +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctls. Note that > +VIDIOC_STREAMOFF removes all buffers from both queues= and > +unlocks all buffers as a side effect. Since there is no notion of doing > +anything "now" on a multitasking system, if an application needs to synchr= onize > +with another event it should examine the &v4l2-buffer; > +timestamp of captured buffers, or set the field > +before enqueuing buffers for output. > + > + Drivers implementing DMABUF importing I/O must support the > +VIDIOC_REQBUFS, VIDIOC_QBUF, > +VIDIOC_DQBUF, VIDIOC_STREAMON and > +VIDIOC_STREAMOFF ioctls, and the > +select() and poll() functions. > + > +
> + >
> Asynchronous I/O > =20 > @@ -673,6 +830,14 @@ memory, set by the application. See for details. > v4l2_buffer structure. > > > + > + int > + fd > + For the single-plane API and when > +memory is V4L2_MEMORY_DMABUF this > +is the file descriptor associated with a DMABUF buffer. > + > + > __u32 > length > > @@ -746,6 +911,15 @@ should set this to 0. > > > > + > + int > + fd > + When the memory type in the containing &v4l2-buffer; is > + V4L2_MEMORY_DMABUF, this is a file > + descriptor associated with a DMABUF buffer, similar to the > + fd field in &v4l2-buffer;. > + > + > __u32 > data_offset > > @@ -973,6 +1147,12 @@ pointer I/O. > 3 > [to do] > > + > + V4L2_MEMORY_DMABUF > + 4 > + The buffer is used for DMA shared > +buffer I/O. > + > > > > diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Docum= entation/DocBook/media/v4l/vidioc-create-bufs.xml > index a8cda1a..1125468 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml > @@ -109,7 +109,8 @@ information. > __u32 > memory > Applications set this field to > -V4L2_MEMORY_MMAP or > +V4L2_MEMORY_MMAP, > +V4L2_MEMORY_DMABUF or > V4L2_MEMORY_USERPTR. See /> > > diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentatio= n/DocBook/media/v4l/vidioc-qbuf.xml > index 77ff5be..436d21c 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml > @@ -109,6 +109,21 @@ they cannot be swapped out to disk. Buffers remain loc= ked until > dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is > called, or until the device is closed. > =20 > + To enqueue a DMABUF buffer appli= cations > +set the memory field to > +V4L2_MEMORY_DMABUF and the m.fd > +field to a file descriptor associated with a DMABUF buffer. When the > +multi-planar API is used m.fd of the passed arr= ay of multi-planar API is used the m.fd fields of the pa= ssed array of > +&v4l2-plane; have to be used instead. When VIDIOC_QBUF is > +called with a pointer to this structure the driver sets the > +V4L2_BUF_FLAG_QUEUED flag and clears the > +V4L2_BUF_FLAG_MAPPED and > +V4L2_BUF_FLAG_DONE flags in the > +flags field, or it returns an error code. This > +ioctl locks the buffer. Buffers remain locked until dequeued, until the > +&VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or until the devic= e is > +closed. You need to explain what a 'locked buffer' means. > + > Applications call the VIDIOC_DQBUF > ioctl to dequeue a filled (capturing) or displayed (output) buffer > from the driver's outgoing queue. They just set the > diff --git a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml b/Documenta= tion/DocBook/media/v4l/vidioc-reqbufs.xml > index d7c9505..20f4323 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml > @@ -48,28 +48,30 @@ > > Description > =20 > - This ioctl is used to initiate memory > -mapped or user pointer > -I/O. Memory mapped buffers are located in device memory and must be > -allocated with this ioctl before they can be mapped into the > -application's address space. User buffers are allocated by > -applications themselves, and this ioctl is merely used to switch the > -driver into user pointer I/O mode and to setup some internal structures. > +This ioctl is used to initiate memory mapped<= /link>, > +user pointer or +linkend=3D"dmabuf">DMABUF based I/O. Memory mapped buffers are loc= ated in > +device memory and must be allocated with this ioctl before they can be map= ped > +into the application's address space. User buffers are allocated by > +applications themselves, and this ioctl is merely used to switch the driver > +into user pointer I/O mode and to setup some internal structures. > +Similarly, DMABUF buffers are allocated by applications through a device > +driver, and this ioctl only configures the driver into DMABUF I/O mode wit= hout > +performing any direct allocation. > =20 > - To allocate device buffers applications initialize all > -fields of the v4l2_requestbuffers structure. > -They set the type field to the respective > -stream or buffer type, the count field to > -the desired number of buffers, memory > -must be set to the requested I/O method and the reserved array > -must be zeroed. When the ioctl > -is called with a pointer to this structure the driver will attempt to allo= cate > -the requested number of buffers and it stores the actual number > -allocated in the count field. It can be > -smaller than the number requested, even zero, when the driver runs out > -of free memory. A larger number is also possible when the driver requires > -more buffers to function correctly. For example video output requires at l= east two buffers, > -one displayed and one filled by the application. > + To allocate device buffers applications initialize all fields of= the > +v4l2_requestbuffers structure. They set the > +type field to the respective stream or buffer t= ype, > +the count field to the desired number of buffer= s, > +memory must be set to the requested I/O method = and > +the reserved array must be zeroed. When the ioc= tl is > +called with a pointer to this structure the driver will attempt to allocat= e the > +requested number of buffers and it stores the actual number allocated in t= he > +count field. It can be smaller than the number > +requested, even zero, when the driver runs out of free memory. A larger nu= mber > +is also possible when the driver requires more buffers to function correct= ly. > +For example video output requires at least two buffers, one displayed and = one > +filled by the application. > When the I/O method is not supported the ioctl > returns an &EINVAL;. > =20 > @@ -102,7 +104,8 @@ as the &v4l2-format; type fi= eld. See __u32 > memory > Applications set this field to > -V4L2_MEMORY_MMAP or > +V4L2_MEMORY_MMAP, > +V4L2_MEMORY_DMABUF or > V4L2_MEMORY_USERPTR. See />. > >=20 You also have to update the VIDIOC_CREATE_BUFS ioctl documentation! I think the VIDIOC_PREPARE_BUF ioctl documentation is OK, but you might want = to check that yourself, just in case. Regards, Hans --===============8235234365777843425==--