diff options
| author | Linus Torvalds <torvalds@linux-foundation.org> | 2016-03-16 18:27:32 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2016-03-16 18:27:32 -0700 |
| commit | bace3db5da970c4d4f80a1ffa988ec66c7f6a8f5 (patch) | |
| tree | ab893a29048a3a4ae91d7261a8f4946f3017eff1 /Documentation | |
| parent | 8759957b77ac1b5b5bdfac5ba049789107e85190 (diff) | |
| parent | 8331c055b23c4155b896a2c3791704ae68992d2b (diff) | |
| download | linux-bace3db5da970c4d4f80a1ffa988ec66c7f6a8f5.tar.bz2 | |
Merge tag 'media/v4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
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
...
Diffstat (limited to 'Documentation')
23 files changed, 788 insertions, 97 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-rc-nuvoton b/Documentation/ABI/testing/sysfs-class-rc-nuvoton new file mode 100644 index 000000000000..905bcdeedef2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rc-nuvoton @@ -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. diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index cdd8b24db68d..cc303a2f641c 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -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 diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index f13a429093f1..361040e6b0f4 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2330,6 +2330,14 @@ 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> </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> </entry> <entry>integer</entry> @@ -5070,6 +5078,46 @@ interface and may change in the future.</para> </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 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> </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> </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> </entry> + <entry>Cinema content.</entry> + </row> + <row> + <entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant> </entry> + <entry>Game content. Audio and video latency should be minimized.</entry> + </row> + <row> + <entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant> </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> </row> @@ -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> diff --git a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml index 63152ab9efba..e0d49fa329f0 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-g-topology.xml @@ -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 diff --git a/Documentation/DocBook/media/v4l/media-types.xml b/Documentation/DocBook/media/v4l/media-types.xml index 0ee0f3386cdf..5e3f20fdcf17 100644 --- a/Documentation/DocBook/media/v4l/media-types.xml +++ b/Documentation/DocBook/media/v4l/media-types.xml @@ -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> diff --git a/Documentation/DocBook/media/v4l/pixfmt-y12i.xml b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml new file mode 100644 index 000000000000..4a2d1e5f67e4 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml @@ -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 & *(__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> diff --git a/Documentation/DocBook/media/v4l/pixfmt-y8i.xml b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml new file mode 100644 index 000000000000..99f389d4c6c8 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml @@ -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 × 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 + 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 + 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 + 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 + 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> diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml index e781cc61786c..7d13fe96657d 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml @@ -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> diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml index 2330667907c7..dd502802cb75 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml @@ -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 ½ 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 × 4 + <title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 × 4 pixel image</title> <formalpara> @@ -75,24 +80,44 @@ pixel image</title> <row><entry></entry></row> <row> <entry>start1 + 0:</entry> - <entry>Cr<subscript>00</subscript></entry> - <entry>Cr<subscript>01</subscript></entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> </row> <row> <entry>start1 + 2:</entry> - <entry>Cr<subscript>10</subscript></entry> - <entry>Cr<subscript>11</subscript></entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + </row> + <row> + <entry>start1 + 4:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + </row> + <row> + <entry>start1 + 6:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> </row> <row><entry></entry></row> <row> <entry>start2 + 0:</entry> - <entry>Cb<subscript>00</subscript></entry> - <entry>Cb<subscript>01</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> </row> <row> <entry>start2 + 2:</entry> - <entry>Cb<subscript>10</subscript></entry> - <entry>Cb<subscript>11</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + </row> + <row> + <entry>start2 + 4:</entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + </row> + <row> + <entry>start2 + 6:</entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> </row> </tbody> </tgroup> @@ -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> diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml new file mode 100644 index 000000000000..1b7335940bc7 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml @@ -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 × 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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> diff --git a/Documentation/DocBook/media/v4l/pixfmt-z16.xml b/Documentation/DocBook/media/v4l/pixfmt-z16.xml new file mode 100644 index 000000000000..3d87e4bf87b8 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-z16.xml @@ -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 × 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 + 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 + 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 + 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 + 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> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index d871245d2973..5a08aeea4360 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -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> diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml index e9c70a8f3476..0c93677d16b4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml @@ -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, diff --git a/Documentation/DocBook/media/v4l/vidioc-querystd.xml b/Documentation/DocBook/media/v4l/vidioc-querystd.xml index 222348542182..3ceae35fab03 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querystd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querystd.xml @@ -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> diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt index 202565313e82..100f0ae43269 100644 --- a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt +++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt @@ -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. diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt new file mode 100644 index 000000000000..8c0fc1a26bf0 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt @@ -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>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt index 9dafe6b06cd2..619193ccf7ff 100644 --- a/Documentation/devicetree/bindings/media/rcar_vin.txt +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -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 diff --git a/Documentation/devicetree/bindings/media/renesas,jpu.txt b/Documentation/devicetree/bindings/media/renesas,jpu.txt index 0cb94201bf92..d3436e5190f9 100644 --- a/Documentation/devicetree/bindings/media/renesas,jpu.txt +++ b/Documentation/devicetree/bindings/media/renesas,jpu.txt @@ -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>; diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt b/Documentation/devicetree/bindings/media/renesas,vsp1.txt index 87fe08abf36d..627405abd144 100644 --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt @@ -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>; }; diff --git a/Documentation/devicetree/bindings/media/ti-cal.txt b/Documentation/devicetree/bindings/media/ti-cal.txt new file mode 100644 index 000000000000..ae9b52f37576 --- /dev/null +++ b/Documentation/devicetree/bindings/media/ti-cal.txt @@ -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>; + }; + }; + }; + }; diff --git a/Documentation/dvb/README.dvb-usb b/Documentation/dvb/README.dvb-usb index 669dc6ce4330..6f4b12f7b844 100644 --- a/Documentation/dvb/README.dvb-usb +++ b/Documentation/dvb/README.dvb-usb @@ -190,7 +190,7 @@ and watch another one. Patches, comments and suggestions are very very welcome. 3. Acknowledgements - Amaury Demol (ademol@dibcom.fr) and Francois Kanounnikoff from DiBcom for + Amaury Demol (Amaury.Demol@parrot.com) and Francois Kanounnikoff from DiBcom for providing specs, code and help, on which the dvb-dibusb, dib3000mb and dib3000mc are based. diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 282102014bb9..335c24338859 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -194,3 +194,4 @@ 193 -> WIS Voyager or compatible [1905:7007] 194 -> AverMedia AverTV/505 [1461:a10a] 195 -> Leadtek Winfast TV2100 FM [107d:6f3a] +196 -> SnaZio* TVPVR PRO [1779:13cf] diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index 5517db602f37..5e759cab4538 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt @@ -647,7 +647,6 @@ Or you can add specific controls to a handler: volume = v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_AUDIO_VOLUME, ...); v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_BRIGHTNESS, ...); v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_CONTRAST, ...); - v4l2_ctrl_add_ctrl(&radio_ctrl_handler, volume); What you should not do is make two identical controls for two handlers. For example: |