code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: <isonum.txt>

====================================
Media subsystem admin and user guide
====================================

This section contains usage information about media subsystem and
its supported drivers.

Please see:

Documentation/userspace-api/media/index.rst

  - for the userspace APIs used on media devices.

Documentation/driver-api/media/index.rst

  - for driver development information and Kernel APIs used by
    media devices;

The media subsystem
===================

.. only:: html

    .. class:: toc-title

        Table of Contents

.. toctree::
	:maxdepth: 2
	:numbered:

	intro
	building

	remote-controller

	cec

	dvb

	cardlist

	v4l-drivers
	dvb-drivers

**Copyright** |copy| 1999-2020 : LinuxTV Developers

::

  This documentation is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the Free
  Software Foundation; either version 2 of the License, or (at your option) any
  later version.

  This program is distributed in the hope that it will be useful, but WITHOUT
  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
  more details.

  For more details see the file COPYING in the source distribution of Linux.


code:
.. SPDX-License-Identifier: GPL-2.0

============
Introduction
============

The media subsystem consists on Linux support for several different types
of devices:

- Audio and video grabbers;
- PC and Laptop Cameras;
- Complex cameras found on Embedded hardware;
- Analog and digital TV;
- HDMI Customer Electronics Control (CEC);
- Multi-touch input devices;
- Remote Controllers;
- Media encoders and decoders.

Due to the diversity of devices, the subsystem provides several different
APIs:

- Remote Controller API;
- HDMI CEC API;
- Video4Linux API;
- Media controller API;
- Video4Linux Request API (experimental);
- Digital TV API (also known as DVB API).

repo_name: angery/linux


code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: <isonum.txt>

===============================================================
Intel Image Processing Unit 3 (IPU3) Imaging Unit (ImgU) driver
===============================================================

Copyright |copy| 2018 Intel Corporation

Introduction
============

This file documents the Intel IPU3 (3rd generation Image Processing Unit)
Imaging Unit drivers located under drivers/media/pci/intel/ipu3 (CIO2) as well
as under drivers/staging/media/ipu3 (ImgU).

The Intel IPU3 found in certain Kaby Lake (as well as certain Sky Lake)
platforms (U/Y processor lines) is made up of two parts namely the Imaging Unit
(ImgU) and the CIO2 device (MIPI CSI2 receiver).

The CIO2 device receives the raw Bayer data from the sensors and outputs the
frames in a format that is specific to the IPU3 (for consumption by the IPU3
ImgU). The CIO2 driver is available as drivers/media/pci/intel/ipu3/ipu3-cio2*
and is enabled through the CONFIG_VIDEO_IPU3_CIO2 config option.

The Imaging Unit (ImgU) is responsible for processing images captured
by the IPU3 CIO2 device. The ImgU driver sources can be found under
drivers/staging/media/ipu3 directory. The driver is enabled through the
CONFIG_VIDEO_IPU3_IMGU config option.

The two driver modules are named ipu3_csi2 and ipu3_imgu, respectively.

The drivers has been tested on Kaby Lake platforms (U/Y processor lines).

Both of the drivers implement V4L2, Media Controller and V4L2 sub-device
interfaces. The IPU3 CIO2 driver supports camera sensors connected to the CIO2
MIPI CSI-2 interfaces through V4L2 sub-device sensor drivers.

CIO2
====

The CIO2 is represented as a single V4L2 subdev, which provides a V4L2 subdev
interface to the user space. There is a video node for each CSI-2 receiver,
with a single media controller interface for the entire device.

The CIO2 contains four independent capture channel, each with its own MIPI CSI-2
receiver and DMA engine. Each channel is modelled as a V4L2 sub-device exposed
to userspace as a V4L2 sub-device node and has two pads:

.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|

.. flat-table::
    :header-rows: 1

    * - Pad
      - Direction
      - Purpose

    * - 0
      - sink
      - MIPI CSI-2 input, connected to the sensor subdev

    * - 1
      - source
      - Raw video capture, connected to the V4L2 video interface

The V4L2 video interfaces model the DMA engines. They are exposed to userspace
as V4L2 video device nodes.

Capturing frames in raw Bayer format
------------------------------------

CIO2 MIPI CSI2 receiver is used to capture frames (in packed raw Bayer format)
from the raw sensors connected to the CSI2 ports. The captured frames are used
as input to the ImgU driver.

Image processing using IPU3 ImgU requires tools such as raw2pnm [#f1]_, and
yavta [#f2]_ due to the following unique requirements and / or features specific
to IPU3.

-- The IPU3 CSI2 receiver outputs the captured frames from the sensor in packed
raw Bayer format that is specific to IPU3.

-- Multiple video nodes have to be operated simultaneously.

Let us take the example of ov5670 sensor connected to CSI2 port 0, for a
2592x1944 image capture.

Using the media controller APIs, the ov5670 sensor is configured to send
frames in packed raw Bayer format to IPU3 CSI2 receiver.

.. code-block:: none

    # This example assumes /dev/media0 as the CIO2 media device
    export MDEV=/dev/media0

    # and that ov5670 sensor is connected to i2c bus 10 with address 0x36
    export SDEV=$(media-ctl -d $MDEV -e "ov5670 10-0036")

    # Establish the link for the media devices using media-ctl [#f3]_
    media-ctl -d $MDEV -l "ov5670:0 -> ipu3-csi2 0:0[1]"

    # Set the format for the media devices
    media-ctl -d $MDEV -V "ov5670:0 [fmt:SGRBG10/2592x1944]"
    media-ctl -d $MDEV -V "ipu3-csi2 0:0 [fmt:SGRBG10/2592x1944]"
    media-ctl -d $MDEV -V "ipu3-csi2 0:1 [fmt:SGRBG10/2592x1944]"

Once the media pipeline is configured, desired sensor specific settings
(such as exposure and gain settings) can be set, using the yavta tool.

e.g

.. code-block:: none

    yavta -w 0x009e0903 444 $SDEV
    yavta -w 0x009e0913 1024 $SDEV
    yavta -w 0x009e0911 2046 $SDEV

Once the desired sensor settings are set, frame captures can be done as below.

e.g

.. code-block:: none

    yavta --data-prefix -u -c10 -n5 -I -s2592x1944 --file=/tmp/frame-#.bin \
          -f IPU3_SGRBG10 $(media-ctl -d $MDEV -e "ipu3-cio2 0")

With the above command, 10 frames are captured at 2592x1944 resolution, with
sGRBG10 format and output as IPU3_SGRBG10 format.

The captured frames are available as /tmp/frame-#.bin files.

ImgU
====

The ImgU is represented as two V4L2 subdevs, each of which provides a V4L2
subdev interface to the user space.

Each V4L2 subdev represents a pipe, which can support a maximum of 2 streams.
This helps to support advanced camera features like Continuous View Finder (CVF)
and Snapshot During Video(SDV).

The ImgU contains two independent pipes, each modelled as a V4L2 sub-device
exposed to userspace as a V4L2 sub-device node.

Each pipe has two sink pads and three source pads for the following purpose:

.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|

.. flat-table::
    :header-rows: 1

    * - Pad
      - Direction
      - Purpose

    * - 0
      - sink
      - Input raw video stream

    * - 1
      - sink
      - Processing parameters

    * - 2
      - source
      - Output processed video stream

    * - 3
      - source
      - Output viewfinder video stream

    * - 4
      - source
      - 3A statistics

Each pad is connected to a corresponding V4L2 video interface, exposed to
userspace as a V4L2 video device node.

Device operation
----------------

With ImgU, once the input video node ("ipu3-imgu 0/1":0, in
<entity>:<pad-number> format) is queued with buffer (in packed raw Bayer
format), ImgU starts processing the buffer and produces the video output in YUV
format and statistics output on respective output nodes. The driver is expected
to have buffers ready for all of parameter, output and statistics nodes, when
input video node is queued with buffer.

At a minimum, all of input, main output, 3A statistics and viewfinder
video nodes should be enabled for IPU3 to start image processing.

Each ImgU V4L2 subdev has the following set of video nodes.

input, output and viewfinder video nodes
----------------------------------------

The frames (in packed raw Bayer format specific to the IPU3) received by the
input video node is processed by the IPU3 Imaging Unit and are output to 2 video
nodes, with each targeting a different purpose (main output and viewfinder
output).

Details onand the Bayer format specific to the IPU3 can be found in
:ref:`v4l2-pix-fmt-ipu3-sbggr10`.

The driver supports V4L2 Video Capture Interface as defined at :ref:`devices`.

Only the multi-planar API is supported. More details can be found at
:ref:`planar-apis`.

Parameters video node
---------------------

The parameters video node receives the ImgU algorithm parameters that are used
to configure how the ImgU algorithms process the image.

Details on processing parameters specific to the IPU3 can be found in
:ref:`v4l2-meta-fmt-params`.

3A statistics video node
------------------------

3A statistics video node is used by the ImgU driver to output the 3A (auto
focus, auto exposure and auto white balance) statistics for the frames that are
being processed by the ImgU to user space applications. User space applications
can use this statistics data to compute the desired algorithm parameters for
the ImgU.

Configuring the Intel IPU3
==========================

The IPU3 ImgU pipelines can be configured using the Media Controller, defined at
:ref:`media_controller`.

Running mode and firmware binary selection
------------------------------------------

ImgU works based on firmware, currently the ImgU firmware support run 2 pipes
in time-sharing with single input frame data. Each pipe can run at certain mode
- "VIDEO" or "STILL", "VIDEO" mode is commonly used for video frames capture,
and "STILL" is used for still frame capture. However, you can also select
"VIDEO" to capture still frames if you want to capture images with less system
load and power. For "STILL" mode, ImgU will try to use smaller BDS factor and
output larger bayer frame for further YUV processing than "VIDEO" mode to get
high quality images. Besides, "STILL" mode need XNR3 to do noise reduction,
hence "STILL" mode will need more power and memory bandwidth than "VIDEO" mode.
TNR will be enabled in "VIDEO" mode and bypassed by "STILL" mode. ImgU is
running at "VIDEO" mode by default, the user can use v4l2 control
V4L2_CID_INTEL_IPU3_MODE (currently defined in
drivers/staging/media/ipu3/include/uapi/intel-ipu3.h) to query and set the
running mode. For user, there is no difference for buffer queueing between the
"VIDEO" and "STILL" mode, mandatory input and main output node should be
enabled and buffers need be queued, the statistics and the view-finder queues
are optional.

The firmware binary will be selected according to current running mode, such log
"using binary if_to_osys_striped " or "using binary if_to_osys_primary_striped"
could be observed if you enable the ImgU dynamic debug, the binary
if_to_osys_striped is selected for "VIDEO" and the binary
"if_to_osys_primary_striped" is selected for "STILL".

Processing the image in raw Bayer format
----------------------------------------

Configuring ImgU V4L2 subdev for image processing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The ImgU V4L2 subdevs have to be configured with media controller APIs to have
all the video nodes setup correctly.

Let us take "ipu3-imgu 0" subdev as an example.

.. code-block:: none

    media-ctl -d $MDEV -r
    media-ctl -d $MDEV -l "ipu3-imgu 0 input":0 -> "ipu3-imgu 0":0[1]
    media-ctl -d $MDEV -l "ipu3-imgu 0":2 -> "ipu3-imgu 0 output":0[1]
    media-ctl -d $MDEV -l "ipu3-imgu 0":3 -> "ipu3-imgu 0 viewfinder":0[1]
    media-ctl -d $MDEV -l "ipu3-imgu 0":4 -> "ipu3-imgu 0 3a stat":0[1]

Also the pipe mode of the corresponding V4L2 subdev should be set as desired
(e.g 0 for video mode or 1 for still mode) through the control id 0x009819a1 as
below.

.. code-block:: none

    yavta -w "0x009819A1 1" /dev/v4l-subdev7

Certain hardware blocks in ImgU pipeline can change the frame resolution by
cropping or scaling, these hardware blocks include Input Feeder(IF), Bayer Down
Scaler (BDS) and Geometric Distortion Correction (GDC).
There is also a block which can change the frame resolution - YUV Scaler, it is
only applicable to the secondary output.

RAW Bayer frames go through these ImgU pipeline hardware blocks and the final
processed image output to the DDR memory.

.. kernel-figure::  ipu3_rcb.svg
   :alt: ipu3 resolution blocks image

   IPU3 resolution change hardware blocks

**Input Feeder**

Input Feeder gets the Bayer frame data from the sensor, it can enable cropping
of lines and columns from the frame and then store pixels into device's internal
pixel buffer which are ready to readout by following blocks.

**Bayer Down Scaler**

Bayer Down Scaler is capable of performing image scaling in Bayer domain, the
downscale factor can be configured from 1X to 1/4X in each axis with
configuration steps of 0.03125 (1/32).

**Geometric Distortion Correction**

Geometric Distortion Correction is used to perform correction of distortions
and image filtering. It needs some extra filter and envelope padding pixels to
work, so the input resolution of GDC should be larger than the output
resolution.

**YUV Scaler**

YUV Scaler which similar with BDS, but it is mainly do image down scaling in
YUV domain, it can support up to 1/12X down scaling, but it can not be applied
to the main output.

The ImgU V4L2 subdev has to be configured with the supported resolutions in all
the above hardware blocks, for a given input resolution.
For a given supported resolution for an input frame, the Input Feeder, Bayer
Down Scaler and GDC blocks should be configured with the supported resolutions
as each hardware block has its own alignment requirement.

You must configure the output resolution of the hardware blocks smartly to meet
the hardware requirement along with keeping the maximum field of view. The
intermediate resolutions can be generated by specific tool -

https://github.com/intel/intel-ipu3-pipecfg

This tool can be used to generate intermediate resolutions. More information can
be obtained by looking at the following IPU3 ImgU configuration table.

https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/master

Under baseboard-poppy/media-libs/cros-camera-hal-configs-poppy/files/gcss
directory, graph_settings_ov5670.xml can be used as an example.

The following steps prepare the ImgU pipeline for the image processing.

1. The ImgU V4L2 subdev data format should be set by using the
VIDIOC_SUBDEV_S_FMT on pad 0, using the GDC width and height obtained above.

2. The ImgU V4L2 subdev cropping should be set by using the
VIDIOC_SUBDEV_S_SELECTION on pad 0, with V4L2_SEL_TGT_CROP as the target,
using the input feeder height and width.

3. The ImgU V4L2 subdev composing should be set by using the
VIDIOC_SUBDEV_S_SELECTION on pad 0, with V4L2_SEL_TGT_COMPOSE as the target,
using the BDS height and width.

For the ov5670 example, for an input frame with a resolution of 2592x1944
(which is input to the ImgU subdev pad 0), the corresponding resolutions
for input feeder, BDS and GDC are 2592x1944, 2592x1944 and 2560x1920
respectively.

Once this is done, the received raw Bayer frames can be input to the ImgU
V4L2 subdev as below, using the open source application v4l2n [#f1]_.

For an image captured with 2592x1944 [#f4]_ resolution, with desired output
resolution as 2560x1920 and viewfinder resolution as 2560x1920, the following
v4l2n command can be used. This helps process the raw Bayer frames and produces
the desired results for the main output image and the viewfinder output, in NV12
format.

.. code-block:: none

    v4l2n --pipe=4 --load=/tmp/frame-#.bin --open=/dev/video4
          --fmt=type:VIDEO_OUTPUT_MPLANE,width=2592,height=1944,pixelformat=0X47337069 \
          --reqbufs=type:VIDEO_OUTPUT_MPLANE,count:1 --pipe=1 \
          --output=/tmp/frames.out --open=/dev/video5 \
          --fmt=type:VIDEO_CAPTURE_MPLANE,width=2560,height=1920,pixelformat=NV12 \
          --reqbufs=type:VIDEO_CAPTURE_MPLANE,count:1 --pipe=2 \
          --output=/tmp/frames.vf --open=/dev/video6 \
          --fmt=type:VIDEO_CAPTURE_MPLANE,width=2560,height=1920,pixelformat=NV12 \
          --reqbufs=type:VIDEO_CAPTURE_MPLANE,count:1 --pipe=3 --open=/dev/video7 \
          --output=/tmp/frames.3A --fmt=type:META_CAPTURE,? \
          --reqbufs=count:1,type:META_CAPTURE --pipe=1,2,3,4 --stream=5

You can also use yavta [#f2]_ command to do same thing as above:

.. code-block:: none

    yavta --data-prefix -Bcapture-mplane -c10 -n5 -I -s2592x1944 \
          --file=frame-#.out-f NV12 /dev/video5 & \
    yavta --data-prefix -Bcapture-mplane -c10 -n5 -I -s2592x1944 \
          --file=frame-#.vf -f NV12 /dev/video6 & \
    yavta --data-prefix -Bmeta-capture -c10 -n5 -I \
          --file=frame-#.3a /dev/video7 & \
    yavta --data-prefix -Boutput-mplane -c10 -n5 -I -s2592x1944 \
          --file=/tmp/frame-in.cio2 -f IPU3_SGRBG10 /dev/video4

where /dev/video4, /dev/video5, /dev/video6 and /dev/video7 devices point to
input, output, viewfinder and 3A statistics video nodes respectively.

Converting the raw Bayer image into YUV domain
----------------------------------------------

The processed images after the above step, can be converted to YUV domain
as below.

Main output frames
~~~~~~~~~~~~~~~~~~

.. code-block:: none

    raw2pnm -x2560 -y1920 -fNV12 /tmp/frames.out /tmp/frames.out.ppm

where 2560x1920 is output resolution, NV12 is the video format, followed
by input frame and output PNM file.

Viewfinder output frames
~~~~~~~~~~~~~~~~~~~~~~~~

.. code-block:: none

    raw2pnm -x2560 -y1920 -fNV12 /tmp/frames.vf /tmp/frames.vf.ppm

where 2560x1920 is output resolution, NV12 is the video format, followed
by input frame and output PNM file.

Example user space code for IPU3
================================

User space code that configures and uses IPU3 is available here.

https://chromium.googlesource.com/chromiumos/platform/arc-camera/+/master/

The source can be located under hal/intel directory.

Overview of IPU3 pipeline
=========================

IPU3 pipeline has a number of image processing stages, each of which takes a
set of parameters as input. The major stages of pipelines are shown here:

.. kernel-render:: DOT
   :alt: IPU3 ImgU Pipeline
   :caption: IPU3 ImgU Pipeline Diagram

   digraph "IPU3 ImgU" {
       node [shape=box]
       splines="ortho"
       rankdir="LR"

       a [label="Raw pixels"]
       b [label="Bayer Downscaling"]
       c [label="Optical Black Correction"]
       d [label="Linearization"]
       e [label="Lens Shading Correction"]
       f [label="White Balance / Exposure / Focus Apply"]
       g [label="Bayer Noise Reduction"]
       h [label="ANR"]
       i [label="Demosaicing"]
       j [label="Color Correction Matrix"]
       k [label="Gamma correction"]
       l [label="Color Space Conversion"]
       m [label="Chroma Down Scaling"]
       n [label="Chromatic Noise Reduction"]
       o [label="Total Color Correction"]
       p [label="XNR3"]
       q [label="TNR"]
       r [label="DDR", style=filled, fillcolor=yellow, shape=cylinder]
       s [label="YUV Downscaling"]
       t [label="DDR", style=filled, fillcolor=yellow, shape=cylinder]

       { rank=same; a -> b -> c -> d -> e -> f -> g -> h -> i }
       { rank=same; j -> k -> l -> m -> n -> o -> p -> q -> s -> t}

       a -> j [style=invis, weight=10]
       i -> j
       q -> r
   }

The table below presents a description of the above algorithms.

======================== =======================================================
Name			 Description
======================== =======================================================
Optical Black Correction Optical Black Correction block subtracts a pre-defined
			 value from the respective pixel values to obtain better
			 image quality.
			 Defined in struct ipu3_uapi_obgrid_param.
Linearization		 This algo block uses linearization parameters to
			 address non-linearity sensor effects. The Lookup table
			 table is defined in
			 struct ipu3_uapi_isp_lin_vmem_params.
SHD			 Lens shading correction is used to correct spatial
			 non-uniformity of the pixel response due to optical
			 lens shading. This is done by applying a different gain
			 for each pixel. The gain, black level etc are
			 configured in struct ipu3_uapi_shd_config_static.
BNR			 Bayer noise reduction block removes image noise by
			 applying a bilateral filter.
			 See struct ipu3_uapi_bnr_static_config for details.
ANR			 Advanced Noise Reduction is a block based algorithm
			 that performs noise reduction in the Bayer domain. The
			 convolution matrix etc can be found in
			 struct ipu3_uapi_anr_config.
DM			 Demosaicing converts raw sensor data in Bayer format
			 into RGB (Red, Green, Blue) presentation. Then add
			 outputs of estimation of Y channel for following stream
			 processing by Firmware. The struct is defined as
			 struct ipu3_uapi_dm_config.
Color Correction	 Color Correction algo transforms sensor specific color
			 space to the standard "sRGB" color space. This is done
			 by applying 3x3 matrix defined in
			 struct ipu3_uapi_ccm_mat_config.
Gamma correction	 Gamma correction struct ipu3_uapi_gamma_config is a
			 basic non-linear tone mapping correction that is
			 applied per pixel for each pixel component.
CSC			 Color space conversion transforms each pixel from the
			 RGB primary presentation to YUV (Y: brightness,
			 UV: Luminance) presentation. This is done by applying
			 a 3x3 matrix defined in
			 struct ipu3_uapi_csc_mat_config
CDS			 Chroma down sampling
			 After the CSC is performed, the Chroma Down Sampling
			 is applied for a UV plane down sampling by a factor
			 of 2 in each direction for YUV 4:2:0 using a 4x2
			 configurable filter struct ipu3_uapi_cds_params.
CHNR			 Chroma noise reduction
			 This block processes only the chrominance pixels and
			 performs noise reduction by cleaning the high
			 frequency noise.
			 See struct struct ipu3_uapi_yuvp1_chnr_config.
TCC			 Total color correction as defined in struct
			 struct ipu3_uapi_yuvp2_tcc_static_config.
XNR3			 eXtreme Noise Reduction V3 is the third revision of
			 noise reduction algorithm used to improve image
			 quality. This removes the low frequency noise in the
			 captured image. Two related structs are  being defined,
			 struct ipu3_uapi_isp_xnr3_params for ISP data memory
			 and struct ipu3_uapi_isp_xnr3_vmem_params for vector
			 memory.
TNR			 Temporal Noise Reduction block compares successive
			 frames in time to remove anomalies / noise in pixel
			 values. struct ipu3_uapi_isp_tnr3_vmem_params and
			 struct ipu3_uapi_isp_tnr3_params are defined for ISP
			 vector and data memory respectively.
======================== =======================================================

Other often encountered acronyms not listed in above table:

	ACC
		Accelerator cluster
	AWB_FR
		Auto white balance filter response statistics
	BDS
		Bayer downscaler parameters
	CCM
		Color correction matrix coefficients
	IEFd
		Image enhancement filter directed
	Obgrid
		Optical black level compensation
	OSYS
		Output system configuration
	ROI
		Region of interest
	YDS
		Y down sampling
	YTM
		Y-tone mapping

A few stages of the pipeline will be executed by firmware running on the ISP
processor, while many others will use a set of fixed hardware blocks also
called accelerator cluster (ACC) to crunch pixel data and produce statistics.

ACC parameters of individual algorithms, as defined by
struct ipu3_uapi_acc_param, can be chosen to be applied by the user
space through struct struct ipu3_uapi_flags embedded in
struct ipu3_uapi_params structure. For parameters that are configured as
not enabled by the user space, the corresponding structs are ignored by the
driver, in which case the existing configuration of the algorithm will be
preserved.

References
==========

.. [#f5] drivers/staging/media/ipu3/include/uapi/intel-ipu3.h

.. [#f1] https://github.com/intel/nvt

.. [#f2] http://git.ideasonboard.org/yavta.git

.. [#f3] http://git.ideasonboard.org/?p=media-ctl.git;a=summary

.. [#f4] ImgU limitation requires an additional 16x16 for all input resolutions


code:
.. SPDX-License-Identifier: GPL-2.0

IVTV cards list
===============

.. tabularcolumns:: |p{1.4cm}|p{12.7cm}|p{3.4cm}|

.. flat-table::
   :header-rows: 1
   :widths: 2 19 18
   :stub-columns: 0

   * - Card number
     - Card name
     - PCI subsystem IDs

   * - 0
     - Hauppauge WinTV PVR-250
     - IVTV16 104d:813d

   * - 1
     - Hauppauge WinTV PVR-350
     - IVTV16 104d:813d

   * - 2
     - Hauppauge WinTV PVR-150
     - IVTV16 104d:813d

   * - 3
     - AVerMedia M179
     - IVTV15 1461:a3cf, IVTV15 1461:a3ce

   * - 4
     - Yuan MPG600, Kuroutoshikou ITVC16-STVLP
     - IVTV16 12ab:fff3, IVTV16 12ab:ffff

   * - 5
     - YUAN MPG160, Kuroutoshikou ITVC15-STVLP, I/O Data GV-M2TV/PCI
     - IVTV15 10fc:40a0

   * - 6
     - Yuan PG600, Diamond PVR-550
     - IVTV16 ff92:0070, IVTV16 ffab:0600

   * - 7
     - Adaptec VideOh! AVC-2410
     - IVTV16 9005:0093

   * - 8
     - Adaptec VideOh! AVC-2010
     - IVTV16 9005:0092

   * - 9
     - Nagase Transgear 5000TV
     - IVTV16 1461:bfff

   * - 10
     - AOpen VA2000MAX-SNT6
     - IVTV16 0000:ff5f

   * - 11
     - Yuan MPG600GR, Kuroutoshikou CX23416GYC-STVLP
     - IVTV16 12ab:0600, IVTV16 fbab:0600, IVTV16 1154:0523

   * - 12
     - I/O Data GV-MVP/RX, GV-MVP/RX2W (dual tuner)
     - IVTV16 10fc:d01e, IVTV16 10fc:d038, IVTV16 10fc:d039

   * - 13
     - I/O Data GV-MVP/RX2E
     - IVTV16 10fc:d025

   * - 14
     - GotView PCI DVD
     - IVTV16 12ab:0600

   * - 15
     - GotView PCI DVD2 Deluxe
     - IVTV16 ffac:0600

   * - 16
     - Yuan MPC622
     - IVTV16 ff01:d998

   * - 17
     - Digital Cowboy DCT-MTVP1
     - IVTV16 1461:bfff

   * - 18
     - Yuan PG600-2, GotView PCI DVD Lite
     - IVTV16 ffab:0600, IVTV16 ffad:0600

   * - 19
     - Club3D ZAP-TV1x01
     - IVTV16 ffab:0600

   * - 20
     - AVerTV MCE 116 Plus
     - IVTV16 1461:c439

   * - 21
     - ASUS Falcon2
     - IVTV16 1043:4b66, IVTV16 1043:462e, IVTV16 1043:4b2e

   * - 22
     - AVerMedia PVR-150 Plus / AVerTV M113 Partsnic (Daewoo) Tuner
     - IVTV16 1461:c034, IVTV16 1461:c035

   * - 23
     - AVerMedia EZMaker PCI Deluxe
     - IVTV16 1461:c03f

   * - 24
     - AVerMedia M104
     - IVTV16 1461:c136

   * - 25
     - Buffalo PC-MV5L/PCI
     - IVTV16 1154:052b

   * - 26
     - AVerMedia UltraTV 1500 MCE / AVerTV M113 Philips Tuner
     - IVTV16 1461:c019, IVTV16 1461:c01b

   * - 27
     - Sony VAIO Giga Pocket (ENX Kikyou)
     - IVTV16 104d:813d

   * - 28
     - Hauppauge WinTV PVR-350 (V1)
     - IVTV16 104d:813d

   * - 29
     - Yuan MPG600GR, Kuroutoshikou CX23416GYC-STVLP (no GR)
     - IVTV16 104d:813d

   * - 30
     - Yuan MPG600GR, Kuroutoshikou CX23416GYC-STVLP (no GR/YCS)
     - IVTV16 104d:813d


code:
.. SPDX-License-Identifier: GPL-2.0

The ivtv driver
===============

Author: Hans Verkuil <hverkuil@xs4all.nl>

This is a v4l2 device driver for the Conexant cx23415/6 MPEG encoder/decoder.
The cx23415 can do both encoding and decoding, the cx23416 can only do MPEG
encoding. Currently the only card featuring full decoding support is the
Hauppauge PVR-350.

.. note::

   #) This driver requires the latest encoder firmware (version 2.06.039, size
      376836 bytes). Get the firmware from here:

      https://linuxtv.org/downloads/firmware/#conexant

   #) 'normal' TV applications do not work with this driver, you need
      an application that can handle MPEG input such as mplayer, xine, MythTV,
      etc.

The primary goal of the IVTV project is to provide a "clean room" Linux
Open Source driver implementation for video capture cards based on the
iCompression iTVC15 or Conexant CX23415/CX23416 MPEG Codec.

Features
--------

 * Hardware mpeg2 capture of broadcast video (and sound) via the tuner or
   S-Video/Composite and audio line-in.
 * Hardware mpeg2 capture of FM radio where hardware support exists
 * Supports NTSC, PAL, SECAM with stereo sound
 * Supports SAP and bilingual transmissions.
 * Supports raw VBI (closed captions and teletext).
 * Supports sliced VBI (closed captions and teletext) and is able to insert
   this into the captured MPEG stream.
 * Supports raw YUV and PCM input.

Additional features for the PVR-350 (CX23415 based)
---------------------------------------------------

 * Provides hardware mpeg2 playback
 * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the
   video signal)
 * Provides a framebuffer (allowing X applications to appear on the video
   device)
 * Supports raw YUV output.

IMPORTANT: In case of problems first read this page:
	https://help.ubuntu.com/community/Install_IVTV_Troubleshooting

See also
--------

https://linuxtv.org

IRC
---

irc://irc.freenode.net/#v4l

----------------------------------------------------------

Devices
-------

A maximum of 12 ivtv boards are allowed at the moment.

Cards that don't have a video output capability (i.e. non PVR350 cards)
lack the vbi8, vbi16, video16 and video48 devices. They also do not
support the framebuffer device /dev/fbx for OSD.

The radio0 device may or may not be present, depending on whether the
card has a radio tuner or not.

Here is a list of the base v4l devices:

.. code-block:: none

	crw-rw----    1 root     video     81,   0 Jun 19 22:22 /dev/video0
	crw-rw----    1 root     video     81,  16 Jun 19 22:22 /dev/video16
	crw-rw----    1 root     video     81,  24 Jun 19 22:22 /dev/video24
	crw-rw----    1 root     video     81,  32 Jun 19 22:22 /dev/video32
	crw-rw----    1 root     video     81,  48 Jun 19 22:22 /dev/video48
	crw-rw----    1 root     video     81,  64 Jun 19 22:22 /dev/radio0
	crw-rw----    1 root     video     81, 224 Jun 19 22:22 /dev/vbi0
	crw-rw----    1 root     video     81, 228 Jun 19 22:22 /dev/vbi8
	crw-rw----    1 root     video     81, 232 Jun 19 22:22 /dev/vbi16

Base devices
------------

For every extra card you have the numbers increased by one. For example,
/dev/video0 is listed as the 'base' encoding capture device so we have:

- /dev/video0  is the encoding capture device for the first card (card 0)
- /dev/video1  is the encoding capture device for the second card (card 1)
- /dev/video2  is the encoding capture device for the third card (card 2)

Note that if the first card doesn't have a feature (eg no decoder, so no
video16, the second card will still use video17. The simple rule is 'add
the card number to the base device number'. If you have other capture
cards (e.g. WinTV PCI) that are detected first, then you have to tell
the ivtv module about it so that it will start counting at 1 (or 2, or
whatever). Otherwise the device numbers can get confusing. The ivtv
'ivtv_first_minor' module option can be used for that.

- /dev/video0

  The encoding capture device(s).

  Read-only.

  Reading from this device gets you the MPEG1/2 program stream.
  Example:

  .. code-block:: none

	cat /dev/video0 > my.mpg (you need to hit ctrl-c to exit)

- /dev/video16

  The decoder output device(s)

  Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.

  An mpeg2 stream sent to this device will appear on the selected video
  display, audio will appear on the line-out/audio out.  It is only
  available for cards that support video out. Example:

  .. code-block:: none

	cat my.mpg >/dev/video16

- /dev/video24

  The raw audio capture device(s).

  Read-only

  The raw audio PCM stereo stream from the currently selected
  tuner or audio line-in.  Reading from this device results in a raw
  (signed 16 bit Little Endian, 48000 Hz, stereo pcm) capture.
  This device only captures audio. This should be replaced by an ALSA
  device in the future.
  Note that there is no corresponding raw audio output device, this is
  not supported in the decoder firmware.

- /dev/video32

  The raw video capture device(s)

  Read-only

  The raw YUV video output from the current video input. The YUV format
  is a 16x16 linear tiled NV12 format (V4L2_PIX_FMT_NV12_16L16)

  Note that the YUV and PCM streams are not synchronized, so they are of
  limited use.

- /dev/video48

  The raw video display device(s)

  Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.

  Writes a YUV stream to the decoder of the card.

- /dev/radio0

  The radio tuner device(s)

  Cannot be read or written.

  Used to enable the radio tuner and tune to a frequency. You cannot
  read or write audio streams with this device.  Once you use this
  device to tune the radio, use /dev/video24 to read the raw pcm stream
  or /dev/video0 to get an mpeg2 stream with black video.

- /dev/vbi0

  The 'vertical blank interval' (Teletext, CC, WSS etc) capture device(s)

  Read-only

  Captures the raw (or sliced) video data sent during the Vertical Blank
  Interval. This data is used to encode teletext, closed captions, VPS,
  widescreen signalling, electronic program guide information, and other
  services.

- /dev/vbi8

  Processed vbi feedback device(s)

  Read-only. Only present if the MPEG decoder (i.e. CX23415) exists.

  The sliced VBI data embedded in an MPEG stream is reproduced on this
  device. So while playing back a recording on /dev/video16, you can
  read the embedded VBI data from /dev/vbi8.

- /dev/vbi16

  The vbi 'display' device(s)

  Write-only. Only present if the MPEG decoder (i.e. CX23415) exists.

  Can be used to send sliced VBI data to the video-out connector.


code:
.. SPDX-License-Identifier: GPL-2.0

Firmware files for lmedm04 cards
================================

To extract firmware for the DM04/QQBOX you need to copy the
following file(s) to this directory.

For DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
-------------------------------------------

The Sharp 7395 driver can be found in windows/system32/drivers

US2A0D.sys (dated 17 Mar 2009)

and run:

.. code-block:: none

	scripts/get_dvb_firmware lme2510c_s7395

will produce dvb-usb-lme2510c-s7395.fw

An alternative but older firmware can be found on the driver
disk DVB-S_EN_3.5A in BDADriver/driver

LMEBDA_DVBS7395C.sys (dated 18 Jan 2008)

and run:

.. code-block:: none

	./get_dvb_firmware lme2510c_s7395_old

will produce dvb-usb-lme2510c-s7395.fw

The LG firmware can be found on the driver
disk DM04+_5.1A[LG] in BDADriver/driver

For DM04 LME2510 (LG Tuner)
---------------------------

LMEBDA_DVBS.sys (dated 13 Nov 2007)

and run:

.. code-block:: none

	./get_dvb_firmware lme2510_lg

will produce dvb-usb-lme2510-lg.fw

Other LG firmware can be extracted manually from US280D.sys
only found in windows/system32/drivers

dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw

For DM04 LME2510C (LG Tuner)
----------------------------

.. code-block:: none

	dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw

The Sharp 0194 tuner driver can be found in windows/system32/drivers

US290D.sys (dated 09 Apr 2009)

For LME2510
-----------

.. code-block:: none

	dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw

For LME2510C
------------

.. code-block:: none

	dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw

The m88rs2000 tuner driver can be found in windows/system32/drivers

US2B0D.sys (dated 29 Jun 2010)

.. code-block:: none

	dd if=US2B0D.sys ibs=1 skip=34432 count=3871 of=dvb-usb-lme2510c-rs2000.fw

We need to modify id of rs2000 firmware or it will warm boot id 3344:1120.

.. code-block:: none

	echo -ne \\xF0\\x22 | dd conv=notrunc bs=1 count=2 seek=266 of=dvb-usb-lme2510c-rs2000.fw

Copy the firmware file(s) to /lib/firmware


code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: <isonum.txt>

Vaio Picturebook Motion Eye Camera Driver
=========================================

Copyright |copy| 2001-2004 Stelian Pop <stelian@popies.net>

Copyright |copy| 2001-2002 Alcôve <www.alcove.com>

Copyright |copy| 2000 Andrew Tridgell <tridge@samba.org>

This driver enable the use of video4linux compatible applications with the
Motion Eye camera. This driver requires the "Sony Laptop Extras" driver (which
can be found in the "Misc devices" section of the kernel configuration utility)
to be compiled and installed (using its "camera=1" parameter).

It can do at maximum 30 fps @ 320x240 or 15 fps @ 640x480.

Grabbing is supported in packed YUV colorspace only.

MJPEG hardware grabbing is supported via a private API (see below).

Hardware supported
------------------

This driver supports the 'second' version of the MotionEye camera :)

The first version was connected directly on the video bus of the Neomagic
video card and is unsupported.

The second one, made by Kawasaki Steel is fully supported by this
driver (PCI vendor/device is 0x136b/0xff01)

The third one, present in recent (more or less last year) Picturebooks
(C1M* models), is not supported. The manufacturer has given the specs
to the developers under a NDA (which allows the development of a GPL
driver however), but things are not moving very fast (see
http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011).

There is a forth model connected on the USB bus in TR1* Vaio laptops.
This camera is not supported at all by the current driver, in fact
little information if any is available for this camera
(USB vendor/device is 0x054c/0x0107).

Driver options
--------------

Several options can be passed to the meye driver using the standard
module argument syntax (<param>=<value> when passing the option to the
module or meye.<param>=<value> on the kernel boot line when meye is
statically linked into the kernel). Those options are:

.. code-block:: none

	gbuffers:	number of capture buffers, default is 2 (32 max)

	gbufsize:	size of each capture buffer, default is 614400

	video_nr:	video device to register (0 = /dev/video0, etc)

Module use
----------

In order to automatically load the meye module on use, you can put those lines
in your /etc/modprobe.d/meye.conf file:

.. code-block:: none

	alias char-major-81 videodev
	alias char-major-81-0 meye
	options meye gbuffers=32

Usage:
------

.. code-block:: none

	xawtv >= 3.49 (<http://bytesex.org/xawtv/>)
		for display and uncompressed video capture:

			xawtv -c /dev/video0 -geometry 640x480
				or
			xawtv -c /dev/video0 -geometry 320x240

	motioneye (<http://popies.net/meye/>)
		for getting ppm or jpg snapshots, mjpeg video

Bugs / Todo
-----------

- 'motioneye' still uses the meye private v4l1 API extensions.


code:
.. SPDX-License-Identifier: GPL-2.0

Firewire driver
===============

The media subsystem also provides a firewire driver for digital TV:

=======  =====================
Driver   Name
=======  =====================
firedtv  FireDTV and FloppyDTV
=======  =====================

Test drivers
============

In order to test userspace applications, there's a number of virtual
drivers, with provide test functionality, simulating real hardware
devices:

=======  ======================================
Driver   Name
=======  ======================================
vicodec  Virtual Codec Driver
vim2m    Virtual Memory-to-Memory Driver
vimc     Virtual Media Controller Driver (VIMC)
vivid    Virtual Video Test Driver
=======  ======================================


code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: <isonum.txt>

OMAP 3 Image Signal Processor (ISP) driver
==========================================

Copyright |copy| 2010 Nokia Corporation

Copyright |copy| 2009 Texas Instruments, Inc.

Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sakari Ailus <sakari.ailus@iki.fi>, David Cohen <dacohen@gmail.com>

Introduction
------------

This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP)
driver located under drivers/media/platform/ti/omap3isp. The original driver was
written by Texas Instruments but since that it has been rewritten (twice) at
Nokia.

The driver has been successfully used on the following versions of OMAP 3:

- 3430
- 3530
- 3630

The driver implements V4L2, Media controller and v4l2_subdev interfaces.
Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel
are supported.

Split to subdevs
----------------

The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP
having one subdev to represent it. Each of the subdevs provide a V4L2 subdev
interface to userspace.

- OMAP3 ISP CCP2
- OMAP3 ISP CSI2a
- OMAP3 ISP CCDC
- OMAP3 ISP preview
- OMAP3 ISP resizer
- OMAP3 ISP AEWB
- OMAP3 ISP AF
- OMAP3 ISP histogram

Each possible link in the ISP is modelled by a link in the Media controller
interface. For an example program see [#]_.

Controlling the OMAP 3 ISP
--------------------------

In general, the settings given to the OMAP 3 ISP take effect at the beginning
of the following frame. This is done when the module becomes idle during the
vertical blanking period on the sensor. In memory-to-memory operation the pipe
is run one frame at a time. Applying the settings is done between the frames.

All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver,
insist on receiving complete frames. Sensors must thus never send the ISP
partial frames.

Autoidle does have issues with some ISP blocks on the 3430, at least.
Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle
is non-zero.

Technical reference manuals (TRMs) and other documentation
----------------------------------------------------------

OMAP 3430 TRM:
<URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip>
Referenced 2011-03-05.

OMAP 35xx TRM:
<URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05.

OMAP 3630 TRM:
<URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip>
Referenced 2011-03-05.

DM 3730 TRM:
<URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06.

References
----------

.. [#] http://git.ideasonboard.org/?p=media-ctl.git;a=summary


code:
.. SPDX-License-Identifier: GPL-2.0

OMAP4 ISS Driver
================

Author: Sergio Aguirre <sergio.a.aguirre@gmail.com>

Copyright (C) 2012, Texas Instruments

Introduction
------------

The OMAP44XX family of chips contains the Imaging SubSystem (a.k.a. ISS),
Which contains several components that can be categorized in 3 big groups:

- Interfaces (2 Interfaces: CSI2-A & CSI2-B/CCP2)
- ISP (Image Signal Processor)
- SIMCOP (Still Image Coprocessor)

For more information, please look in [#f1]_ for latest version of:
"OMAP4430 Multimedia Device Silicon Revision 2.x"

As of Revision AB, the ISS is described in detail in section 8.

This driver is supporting **only** the CSI2-A/B interfaces for now.

It makes use of the Media Controller framework [#f2]_, and inherited most of the
code from OMAP3 ISP driver (found under drivers/media/platform/ti/omap3isp/\*),
except that it doesn't need an IOMMU now for ISS buffers memory mapping.

Supports usage of MMAP buffers only (for now).

Tested platforms
----------------

- OMAP4430SDP, w/ ES2.1 GP & SEVM4430-CAM-V1-0 (Contains IMX060 & OV5640, in
  which only the last one is supported, outputting YUV422 frames).

- TI Blaze MDP, w/ OMAP4430 ES2.2 EMU (Contains 1 IMX060 & 2 OV5650 sensors, in
  which only the OV5650 are supported, outputting RAW10 frames).

- PandaBoard, Rev. A2, w/ OMAP4430 ES2.1 GP & OV adapter board, tested with
  following sensors:
  * OV5640
  * OV5650

- Tested on mainline kernel:

	http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary

  Tag: v3.3 (commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7)

File list
---------
drivers/staging/media/omap4iss/
include/linux/platform_data/media/omap4iss.h

References
----------

.. [#f1] http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?navigationId=12037&templateId=6123#62
.. [#f2] http://lwn.net/Articles/420485/


code:
.. SPDX-License-Identifier: GPL-2.0

Opera firmware
==============

Author: Marco Gittler <g.marco@freenet.de>

To extract the firmware for the Opera DVB-S1 USB-Box
you need to copy the files:

2830SCap2.sys
2830SLoad2.sys

from the windriver disk into this directory.

Then run:

.. code-block:: none

	scripts/get_dvb_firmware opera1

and after that you have 2 files:

dvb-usb-opera-01.fw
dvb-usb-opera1-fpga-01.fw

in here.

Copy them into /lib/firmware/ .

After that the driver can load the firmware
(if you have enabled firmware loading
in kernel config and have hotplug running).


code:
.. SPDX-License-Identifier: GPL-2.0

Other USB cards list
====================

================  ======================================  =====================
Driver            Card name                               USB IDs
================  ======================================  =====================
airspy		  Airspy				  1d50:60a1
dvb-as102	  Abilis Systems DVB-Titan		  1BA6:0001
dvb-as102	  PCTV Systems picoStick (74e)		  2013:0246
dvb-as102	  Elgato EyeTV DTT Deluxe		  0fd9:002c
dvb-as102	  nBox DVB-T Dongle			  0b89:0007
dvb-as102	  Sky IT Digital Key (green led)	  2137:0001
b2c2-flexcop-usb  Technisat/B2C2 FlexCop II/IIb/III	  0af7:0101
		  Digital TV
cpia2		  Vision's CPiA2 cameras		  0553:0100, 0553:0140,
		  such as the Digital Blue QX5		  0553:0151
go7007		  WIS GO7007 MPEG encoder		  1943:a250, 093b:a002,
							  093b:a004, 0eb1:6666,
							  0eb1:6668
hackrf		  HackRF Software Decoder Radio		  1d50:6089
hdpvr		  Hauppauge HD PVR			  2040:4900, 2040:4901,
							  2040:4902, 2040:4982,
							  2040:4903
msi2500		  Mirics MSi3101 SDR Dongle		  1df7:2500, 2040:d300
pvrusb2		  Hauppauge WinTV-PVR USB2		  2040:2900, 2040:2950,
							  2040:2400, 1164:0622,
							  1164:0602, 11ba:1003,
							  11ba:1001, 2040:7300,
							  2040:7500, 2040:7501,
							  0ccd:0039, 2040:7502,
							  2040:7510
pwc		  Creative Webcam 5			  041E:400C
pwc		  Creative Webcam Pro Ex		  041E:4011
pwc		  Logitech QuickCam 3000 Pro		  046D:08B0
pwc		  Logitech QuickCam Notebook Pro	  046D:08B1
pwc		  Logitech QuickCam 4000 Pro		  046D:08B2
pwc		  Logitech QuickCam Zoom (old model)	  046D:08B3
pwc		  Logitech QuickCam Zoom (new model)	  046D:08B4
pwc		  Logitech QuickCam Orbit/Sphere	  046D:08B5
pwc		  Logitech/Cisco VT Camera		  046D:08B6
pwc		  Logitech ViewPort AV 100		  046D:08B7
pwc		  Logitech QuickCam			  046D:08B8
pwc		  Philips PCA645VC			  0471:0302
pwc		  Philips PCA646VC			  0471:0303
pwc		  Askey VC010 type 2			  0471:0304
pwc		  Philips PCVC675K (Vesta)		  0471:0307
pwc		  Philips PCVC680K (Vesta Pro)		  0471:0308
pwc		  Philips PCVC690K (Vesta Pro Scan)	  0471:030C
pwc		  Philips PCVC730K (ToUCam Fun),	  0471:0310
		  PCVC830 (ToUCam II)
pwc		  Philips PCVC740K (ToUCam Pro),	  0471:0311
		  PCVC840 (ToUCam II)
pwc		  Philips PCVC750K (ToUCam Pro Scan)	  0471:0312
pwc		  Philips PCVC720K/40 (ToUCam XS)	  0471:0313
pwc		  Philips SPC 900NC			  0471:0329
pwc		  Philips SPC 880NC			  0471:032C
pwc		  Sotec Afina Eye			  04CC:8116
pwc		  Samsung MPC-C10			  055D:9000
pwc		  Samsung MPC-C30			  055D:9001
pwc		  Samsung SNC-35E (Ver3.0)		  055D:9002
pwc		  Askey VC010 type 1			  069A:0001
pwc		  AME Co. Afina Eye			  06BE:8116
pwc		  Visionite VCS-UC300			  0d81:1900
pwc		  Visionite VCS-UM100			  0d81:1910
s2255drv	  Sensoray 2255				  1943:2255, 1943:2257
stk1160		  STK1160 USB video capture dongle	  05e1:0408
stkwebcam	  Syntek DC1125				  174f:a311, 05e1:0501
dvb-ttusb-budget  Technotrend/Hauppauge Nova-USB devices  0b48:1003, 0b48:1004,
							  0b48:1005
dvb-ttusb_dec	  Technotrend/Hauppauge MPEG decoder	  0b48:1006
		  DEC3000-s
dvb-ttusb_dec	  Technotrend/Hauppauge MPEG decoder	  0b48:1007
dvb-ttusb_dec	  Technotrend/Hauppauge MPEG decoder	  0b48:1008
		  DEC2000-t
dvb-ttusb_dec	  Technotrend/Hauppauge MPEG decoder
		  DEC2540-t				  0b48:1009
usbtv		  Fushicai USBTV007 Audio-Video Grabber	  1b71:3002, 1f71:3301,
							  1f71:3306
zr364xx		  USB ZR364XX Camera			  08ca:0109, 041e:4024,
							  0d64:0108, 0546:3187,
							  0d64:3108, 0595:4343,
							  0bb0:500d, 0feb:2004,
							  055f:b500, 08ca:2062,
							  052b:1a18, 04c8:0729,
							  04f2:a208, 0784:0040,
							  06d6:0034, 0a17:0062,
							  06d6:003b, 0a17:004e,
							  041e:405d, 08ca:2102,
							  06d6:003d
================  ======================================  =====================


code:
.. SPDX-License-Identifier: GPL-2.0

PCI drivers
===========

The PCI boards are identified by an identification called PCI ID. The PCI ID
is actually composed by two parts:

	- Vendor ID and device ID;
	- Subsystem ID and Subsystem device ID;

The ``lspci -nn`` command allows identifying the vendor/device PCI IDs:

.. code-block:: none
   :emphasize-lines: 3

    $ lspci -nn
    ...
    00:0a.0 Multimedia controller [0480]: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder [1131:7133] (rev d1)
    00:0b.0 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 11)
    01:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23887/8 PCIe Broadcast Audio and Video Decoder with 3D Comb [14f1:8880] (rev 0f)
    02:01.0 Multimedia video controller [0400]: Internext Compression Inc iTVC15 (CX23415) Video Decoder [4444:0803] (rev 01)
    02:02.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder [14f1:5b7a]
    02:03.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 11)
    ...

The subsystem IDs can be obtained using ``lspci -vn``

.. code-block:: none
   :emphasize-lines: 4

    $ lspci -vn
    ...
	00:0a.0 0480: 1131:7133 (rev d1)
		Subsystem: 1461:f01d
		Flags: bus master, medium devsel, latency 32, IRQ 209
		Memory at e2002000 (32-bit, non-prefetchable) [size=2K]
		Capabilities: [40] Power Management version 2
    ...

At the above example, the first card uses the ``saa7134`` driver, and
has a vendor/device PCI ID equal to ``1131:7133`` and a PCI subsystem
ID equal to ``1461:f01d`` (see :doc:`Saa7134 card list<saa7134-cardlist>`).

Unfortunately, sometimes the same PCI subsystem ID is used by different
products. So, several media drivers allow passing a ``card=`` parameter,
in order to setup a card number that would match the correct settings for
an specific board.

The current supported PCI/PCIe cards (not including staging drivers) are
listed below\ [#]_.

.. [#] some of the drivers have sub-drivers, not shown at this table

================  ========================================================
Driver            Name
================  ========================================================
altera-ci         Altera FPGA based CI module
b2c2-flexcop-pci  Technisat/B2C2 Air/Sky/Cable2PC PCI
bt878             DVB/ATSC Support for bt878 based TV cards
bttv              BT8x8 Video For Linux
cobalt            Cisco Cobalt
cx18              Conexant cx23418 MPEG encoder
cx23885           Conexant cx23885 (2388x successor)
cx25821           Conexant cx25821
cx88xx            Conexant 2388x (bt878 successor)
ddbridge          Digital Devices bridge
dm1105            SDMC DM1105 based PCI cards
dt3155            DT3155 frame grabber
dvb-ttpci         AV7110 cards
earth-pt1         PT1 cards
earth-pt3         Earthsoft PT3 cards
hexium_gemini     Hexium Gemini frame grabber
hexium_orion      Hexium HV-PCI6 and Orion frame grabber
hopper            HOPPER based cards
ipu3-cio2         Intel ipu3-cio2 driver
ivtv              Conexant cx23416/cx23415 MPEG encoder/decoder
ivtvfb            Conexant cx23415 framebuffer
mantis            MANTIS based cards
meye              Sony Vaio Picturebook Motion Eye
mxb               Siemens-Nixdorf 'Multimedia eXtension Board'
netup-unidvb      NetUP Universal DVB card
ngene             Micronas nGene
pluto2            Pluto2 cards
saa7134           Philips SAA7134
saa7164           NXP SAA7164
smipcie           SMI PCIe DVBSky cards
solo6x10          Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)
sta2x11_vip       STA2X11 VIP Video For Linux
tw5864            Techwell TW5864 video/audio grabber and encoder
tw686x            Intersil/Techwell TW686x
tw68              Techwell tw68x Video For Linux
zoran             Zoran-36057/36067 JPEG codec
================  ========================================================

Some of those drivers support multiple devices, as shown at the card
lists below:

.. toctree::
	:maxdepth: 1

	bttv-cardlist
	cx18-cardlist
	cx23885-cardlist
	cx88-cardlist
	ivtv-cardlist
	saa7134-cardlist
	saa7164-cardlist
	zoran-cardlist


code:
.. SPDX-License-Identifier: GPL-2.0

Philips webcams (pwc driver)
============================

This file contains some additional information for the Philips and OEM webcams.
E-mail: webcam@smcc.demon.nl                        Last updated: 2004-01-19
Site: http://www.smcc.demon.nl/webcam/

As of this moment, the following cameras are supported:

 * Philips PCA645
 * Philips PCA646
 * Philips PCVC675
 * Philips PCVC680
 * Philips PCVC690
 * Philips PCVC720/40
 * Philips PCVC730
 * Philips PCVC740
 * Philips PCVC750
 * Askey VC010
 * Creative Labs Webcam 5
 * Creative Labs Webcam Pro Ex
 * Logitech QuickCam 3000 Pro
 * Logitech QuickCam 4000 Pro
 * Logitech QuickCam Notebook Pro
 * Logitech QuickCam Zoom
 * Logitech QuickCam Orbit
 * Logitech QuickCam Sphere
 * Samsung MPC-C10
 * Samsung MPC-C30
 * Sotec Afina Eye
 * AME CU-001
 * Visionite VCS-UM100
 * Visionite VCS-UC300

The main webpage for the Philips driver is at the address above. It contains
a lot of extra information, a FAQ, and the binary plugin 'PWCX'. This plugin
contains decompression routines that allow you to use higher image sizes and
framerates; in addition the webcam uses less bandwidth on the USB bus (handy
if you want to run more than 1 camera simultaneously). These routines fall
under a NDA, and may therefore not be distributed as source; however, its use
is completely optional.

You can build this code either into your kernel, or as a module. I recommend
the latter, since it makes troubleshooting a lot easier. The built-in
microphone is supported through the USB Audio class.

When you load the module you can set some default settings for the
camera; some programs depend on a particular image-size or -format and
don't know how to set it properly in the driver. The options are:

size
   Can be one of 'sqcif', 'qsif', 'qcif', 'sif', 'cif' or
   'vga', for an image size of resp. 128x96, 160x120, 176x144,
   320x240, 352x288 and 640x480 (of course, only for those cameras that
   support these resolutions).

fps
   Specifies the desired framerate. Is an integer in the range of 4-30.

fbufs
   This parameter specifies the number of internal buffers to use for storing
   frames from the cam. This will help if the process that reads images from
   the cam is a bit slow or momentarily busy. However, on slow machines it
   only introduces lag, so choose carefully. The default is 3, which is
   reasonable. You can set it between 2 and 5.

mbufs
   This is an integer between 1 and 10. It will tell the module the number of
   buffers to reserve for mmap(), VIDIOCCGMBUF, VIDIOCMCAPTURE and friends.
   The default is 2, which is adequate for most applications (double
   buffering).

   Should you experience a lot of 'Dumping frame...' messages during
   grabbing with a tool that uses mmap(), you might want to increase if.
   However, it doesn't really buffer images, it just gives you a bit more
   slack when your program is behind. But you need a multi-threaded or
   forked program to really take advantage of these buffers.

   The absolute maximum is 10, but don't set it too high!  Every buffer takes
   up 460 KB of RAM, so unless you have a lot of memory setting this to
   something more than 4 is an absolute waste.  This memory is only
   allocated during open(), so nothing is wasted when the camera is not in
   use.

power_save
   When power_save is enabled (set to 1), the module will try to shut down
   the cam on close() and re-activate on open(). This will save power and
   turn off the LED. Not all cameras support this though (the 645 and 646
   don't have power saving at all), and some models don't work either (they
   will shut down, but never wake up). Consider this experimental. By
   default this option is disabled.

compression (only useful with the plugin)
   With this option you can control the compression factor that the camera
   uses to squeeze the image through the USB bus. You can set the
   parameter between 0 and 3::

     0 = prefer uncompressed images; if the requested mode is not available
	 in an uncompressed format, the driver will silently switch to low
	 compression.
     1 = low compression.
     2 = medium compression.
     3 = high compression.

   High compression takes less bandwidth of course, but it could also
   introduce some unwanted artefacts. The default is 2, medium compression.
   See the FAQ on the website for an overview of which modes require
   compression.

   The compression parameter does not apply to the 645 and 646 cameras
   and OEM models derived from those (only a few). Most cams honour this
   parameter.

leds
   This settings takes 2 integers, that define the on/off time for the LED
   (in milliseconds). One of the interesting things that you can do with
   this is let the LED blink while the camera is in use. This::

     leds=500,500

   will blink the LED once every second. But with::

     leds=0,0

   the LED never goes on, making it suitable for silent surveillance.

   By default the camera's LED is on solid while in use, and turned off
   when the camera is not used anymore.

   This parameter works only with the ToUCam range of cameras (720, 730, 740,
   750) and OEMs. For other cameras this command is silently ignored, and
   the LED cannot be controlled.

   Finally: this parameters does not take effect UNTIL the first time you
   open the camera device. Until then, the LED remains on.

dev_hint
   A long standing problem with USB devices is their dynamic nature: you
   never know what device a camera gets assigned; it depends on module load
   order, the hub configuration, the order in which devices are plugged in,
   and the phase of the moon (i.e. it can be random). With this option you
   can give the driver a hint as to what video device node (/dev/videoX) it
   should use with a specific camera. This is also handy if you have two
   cameras of the same model.

   A camera is specified by its type (the number from the camera model,
   like PCA645, PCVC750VC, etc) and optionally the serial number (visible
   in /sys/kernel/debug/usb/devices). A hint consists of a string with the
   following format::

      [type[.serialnumber]:]node

   The square brackets mean that both the type and the serialnumber are
   optional, but a serialnumber cannot be specified without a type (which
   would be rather pointless). The serialnumber is separated from the type
   by a '.'; the node number by a ':'.

   This somewhat cryptic syntax is best explained by a few examples::

     dev_hint=3,5              The first detected cam gets assigned
			       /dev/video3, the second /dev/video5. Any
			       other cameras will get the first free
			       available slot (see below).

     dev_hint=645:1,680:2      The PCA645 camera will get /dev/video1,
			       and a PCVC680 /dev/video2.

     dev_hint=645.0123:3,645.4567:0	The PCA645 camera with serialnumber
					0123 goes to /dev/video3, the same
					camera model with the 4567 serial
					gets /dev/video0.

     dev_hint=750:1,4,5,6       The PCVC750 camera will get /dev/video1, the
				next 3 Philips cams will use /dev/video4
				through /dev/video6.

   Some points worth knowing:

   - Serialnumbers are case sensitive and must be written full, including
     leading zeroes (it's treated as a string).
   - If a device node is already occupied, registration will fail and
     the webcam is not available.
   - You can have up to 64 video devices; be sure to make enough device
     nodes in /dev if you want to spread the numbers.
     After /dev/video9 comes /dev/video10 (not /dev/videoA).
   - If a camera does not match any dev_hint, it will simply get assigned
     the first available device node, just as it used to be.

trace
   In order to better detect problems, it is now possible to turn on a
   'trace' of some of the calls the module makes; it logs all items in your
   kernel log at debug level.

   The trace variable is a bitmask; each bit represents a certain feature.
   If you want to trace something, look up the bit value(s) in the table
   below, add the values together and supply that to the trace variable.

   ====== ======= ================================================ =======
   Value  Value   Description					   Default
   (dec)  (hex)
   ====== ======= ================================================ =======
       1    0x1   Module initialization; this will log messages       On
		  while loading and unloading the module

       2    0x2   probe() and disconnect() traces                     On

       4    0x4   Trace open() and close() calls                      Off

       8    0x8   read(), mmap() and associated ioctl() calls         Off

      16   0x10   Memory allocation of buffers, etc.                  Off

      32   0x20   Showing underflow, overflow and Dumping frame       On
		  messages

      64   0x40   Show viewport and image sizes                       Off

     128   0x80   PWCX debugging                                      Off
   ====== ======= ================================================ =======

   For example, to trace the open() & read() functions, sum 8 + 4 = 12,
   so you would supply trace=12 during insmod or modprobe. If
   you want to turn the initialization and probing tracing off, set trace=0.
   The default value for trace is 35 (0x23).

Example::

     # modprobe pwc size=cif fps=15 power_save=1

The fbufs, mbufs and trace parameters are global and apply to all connected
cameras. Each camera has its own set of buffers.

size and fps only specify defaults when you open() the device; this is to
accommodate some tools that don't set the size. You can change these
settings after open() with the Video4Linux ioctl() calls. The default of
defaults is QCIF size at 10 fps.

The compression parameter is semiglobal; it sets the initial compression
preference for all camera's, but this parameter can be set per camera with
the VIDIOCPWCSCQUAL ioctl() call.

All parameters are optional.


code:
.. SPDX-License-Identifier: GPL-2.0

Platform drivers
================

There are several drivers that are focused on providing support for
functionality that are already included at the main board, and don't
use neither USB nor PCI bus. Those drivers are called platform
drivers, and are very popular on embedded devices.

The current supported of platform drivers (not including staging drivers) are
listed below

=================  ============================================================
Driver             Name
=================  ============================================================
am437x-vpfe        TI AM437x VPFE
aspeed-video       Aspeed AST2400 and AST2500
atmel-isc          ATMEL Image Sensor Controller (ISC)
atmel-isi          ATMEL Image Sensor Interface (ISI)
c8sectpfe          SDR platform devices
c8sectpfe          SDR platform devices
cafe_ccic          Marvell 88ALP01 (Cafe) CMOS Camera Controller
cdns-csi2rx        Cadence MIPI-CSI2 RX Controller
cdns-csi2tx        Cadence MIPI-CSI2 TX Controller
coda-vpu           Chips&Media Coda multi-standard codec IP
dm355_ccdc         TI DM355 CCDC video capture
dm644x_ccdc        TI DM6446 CCDC video capture
exynos-fimc-is     EXYNOS4x12 FIMC-IS (Imaging Subsystem)
exynos-fimc-lite   EXYNOS FIMC-LITE camera interface
exynos-gsc         Samsung Exynos G-Scaler
exy                Samsung S5P/EXYNOS4 SoC series Camera Subsystem
fsl-viu            Freescale VIU
imx-pxp            i.MX Pixel Pipeline (PXP)
isdf               TI DM365 ISIF video capture
mmp_camera         Marvell Armada 610 integrated camera controller
mtk_jpeg           Mediatek JPEG Codec
mtk-mdp            Mediatek MDP
mtk-vcodec-dec     Mediatek Video Codec
mtk-vpu            Mediatek Video Processor Unit
mx2_emmaprp        MX2 eMMa-PrP
omap3-isp          OMAP 3 Camera
omap-vout          OMAP2/OMAP3 V4L2-Display
pxa_camera         PXA27x Quick Capture Interface
qcom-camss         Qualcomm V4L2 Camera Subsystem
rcar-csi2          R-Car MIPI CSI-2 Receiver
rcar_drif          Renesas Digital Radio Interface (DRIF)
rcar-fcp           Renesas Frame Compression Processor
rcar_fdp1          Renesas Fine Display Processor
rcar_jpu           Renesas JPEG Processing Unit
rcar-vin           R-Car Video Input (VIN)
renesas-ceu        Renesas Capture Engine Unit (CEU)
rockchip-rga       Rockchip Raster 2d Graphic Acceleration Unit
s3c-camif          Samsung S3C24XX/S3C64XX SoC Camera Interface
s5p-csis           S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS)
s5p-fimc           S5P/EXYNOS4 FIMC/CAMIF camera interface
s5p-g2d            Samsung S5P and EXYNOS4 G2D 2d graphics accelerator
s5p-jpeg           Samsung S5P/Exynos3250/Exynos4 JPEG codec
s5p-mfc            Samsung S5P MFC Video Codec
sh_veu             SuperH VEU mem2mem video processing
sh_vou             SuperH VOU video output
stm32-dcmi         STM32 Digital Camera Memory Interface (DCMI)
stm32-dma2d        STM32 Chrom-Art Accelerator Unit
sun4i-csi          Allwinner A10 CMOS Sensor Interface Support
sun6i-csi          Allwinner V3s Camera Sensor Interface
sun8i-di           Allwinner Deinterlace
sun8i-rotate       Allwinner DE2 rotation
ti-cal             TI Memory-to-memory multimedia devices
ti-csc             TI DVB platform devices
ti-vpe             TI VPE (Video Processing Engine)
venus-enc          Qualcomm Venus V4L2 encoder/decoder
via-camera         VIAFB camera controller
video-mux          Video Multiplexer
vpif_display       TI DaVinci VPIF V4L2-Display
vpif_capture       TI DaVinci VPIF video capture
vpss               TI DaVinci VPBE V4L2-Display
vsp1               Renesas VSP1 Video Processing Engine
xilinx-tpg         Xilinx Video Test Pattern Generator
xilinx-video       Xilinx Video IP (EXPERIMENTAL)
xilinx-vtc         Xilinx Video Timing Controller
=================  ============================================================

MMC/SDIO DVB adapters
---------------------

=======  ===========================================
Driver   Name
=======  ===========================================
smssdio  Siano SMS1xxx based MDTV via SDIO interface
=======  ===========================================


code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: <isonum.txt>

Qualcomm Camera Subsystem driver
================================

Introduction
------------

This file documents the Qualcomm Camera Subsystem driver located under
drivers/media/platform/qcom/camss.

The current version of the driver supports the Camera Subsystem found on
Qualcomm MSM8916/APQ8016 and MSM8996/APQ8096 processors.

The driver implements V4L2, Media controller and V4L2 subdev interfaces.
Camera sensor using V4L2 subdev interface in the kernel is supported.

The driver is implemented using as a reference the Qualcomm Camera Subsystem
driver for Android as found in Code Aurora [#f1]_ [#f2]_.

Qualcomm Camera Subsystem hardware
----------------------------------

The Camera Subsystem hardware found on 8x16 / 8x96 processors and supported by
the driver consists of:

- 2 / 3 CSIPHY modules. They handle the Physical layer of the CSI2 receivers.
  A separate camera sensor can be connected to each of the CSIPHY module;
- 2 / 4 CSID (CSI Decoder) modules. They handle the Protocol and Application
  layer of the CSI2 receivers. A CSID can decode data stream from any of the
  CSIPHY. Each CSID also contains a TG (Test Generator) block which can generate
  artificial input data for test purposes;
- ISPIF (ISP Interface) module. Handles the routing of the data streams from
  the CSIDs to the inputs of the VFE;
- 1 / 2 VFE (Video Front End) module(s). Contain a pipeline of image processing
  hardware blocks. The VFE has different input interfaces. The PIX (Pixel) input
  interface feeds the input data to the image processing pipeline. The image
  processing pipeline contains also a scale and crop module at the end. Three
  RDI (Raw Dump Interface) input interfaces bypass the image processing
  pipeline. The VFE also contains the AXI bus interface which writes the output
  data to memory.

Supported functionality
-----------------------

The current version of the driver supports:

- Input from camera sensor via CSIPHY;
- Generation of test input data by the TG in CSID;
- RDI interface of VFE

  - Raw dump of the input data to memory.

    Supported formats:

    - YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2 - V4L2_PIX_FMT_YUYV /
      V4L2_PIX_FMT_UYVY / V4L2_PIX_FMT_YVYU / V4L2_PIX_FMT_VYUY);
    - MIPI RAW8 (8bit Bayer RAW - V4L2_PIX_FMT_SRGGB8 /
      V4L2_PIX_FMT_SGRBG8 / V4L2_PIX_FMT_SGBRG8 / V4L2_PIX_FMT_SBGGR8);
    - MIPI RAW10 (10bit packed Bayer RAW - V4L2_PIX_FMT_SBGGR10P /
      V4L2_PIX_FMT_SGBRG10P / V4L2_PIX_FMT_SGRBG10P / V4L2_PIX_FMT_SRGGB10P /
      V4L2_PIX_FMT_Y10P);
    - MIPI RAW12 (12bit packed Bayer RAW - V4L2_PIX_FMT_SRGGB12P /
      V4L2_PIX_FMT_SGBRG12P / V4L2_PIX_FMT_SGRBG12P / V4L2_PIX_FMT_SRGGB12P).
    - (8x96 only) MIPI RAW14 (14bit packed Bayer RAW - V4L2_PIX_FMT_SRGGB14P /
      V4L2_PIX_FMT_SGBRG14P / V4L2_PIX_FMT_SGRBG14P / V4L2_PIX_FMT_SRGGB14P).

  - (8x96 only) Format conversion of the input data.

    Supported input formats:

    - MIPI RAW10 (10bit packed Bayer RAW - V4L2_PIX_FMT_SBGGR10P / V4L2_PIX_FMT_Y10P).

    Supported output formats:

    - Plain16 RAW10 (10bit unpacked Bayer RAW - V4L2_PIX_FMT_SBGGR10 / V4L2_PIX_FMT_Y10).

- PIX interface of VFE

  - Format conversion of the input data.

    Supported input formats:

    - YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2 - V4L2_PIX_FMT_YUYV /
      V4L2_PIX_FMT_UYVY / V4L2_PIX_FMT_YVYU / V4L2_PIX_FMT_VYUY).

    Supported output formats:

    - NV12/NV21 (two plane YUV 4:2:0 - V4L2_PIX_FMT_NV12 / V4L2_PIX_FMT_NV21);
    - NV16/NV61 (two plane YUV 4:2:2 - V4L2_PIX_FMT_NV16 / V4L2_PIX_FMT_NV61).
    - (8x96 only) YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2 - V4L2_PIX_FMT_YUYV /
      V4L2_PIX_FMT_UYVY / V4L2_PIX_FMT_YVYU / V4L2_PIX_FMT_VYUY).

  - Scaling support. Configuration of the VFE Encoder Scale module
    for downscalling with ratio up to 16x.

  - Cropping support. Configuration of the VFE Encoder Crop module.

- Concurrent and independent usage of two (8x96: three) data inputs -
  could be camera sensors and/or TG.

Driver Architecture and Design
------------------------------

The driver implements the V4L2 subdev interface. With the goal to model the
hardware links between the modules and to expose a clean, logical and usable
interface, the driver is split into V4L2 sub-devices as follows (8x16 / 8x96):

- 2 / 3 CSIPHY sub-devices - each CSIPHY is represented by a single sub-device;
- 2 / 4 CSID sub-devices - each CSID is represented by a single sub-device;
- 2 / 4 ISPIF sub-devices - ISPIF is represented by a number of sub-devices
  equal to the number of CSID sub-devices;
- 4 / 8 VFE sub-devices - VFE is represented by a number of sub-devices equal to
  the number of the input interfaces (3 RDI and 1 PIX for each VFE).

The considerations to split the driver in this particular way are as follows:

- representing CSIPHY and CSID modules by a separate sub-device for each module
  allows to model the hardware links between these modules;
- representing VFE by a separate sub-devices for each input interface allows
  to use the input interfaces concurrently and independently as this is
  supported by the hardware;
- representing ISPIF by a number of sub-devices equal to the number of CSID
  sub-devices allows to create linear media controller pipelines when using two
  cameras simultaneously. This avoids branches in the pipelines which otherwise
  will require a) userspace and b) media framework (e.g. power on/off
  operations) to  make assumptions about the data flow from a sink pad to a
  source pad on a single media entity.

Each VFE sub-device is linked to a separate video device node.

The media controller pipeline graph is as follows (with connected two / three
OV5645 camera sensors):

.. _qcom_camss_graph:

.. kernel-figure:: qcom_camss_graph.dot
    :alt:   qcom_camss_graph.dot
    :align: center

    Media pipeline graph 8x16

.. kernel-figure:: qcom_camss_8x96_graph.dot
    :alt:   qcom_camss_8x96_graph.dot
    :align: center

    Media pipeline graph 8x96

Implementation
--------------

Runtime configuration of the hardware (updating settings while streaming) is
not required to implement the currently supported functionality. The complete
configuration on each hardware module is applied on STREAMON ioctl based on
the current active media links, formats and controls set.

The output size of the scaler module in the VFE is configured with the actual
compose selection rectangle on the sink pad of the 'msm_vfe0_pix' entity.

The crop output area of the crop module in the VFE is configured with the actual
crop selection rectangle on the source pad of the 'msm_vfe0_pix' entity.

Documentation
-------------

APQ8016 Specification:
https://developer.qualcomm.com/download/sd410/snapdragon-410-processor-device-specification.pdf
Referenced 2016-11-24.

APQ8096 Specification:
https://developer.qualcomm.com/download/sd820e/qualcomm-snapdragon-820e-processor-apq8096sge-device-specification.pdf
Referenced 2018-06-22.

References
----------

.. [#f1] https://source.codeaurora.org/quic/la/kernel/msm-3.10/
.. [#f2] https://source.codeaurora.org/quic/la/kernel/msm-3.18/


code:
# SPDX-License-Identifier: GPL-2.0

digraph board {
	rankdir=TB
	n00000001 [label="{{<port0> 0} | msm_csiphy0\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000001:port1 -> n0000000a:port0 [style=dashed]
	n00000001:port1 -> n0000000d:port0 [style=dashed]
	n00000001:port1 -> n00000010:port0 [style=dashed]
	n00000001:port1 -> n00000013:port0 [style=dashed]
	n00000004 [label="{{<port0> 0} | msm_csiphy1\n/dev/v4l-subdev1 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000004:port1 -> n0000000a:port0 [style=dashed]
	n00000004:port1 -> n0000000d:port0 [style=dashed]
	n00000004:port1 -> n00000010:port0 [style=dashed]
	n00000004:port1 -> n00000013:port0 [style=dashed]
	n00000007 [label="{{<port0> 0} | msm_csiphy2\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000007:port1 -> n0000000a:port0 [style=dashed]
	n00000007:port1 -> n0000000d:port0 [style=dashed]
	n00000007:port1 -> n00000010:port0 [style=dashed]
	n00000007:port1 -> n00000013:port0 [style=dashed]
	n0000000a [label="{{<port0> 0} | msm_csid0\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000000a:port1 -> n00000016:port0 [style=dashed]
	n0000000a:port1 -> n00000019:port0 [style=dashed]
	n0000000a:port1 -> n0000001c:port0 [style=dashed]
	n0000000a:port1 -> n0000001f:port0 [style=dashed]
	n0000000d [label="{{<port0> 0} | msm_csid1\n/dev/v4l-subdev4 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000000d:port1 -> n00000016:port0 [style=dashed]
	n0000000d:port1 -> n00000019:port0 [style=dashed]
	n0000000d:port1 -> n0000001c:port0 [style=dashed]
	n0000000d:port1 -> n0000001f:port0 [style=dashed]
	n00000010 [label="{{<port0> 0} | msm_csid2\n/dev/v4l-subdev5 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000010:port1 -> n00000016:port0 [style=dashed]
	n00000010:port1 -> n00000019:port0 [style=dashed]
	n00000010:port1 -> n0000001c:port0 [style=dashed]
	n00000010:port1 -> n0000001f:port0 [style=dashed]
	n00000013 [label="{{<port0> 0} | msm_csid3\n/dev/v4l-subdev6 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000013:port1 -> n00000016:port0 [style=dashed]
	n00000013:port1 -> n00000019:port0 [style=dashed]
	n00000013:port1 -> n0000001c:port0 [style=dashed]
	n00000013:port1 -> n0000001f:port0 [style=dashed]
	n00000016 [label="{{<port0> 0} | msm_ispif0\n/dev/v4l-subdev7 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000016:port1 -> n00000022:port0 [style=dashed]
	n00000016:port1 -> n0000002b:port0 [style=dashed]
	n00000016:port1 -> n00000034:port0 [style=dashed]
	n00000016:port1 -> n0000003d:port0 [style=dashed]
	n00000016:port1 -> n00000046:port0 [style=dashed]
	n00000016:port1 -> n0000004f:port0 [style=dashed]
	n00000016:port1 -> n00000058:port0 [style=dashed]
	n00000016:port1 -> n00000061:port0 [style=dashed]
	n00000019 [label="{{<port0> 0} | msm_ispif1\n/dev/v4l-subdev8 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000019:port1 -> n00000022:port0 [style=dashed]
	n00000019:port1 -> n0000002b:port0 [style=dashed]
	n00000019:port1 -> n00000034:port0 [style=dashed]
	n00000019:port1 -> n0000003d:port0 [style=dashed]
	n00000019:port1 -> n00000046:port0 [style=dashed]
	n00000019:port1 -> n0000004f:port0 [style=dashed]
	n00000019:port1 -> n00000058:port0 [style=dashed]
	n00000019:port1 -> n00000061:port0 [style=dashed]
	n0000001c [label="{{<port0> 0} | msm_ispif2\n/dev/v4l-subdev9 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000001c:port1 -> n00000022:port0 [style=dashed]
	n0000001c:port1 -> n0000002b:port0 [style=dashed]
	n0000001c:port1 -> n00000034:port0 [style=dashed]
	n0000001c:port1 -> n0000003d:port0 [style=dashed]
	n0000001c:port1 -> n00000046:port0 [style=dashed]
	n0000001c:port1 -> n0000004f:port0 [style=dashed]
	n0000001c:port1 -> n00000058:port0 [style=dashed]
	n0000001c:port1 -> n00000061:port0 [style=dashed]
	n0000001f [label="{{<port0> 0} | msm_ispif3\n/dev/v4l-subdev10 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000001f:port1 -> n00000022:port0 [style=dashed]
	n0000001f:port1 -> n0000002b:port0 [style=dashed]
	n0000001f:port1 -> n00000034:port0 [style=dashed]
	n0000001f:port1 -> n0000003d:port0 [style=dashed]
	n0000001f:port1 -> n00000046:port0 [style=dashed]
	n0000001f:port1 -> n0000004f:port0 [style=dashed]
	n0000001f:port1 -> n00000058:port0 [style=dashed]
	n0000001f:port1 -> n00000061:port0 [style=dashed]
	n00000022 [label="{{<port0> 0} | msm_vfe0_rdi0\n/dev/v4l-subdev11 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000022:port1 -> n00000025 [style=bold]
	n00000025 [label="msm_vfe0_video0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
	n0000002b [label="{{<port0> 0} | msm_vfe0_rdi1\n/dev/v4l-subdev12 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000002b:port1 -> n0000002e [style=bold]
	n0000002e [label="msm_vfe0_video1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
	n00000034 [label="{{<port0> 0} | msm_vfe0_rdi2\n/dev/v4l-subdev13 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000034:port1 -> n00000037 [style=bold]
	n00000037 [label="msm_vfe0_video2\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
	n0000003d [label="{{<port0> 0} | msm_vfe0_pix\n/dev/v4l-subdev14 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000003d:port1 -> n00000040 [style=bold]
	n00000040 [label="msm_vfe0_video3\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
	n00000046 [label="{{<port0> 0} | msm_vfe1_rdi0\n/dev/v4l-subdev15 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000046:port1 -> n00000049 [style=bold]
	n00000049 [label="msm_vfe1_video0\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
	n0000004f [label="{{<port0> 0} | msm_vfe1_rdi1\n/dev/v4l-subdev16 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000004f:port1 -> n00000052 [style=bold]
	n00000052 [label="msm_vfe1_video1\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
	n00000058 [label="{{<port0> 0} | msm_vfe1_rdi2\n/dev/v4l-subdev17 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000058:port1 -> n0000005b [style=bold]
	n0000005b [label="msm_vfe1_video2\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
	n00000061 [label="{{<port0> 0} | msm_vfe1_pix\n/dev/v4l-subdev18 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000061:port1 -> n00000064 [style=bold]
	n00000064 [label="msm_vfe1_video3\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
	n000000e2 [label="{{} | ov5645 3-0039\n/dev/v4l-subdev19 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
	n000000e2:port0 -> n00000004:port0 [style=bold]
	n000000e4 [label="{{} | ov5645 3-003a\n/dev/v4l-subdev20 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
	n000000e4:port0 -> n00000007:port0 [style=bold]
	n000000e6 [label="{{} | ov5645 3-003b\n/dev/v4l-subdev21 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
	n000000e6:port0 -> n00000001:port0 [style=bold]
}


code:
# SPDX-License-Identifier: GPL-2.0

digraph board {
	rankdir=TB
	n00000001 [label="{{<port0> 0} | msm_csiphy0\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000001:port1 -> n00000007:port0 [style=dashed]
	n00000001:port1 -> n0000000a:port0 [style=dashed]
	n00000004 [label="{{<port0> 0} | msm_csiphy1\n/dev/v4l-subdev1 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000004:port1 -> n00000007:port0 [style=dashed]
	n00000004:port1 -> n0000000a:port0 [style=dashed]
	n00000007 [label="{{<port0> 0} | msm_csid0\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000007:port1 -> n0000000d:port0 [style=dashed]
	n00000007:port1 -> n00000010:port0 [style=dashed]
	n0000000a [label="{{<port0> 0} | msm_csid1\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000000a:port1 -> n0000000d:port0 [style=dashed]
	n0000000a:port1 -> n00000010:port0 [style=dashed]
	n0000000d [label="{{<port0> 0} | msm_ispif0\n/dev/v4l-subdev4 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000000d:port1 -> n00000013:port0 [style=dashed]
	n0000000d:port1 -> n0000001c:port0 [style=dashed]
	n0000000d:port1 -> n00000025:port0 [style=dashed]
	n0000000d:port1 -> n0000002e:port0 [style=dashed]
	n00000010 [label="{{<port0> 0} | msm_ispif1\n/dev/v4l-subdev5 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000010:port1 -> n00000013:port0 [style=dashed]
	n00000010:port1 -> n0000001c:port0 [style=dashed]
	n00000010:port1 -> n00000025:port0 [style=dashed]
	n00000010:port1 -> n0000002e:port0 [style=dashed]
	n00000013 [label="{{<port0> 0} | msm_vfe0_rdi0\n/dev/v4l-subdev6 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000013:port1 -> n00000016 [style=bold]
	n00000016 [label="msm_vfe0_video0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
	n0000001c [label="{{<port0> 0} | msm_vfe0_rdi1\n/dev/v4l-subdev7 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000001c:port1 -> n0000001f [style=bold]
	n0000001f [label="msm_vfe0_video1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
	n00000025 [label="{{<port0> 0} | msm_vfe0_rdi2\n/dev/v4l-subdev8 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000025:port1 -> n00000028 [style=bold]
	n00000028 [label="msm_vfe0_video2\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
	n0000002e [label="{{<port0> 0} | msm_vfe0_pix\n/dev/v4l-subdev9 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000002e:port1 -> n00000031 [style=bold]
	n00000031 [label="msm_vfe0_video3\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
	n00000057 [label="{{} | ov5645 1-0076\n/dev/v4l-subdev10 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000057:port0 -> n00000001:port0 [style=bold]
	n00000059 [label="{{} | ov5645 1-0074\n/dev/v4l-subdev11 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000059:port0 -> n00000004:port0 [style=bold]
}


code:
.. SPDX-License-Identifier: GPL-2.0

Radio drivers
=============

There is also support for pure AM/FM radio, and even for some FM radio
transmitters:

=====================  =========================================================
Driver                 Name
=====================  =========================================================
si4713                 Silicon Labs Si4713 FM Radio Transmitter
radio-aztech           Aztech/Packard Bell Radio
radio-cadet            ADS Cadet AM/FM Tuner
radio-gemtek           GemTek Radio card (or compatible)
radio-maxiradio        Guillemot MAXI Radio FM 2000 radio
radio-miropcm20        miroSOUND PCM20 radio
radio-aimslab          AIMSlab RadioTrack (aka RadioReveal)
radio-rtrack2          AIMSlab RadioTrack II
saa7706h               SAA7706H Car Radio DSP
radio-sf16fmi          SF16-FMI/SF16-FMP/SF16-FMD Radio
radio-sf16fmr2         SF16-FMR2/SF16-FMD2 Radio
radio-shark            Griffin radioSHARK USB radio receiver
shark2                 Griffin radioSHARK2 USB radio receiver
radio-si470x-common    Silicon Labs Si470x FM Radio Receiver
radio-si476x           Silicon Laboratories Si476x I2C FM Radio
radio-tea5764          TEA5764 I2C FM radio
tef6862                TEF6862 Car Radio Enhanced Selectivity Tuner
radio-terratec         TerraTec ActiveRadio ISA Standalone
radio-timb             Enable the Timberdale radio driver
radio-trust            Trust FM radio card
radio-typhoon          Typhoon Radio (a.k.a. EcoRadio)
radio-wl1273           Texas Instruments WL1273 I2C FM Radio
fm_drv                 ISA radio devices
fm_drv                 ISA radio devices
radio-zoltrix          Zoltrix Radio
dsbr100                D-Link/GemTek USB FM radio
radio-keene            Keene FM Transmitter USB
radio-ma901            Masterkit MA901 USB FM radio
radio-mr800            AverMedia MR 800 USB FM radio
radio-raremono         Thanko's Raremono AM/FM/SW radio
radio-si470x-usb       Silicon Labs Si470x FM Radio Receiver support with USB
radio-usb-si4713       Silicon Labs Si4713 FM Radio Transmitter support with USB
=====================  =========================================================


code:
.. SPDX-License-Identifier: GPL-2.0

Renesas R-Car Fine Display Processor (FDP1) Driver
==================================================

The R-Car FDP1 driver implements driver-specific controls as follows.

``V4L2_CID_DEINTERLACING_MODE (menu)``
    The video deinterlacing mode (such as Bob, Weave, ...). The R-Car FDP1
    driver implements the following modes.

.. flat-table::
    :header-rows:  0
    :stub-columns: 0
    :widths:       1 4

    * - ``"Progressive" (0)``
      - The input image video stream is progressive (not interlaced). No
        deinterlacing is performed. Apart from (optional) format and encoding
        conversion output frames are identical to the input frames.
    * - ``"Adaptive 2D/3D" (1)``
      - Motion adaptive version of 2D and 3D deinterlacing. Use 3D deinterlacing
        in the presence of fast motion and 2D deinterlacing with diagonal
        interpolation otherwise.
    * - ``"Fixed 2D" (2)``
      - The current field is scaled vertically by averaging adjacent lines to
        recover missing lines. This method is also known as blending or Line
        Averaging (LAV).
    * - ``"Fixed 3D" (3)``
      - The previous and next fields are averaged to recover lines missing from
        the current field. This method is also known as Field Averaging (FAV).
    * - ``"Previous field" (4)``
      - The current field is weaved with the previous field, i.e. the previous
        field is used to fill missing lines from the current field. This method
        is also known as weave deinterlacing.
    * - ``"Next field" (5)``
      - The current field is weaved with the next field, i.e. the next field is
        used to fill missing lines from the current field. This method is also
        known as weave deinterlacing.


code:
.. SPDX-License-Identifier: GPL-2.0

======================================================
Infrared remote control support in video4linux drivers
======================================================

Authors: Gerd Hoffmann, Mauro Carvalho Chehab

Basics
======

Most analog and digital TV boards support remote controllers. Several of
them have a microprocessor that receives the IR carriers, convert into
pulse/space sequences and then to scan codes, returning such codes to
userspace ("scancode mode"). Other boards return just the pulse/space
sequences ("raw mode").

The support for remote controller in scancode mode is provided by the
standard Linux input layer. The support for raw mode is provided via LIRC.

In order to check the support and test it, it is suggested to download
the `v4l-utils <https://git.linuxtv.org/v4l-utils.git/>`_. It provides
two tools to handle remote controllers:

- ir-keytable: provides a way to query the remote controller, list the
  protocols it supports, enable in-kernel support for IR decoder or
  switch the protocol and to test the reception of scan codes;

- ir-ctl: provide tools to handle remote controllers that support raw mode
  via LIRC interface.

Usually, the remote controller module is auto-loaded when the TV card is
detected. However, for a few devices, you need to manually load the
ir-kbd-i2c module.

How it works
============

The modules register the remote as keyboard within the linux input
layer, i.e. you'll see the keys of the remote as normal key strokes
(if CONFIG_INPUT_KEYBOARD is enabled).

Using the event devices (CONFIG_INPUT_EVDEV) it is possible for
applications to access the remote via /dev/input/event<n> devices.
The udev/systemd will automatically create the devices. If you install
the `v4l-utils <https://git.linuxtv.org/v4l-utils.git/>`_, it may also
automatically load a different keytable than the default one. Please see
`v4l-utils <https://git.linuxtv.org/v4l-utils.git/>`_ ir-keytable.1
man page for details.

The ir-keytable tool is nice for trouble shooting, i.e. to check
whenever the input device is really present, which of the devices it
is, check whenever pressing keys on the remote actually generates
events and the like.  You can also use any other input utility that changes
the keymaps, like the input kbd utility.

Using with lircd
----------------

The latest versions of the lircd daemon supports reading events from the
linux input layer (via event device). It also supports receiving IR codes
in lirc mode.

Using without lircd
-------------------

Xorg recognizes several IR keycodes that have its numerical value lower
than 247. With the advent of Wayland, the input driver got updated too,
and should now accept all keycodes. Yet, you may want to just reassign
the keycodes to something that your favorite media application likes.

This can be done by setting
`v4l-utils <https://git.linuxtv.org/v4l-utils.git/>`_ to load your own
keytable in runtime. Please read  ir-keytable.1 man page for details.


code:
digraph board {
	rankdir=TB
	n00000001 [label="{{<port0> 0 | <port1> 1} | rkisp1_isp\n/dev/v4l-subdev0 | {<port2> 2 | <port3> 3}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000001:port2 -> n00000006:port0
	n00000001:port2 -> n00000009:port0
	n00000001:port3 -> n00000014 [style=bold]
	n00000006 [label="{{<port0> 0} | rkisp1_resizer_mainpath\n/dev/v4l-subdev1 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000006:port1 -> n0000000c [style=bold]
	n00000009 [label="{{<port0> 0} | rkisp1_resizer_selfpath\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
	n00000009:port1 -> n00000010 [style=bold]
	n0000000c [label="rkisp1_mainpath\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
	n00000010 [label="rkisp1_selfpath\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
	n00000014 [label="rkisp1_stats\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
	n00000018 [label="rkisp1_params\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
	n00000018 -> n00000001:port1 [style=bold]
	n0000001c [label="{{} | imx219 4-0010\n/dev/v4l-subdev3 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
	n0000001c:port0 -> n00000001:port0
}