ukui/kernel
0
0
Fork 0
mirror of https://github.com/ukui/kernel.git synced 2026-03-09 10:07:04 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge tag 'media/v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Browse Source 
Pull media updates from Mauro Carvalho Chehab:
 - Added support for some new video formats
 - mn88473 DVB frontend driver got promoted from staging
 - several improvements at the VSP1 driver
 - several cleanups and improvements at the Media Controller
 - added Media Controller support to snd-usb-audio.  Currently, enabled
   only for au0828-based V4L2/DVB boards
 - Several improvements at nuvoton-cir: it now supports wake up codes
 - Add media controller support to em28xx and saa7134 drivers
 - coda driver now accepts NXP distributed firmware files
 - Some legacy SoC camera drivers will be moving to staging, as they're
   outdated and nobody so far is willing to fix and convert them to use
   the current media framework
 - As usual, lots of cleanups, improvements and new board additions.

* tag 'media/v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (381 commits)
  media: au0828 disable tuner to demod link in au0828_media_device_register()
  [media] touptek: cast char types on %x printk
  [media] touptek: don't DMA at the stack
  [media] mceusb: use %*ph for small buffer dumps
  [media] v4l: exynos4-is: Drop unneeded check when setting up fimc-lite links
  [media] v4l: vsp1: Check if an entity is a subdev with the right function
  [media] hide unused functions for !MEDIA_CONTROLLER
  [media] em28xx: fix Terratec Grabby AC97 codec detection
  [media] media: add prefixes to interface types
  [media] media: rc: nuvoton: switch attribute wakeup_data to text
  [media] v4l2-ioctl: fix YUV422P pixel format description
  [media] media: fix null pointer dereference in v4l_vb2q_enable_media_source()
  [media] v4l2-mc.h: fix yet more compiler errors
  [media] staging/media: add missing TODO files
  [media] media.h: always start with 1 for the audio entities
  [media] sound/usb: Use meaninful names for goto labels
  [media] v4l2-mc.h: fix compiler warnings
  [media] media: au0828 audio mixer isn't connected to decoder
  [media] sound/usb: Use Media Controller API to share media resources
  [media] dw2102: add support for TeVii S662
  ...
This commit is contained in:
Linus Torvalds
2016-03-16 18:27:32 -07:00
parent 8759957b77 8331c055b2
commit bace3db5da
398 changed files with 12341 additions and 4943 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
Documentation/ABI/testing/sysfs-class-rc-nuvoton Normal file
View File

@@ -0,0 +1,15 @@
What: /sys/class/rc/rcN/wakeup_data
Date: Mar 2016
KernelVersion: 4.6
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns the stored CIR wakeup sequence.
It starts with a pulse, followed by a space, pulse etc.
All values are in microseconds.
The same format can be used to store a wakeup sequence
in the Nuvoton chip by writing to this file.
Note: Some systems reset the stored wakeup sequence to a
factory default on each boot. On such systems store the
wakeup sequence in a file and set it on boot using e.g.
a udev rule.

1
Documentation/DocBook/device-drivers.tmpl
View File

@@ -229,6 +229,7 @@ X!Isound/sound_firmware.c
!Iinclude/media/v4l2-dv-timings.h
!Iinclude/media/v4l2-event.h
!Iinclude/media/v4l2-flash-led-class.h
!Iinclude/media/v4l2-mc.h
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h

58
Documentation/DocBook/media/v4l/controls.xml
View File

@@ -2329,6 +2329,14 @@ to search and match for the present Macroblock (MB) in the reference picture. Th
vertical search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-force-key-frame">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME</constant>&nbsp;</entry>
<entry>button</entry>
</row><row><entry spanname="descr">Force a key frame for the next queued buffer. Applicable to encoders.
This is a general, codec-agnostic keyframe control.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
@@ -5069,6 +5077,46 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant></entry>
<entry id="v4l2-dv-content-type">enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Configures the IT Content Type
of the transmitted video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. The
enum&nbsp;v4l2_dv_it_content_type defines the possible content types:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GRAPHICS</constant>&nbsp;</entry>
<entry>Graphics content. Pixel data should be passed unfiltered and without
analog reconstruction.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_PHOTO</constant>&nbsp;</entry>
<entry>Photo content. The content is derived from digital still pictures.
The content should be passed through with minimal scaling and picture
enhancements.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_CINEMA</constant>&nbsp;</entry>
<entry>Cinema content.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant>&nbsp;</entry>
<entry>Game content. Audio and video latency should be minimized.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant>&nbsp;</entry>
<entry>No IT Content information is available and the ITC bit in the AVI
InfoFrame is set to 0.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
<entry>bitmask</entry>
@@ -5098,6 +5146,16 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_IT_CONTENT_TYPE</constant></entry>
<entry>enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Reads the IT Content Type
of the received video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. See
<constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant> for the available content types.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>

3
Documentation/DocBook/media/v4l/media-ioc-g-topology.xml
View File

@@ -48,9 +48,6 @@
<refsect1>
<title>Description</title>
<para><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para>
<para>The typical usage of this ioctl is to call it twice.
On the first call, the structure defined at &media-v2-topology; should
be zeroed. At return, if no errors happen, this ioctl will return the

81
Documentation/DocBook/media/v4l/media-types.xml
View File

@@ -80,7 +80,46 @@
</row>
<row>
<entry><constant>MEDIA_ENT_F_TUNER</constant></entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner.</entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner,
with consists on a PLL tuning stage that converts radio
frequency (RF) signal into an Intermediate Frequency (IF).
Modern tuners have internally IF-PLL decoders for audio
and video, but older models have those stages implemented
on separate entities.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_VID_DECODER</constant></entry>
<entry>IF-PLL video decoder. It receives the IF from a PLL
and decodes the analog TV video signal. This is commonly
found on some very old analog tuners, like Philips MK3
designs. They all contain a tda9887 (or some software
compatible similar chip, like tda9885). Those devices
use a different I2C address than the tuner PLL.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_AUD_DECODER</constant></entry>
<entry>IF-PLL sound decoder. It receives the IF from a PLL
and decodes the analog TV audio signal. This is commonly
found on some very old analog hardware, like Micronas
msp3400, Philips tda9840, tda985x, etc. Those devices
use a different I2C address than the tuner PLL and
should be controlled together with the IF-PLL video
decoder.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_CAPTURE</constant></entry>
<entry>Audio Capture Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_PLAYBACK</constant></entry>
<entry>Audio Playback Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_MIXER</constant></entry>
<entry>Audio Mixer Function Entity.</entry>
</row>
</tbody>
</tgroup>
@@ -162,6 +201,46 @@
<entry>Device node interface for Software Defined Radio (V4L)</entry>
<entry>typically, /dev/swradio?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_CAPTURE</constant></entry>
<entry>Device node interface for ALSA PCM Capture</entry>
<entry>typically, /dev/snd/pcmC?D?c</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_PLAYBACK</constant></entry>
<entry>Device node interface for ALSA PCM Playback</entry>
<entry>typically, /dev/snd/pcmC?D?p</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_CONTROL</constant></entry>
<entry>Device node interface for ALSA Control</entry>
<entry>typically, /dev/snd/controlC?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_COMPRESS</constant></entry>
<entry>Device node interface for ALSA Compress</entry>
<entry>typically, /dev/snd/compr?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_RAWMIDI</constant></entry>
<entry>Device node interface for ALSA Raw MIDI</entry>
<entry>typically, /dev/snd/midi?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_HWDEP</constant></entry>
<entry>Device node interface for ALSA Hardware Dependent</entry>
<entry>typically, /dev/snd/hwC?D?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_SEQUENCER</constant></entry>
<entry>Device node interface for ALSA Sequencer</entry>
<entry>typically, /dev/snd/seq</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_TIMER</constant></entry>
<entry>Device node interface for ALSA Timer</entry>
<entry>typically, /dev/snd/timer</entry>
</row>
</tbody>
</tgroup>
</table>

49
Documentation/DocBook/media/v4l/pixfmt-y12i.xml Normal file
View File

@@ -0,0 +1,49 @@
<refentry id="V4L2-PIX-FMT-Y12I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12I ('Y12I')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel, but with
pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a
24-bit word in the little-endian order. On a little-endian machine these pixels
can be deinterlaced using</para>
<para>
<programlisting>
__u8 *buf;
left0 = 0xfff &amp; *(__u16 *)buf;
right0 = *(__u16 *)(buf + 1) >> 4;
</programlisting>
</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes</title>
<formalpara>
<title>Bit-packed representation</title>
<para>pixels cross the byte boundary and have a ratio of 3 bytes for each
interleaved pixel.
<informaltable frame="all">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>Y'<subscript>0left[7:0]</subscript></entry>
<entry>Y'<subscript>0right[3:0]</subscript>Y'<subscript>0left[11:8]</subscript></entry>
<entry>Y'<subscript>0right[11:4]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

80
Documentation/DocBook/media/v4l/pixfmt-y8i.xml Normal file
View File

@@ -0,0 +1,80 @@
<refentry id="V4L2-PIX-FMT-Y8I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y8I ('Y8I ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y8I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 8 bits per pixel, but with
pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g.
the R200 RealSense camera stores pixel from the left sensor in lower and from
the right sensor in the higher 8 bits.</para>
<example>
<title><constant>V4L2_PIX_FMT_Y8I</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00left</subscript></entry>
<entry>Y'<subscript>00right</subscript></entry>
<entry>Y'<subscript>01left</subscript></entry>
<entry>Y'<subscript>01right</subscript></entry>
<entry>Y'<subscript>02left</subscript></entry>
<entry>Y'<subscript>02right</subscript></entry>
<entry>Y'<subscript>03left</subscript></entry>
<entry>Y'<subscript>03right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10left</subscript></entry>
<entry>Y'<subscript>10right</subscript></entry>
<entry>Y'<subscript>11left</subscript></entry>
<entry>Y'<subscript>11right</subscript></entry>
<entry>Y'<subscript>12left</subscript></entry>
<entry>Y'<subscript>12right</subscript></entry>
<entry>Y'<subscript>13left</subscript></entry>
<entry>Y'<subscript>13right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20left</subscript></entry>
<entry>Y'<subscript>20right</subscript></entry>
<entry>Y'<subscript>21left</subscript></entry>
<entry>Y'<subscript>21right</subscript></entry>
<entry>Y'<subscript>22left</subscript></entry>
<entry>Y'<subscript>22right</subscript></entry>
<entry>Y'<subscript>23left</subscript></entry>
<entry>Y'<subscript>23right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30left</subscript></entry>
<entry>Y'<subscript>30right</subscript></entry>
<entry>Y'<subscript>31left</subscript></entry>
<entry>Y'<subscript>31right</subscript></entry>
<entry>Y'<subscript>32left</subscript></entry>
<entry>Y'<subscript>32right</subscript></entry>
<entry>Y'<subscript>33left</subscript></entry>
<entry>Y'<subscript>33right</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

26
Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml
View File

@@ -1,35 +1,43 @@
<refentry id="V4L2-PIX-FMT-YUV420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV420M"><constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU420M"><constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> and
<constant>V4L2_PIX_FMT_YVU420</constant> with planes non contiguous
in memory.</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub- images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cb data
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV420M</constant> the Cb data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cb belongs to four
pixels, a two-by-two square of the image. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
in the third plane.</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV420M</constant> and
<constant>V4L2_PIX_FMT_YVU420M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>

114
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml → Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml
View File

@@ -1,40 +1,45 @@
<refentry id="V4L2-PIX-FMT-YVU420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV422M"><constant>V4L2_PIX_FMT_YUV422M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU422M"><constant>V4L2_PIX_FMT_YVU422M</constant></refname>
<refpurpose>Planar formats with &frac12; horizontal resolution, also
known as YUV and YVU 4:2:2</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cr data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cr belongs to four
pixels, a two-by-two square of the image. For example,
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
the third plane. </para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV422M</constant> the Cb data
constitutes the second plane which is half the width of the Y plane (and of the
image). Each Cb belongs to two pixels. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cr
and Cb planes have half as many pad bytes after their rows. In other
<para><constant>V4L2_PIX_FMT_YVU422M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV422M</constant> and
<constant>V4L2_PIX_FMT_YVU422M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
<title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 &times; 4
pixel image</title>
<formalpara>
@@ -75,25 +80,45 @@ pixel image</title>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;6:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;6:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
@@ -113,36 +138,23 @@ pixel image</title>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
</tbody>
</tgroup>

177
Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml Normal file
View File

@@ -0,0 +1,177 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-YUV444M"><constant>V4L2_PIX_FMT_YUV444M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU444M"><constant>V4L2_PIX_FMT_YVU444M</constant></refname>
<refpurpose>Planar formats with full horizontal resolution, also
known as YUV and YVU 4:4:4</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.</para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV444M</constant> the Cb data
constitutes the second plane which is the same width and height as the Y plane
(and as the image). The Cr data, just like the Cb plane, is in the third plane.
</para>
<para><constant>V4L2_PIX_FMT_YVU444M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have the same number of pad bytes after their rows.</para>
<para><constant>V4L2_PIX_FMT_YUV444M</constant> and
<constant>V4L2_PIX_FMT_YUV444M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YUV444M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cb<subscript>03</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cb<subscript>13</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cb<subscript>23</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cb<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
<entry>Cr<subscript>03</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
<entry>Cr<subscript>13</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;8:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
<entry>Cr<subscript>23</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;12:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
<entry>Cr<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>1</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>2</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>3</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

81
Documentation/DocBook/media/v4l/pixfmt-z16.xml Normal file
View File

@@ -0,0 +1,81 @@
<refentry id="V4L2-PIX-FMT-Z16">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Z16 ('Z16 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Z16</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a 16-bit format, representing depth data. Each pixel is a
distance to the respective point in the image coordinates. Distance unit can
vary and has to be negotiated with the device separately. Each pixel is stored
in a 16-bit word in the little endian byte order.
</para>
<example>
<title><constant>V4L2_PIX_FMT_Z16</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Z<subscript>00low</subscript></entry>
<entry>Z<subscript>00high</subscript></entry>
<entry>Z<subscript>01low</subscript></entry>
<entry>Z<subscript>01high</subscript></entry>
<entry>Z<subscript>02low</subscript></entry>
<entry>Z<subscript>02high</subscript></entry>
<entry>Z<subscript>03low</subscript></entry>
<entry>Z<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Z<subscript>10low</subscript></entry>
<entry>Z<subscript>10high</subscript></entry>
<entry>Z<subscript>11low</subscript></entry>
<entry>Z<subscript>11high</subscript></entry>
<entry>Z<subscript>12low</subscript></entry>
<entry>Z<subscript>12high</subscript></entry>
<entry>Z<subscript>13low</subscript></entry>
<entry>Z<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Z<subscript>20low</subscript></entry>
<entry>Z<subscript>20high</subscript></entry>
<entry>Z<subscript>21low</subscript></entry>
<entry>Z<subscript>21high</subscript></entry>
<entry>Z<subscript>22low</subscript></entry>
<entry>Z<subscript>22high</subscript></entry>
<entry>Z<subscript>23low</subscript></entry>
<entry>Z<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Z<subscript>30low</subscript></entry>
<entry>Z<subscript>30high</subscript></entry>
<entry>Z<subscript>31low</subscript></entry>
<entry>Z<subscript>31high</subscript></entry>
<entry>Z<subscript>32low</subscript></entry>
<entry>Z<subscript>32high</subscript></entry>
<entry>Z<subscript>33low</subscript></entry>
<entry>Z<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

13
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@@ -1620,6 +1620,8 @@ information.</para>
&sub-y10b;
&sub-y16;
&sub-y16-be;
&sub-y8i;
&sub-y12i;
&sub-uv8;
&sub-yuyv;
&sub-uyvy;
@@ -1628,7 +1630,8 @@ information.</para>
&sub-y41p;
&sub-yuv420;
&sub-yuv420m;
&sub-yvu420m;
&sub-yuv422m;
&sub-yuv444m;
&sub-yuv410;
&sub-yuv422p;
&sub-yuv411p;
@@ -1641,6 +1644,14 @@ information.</para>
&sub-m420;
</section>
<section id="depth-formats">
<title>Depth Formats</title>
<para>Depth data provides distance to points, mapped onto the image plane
</para>
&sub-z16;
</section>
<section>
<title>Compressed Formats</title>

14
Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml
View File

@@ -60,9 +60,19 @@ input</refpurpose>
automatically, similar to sensing the video standard. To do so, applications
call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a
&v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the
timings structure.
timings structure.</para>
If the timings could not be detected because there was no signal, then
<para>Please note that drivers shall <emphasis>not</emphasis> switch timings automatically
if new timings are detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERY_DV_TIMINGS</constant>.
The reason is that new timings usually mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERY_DV_TIMINGS</constant>,
and if the detected timings are valid they will have to stop streaming, set the new
timings, allocate new buffers and start streaming again.</para>
<para>If the timings could not be detected because there was no signal, then
<errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but
it was unstable and the receiver could not lock to the signal, then
<errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal,

10
Documentation/DocBook/media/v4l/vidioc-querystd.xml
View File

@@ -59,6 +59,16 @@ 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>
<para>Please note that drivers shall <emphasis>not</emphasis> switch the video standard
automatically if a new video standard is detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERYSTD</constant>.
The reason is that a new video standard can mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERYSTD</constant>,
and if the detected video standard is valid they will have to stop streaming, set the new
standard, allocate new buffers and start streaming again.</para>
</refsect1>
<refsect1>

2
Documentation/devicetree/bindings/media/i2c/mt9v032.txt
View File

@@ -20,6 +20,8 @@ Optional Properties:
- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
expressed as a 64-bit big-endian integer.
- reset-gpios: GPIO handle which is connected to the reset pin of the chip.
- standby-gpios: GPIO handle which is connected to the standby pin of the chip.
For further reading on port node refer to
Documentation/devicetree/bindings/media/video-interfaces.txt.

45
Documentation/devicetree/bindings/media/i2c/tvp5150.txt Normal file
View File

@@ -0,0 +1,45 @@
* Texas Instruments TVP5150 and TVP5151 video decoders
The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL
(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV
with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats.
Required Properties:
- compatible: value must be "ti,tvp5150"
- reg: I2C slave address
Optional Properties:
- pdn-gpios: phandle for the GPIO connected to the PDN pin, if any.
- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
The device node must contain one 'port' child node for its digital output
video port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Required Endpoint Properties for parallel synchronization:
- hsync-active: active state of the HSYNC signal. Must be <1> (HIGH).
- vsync-active: active state of the VSYNC signal. Must be <1> (HIGH).
- field-even-active: field signal level during the even field data
transmission. Must be <0>.
If none of hsync-active, vsync-active and field-even-active is specified,
the endpoint is assumed to use embedded BT.656 synchronization.
Example:
&i2c2 {
...
tvp5150@5c {
compatible = "ti,tvp5150";
reg = <0x5c>;
pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
port {
tvp5150_1: endpoint {
remote-endpoint = <&ccdc_ep>;
};
};
};
};

1
Documentation/devicetree/bindings/media/rcar_vin.txt
View File

@@ -6,6 +6,7 @@ family of devices. The current blocks are always slaves and suppot one input
channel which can be either RGB, YUYV or BT656.
- compatible: Must be one of the following
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7793" for the R8A7793 device
- "renesas,vin-r8a7791" for the R8A7791 device

13
Documentation/devicetree/bindings/media/renesas,jpu.txt
View File

@@ -5,11 +5,12 @@ and decoding function conforming to the JPEG baseline process, so that the JPU
can encode image data and decode JPEG data quickly.
Required properties:
- compatible: should containg one of the following:
- "renesas,jpu-r8a7790" for R-Car H2
- "renesas,jpu-r8a7791" for R-Car M2-W
- "renesas,jpu-r8a7792" for R-Car V2H
- "renesas,jpu-r8a7793" for R-Car M2-N
- compatible: "renesas,jpu-<soctype>", "renesas,rcar-gen2-jpu" as fallback.
Examples with soctypes are:
- "renesas,jpu-r8a7790" for R-Car H2
- "renesas,jpu-r8a7791" for R-Car M2-W
- "renesas,jpu-r8a7792" for R-Car V2H
- "renesas,jpu-r8a7793" for R-Car M2-N
- reg: Base address and length of the registers block for the JPU.
- interrupts: JPU interrupt specifier.
@@ -17,7 +18,7 @@ Required properties:
Example: R8A7790 (R-Car H2) JPU node
jpeg-codec@fe980000 {
compatible = "renesas,jpu-r8a7790";
compatible = "renesas,jpu-r8a7790", "renesas,rcar-gen2-jpu";
reg = <0 0xfe980000 0 0x10300>;
interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp1_clks R8A7790_CLK_JPU>;

34
Documentation/devicetree/bindings/media/renesas,vsp1.txt
View File

@@ -1,30 +1,18 @@
* Renesas VSP1 Video Processing Engine
* Renesas VSP Video Processing Engine
The VSP1 is a video processing engine that supports up-/down-scaling, alpha
The VSP is a video processing engine that supports up-/down-scaling, alpha
blending, color space conversion and various other image processing features.
It can be found in the Renesas R-Car second generation SoCs.
Required properties:
- compatible: Must contain "renesas,vsp1"
- compatible: Must contain one of the following values
- "renesas,vsp1" for the R-Car Gen2 VSP1
- "renesas,vsp2" for the R-Car Gen3 VSP2
- reg: Base address and length of the registers block for the VSP1.
- interrupts: VSP1 interrupt specifier.
- clocks: A phandle + clock-specifier pair for the VSP1 functional clock.
- renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1.
- renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1.
- renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1.
Optional properties:
- renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is
available.
- renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is
available.
- renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU)
module is available.
- reg: Base address and length of the registers block for the VSP.
- interrupts: VSP interrupt specifier.
- clocks: A phandle + clock-specifier pair for the VSP functional clock.
Example: R8A7790 (R-Car H2) VSP1-S node
@@ -34,10 +22,4 @@ Example: R8A7790 (R-Car H2) VSP1-S node
reg = <0 0xfe928000 0 0x8000>;
interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>;
renesas,has-lut;
renesas,has-sru;
renesas,#rpf = <5>;
renesas,#uds = <3>;
renesas,#wpf = <4>;
};

72
Documentation/devicetree/bindings/media/ti-cal.txt Normal file
View File

@@ -0,0 +1,72 @@
Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)
------------------------------------------------------
The Camera Adaptation Layer (CAL) is a key component for image capture
applications. The capture module provides the system interface and the
processing capability to connect CSI2 image-sensor modules to the
DRA72x device.
Required properties:
- compatible: must be "ti,dra72-cal"
- reg: CAL Top level, Receiver Core #0, Receiver Core #1 and Camera RX
control address space
- reg-names: cal_top, cal_rx_core0, cal_rx_core1, and camerrx_control
registers
- interrupts: should contain IRQ line for the CAL;
CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
should contain a 'port' child node with child 'endpoint' node. Please
refer to the bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
cal: cal@4845b000 {
compatible = "ti,dra72-cal";
ti,hwmods = "cal";
reg = <0x4845B000 0x400>,
<0x4845B800 0x40>,
<0x4845B900 0x40>,
<0x4A002e94 0x4>;
reg-names = "cal_top",
"cal_rx_core0",
"cal_rx_core1",
"camerrx_control";
interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
csi2_0: port@0 {
reg = <0>;
endpoint {
slave-mode;
remote-endpoint = <&ar0330_1>;
};
};
csi2_1: port@1 {
reg = <1>;
};
};
};
i2c5: i2c@4807c000 {
ar0330@10 {
compatible = "ti,ar0330";
reg = <0x10>;
port {
#address-cells = <1>;
#size-cells = <0>;
ar0330_1: endpoint {
reg = <0>;
clock-lanes = <1>;
data-lanes = <0 2 3 4>;
remote-endpoint = <&csi2_0>;
};
};
};
};

Some files were not shown because too many files have changed in this diff Show More