From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: linux-media@vger.kernel.org
Cc: laurent.pinchart@ideasonboard.com, hverkuil@xs4all.nl,
mchehab@osg.samsung.com,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Subject: [RFC 17/22] DocBook: media: Document the media request API
Date: Fri, 6 May 2016 13:53:26 +0300 [thread overview]
Message-ID: <1462532011-15527-18-git-send-email-sakari.ailus@linux.intel.com> (raw)
In-Reply-To: <1462532011-15527-1-git-send-email-sakari.ailus@linux.intel.com>
From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The media request API is made of a new ioctl to implement request
management. Document it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Strip off the reserved fields.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
.../DocBook/media/v4l/media-controller.xml | 1 +
.../DocBook/media/v4l/media-ioc-request-cmd.xml | 188 +++++++++++++++++++++
2 files changed, 189 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
diff --git a/Documentation/DocBook/media/v4l/media-controller.xml b/Documentation/DocBook/media/v4l/media-controller.xml
index 5f2fc07..2a5a5d0 100644
--- a/Documentation/DocBook/media/v4l/media-controller.xml
+++ b/Documentation/DocBook/media/v4l/media-controller.xml
@@ -101,5 +101,6 @@
&sub-media-ioc-g-topology;
&sub-media-ioc-enum-entities;
&sub-media-ioc-enum-links;
+ &sub-media-ioc-request-cmd;
&sub-media-ioc-setup-link;
</appendix>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml b/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
new file mode 100644
index 0000000..4f4acea
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/media-ioc-request-cmd.xml
@@ -0,0 +1,188 @@
+<refentry id="media-ioc-request-cmd">
+ <refmeta>
+ <refentrytitle>ioctl MEDIA_IOC_REQUEST_CMD</refentrytitle>
+ &manvol;
+ </refmeta>
+
+ <refnamediv>
+ <refname>MEDIA_IOC_REQUEST_CMD</refname>
+ <refpurpose>Manage media device requests</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 media_request_cmd *<parameter>argp</parameter></paramdef>
+ </funcprototype>
+ </funcsynopsis>
+ </refsynopsisdiv>
+
+ <refsect1>
+ <title>Arguments</title>
+
+ <variablelist>
+ <varlistentry>
+ <term><parameter>fd</parameter></term>
+ <listitem>
+ <para>File descriptor returned by
+ <link linkend='media-func-open'><function>open()</function></link>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><parameter>request</parameter></term>
+ <listitem>
+ <para>MEDIA_IOC_REQUEST_CMD</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><parameter>argp</parameter></term>
+ <listitem>
+ <para></para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Description</title>
+
+ <para>The MEDIA_IOC_REQUEST_CMD ioctl allow applications to manage media
+ device requests. A request is an object that can group media device
+ configuration parameters, including subsystem-specific parameters, in order
+ to apply all the parameters atomically. Applications are responsible for
+ allocating and deleting requests, filling them with configuration parameters
+ and (synchronously) applying or (asynchronously) queuing them.</para>
+
+ <para>Request operations are performed by calling the MEDIA_IOC_REQUEST_CMD
+ ioctl with a pointer to a &media-request-cmd; with the
+ <structfield>cmd</structfield> set to the appropriate command.
+ <xref linkend="media-request-commands" /> lists the commands supported by
+ the ioctl.</para>
+
+ <para>The &media-request-cmd; <structfield>request</structfield> field
+ contains the ID of the request on which the command operates. For the
+ <constant>MEDIA_REQ_CMD_ALLOC</constant> command the field is set to zero
+ by applications and filled by the driver. For all other commands the field
+ is set by applications and left untouched by the driver.</para>
+
+ <para>To allocate a new request applications use the
+ <constant>MEDIA_REQ_CMD_ALLOC</constant>. The driver will allocate a new
+ request and return its ID in the <structfield>request</structfield> field.
+ </para>
+
+ <para>Requests are reference-counted. A newly allocate request is referenced
+ by the media device file handled on which it has been created, and can be
+ later referenced by subsystem-specific operations using the request ID.
+ Requests will thus be automatically deleted when they're not longer used
+ after the media device file handle is closed.</para>
+
+ <para>If a request isn't needed applications can delete it using the
+ <constant>MEDIA_REQ_CMD_DELETE</constant> command. The driver will drop the
+ reference to the request stored in the media device file handle. The request
+ will not be usable through the MEDIA_IOC_REQUEST_CMD ioctl anymore, but will
+ only be deleted when the last reference is released. If no other reference
+ exists when the delete command is invoked the request will be deleted
+ immediately.</para>
+
+ <para>After creating a request applications should fill it with
+ configuration parameters. This is performed through subsystem-specific
+ request APIs outside the scope of the media controller API. See the
+ appropriate subsystem APIs for more information, including how they interact
+ with the MEDIA_IOC_REQUEST_CMD ioctl.</para>
+
+ <para>Once a request contains all the desired configuration parameters it
+ can be applied synchronously or queued asynchronously. To apply a request
+ applications use the <constant>MEDIA_REQ_CMD_APPLY</constant> command. The
+ driver will apply all configuration parameters stored in the request to the
+ device atomically. The ioctl will return once all parameters have been
+ applied, but it should be noted that they might not have fully taken effect
+ yet.</para>
+
+ <para>To queue a request applications use the
+ <constant>MEDIA_REQ_CMD_QUEUE</constant> command. The driver will queue the
+ request for processing and return immediately. The request will then be
+ processed and applied after all previously queued requests.</para>
+
+ <para>Once a request has been queued applications are not allowed to modify
+ its configuration parameters until the request has been fully processed.
+ Any attempt to do so will result in the related subsystem API returning
+ an error. The media device request API doesn't notify applications of
+ request processing completion, this is left to the other subsystems APIs to
+ implement.</para>
+
+ <table pgwide="1" frame="none" id="media-request-cmd">
+ <title>struct <structname>media_request_cmd</structname></title>
+ <tgroup cols="3">
+ &cs-str;
+ <tbody valign="top">
+ <row>
+ <entry>__u32</entry>
+ <entry><structfield>cmd</structfield></entry>
+ <entry>Command, set by the application. See
+ <xref linkend="media-request-commands" /> for the list of supported
+ commands.</entry>
+ </row>
+ <row>
+ <entry>__u32</entry>
+ <entry><structfield>request</structfield></entry>
+ <entry>Request ID, set by the driver for the
+ <constant>MEDIA_REQ_CMD_ALLOC</constant> and by the application
+ for all other commands.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table frame="none" pgwide="1" id="media-request-commands">
+ <title>Media request commands</title>
+ <tgroup cols="2">
+ <colspec colname="c1"/>
+ <colspec colname="c2"/>
+ <tbody valign="top">
+ <row>
+ <entry><constant>MEDIA_REQ_CMD_ALLOC</constant></entry>
+ <entry>Allocate a new request.</entry>
+ </row>
+ <row>
+ <entry><constant>MEDIA_REQ_CMD_DELETE</constant></entry>
+ <entry>Delete a request.</entry>
+ </row>
+ <row>
+ <entry><constant>MEDIA_REQ_CMD_APPLY</constant></entry>
+ <entry>Apply all settings from a request.</entry>
+ </row>
+ <row>
+ <entry><constant>MEDIA_REQ_CMD_QUEUE</constant></entry>
+ <entry>Queue a request for processing.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </refsect1>
+
+ <refsect1>
+ &return-value;
+
+ <variablelist>
+ <varlistentry>
+ <term><errorcode>EINVAL</errorcode></term>
+ <listitem>
+ <para>The &media-request-cmd; specifies an invalid command or
+ references a non-existing request.
+ </para>
+ </listitem>
+ <term><errorcode>ENOSYS</errorcode></term>
+ <listitem>
+ <para>The &media-request-cmd; specifies the
+ <constant>MEDIA_REQ_CMD_QUEUE</constant> or
+ <constant>MEDIA_REQ_CMD_APPLY</constant> and that command isn't
+ implemented by the device.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+</refentry>
--
1.9.1
next prev parent reply other threads:[~2016-05-06 10:56 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 10:53 [RFC 00/22] Media request API Sakari Ailus
2016-05-06 10:53 ` [RFC 01/22] media: Add " Sakari Ailus
2016-05-06 10:53 ` [RFC 02/22] media: Add media device request state Sakari Ailus
2016-05-06 10:53 ` [RFC 03/22] media: Prevent queueing queued requests Sakari Ailus
2016-05-06 10:53 ` [RFC 04/22] media: Only requests in IDLE state may be deleted Sakari Ailus
2016-05-06 10:53 ` [RFC 05/22] media: Add media_device_request_complete() to mark requests complete Sakari Ailus
2016-05-06 10:53 ` [RFC 06/22] media: Add per-entity request data support Sakari Ailus
2016-05-06 10:53 ` [RFC 07/22] videodev2.h: Add request field to v4l2_buffer Sakari Ailus
2016-05-06 10:53 ` [RFC 08/22] videodev2.h: Add request field to v4l2_pix_format_mplane Sakari Ailus
2016-05-06 16:33 ` Nicolas Dufresne
2016-05-06 21:48 ` Sakari Ailus
2016-05-06 10:53 ` [RFC 09/22] v4l2-subdev.h: Add request field to format and selection structures Sakari Ailus
2016-05-06 10:53 ` [RFC 10/22] v4l: Support the request API in format operations Sakari Ailus
2016-05-06 10:53 ` [RFC 11/22] v4l: subdev: Support the request API in format and selection operations Sakari Ailus
2016-05-06 10:53 ` [RFC 12/22] vb2: Add allow_requests flag Sakari Ailus
2016-05-06 10:53 ` [RFC 13/22] vb2: Add helper function to check for request buffers Sakari Ailus
2016-05-06 10:53 ` [RFC 14/22] media: Add MEDIA_IOC_DQEVENT Sakari Ailus
2016-05-06 10:53 ` [RFC 15/22] media: Make events on request completion optional, disabled by default Sakari Ailus
2016-05-06 11:05 ` Sakari Ailus
2016-05-06 10:53 ` [RFC 16/22] media: Add poll support Sakari Ailus
2016-05-06 10:53 ` Sakari Ailus [this message]
2016-05-06 10:53 ` [RFC 18/22] DocBook: media: Document the V4L2 request API Sakari Ailus
2016-05-06 10:53 ` [RFC 19/22] DocBook: media: Document the subdev selection API Sakari Ailus
2016-05-06 10:53 ` [RFC 20/22] DocBook: media: Document the V4L2 subdev request API Sakari Ailus
2016-05-06 10:53 ` [RFC 21/22] DocBook: media: Document media events (MEDIA_IOC_DQEVENT IOCTL) Sakari Ailus
2016-05-06 10:53 ` [RFC 22/22] DocBook: media: Document request flags Sakari Ailus
2016-05-06 15:25 ` [RFC 00/22] Media request API Sakari Ailus
2016-05-17 8:05 ` Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1462532011-15527-18-git-send-email-sakari.ailus@linux.intel.com \
--to=sakari.ailus@linux.intel.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox