mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-30 19:51:31 -04:00
Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
"This series contain:
- new i2c video drivers: ml86v7667 (video decoder),
ths8200 (video encoder)
- a new video driver for EasyCap cards based on Fushicai USBTV007
- Improved support for OF and embedded systems, with V4L2 async
initialization and a better support for clocks
- API cleanups on the ioctls used by the v4l2 debug tool
- Lots of cleanups
- As usual, several driver improvements and new cards additions
- Revert two changesets that change the minimal symbol rate for
stv0399, as request by Manu
- Update MAINTAINERS and other files to point to my new e-mail"
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (378 commits)
MAINTAINERS & ABI: Update to point to my new email
[media] stb0899: restore minimal rate to 5Mbauds
[media] exynos4-is: Correct colorspace handling at FIMC-LITE
[media] exynos4-is: Set valid initial format on FIMC.n subdevs
[media] exynos4-is: Set valid initial format on FIMC-IS-ISP subdev pads
[media] exynos4-is: Fix format propagation on FIMC-IS-ISP subdev
[media] exynos4-is: Set valid initial format at FIMC-LITE
[media] exynos4-is: Fix format propagation on FIMC-LITE.n subdevs
[media] MAINTAINERS: Update S5P/Exynos FIMC driver entry
[media] Documentation: Update driver's directory in video4linux/fimc.txt
[media] exynos4-is: Change fimc-is firmware file names
[media] exynos4-is: Add support for Exynos5250 MIPI-CSIS
[media] exynos4-is: Add Exynos5250 SoC support to fimc-lite driver
[media] exynos4-is: Drop drvdata handling in fimc-lite for non-dt platforms
[media] media: i2c: tvp514x: remove manual setting of subdev name
[media] media: i2c: tvp7002: remove manual setting of subdev name
[media] mem2mem: set missing v4l2_dev pointer
[media] wl128x: add missing struct v4l2_device
[media] tvp514x: Fix init seqeunce
[media] saa7134: Fix sparse warnings by adding __user annotation
...
This commit is contained in:
commit
858655116b
359 changed files with 10887 additions and 9847 deletions
|
|
@ -77,7 +77,7 @@ Description: Read/Write attribute file that controls memory scrubbing.
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/max_location
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
[email protected]
|
||||
Description: This attribute file displays the information about the last
|
||||
available memory slot in this memory controller. It is used by
|
||||
|
|
@ -85,7 +85,7 @@ Description: This attribute file displays the information about the last
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
[email protected]
|
||||
Description: This attribute file will display the size of dimm or rank.
|
||||
For dimm*/size, this is the size, in MB of the DIMM memory
|
||||
|
|
@ -96,14 +96,14 @@ Description: This attribute file will display the size of dimm or rank.
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
[email protected]
|
||||
Description: This attribute file will display what type of DRAM device is
|
||||
being utilized on this DIMM (x1, x2, x4, x8, ...).
|
||||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
[email protected]
|
||||
Description: This attribute file will display what type of Error detection
|
||||
and correction is being utilized. For example: S4ECD4ED would
|
||||
|
|
@ -111,7 +111,7 @@ Description: This attribute file will display what type of Error detection
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
[email protected]
|
||||
Description: This control file allows this DIMM to have a label assigned
|
||||
to it. With this label in the module, when errors occur
|
||||
|
|
@ -126,14 +126,14 @@ Description: This control file allows this DIMM to have a label assigned
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
[email protected]
|
||||
Description: This attribute file will display the location (csrow/channel,
|
||||
branch/channel/slot or channel/slot) of the dimm or rank.
|
||||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
[email protected]
|
||||
Description: This attribute file will display what type of memory is
|
||||
currently on this csrow. Normally, either buffered or
|
||||
|
|
|
|||
|
|
@ -2254,7 +2254,7 @@ video encoding.</para>
|
|||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The <constant>VIDIOC_G_CHIP_IDENT</constant> ioctl was renamed
|
||||
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and &VIDIOC-DBG-G-CHIP-IDENT;
|
||||
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and <constant>VIDIOC_DBG_G_CHIP_IDENT</constant>
|
||||
was introduced in its place. The old struct <structname>v4l2_chip_ident</structname>
|
||||
was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structname>.</para>
|
||||
</listitem>
|
||||
|
|
@ -2513,6 +2513,16 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.11</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Remove obsolete <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> ioctl.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
|
@ -2596,7 +2606,7 @@ and may change in the future.</para>
|
|||
ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
|
||||
<para>&VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
|
||||
|
|
|
|||
|
|
@ -140,6 +140,14 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
(compat.xml), along with the possible impact on existing drivers and
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.11</revnumber>
|
||||
<date>2013-05-26</date>
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Remove obsolete VIDIOC_DBG_G_CHIP_IDENT ioctl.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.10</revnumber>
|
||||
<date>2013-03-25</date>
|
||||
|
|
@ -493,7 +501,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.10</subtitle>
|
||||
<subtitle>Revision 3.11</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
@ -547,7 +555,6 @@ and discussions on the V4L mailing list.</revremark>
|
|||
<!-- All ioctls go here. -->
|
||||
&sub-create-bufs;
|
||||
&sub-cropcap;
|
||||
&sub-dbg-g-chip-ident;
|
||||
&sub-dbg-g-chip-info;
|
||||
&sub-dbg-g-register;
|
||||
&sub-decoder-cmd;
|
||||
|
|
|
|||
|
|
@ -1,271 +0,0 @@
|
|||
<refentry id="vidioc-dbg-g-chip-ident">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_DBG_G_CHIP_IDENT</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_DBG_G_CHIP_IDENT</refname>
|
||||
<refpurpose>Identify the chips on a TV card</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_dbg_chip_ident
|
||||
*<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_DBG_G_CHIP_IDENT</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link
|
||||
linkend="experimental">experimental</link> interface and may change in
|
||||
the future.</para>
|
||||
</note>
|
||||
|
||||
<para>For driver debugging purposes this ioctl allows test
|
||||
applications to query the driver about the chips present on the TV
|
||||
card. Regular applications must not use it. When you found a chip
|
||||
specific bug, please contact the linux-media mailing list (&v4l-ml;)
|
||||
so it can be fixed.</para>
|
||||
|
||||
<para>To query the driver applications must initialize the
|
||||
<structfield>match.type</structfield> and
|
||||
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
|
||||
fields of a &v4l2-dbg-chip-ident;
|
||||
and call <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> with a pointer to
|
||||
this structure. On success the driver stores information about the
|
||||
selected chip in the <structfield>ident</structfield> and
|
||||
<structfield>revision</structfield> fields. On failure the structure
|
||||
remains unchanged.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_HOST</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth non-&i2c; chip
|
||||
on the TV card. You can enumerate all chips by starting at zero and
|
||||
incrementing <structfield>match.addr</structfield> by one until
|
||||
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.
|
||||
The number zero always selects the host chip, ⪚ the chip connected
|
||||
to the PCI or USB bus.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
|
||||
<structfield>match.name</structfield> contains the I2C driver name.
|
||||
For instance
|
||||
<constant>"saa7127"</constant> will match any chip
|
||||
supported by the saa7127 driver, regardless of its &i2c; bus address.
|
||||
When multiple chips supported by the same driver are present, the
|
||||
ioctl will return <constant>V4L2_IDENT_AMBIGUOUS</constant> in the
|
||||
<structfield>ident</structfield> field.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
|
||||
<structfield>match.addr</structfield> selects a chip by its 7 bit
|
||||
&i2c; bus address.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_AC97</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth AC97 chip
|
||||
on the TV card. You can enumerate all chips by starting at zero and
|
||||
incrementing <structfield>match.addr</structfield> by one until
|
||||
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.</para>
|
||||
|
||||
<para>On success, the <structfield>ident</structfield> field will
|
||||
contain a chip ID from the Linux
|
||||
<filename>media/v4l2-chip-ident.h</filename> header file, and the
|
||||
<structfield>revision</structfield> field will contain a driver
|
||||
specific value, or zero if no particular revision is associated with
|
||||
this chip.</para>
|
||||
|
||||
<para>When the driver could not identify the selected chip,
|
||||
<structfield>ident</structfield> will contain
|
||||
<constant>V4L2_IDENT_UNKNOWN</constant>. When no chip matched
|
||||
the ioctl will succeed but the
|
||||
<structfield>ident</structfield> field will contain
|
||||
<constant>V4L2_IDENT_NONE</constant>. If multiple chips matched,
|
||||
<structfield>ident</structfield> will contain
|
||||
<constant>V4L2_IDENT_AMBIGUOUS</constant>. In all these cases the
|
||||
<structfield>revision</structfield> field remains unchanged.</para>
|
||||
|
||||
<para>This ioctl is optional, not all drivers may support it. It
|
||||
was introduced in Linux 2.6.21, but the API was changed to the
|
||||
one described here in 2.6.29.</para>
|
||||
|
||||
<para>We recommended the <application>v4l2-dbg</application>
|
||||
utility over calling this ioctl directly. It is available from the
|
||||
LinuxTV v4l-dvb repository; see <ulink
|
||||
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
|
||||
access instructions.</para>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-register.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="ident-v4l2-dbg-match">
|
||||
<title>struct <structname>v4l2_dbg_match</structname></title>
|
||||
<tgroup cols="4">
|
||||
&cs-ustr;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
|
||||
possible types.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
<entry>(anonymous)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>addr</structfield></entry>
|
||||
<entry>Match a chip by this number, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>char</entry>
|
||||
<entry><structfield>name[32]</structfield></entry>
|
||||
<entry>Match a chip by this name, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-dbg-chip-ident">
|
||||
<title>struct <structname>v4l2_dbg_chip_ident</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>struct v4l2_dbg_match</entry>
|
||||
<entry><structfield>match</structfield></entry>
|
||||
<entry>How to match the chip, see <xref linkend="ident-v4l2-dbg-match" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>ident</structfield></entry>
|
||||
<entry>A chip identifier as defined in the Linux
|
||||
<filename>media/v4l2-chip-ident.h</filename> header file, or one of
|
||||
the values from <xref linkend="chip-ids" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>revision</structfield></entry>
|
||||
<entry>A chip revision, chip and driver specific.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-register.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="ident-chip-match-types">
|
||||
<title>Chip Match Types</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>Match the nth chip on the card, zero for the
|
||||
bridge chip. Does not match sub-devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Match an &i2c; chip by its driver name.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry>Match the nth anciliary AC97 chip.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
|
||||
<entry>4</entry>
|
||||
<entry>Match the nth sub-device. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<!-- This is an anonymous enum in media/v4l2-chip-ident.h. -->
|
||||
<table pgwide="1" frame="none" id="chip-ids">
|
||||
<title>Chip Identifiers</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_IDENT_NONE</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>No chip matched.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_IDENT_AMBIGUOUS</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Multiple chips matched.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_IDENT_UNKNOWN</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>A chip is present at this address, but the driver
|
||||
could not identify it.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The <structfield>match_type</structfield> is invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -73,8 +73,7 @@ fields of a &v4l2-dbg-chip-info;
|
|||
and call <constant>VIDIOC_DBG_G_CHIP_INFO</constant> with a pointer to
|
||||
this structure. On success the driver stores information about the
|
||||
selected chip in the <structfield>name</structfield> and
|
||||
<structfield>flags</structfield> fields. On failure the structure
|
||||
remains unchanged.</para>
|
||||
<structfield>flags</structfield> fields.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
|
||||
|
|
@ -132,7 +131,7 @@ to the <structfield>type</structfield> field.</entry>
|
|||
<entry>char</entry>
|
||||
<entry><structfield>name[32]</structfield></entry>
|
||||
<entry>Match a chip by this name, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
to the <structfield>type</structfield> field. Currently unused.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -182,21 +181,6 @@ is set, then the driver supports reading registers from the device. If
|
|||
<entry>Match the nth chip on the card, zero for the
|
||||
bridge chip. Does not match sub-devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Match an &i2c; chip by its driver name. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Match a chip by its 7 bit &i2c; bus address. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry>Match the nth anciliary AC97 chip. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
|
||||
<entry>4</entry>
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ compiled with the <constant>CONFIG_VIDEO_ADV_DEBUG</constant> option
|
|||
to enable these ioctls.</para>
|
||||
|
||||
<para>To write a register applications must initialize all fields
|
||||
of a &v4l2-dbg-register; and call
|
||||
of a &v4l2-dbg-register; except for <structfield>size</structfield> and call
|
||||
<constant>VIDIOC_DBG_S_REGISTER</constant> with a pointer to this
|
||||
structure. The <structfield>match.type</structfield> and
|
||||
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
|
||||
|
|
@ -91,8 +91,8 @@ written into the register.</para>
|
|||
<structfield>reg</structfield> fields, and call
|
||||
<constant>VIDIOC_DBG_G_REGISTER</constant> with a pointer to this
|
||||
structure. On success the driver stores the register value in the
|
||||
<structfield>val</structfield> field. On failure the structure remains
|
||||
unchanged.</para>
|
||||
<structfield>val</structfield> field and the size (in bytes) of the
|
||||
value in <structfield>size</structfield>.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
|
||||
|
|
@ -101,40 +101,10 @@ on the TV card. The number zero always selects the host chip, ⪚ the
|
|||
chip connected to the PCI or USB bus. You can find out which chips are
|
||||
present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
|
||||
<structfield>match.name</structfield> contains the I2C driver name.
|
||||
For instance
|
||||
<constant>"saa7127"</constant> will match any chip
|
||||
supported by the saa7127 driver, regardless of its &i2c; bus address.
|
||||
When multiple chips supported by the same driver are present, the
|
||||
effect of these ioctls is undefined. Again with the
|
||||
&VIDIOC-DBG-G-CHIP-INFO; ioctl you can find out which &i2c; chips are
|
||||
present.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
|
||||
<structfield>match.addr</structfield> selects a chip by its 7 bit &i2c;
|
||||
bus address.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_AC97</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth AC97 chip
|
||||
on the TV card.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth sub-device.</para>
|
||||
|
||||
<note>
|
||||
<title>Success not guaranteed</title>
|
||||
|
||||
<para>Due to a flaw in the Linux &i2c; bus driver these ioctls may
|
||||
return successfully without actually reading or writing a register. To
|
||||
catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-INFO;
|
||||
call confirming the presence of the selected &i2c; chip.</para>
|
||||
</note>
|
||||
|
||||
<para>These ioctls are optional, not all drivers may support them.
|
||||
However when a driver supports these ioctls it must also support
|
||||
&VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support
|
||||
|
|
@ -150,7 +120,7 @@ LinuxTV v4l-dvb repository; see <ulink
|
|||
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
|
||||
access instructions.</para>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="v4l2-dbg-match">
|
||||
<title>struct <structname>v4l2_dbg_match</structname></title>
|
||||
|
|
@ -160,7 +130,7 @@ access instructions.</para>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
|
||||
<entry>See <xref linkend="chip-match-types" /> for a list of
|
||||
possible types.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
@ -179,7 +149,7 @@ to the <structfield>type</structfield> field.</entry>
|
|||
<entry>char</entry>
|
||||
<entry><structfield>name[32]</structfield></entry>
|
||||
<entry>Match a chip by this name, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
to the <structfield>type</structfield> field. Currently unused.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -198,6 +168,11 @@ to the <structfield>type</structfield> field.</entry>
|
|||
<entry><structfield>match</structfield></entry>
|
||||
<entry>How to match the chip, see <xref linkend="v4l2-dbg-match" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>size</structfield></entry>
|
||||
<entry>The register size in bytes.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u64</entry>
|
||||
<entry><structfield>reg</structfield></entry>
|
||||
|
|
@ -213,7 +188,7 @@ register.</entry>
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="chip-match-types">
|
||||
<title>Chip Match Types</title>
|
||||
|
|
@ -226,21 +201,6 @@ register.</entry>
|
|||
<entry>Match the nth chip on the card, zero for the
|
||||
bridge chip. Does not match sub-devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Match an &i2c; chip by its driver name.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry>Match the nth anciliary AC97 chip.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
|
||||
<entry>4</entry>
|
||||
|
|
|
|||
|
|
@ -54,7 +54,8 @@ standard automatically. To do so, applications call <constant>
|
|||
VIDIOC_QUERYSTD</constant> with a pointer to a &v4l2-std-id; type. The
|
||||
driver stores here a set of candidates, this can be a single flag or a
|
||||
set of supported standards if for example the hardware can only
|
||||
distinguish between 50 and 60 Hz systems. When detection is not
|
||||
distinguish between 50 and 60 Hz systems. If no signal was detected,
|
||||
then the driver will return V4L2_STD_UNKNOWN. When detection is not
|
||||
possible or fails, the set must contain all standards supported by the
|
||||
current video input or output.</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,8 +2,10 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and
|
||||
Exynos4412 SoCs;
|
||||
- compatible : should be one of:
|
||||
"samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs,
|
||||
"samsung,exynos5250-fimc-lite" for Exynos5250 compatible
|
||||
devices;
|
||||
- reg : physical base address and size of the device memory mapped
|
||||
registers;
|
||||
- interrupts : should contain FIMC-LITE interrupt;
|
||||
|
|
|
|||
40
Documentation/devicetree/bindings/media/i2c/mt9p031.txt
Normal file
40
Documentation/devicetree/bindings/media/i2c/mt9p031.txt
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
|
||||
|
||||
The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with
|
||||
an active array size of 2592H x 1944V. It is programmable through a simple
|
||||
two-wire serial interface.
|
||||
|
||||
Required Properties:
|
||||
- compatible: value should be either one among the following
|
||||
(a) "aptina,mt9p031" for mt9p031 sensor
|
||||
(b) "aptina,mt9p031m" for mt9p031m sensor
|
||||
|
||||
- input-clock-frequency: Input clock frequency.
|
||||
|
||||
- pixel-clock-frequency: Pixel clock frequency.
|
||||
|
||||
Optional Properties:
|
||||
- reset-gpios: Chip reset GPIO
|
||||
|
||||
For further reading on port node refer to
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c0@1c22000 {
|
||||
...
|
||||
...
|
||||
mt9p031@5d {
|
||||
compatible = "aptina,mt9p031";
|
||||
reg = <0x5d>;
|
||||
reset-gpios = <&gpio3 30 0>;
|
||||
|
||||
port {
|
||||
mt9p031_1: endpoint {
|
||||
input-clock-frequency = <6000000>;
|
||||
pixel-clock-frequency = <96000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
44
Documentation/devicetree/bindings/media/i2c/tvp514x.txt
Normal file
44
Documentation/devicetree/bindings/media/i2c/tvp514x.txt
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
* Texas Instruments TVP514x video decoder
|
||||
|
||||
The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
|
||||
digital video decoder that digitizes and decodes all popular baseband analog
|
||||
video formats into digital video component. The tvp514x decoder supports analog-
|
||||
to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
|
||||
conversion and decoding of NTSC, PAL and SECAM composite and S-video into
|
||||
component YCbCr.
|
||||
|
||||
Required Properties :
|
||||
- compatible : value should be either one among the following
|
||||
(a) "ti,tvp5146" for tvp5146 decoder.
|
||||
(b) "ti,tvp5146m2" for tvp5146m2 decoder.
|
||||
(c) "ti,tvp5147" for tvp5147 decoder.
|
||||
(d) "ti,tvp5147m1" for tvp5147m1 decoder.
|
||||
|
||||
- hsync-active: HSYNC Polarity configuration for endpoint.
|
||||
|
||||
- vsync-active: VSYNC Polarity configuration for endpoint.
|
||||
|
||||
- pclk-sample: Clock polarity of the endpoint.
|
||||
|
||||
For further reading on port node refer to Documentation/devicetree/bindings/
|
||||
media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c0@1c22000 {
|
||||
...
|
||||
...
|
||||
tvp514x@5c {
|
||||
compatible = "ti,tvp5146";
|
||||
reg = <0x5c>;
|
||||
|
||||
port {
|
||||
tvp514x_1: endpoint {
|
||||
hsync-active = <1>;
|
||||
vsync-active = <1>;
|
||||
pclk-sample = <0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
@ -127,22 +127,22 @@ Example:
|
|||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* MIPI CSI-2 bus IF sensor */
|
||||
s5c73m3: sensor@0x1a {
|
||||
compatible = "samsung,s5c73m3";
|
||||
reg = <0x1a>;
|
||||
vddio-supply = <...>;
|
||||
/* MIPI CSI-2 bus IF sensor */
|
||||
s5c73m3: sensor@0x1a {
|
||||
compatible = "samsung,s5c73m3";
|
||||
reg = <0x1a>;
|
||||
vddio-supply = <...>;
|
||||
|
||||
clock-frequency = <24000000>;
|
||||
clocks = <...>;
|
||||
clock-names = "mclk";
|
||||
clock-frequency = <24000000>;
|
||||
clocks = <...>;
|
||||
clock-names = "mclk";
|
||||
|
||||
port {
|
||||
s5c73m3_1: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
remote-endpoint = <&csis0_ep>;
|
||||
port {
|
||||
s5c73m3_1: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
remote-endpoint = <&csis0_ep>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ Required properties:
|
|||
|
||||
- compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110),
|
||||
"samsung,exynos4210-csis" for Exynos4210 (S5PC210),
|
||||
"samsung,exynos4212-csis" for Exynos4212/Exynos4412
|
||||
SoC series;
|
||||
"samsung,exynos4212-csis" for Exynos4212/Exynos4412,
|
||||
"samsung,exynos5250-csis" for Exynos5250;
|
||||
- reg : offset and length of the register set for the device;
|
||||
- interrupts : should contain MIPI CSIS interrupt; the format of the
|
||||
interrupt specifier depends on the interrupt controller;
|
||||
|
|
|
|||
18
Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
Normal file
18
Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
Bindings, specific for the sh_mobile_ceu_camera.c driver:
|
||||
- compatible: Should be "renesas,sh-mobile-ceu"
|
||||
- reg: register base and size
|
||||
- interrupts: the interrupt number
|
||||
- interrupt-parent: the interrupt controller
|
||||
- renesas,max-width: maximum image width, supported on this SoC
|
||||
- renesas,max-height: maximum image height, supported on this SoC
|
||||
|
||||
Example:
|
||||
|
||||
ceu0: ceu@0xfe910000 {
|
||||
compatible = "renesas,sh-mobile-ceu";
|
||||
reg = <0xfe910000 0xa0>;
|
||||
interrupt-parent = <&intcs>;
|
||||
interrupts = <0x880>;
|
||||
renesas,max-width = <8188>;
|
||||
renesas,max-height = <8188>;
|
||||
};
|
||||
|
|
@ -265,7 +265,7 @@ connected to another pad through an enabled link
|
|||
media_entity_find_link(struct media_pad *source,
|
||||
struct media_pad *sink);
|
||||
|
||||
media_entity_remote_source(struct media_pad *pad);
|
||||
media_entity_remote_pad(struct media_pad *pad);
|
||||
|
||||
Refer to the kerneldoc documentation for more information.
|
||||
|
||||
|
|
|
|||
|
|
@ -160,3 +160,6 @@
|
|||
159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
|
||||
160 -> Tongwei Video Technology TD-3116 [f200:3116]
|
||||
161 -> Aposonic W-DVR [0279:0228]
|
||||
162 -> Adlink MPG24
|
||||
163 -> Bt848 Capture 14MHz
|
||||
164 -> CyberVision CV06 (SV)
|
||||
|
|
|
|||
|
|
@ -190,3 +190,4 @@
|
|||
189 -> Kworld PC150-U [17de:a134]
|
||||
190 -> Asus My Cinema PS3-100 [1043:48cd]
|
||||
191 -> Hawell HW-9004V1
|
||||
192 -> AverMedia AverTV Satellite Hybrid+FM A706 [1461:2055]
|
||||
|
|
|
|||
|
|
@ -86,6 +86,6 @@ tuner=85 - Philips FQ1236 MK5
|
|||
tuner=86 - Tena TNF5337 MFD
|
||||
tuner=87 - Xceive 4000 tuner
|
||||
tuner=88 - Xceive 5000C tuner
|
||||
tuner=89 - Sony PAL+SECAM (BTF-PG472Z)
|
||||
tuner=90 - Sony NTSC-M-JP (BTF-PK467Z)
|
||||
tuner=91 - Sony NTSC-M (BTF-PB463Z)
|
||||
tuner=89 - Sony BTF-PG472Z PAL/SECAM
|
||||
tuner=90 - Sony BTF-PK467Z NTSC-M-JP
|
||||
tuner=91 - Sony BTF-PB463Z NTSC-M
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Samsung S5P/EXYNOS4 FIMC driver
|
||||
|
||||
Copyright (C) 2012 Samsung Electronics Co., Ltd.
|
||||
Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
The FIMC (Fully Interactive Mobile Camera) device available in Samsung
|
||||
|
|
@ -10,7 +10,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data
|
|||
path. There are multiple FIMC instances in the SoCs (up to 4), having
|
||||
slightly different capabilities, like pixel alignment constraints, rotator
|
||||
availability, LCD writeback support, etc. The driver is located at
|
||||
drivers/media/platform/s5p-fimc directory.
|
||||
drivers/media/platform/exynos4-is directory.
|
||||
|
||||
1. Supported SoCs
|
||||
=================
|
||||
|
|
@ -36,21 +36,21 @@ Not currently supported:
|
|||
=====================
|
||||
|
||||
- media device driver
|
||||
drivers/media/platform/s5p-fimc/fimc-mdevice.[ch]
|
||||
drivers/media/platform/exynos4-is/media-dev.[ch]
|
||||
|
||||
- camera capture video device driver
|
||||
drivers/media/platform/s5p-fimc/fimc-capture.c
|
||||
drivers/media/platform/exynos4-is/fimc-capture.c
|
||||
|
||||
- MIPI-CSI2 receiver subdev
|
||||
drivers/media/platform/s5p-fimc/mipi-csis.[ch]
|
||||
drivers/media/platform/exynos4-is/mipi-csis.[ch]
|
||||
|
||||
- video post-processor (mem-to-mem)
|
||||
drivers/media/platform/s5p-fimc/fimc-core.c
|
||||
drivers/media/platform/exynos4-is/fimc-core.c
|
||||
|
||||
- common files
|
||||
drivers/media/platform/s5p-fimc/fimc-core.h
|
||||
drivers/media/platform/s5p-fimc/fimc-reg.h
|
||||
drivers/media/platform/s5p-fimc/regs-fimc.h
|
||||
drivers/media/platform/exynos4-is/fimc-core.h
|
||||
drivers/media/platform/exynos4-is/fimc-reg.h
|
||||
drivers/media/platform/exynos4-is/regs-fimc.h
|
||||
|
||||
4. User space interfaces
|
||||
========================
|
||||
|
|
@ -143,7 +143,8 @@ or retrieve the information from /dev/media? with help of the media-ctl tool:
|
|||
6. Platform support
|
||||
===================
|
||||
|
||||
The machine code (plat-s5p and arch/arm/mach-*) must select following options
|
||||
The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select
|
||||
following options:
|
||||
|
||||
CONFIG_S5P_DEV_FIMC0 mandatory
|
||||
CONFIG_S5P_DEV_FIMC1 \
|
||||
|
|
|
|||
|
|
@ -246,7 +246,6 @@ may be NULL if the subdev driver does not support anything from that category.
|
|||
It looks like this:
|
||||
|
||||
struct v4l2_subdev_core_ops {
|
||||
int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip);
|
||||
int (*log_status)(struct v4l2_subdev *sd);
|
||||
int (*init)(struct v4l2_subdev *sd, u32 val);
|
||||
...
|
||||
|
|
@ -326,8 +325,27 @@ that width, height and the media bus pixel code are equal on both source and
|
|||
sink of the link. Subdev drivers are also free to use this function to
|
||||
perform the checks mentioned above in addition to their own checks.
|
||||
|
||||
A device (bridge) driver needs to register the v4l2_subdev with the
|
||||
v4l2_device:
|
||||
There are currently two ways to register subdevices with the V4L2 core. The
|
||||
first (traditional) possibility is to have subdevices registered by bridge
|
||||
drivers. This can be done when the bridge driver has the complete information
|
||||
about subdevices connected to it and knows exactly when to register them. This
|
||||
is typically the case for internal subdevices, like video data processing units
|
||||
within SoCs or complex PCI(e) boards, camera sensors in USB cameras or connected
|
||||
to SoCs, which pass information about them to bridge drivers, usually in their
|
||||
platform data.
|
||||
|
||||
There are however also situations where subdevices have to be registered
|
||||
asynchronously to bridge devices. An example of such a configuration is a Device
|
||||
Tree based system where information about subdevices is made available to the
|
||||
system independently from the bridge devices, e.g. when subdevices are defined
|
||||
in DT as I2C device nodes. The API used in this second case is described further
|
||||
below.
|
||||
|
||||
Using one or the other registration method only affects the probing process, the
|
||||
run-time bridge-subdevice interaction is in both cases the same.
|
||||
|
||||
In the synchronous case a device (bridge) driver needs to register the
|
||||
v4l2_subdev with the v4l2_device:
|
||||
|
||||
int err = v4l2_device_register_subdev(v4l2_dev, sd);
|
||||
|
||||
|
|
@ -346,24 +364,24 @@ Afterwards the subdev module can be unloaded and sd->dev == NULL.
|
|||
|
||||
You can call an ops function either directly:
|
||||
|
||||
err = sd->ops->core->g_chip_ident(sd, &chip);
|
||||
err = sd->ops->core->g_std(sd, &norm);
|
||||
|
||||
but it is better and easier to use this macro:
|
||||
|
||||
err = v4l2_subdev_call(sd, core, g_chip_ident, &chip);
|
||||
err = v4l2_subdev_call(sd, core, g_std, &norm);
|
||||
|
||||
The macro will to the right NULL pointer checks and returns -ENODEV if subdev
|
||||
is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is
|
||||
NULL, or the actual result of the subdev->ops->core->g_chip_ident ops.
|
||||
is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_std is
|
||||
NULL, or the actual result of the subdev->ops->core->g_std ops.
|
||||
|
||||
It is also possible to call all or a subset of the sub-devices:
|
||||
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
Any subdev that does not support this ops is skipped and error results are
|
||||
ignored. If you want to check for errors use this:
|
||||
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
Any error except -ENOIOCTLCMD will exit the loop with that error. If no
|
||||
errors (except -ENOIOCTLCMD) occurred, then 0 is returned.
|
||||
|
|
@ -394,6 +412,30 @@ controlled through GPIO pins. This distinction is only relevant when setting
|
|||
up the device, but once the subdev is registered it is completely transparent.
|
||||
|
||||
|
||||
In the asynchronous case subdevice probing can be invoked independently of the
|
||||
bridge driver availability. The subdevice driver then has to verify whether all
|
||||
the requirements for a successful probing are satisfied. This can include a
|
||||
check for a master clock availability. If any of the conditions aren't satisfied
|
||||
the driver might decide to return -EPROBE_DEFER to request further reprobing
|
||||
attempts. Once all conditions are met the subdevice shall be registered using
|
||||
the v4l2_async_register_subdev() function. Unregistration is performed using
|
||||
the v4l2_async_unregister_subdev() call. Subdevices registered this way are
|
||||
stored in a global list of subdevices, ready to be picked up by bridge drivers.
|
||||
|
||||
Bridge drivers in turn have to register a notifier object with an array of
|
||||
subdevice descriptors that the bridge device needs for its operation. This is
|
||||
performed using the v4l2_async_notifier_register() call. To unregister the
|
||||
notifier the driver has to call v4l2_async_notifier_unregister(). The former of
|
||||
the two functions takes two arguments: a pointer to struct v4l2_device and a
|
||||
pointer to struct v4l2_async_notifier. The latter contains a pointer to an array
|
||||
of pointers to subdevice descriptors of type struct v4l2_async_subdev type. The
|
||||
V4L2 core will then use these descriptors to match asynchronously registered
|
||||
subdevices to them. If a match is detected the .bound() notifier callback is
|
||||
called. After all subdevices have been located the .complete() callback is
|
||||
called. When a subdevice is removed from the system the .unbind() method is
|
||||
called. All three callbacks are optional.
|
||||
|
||||
|
||||
V4L2 sub-device userspace API
|
||||
-----------------------------
|
||||
|
||||
|
|
@ -575,9 +617,13 @@ of the video device exits.
|
|||
The default video_device_release() callback just calls kfree to free the
|
||||
allocated memory.
|
||||
|
||||
There is also a video_device_release_empty() function that does nothing
|
||||
(is empty) and can be used if the struct is embedded and there is nothing
|
||||
to do when it is released.
|
||||
|
||||
You should also set these fields:
|
||||
|
||||
- v4l2_dev: set to the v4l2_device parent device.
|
||||
- v4l2_dev: must be set to the v4l2_device parent device.
|
||||
|
||||
- name: set to something descriptive and unique.
|
||||
|
||||
|
|
@ -614,15 +660,16 @@ You should also set these fields:
|
|||
If you want to have a separate priority state per (group of) device node(s),
|
||||
then you can point it to your own struct v4l2_prio_state.
|
||||
|
||||
- parent: you only set this if v4l2_device was registered with NULL as
|
||||
- dev_parent: you only set this if v4l2_device was registered with NULL as
|
||||
the parent device struct. This only happens in cases where one hardware
|
||||
device has multiple PCI devices that all share the same v4l2_device core.
|
||||
|
||||
The cx88 driver is an example of this: one core v4l2_device struct, but
|
||||
it is used by both an raw video PCI device (cx8800) and a MPEG PCI device
|
||||
(cx8802). Since the v4l2_device cannot be associated with a particular
|
||||
PCI device it is setup without a parent device. But when the struct
|
||||
video_device is setup you do know which parent PCI device to use.
|
||||
it is used by both a raw video PCI device (cx8800) and a MPEG PCI device
|
||||
(cx8802). Since the v4l2_device cannot be associated with two PCI devices
|
||||
at the same time it is setup without a parent device. But when the struct
|
||||
video_device is initialized you *do* know which parent PCI device to use and
|
||||
so you set dev_device to the correct PCI device.
|
||||
|
||||
- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework
|
||||
handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
|
||||
|
|
@ -1061,3 +1108,29 @@ available event type is 'class base + 1'.
|
|||
|
||||
An example on how the V4L2 events may be used can be found in the OMAP
|
||||
3 ISP driver (drivers/media/platform/omap3isp).
|
||||
|
||||
|
||||
V4L2 clocks
|
||||
-----------
|
||||
|
||||
Many subdevices, like camera sensors, TV decoders and encoders, need a clock
|
||||
signal to be supplied by the system. Often this clock is supplied by the
|
||||
respective bridge device. The Linux kernel provides a Common Clock Framework for
|
||||
this purpose. However, it is not (yet) available on all architectures. Besides,
|
||||
the nature of the multi-functional (clock, data + synchronisation, I2C control)
|
||||
connection of subdevices to the system might impose special requirements on the
|
||||
clock API usage. E.g. V4L2 has to support clock provider driver unregistration
|
||||
while a subdevice driver is holding a reference to the clock. For these reasons
|
||||
a V4L2 clock helper API has been developed and is provided to bridge and
|
||||
subdevice drivers.
|
||||
|
||||
The API consists of two parts: two functions to register and unregister a V4L2
|
||||
clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control
|
||||
a clock object, similar to the respective generic clock API calls:
|
||||
v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(),
|
||||
v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide
|
||||
clock operations that will be called when clock users invoke respective API
|
||||
methods.
|
||||
|
||||
It is expected that once the CCF becomes available on all relevant
|
||||
architectures this API will be removed.
|
||||
|
|
|
|||
|
|
@ -247,7 +247,6 @@ i2c_client 结构体,i2c_set_clientdata() 函数可用于保存一个 v4l2_sub
|
|||
这些结构体定义如下:
|
||||
|
||||
struct v4l2_subdev_core_ops {
|
||||
int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip);
|
||||
int (*log_status)(struct v4l2_subdev *sd);
|
||||
int (*init)(struct v4l2_subdev *sd, u32 val);
|
||||
...
|
||||
|
|
@ -337,24 +336,24 @@ subdev->dev 域就指向了 v4l2_device。
|
|||
|
||||
注册之设备后,可通过以下方式直接调用其操作函数:
|
||||
|
||||
err = sd->ops->core->g_chip_ident(sd, &chip);
|
||||
err = sd->ops->core->g_std(sd, &norm);
|
||||
|
||||
但使用如下宏会比较容易且合适:
|
||||
|
||||
err = v4l2_subdev_call(sd, core, g_chip_ident, &chip);
|
||||
err = v4l2_subdev_call(sd, core, g_std, &norm);
|
||||
|
||||
这个宏将会做 NULL 指针检查,如果 subdev 为 NULL,则返回-ENODEV;如果
|
||||
subdev->core 或 subdev->core->g_chip_ident 为 NULL,则返回 -ENOIOCTLCMD;
|
||||
否则将返回 subdev->ops->core->g_chip_ident ops 调用的实际结果。
|
||||
subdev->core 或 subdev->core->g_std 为 NULL,则返回 -ENOIOCTLCMD;
|
||||
否则将返回 subdev->ops->core->g_std ops 调用的实际结果。
|
||||
|
||||
有时也可能同时调用所有或一系列子设备的某个操作函数:
|
||||
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
任何不支持此操作的子设备都会被跳过,并忽略错误返回值。但如果你需要
|
||||
检查出错码,则可使用如下函数:
|
||||
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
除 -ENOIOCTLCMD 外的任何错误都会跳出循环并返回错误值。如果(除 -ENOIOCTLCMD
|
||||
外)没有错误发生,则返回 0。
|
||||
|
|
|
|||
Loading…
Reference in a new issue