diff options
author | Mauro Carvalho Chehab <mchehab@redhat.com> | 2011-05-31 21:27:44 +0200 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2011-07-27 22:52:05 +0200 |
commit | 4266129964b8238526936d723de65b419d8069c6 (patch) | |
tree | 38c6b5cd3dc99b8599391ffad3b87e399bef56a2 /Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | |
parent | [media] DocBook: Add rules to auto-generate some media docbook (diff) | |
download | linux-4266129964b8238526936d723de65b419d8069c6.tar.xz linux-4266129964b8238526936d723de65b419d8069c6.zip |
[media] DocBook: Move all media docbook stuff into its own directory
This patch addresses several issues pointed by Randy Dunlap
<rdunlap@xenotime.net> at changeset ece722c:
- In the generated index.html file, "media" is listed first, but it
should be listed in alphabetical order, not first.
- The generated files are (hidden) in .tmpmedia/
- The link from the top-level index.html file to "media" is to
media/index.html, but the file is actually in .tmpmedia/media/index.html
- Please build docs with and without using "O=builddir" and test that.
- Would it be possible for media to have its own Makefile instead of
merging into this one?
Due to the way cleandocs target works, I had to rename the media DocBook
to media_api, otherwise cleandocs would remove the /media directory.
Thanks-to: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/DocBook/media/v4l/vidioc-reqbufs.xml')
-rw-r--r-- | Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 150 |
1 files changed, 150 insertions, 0 deletions
diff --git a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml new file mode 100644 index 000000000000..69800ae23348 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml @@ -0,0 +1,150 @@ +<refentry id="vidioc-reqbufs"> + <refmeta> + <refentrytitle>ioctl VIDIOC_REQBUFS</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_REQBUFS</refname> + <refpurpose>Initiate Memory Mapping or User Pointer I/O</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>struct v4l2_requestbuffers *<parameter>argp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Arguments</title> + + <variablelist> + <varlistentry> + <term><parameter>fd</parameter></term> + <listitem> + <para>&fd;</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>request</parameter></term> + <listitem> + <para>VIDIOC_REQBUFS</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>This ioctl is used to initiate <link linkend="mmap">memory +mapped</link> or <link linkend="userp">user pointer</link> +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.</para> + + <para>To allocate device buffers applications initialize all +fields of the <structname>v4l2_requestbuffers</structname> structure. +They set the <structfield>type</structfield> field to the respective +stream or buffer type, the <structfield>count</structfield> field to +the desired number of buffers, <structfield>memory</structfield> +must be set to the requested I/O method and the <structfield>reserved</structfield> array +must be zeroed. When the ioctl +is called with a pointer to this structure the driver will attempt to allocate +the requested number of buffers and it stores the actual number +allocated in the <structfield>count</structfield> 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 least two buffers, +one displayed and one filled by the application.</para> + <para>When the I/O method is not supported the ioctl +returns an &EINVAL;.</para> + + <para>Applications can call <constant>VIDIOC_REQBUFS</constant> +again to change the number of buffers, however this cannot succeed +when any buffers are still mapped. A <structfield>count</structfield> +value of zero frees all buffers, after aborting or finishing any DMA +in progress, an implicit &VIDIOC-STREAMOFF;. <!-- mhs: I see no +reason why munmap()ping one or even all buffers must imply +streamoff.--></para> + + <table pgwide="1" frame="none" id="v4l2-requestbuffers"> + <title>struct <structname>v4l2_requestbuffers</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>count</structfield></entry> + <entry>The number of buffers requested or granted.</entry> + </row> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of the stream or buffers, this is the same +as the &v4l2-format; <structfield>type</structfield> field. See <xref + linkend="v4l2-buf-type" /> for valid values.</entry> + </row> + <row> + <entry>&v4l2-memory;</entry> + <entry><structfield>memory</structfield></entry> + <entry>Applications set this field to +<constant>V4L2_MEMORY_MMAP</constant> or +<constant>V4L2_MEMORY_USERPTR</constant>.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>A place holder for future extensions and custom +(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and +higher. This array should be zeroed by applications.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The driver supports multiple opens and I/O is already +in progress, or reallocation of buffers was attempted although one or +more are still mapped.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The buffer type (<structfield>type</structfield> field) or the +requested I/O method (<structfield>memory</structfield>) is not +supported.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> |