About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / DocBook / media / v4l / media-controller.xml

Custom Search

Based on kernel version 4.7.2. Page generated on 2016-08-22 22:45 EST.

1	<partinfo>
2	  <authorgroup>
3	    <author>
4	      <firstname>Laurent</firstname>
5	      <surname>Pinchart</surname>
6	      <affiliation><address><email>laurent.pinchart@ideasonboard.com</email></address></affiliation>
7	      <contrib>Initial version.</contrib>
8	    </author>
9	  </authorgroup>
10	  <copyright>
11	    <year>2010</year>
12	    <holder>Laurent Pinchart</holder>
13	  </copyright>
15	  <revhistory>
16	    <!-- Put document revisions here, newest first. -->
17	    <revision>
18	      <revnumber>1.0.0</revnumber>
19	      <date>2010-11-10</date>
20	      <authorinitials>lp</authorinitials>
21	      <revremark>Initial revision</revremark>
22	    </revision>
23	  </revhistory>
24	</partinfo>
26	<title>Media Controller API</title>
28	<chapter id="media_controller">
29	  <title>Media Controller</title>
31	  <section id="media-controller-intro">
32	    <title>Introduction</title>
33	    <para>Media devices increasingly handle multiple related functions. Many USB
34	    cameras include microphones, video capture hardware can also output video,
35	    or SoC camera interfaces also perform memory-to-memory operations similar to
36	    video codecs.</para>
37	    <para>Independent functions, even when implemented in the same hardware, can
38	    be modelled as separate devices. A USB camera with a microphone will be
39	    presented to userspace applications as V4L2 and ALSA capture devices. The
40	    devices' relationships (when using a webcam, end-users shouldn't have to
41	    manually select the associated USB microphone), while not made available
42	    directly to applications by the drivers, can usually be retrieved from
43	    sysfs.</para>
44	    <para>With more and more advanced SoC devices being introduced, the current
45	    approach will not scale. Device topologies are getting increasingly complex
46	    and can't always be represented by a tree structure. Hardware blocks are
47	    shared between different functions, creating dependencies between seemingly
48	    unrelated devices.</para>
49	    <para>Kernel abstraction APIs such as V4L2 and ALSA provide means for
50	    applications to access hardware parameters. As newer hardware expose an
51	    increasingly high number of those parameters, drivers need to guess what
52	    applications really require based on limited information, thereby
53	    implementing policies that belong to userspace.</para>
54	    <para>The media controller API aims at solving those problems.</para>
55	  </section>
57	  <section id="media-controller-model">
58	    <title>Media device model</title>
59	    <para>Discovering a device internal topology, and configuring it at runtime,
60	    is one of the goals of the media controller API. To achieve this, hardware
61	    devices and Linux Kernel interfaces are modelled as graph objects on
62	    an oriented graph. The object types that constitute the graph are:</para>
63	    <itemizedlist>
64	    <listitem><para>An <emphasis role="bold">entity</emphasis>
65	    is a basic media hardware or software building block. It can correspond to
66	    a large variety of logical blocks such as physical hardware devices
67	    (CMOS sensor for instance), logical hardware devices (a building block in
68	    a System-on-Chip image processing pipeline), DMA channels or physical
69	    connectors.</para></listitem>
70	    <listitem><para>An <emphasis role="bold">interface</emphasis>
71	    is a graph representation of a Linux Kernel userspace API interface,
72	    like a device node or a sysfs file that controls one or more entities
73	    in the graph.</para></listitem>
74	    <listitem><para>A <emphasis role="bold">pad</emphasis>
75	    is a data connection endpoint through which an entity can interact with
76	    other entities. Data (not restricted to video) produced by an entity
77	    flows from the entity's output to one or more entity inputs. Pads should
78	    not be confused with physical pins at chip boundaries.</para></listitem>
79	    <listitem><para>A <emphasis role="bold">data link</emphasis>
80	    is a point-to-point oriented connection between two pads, either on the
81	    same entity or on different entities. Data flows from a source pad to a
82	    sink pad.</para></listitem>
83	    <listitem><para>An <emphasis role="bold">interface link</emphasis>
84	    is a point-to-point bidirectional control connection between a Linux
85	    Kernel interface and an entity.m</para></listitem>
86	    </itemizedlist>
87	  </section>
89	  <!-- All non-ioctl specific data types go here. -->
90	  &sub-media-types;
91	</chapter>
93	<appendix id="media-user-func">
94	  <title>Function Reference</title>
95	  <!-- Keep this alphabetically sorted. -->
96	  &sub-media-func-open;
97	  &sub-media-func-close;
98	  &sub-media-func-ioctl;
99	  <!-- All ioctls go here. -->
100	  &sub-media-ioc-device-info;
101	  &sub-media-ioc-g-topology;
102	  &sub-media-ioc-enum-entities;
103	  &sub-media-ioc-enum-links;
104	  &sub-media-ioc-setup-link;
105	</appendix>
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.