leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

media updates for v5.11-rc1

Browse Source 
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAl/XHngACgkQCF8+vY7k
 4RXHjg/8CVAkeLzVHFJ8odrt/tABXd5UxFE8RvqDnrb9SRvtx1tyLmcRb/WXoAhw
 Eg0MM+o5qYN8t7uP3x16yOxzsm3ix2Z+imRiIWBLSju14BTPSD7kLp+W+AaY6kT5
 cudI/907vqIb7uEZvG7jF7jM6BJfz58Du8dnmhCgehWTBguUOChc0lBxjuTG/KGZ
 Cueiq+LgvxKeZk9GvN4H6xeMPsn/ZEB5VSe/Knp95iCA6kEFq56DC0oYCUFzi2ao
 5sX5UsX9xpertFXna/tZBTo34RIofpPcctNd98La36oIV4XIVDp0FMpKCpmaDcHM
 wCMmK/K7sGRLqS6pmPZvfA6V1uIITQbYLz4z3WO9k0rJb3LgD9ied0XmHfcgNP8P
 NxTPm4jYTk6ELc/bgB/2k1AXrOm6kWItiITKZThcuCBffoLOrRcYgsVdP+ieSeb5
 8XkhjH5jADtB2HdSNvkX9CikJMB3XzaFjqLzcaFgwDqTgw1voh2ardSp5xuZuiEJ
 fw3QEpnBYbN5XFXlkwJY7VA94Dt93OQX5pfT2fUAh6MJt+SzmW17Tup+6LsfvzL5
 yJcZ18rjyo5rr0kIfBl7FLZ7nrM9PA4erayJ2gZwCUxP9mF+URW+/UI/ytL1cOIu
 iFqzj7KRD2nwfySd5UgOkD1yViXb6M4dLf5E/t5VbyU3qIHUpwM=
 =mi60
 -----END PGP SIGNATURE-----

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

Pull media updates from Mauro Carvalho Chehab:

 - some rework at the uAPI pixel format docs

 - the smiapp driver has started to gain support for MIPI CSS camera
   sensors and was renamed

 - two new sensor drivers: ov02a10 and ov9734

 - Meson gained a driver for the 2D acceleration unit

 - Rockchip rkisp1 driver was promoted from staging

 - Cedrus driver gained support for VP8

 - two new remote controller keymaps were added

 - the usual set of fixes cleanups and driver improvements

* tag 'media/v5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (447 commits)
  media: ccs: Add support for obtaining C-PHY configuration from firmware
  media: ccs-pll: Print pixel rates
  media: ccs: Print written register values
  media: ccs: Add support for DDR OP SYS and OP PIX clocks
  media: ccs-pll: Add support for DDR OP system and pixel clocks
  media: ccs: Dual PLL support
  media: ccs-pll: Add trivial dual PLL support
  media: ccs-pll: Separate VT divisor limit calculation from the rest
  media: ccs-pll: Fix VT post-PLL divisor calculation
  media: ccs-pll: Make VT divisors 16-bit
  media: ccs-pll: Rework bounds checks
  media: ccs-pll: Print relevant information on PLL tree
  media: ccs-pll: Better separate OP and VT sub-tree calculation
  media: ccs-pll: Check for derating and overrating, support non-derating sensors
  media: ccs-pll: Split off VT subtree calculation
  media: ccs-pll: Add C-PHY support
  media: ccs-pll: Add sanity checks
  media: ccs-pll: Add support flexible OP PLL pixel clock divider
  media: ccs-pll: Support two cycles per pixel on OP domain
  media: ccs-pll: Add support for extended input PLL clock divider
  ...
This commit is contained in:
Linus Torvalds 2020-12-14 11:47:37 -08:00
commit fab0fca1da
408 changed files with 24047 additions and 14030 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Documentation/admin-guide/media/rkisp1.rst
View File

@ -86,7 +86,7 @@ the driver through the rkisp_params node to improve image quality during a
video stream.
The buffer format is defined by struct :c:type:`rkisp1_stat_buffer`, and
userspace should set
:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A <v4l2-meta-fmt-stat-rkisp1>` as the
:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A <v4l2-meta-fmt-rk-isp1-stat-3a>` as the
dataformat.
.. _rkisp1_params:
@ -100,7 +100,7 @@ and others.
The buffer format is defined by struct :c:type:`rkisp1_params_cfg`, and
userspace should set
:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-params-rkisp1>` as the
:ref:`V4L2_META_FMT_RK_ISP1_PARAMS <v4l2-meta-fmt-rk-isp1-params>` as the
dataformat.

2
Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
View File

@ -18,6 +18,8 @@ properties:
- allwinner,sun7i-a20-video-engine
- allwinner,sun8i-a33-video-engine
- allwinner,sun8i-h3-video-engine
- allwinner,sun8i-v3s-video-engine
- allwinner,sun8i-r40-video-engine
- allwinner,sun50i-a64-video-engine
- allwinner,sun50i-h5-video-engine
- allwinner,sun50i-h6-video-engine

47
Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml Normal file
View File

@ -0,0 +1,47 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2020 BayLibre, SAS
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Amlogic GE2D Acceleration Unit
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
properties:
compatible:
enum:
- amlogic,axg-ge2d
interrupts:
minItems: 1
reg:
minItems: 1
resets:
maxItems: 1
clocks:
minItems: 1
required:
- compatible
- reg
- interrupts
- clocks
- resets
additionalProperties: false
examples:
- |
ge2d: ge2d@ff940000 {
compatible = "amlogic,axg-ge2d";
reg = <0xff940000 0x10000>;
interrupts = <150>;
clocks = <&clk_ge2d>;
resets = <&reset_ge2d>;
};

31
Documentation/devicetree/bindings/media/coda.txt
View File

@ -1,31 +0,0 @@
Chips&Media Coda multi-standard codec IP
========================================
Coda codec IPs are present in i.MX SoCs in various versions,
called VPU (Video Processing Unit).
Required properties:
- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
(a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
(b) "fsl,imx51-vpu" for CodaHx4 present in i.MX51
(c) "fsl,imx53-vpu" for CODA7541 present in i.MX53
(d) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
- reg: should be register base and length as documented in the
SoC reference manual
- interrupts : Should contain the VPU interrupt. For CODA960,
a second interrupt is needed for the MJPEG unit.
- clocks : Should contain the ahb and per clocks, in the order
determined by the clock-names property.
- clock-names : Should be "ahb", "per"
- iram : phandle pointing to the SRAM device node
Example:
vpu: vpu@63ff4000 {
compatible = "fsl,imx53-vpu";
reg = <0x63ff4000 0x1000>;
interrupts = <9>;
clocks = <&clks 63>, <&clks 63>;
clock-names = "ahb", "per";
iram = <&ocram>;
};

108
Documentation/devicetree/bindings/media/coda.yaml Normal file
View File

@ -0,0 +1,108 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/coda.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Chips&Media Coda multi-standard codec IP
maintainers:
- Philipp Zabel <p.zabel@pengutronix.de>
description: |-
Coda codec IPs are present in i.MX SoCs in various versions,
called VPU (Video Processing Unit).
properties:
compatible:
oneOf:
- items:
- const: fsl,imx27-vpu
- const: cnm,codadx6
- items:
- const: fsl,imx51-vpu
- const: cnm,codahx4
- items:
- const: fsl,imx53-vpu
- const: cnm,coda7541
- items:
- enum:
- fsl,imx6dl-vpu
- fsl,imx6q-vpu
- const: cnm,coda960
reg:
maxItems: 1
clocks:
items:
- description: PER clock
- description: AHB interface clock
clock-names:
items:
- const: per
- const: ahb
resets:
maxItems: 1
iram:
$ref: /schemas/types.yaml#/definitions/phandle
description: phandle pointing to the SRAM device node
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
allOf:
- if:
properties:
compatible:
contains:
const: cnm,coda960
then:
properties:
interrupts:
items:
- description: BIT processor interrupt
- description: JPEG unit interrupt
interrupt-names:
items:
- const: bit
- const: jpeg
else:
properties:
interrupts:
items:
- description: BIT processor interrupt
- if:
properties:
compatible:
contains:
enum:
- fsl,imx6dl-vpu
- fsl,imx6q-vpu
then:
properties:
power-domains:
$ref: /schemas/types.yaml#/definitions/phandle
description: phandle pointing to the PU power domain
maxItems: 1
examples:
- |
vpu: video-codec@63ff4000 {
compatible = "fsl,imx53-vpu", "cnm,coda7541";
reg = <0x63ff4000 0x1000>;
interrupts = <9>;
clocks = <&clks 63>, <&clks 63>;
clock-names = "per", "ahb";
iram = <&ocram>;
};

88
Documentation/devicetree/bindings/media/i2c/adv7604.txt
View File

@ -1,88 +0,0 @@
* Analog Devices ADV7604/11/12 video decoder with HDMI receiver
The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated
HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog
input, and the ADV7611 has one HDMI input and no analog input. The 7612 is
similar to the 7611 but has 2 HDMI inputs.
These device tree bindings support the ADV7611/12 only at the moment.
Required Properties:
- compatible: Must contain one of the following
- "adi,adv7611" for the ADV7611
- "adi,adv7612" for the ADV7612
- reg: I2C slave addresses
The ADV76xx has up to thirteen 256-byte maps that can be accessed via the
main I2C ports. Each map has it own I2C address and acts as a standard
slave device on the I2C bus. The main address is mandatory, others are
optional and revert to defaults if not specified.
- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
detection pins, one per HDMI input. The active flag indicates the GPIO
level that enables hot-plug detection.
The device node must contain one 'port' child node per device input and output
port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
are numbered as follows.
Port ADV7611 ADV7612
------------------------------------------------------------
HDMI 0 0, 1
Digital output 1 2
The digital output port node must contain at least one endpoint.
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
- default-input: Select which input is selected after reset.
- reg-names : Names of maps with programmable addresses.
It can contain any map needing a non-default address.
Possible maps names are :
"main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
"rep", "edid", "hdmi", "test", "cp", "vdp"
Optional Endpoint Properties:
The following three properties are defined in video-interfaces.txt and are
valid for source endpoints only.
- hsync-active: Horizontal synchronization polarity. Defaults to active low.
- vsync-active: Vertical synchronization polarity. Defaults to active low.
- pclk-sample: Pixel clock polarity. Defaults to output on the falling edge.
If none of hsync-active, vsync-active and pclk-sample is specified the
endpoint will use embedded BT.656 synchronization.
Example:
hdmi_receiver@4c {
compatible = "adi,adv7611";
/*
* The edid page will be accessible @ 0x66 on the I2C bus. All
* other maps will retain their default addresses.
*/
reg = <0x4c>, <0x66>;
reg-names = "main", "edid";
reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
default-input = <0>;
port@0 {
reg = <0>;
};
port@1 {
reg = <1>;
hdmi_in: endpoint {
remote-endpoint = <&ccdc_in>;
};
};
};

178
Documentation/devicetree/bindings/media/i2c/adv7604.yaml Normal file
View File

@ -0,0 +1,178 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/adv7604.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADV7604/11/12 video decoder with HDMI receiver
maintainers:
- Hans Verkuil <hverkuil-cisco@xs4all.nl>
description:
The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated
HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog
input, and the ADV7611 has one HDMI input and no analog input. The 7612 is
similar to the 7611 but has 2 HDMI inputs.
These device tree bindings support the ADV7611/12 only at the moment.
properties:
compatible:
items:
- enum:
- adi,adv7611
- adi,adv7612
reg:
minItems: 1
maxItems: 13
reg-names:
minItems: 1
maxItems: 13
items:
- const: main
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
interrupts:
maxItems: 1
reset-gpios:
maxItems: 1
hpd-gpios:
minItems: 1
description:
References to the GPIOs that control the HDMI hot-plug detection pins,
one per HDMI input. The active flag indicates the GPIO level that
enables hot-plug detection.
default-input:
maxItems: 1
description:
Select which input is selected after reset.
ports:
type: object
description:
A node containing input and output port nodes with endpoint definitions
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
required:
- compatible
- reg
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: adi,adv7611
then:
properties:
ports:
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@0:
type: object
description: Input port
port@1:
type: object
description: Output port
required:
- port@1
additionalProperties: false
required:
- ports
- if:
properties:
compatible:
contains:
const: adi,adv7612
then:
properties:
ports:
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@2:
type: object
description: Output port
patternProperties:
"^port@[0-1]$":
type: object
description: Input port
required:
- port@2
additionalProperties: false
required:
- ports
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
hdmi_receiver@4c {
compatible = "adi,adv7611";
/*
* The edid page will be accessible @ 0x66 on the I2C bus. All
* other maps will retain their default addresses.
*/
reg = <0x4c>, <0x66>;
reg-names = "main", "edid";
reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
default-input = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
};
port@1 {
reg = <1>;
hdmi_in: endpoint {
remote-endpoint = <&ccdc_in>;
};
};
};
};
};

46
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
View File

@ -1,46 +0,0 @@
* Aptina MT9V111 CMOS sensor
----------------------------
The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
The sensor has an active pixel array of 640x480 pixels and can output a number
of image resolution and formats controllable through a simple two-wires
interface.
Required properties:
--------------------
- compatible: shall be "aptina,mt9v111".
- clocks: reference to the system clock input provider.
Optional properties:
--------------------
- enable-gpios: output enable signal, pin name "OE#". Active low.
- standby-gpios: low power state control signal, pin name "STANDBY".
Active high.
- reset-gpios: chip reset signal, pin name "RESET#". Active low.
The device node must contain one 'port' child node with one 'endpoint' child
sub-node for its digital output video port, in accordance with the video
interface bindings defined in:
Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
--------
&i2c1 {
camera@48 {
compatible = "aptina,mt9v111";
reg = <0x48>;
clocks = <&camera_clk>;
port {
mt9v111_out: endpoint {
remote-endpoint = <&ceu_in>;
};
};
};
};

75
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/aptina,mt9v111.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Aptina MT9V111 CMOS sensor
maintainers:
- Jacopo Mondi <jacopo@jmondi.org>
description: |
The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
The sensor has an active pixel array of 640x480 pixels and can output a number
of image resolutions and formats controllable through a simple two-wires
interface.
properties:
compatible:
const: aptina,mt9v111
reg:
maxItems: 1
clocks:
maxItems: 1
enable-gpios:
description: Enable signal, pin name "OE#". Active low.
maxItems: 1
standby-gpios:
description: |
Low power state control signal, pin name "STANDBY". Active high.
maxItems: 1
reset-gpios:
description: Chip reset signal, pin name "RESET#". Active low.
maxItems: 1
port:
type: object
description: |
Output video port. See ../video-interfaces.txt.
required:
- compatible
- reg
- clocks
- port
additionalProperties: false
examples:
- |
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
camera@48 {
compatible = "aptina,mt9v111";
reg = <0x48>;
clocks = <&camera_clk>;
port {
mt9v111_out: endpoint {
remote-endpoint = <&ceu_in>;
};
};
};
};
...

135
Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml Normal file
View File

@ -0,0 +1,135 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) 2014--2020 Intel Corporation
$id: http://devicetree.org/schemas/media/i2c/mipi-ccs.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MIPI CCS, SMIA++ and SMIA compliant camera sensors
maintainers:
- Sakari Ailus <sakari.ailus@linux.intel.com>
description:
CCS (Camera Command Set) is a raw Bayer camera sensor standard defined by the
MIPI Alliance; see
<URL:https://www.mipi.org/specifications/camera-command-set>.
SMIA (Standard Mobile Imaging Architecture) is an image sensor standard
defined jointly by Nokia and ST. SMIA++, defined by Nokia, is an extension of
that.
More detailed documentation can be found in
Documentation/devicetree/bindings/media/video-interfaces.txt .
properties:
compatible:
oneOf:
- items:
- const: mipi-ccs-1.1
- const: mipi-ccs
- items:
- const: mipi-ccs-1.0
- const: mipi-ccs
- const: nokia,smia
reg:
maxItems: 1
vana-supply:
description: Analogue voltage supply (VANA), sensor dependent.
maxItems: 1
vcore-supply:
description: Core voltage supply (VCore), sensor dependent.
maxItems: 1
vio-supply:
description: I/O voltage supply (VIO), sensor dependent.
maxItems: 1
clocks:
description: External clock to the sensor.
maxItems: 1
clock-frequency:
description: Frequency of the external clock to the sensor in Hz.
reset-gpios:
description: Reset GPIO. Also commonly called XSHUTDOWN in hardware
documentation.
maxItems: 1
flash-leds:
description: Flash LED phandles. See ../video-interfaces.txt for details.
lens-focus:
description: Lens focus controller phandles. See ../video-interfaces.txt
for details.
rotation:
description: Rotation of the sensor. See ../video-interfaces.txt for
details.
enum: [ 0, 180 ]
port:
type: object
properties:
endpoint:
type: object
properties:
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: List of allowed data link frequencies.
data-lanes:
minItems: 1
maxItems: 8
bus-type:
description: The type of the data bus.
oneOf:
- const: 1 # CSI-2 C-PHY
- const: 3 # CCP2
- const: 4 # CSI-2 D-PHY
required:
- link-frequencies
- data-lanes
- bus-type
required:
- compatible
- reg
- clock-frequency
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c2 {
#address-cells = <1>;
#size-cells = <0>;
clock-frequency = <400000>;
camera-sensor@10 {
compatible = "mipi-ccs-1.0", "mipi-ccs";
reg = <0x10>;
reset-gpios = <&gpio3 20 GPIO_ACTIVE_LOW>;
vana-supply = <&vaux3>;
clocks = <&omap3_isp 0>;
clock-frequency = <9600000>;
port {
ccs_ep: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&csi2a_ep>;
link-frequencies = /bits/ 64 <199200000 210000000
499200000>;
bus-type = <4>;
};
};
};
};
...

66
Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
View File

@ -1,66 +0,0 @@
SMIA/SMIA++ sensor
SMIA (Standard Mobile Imaging Architecture) is an image sensor standard
defined jointly by Nokia and ST. SMIA++, defined by Nokia, is an extension
of that. These definitions are valid for both types of sensors.
More detailed documentation can be found in
Documentation/devicetree/bindings/media/video-interfaces.txt .
The device node should contain a "port" node which may contain one or more
endpoint nodes, in accordance with video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt .
Mandatory properties
--------------------
- compatible: "nokia,smia"
- reg: I2C address (0x10, or an alternative address)
- vana-supply: Analogue voltage supply (VANA), typically 2,8 volts (sensor
dependent).
- clocks: External clock to the sensor
- clock-frequency: Frequency of the external clock to the sensor
- link-frequencies: List of allowed data link frequencies. An array of
64-bit elements.
Optional properties
-------------------
- reset-gpios: XSHUTDOWN GPIO
- flash-leds: See ../video-interfaces.txt
- lens-focus: See ../video-interfaces.txt
- rotation: Integer property; valid values are 0 (sensor mounted upright)
and 180 (sensor mounted upside down). See
../video-interfaces.txt .
Endpoint node mandatory properties
----------------------------------
- data-lanes: <1..n>
Example
-------
&i2c2 {
clock-frequency = <400000>;
camera-sensor@10 {
compatible = "nokia,smia";
reg = <0x10>;
reset-gpios = <&gpio3 20 0>;
vana-supply = <&vaux3>;
clocks = <&omap3_isp 0>;
clock-frequency = <9600000>;
nokia,nvm-size = <512>; /* 8 * 64 */
link-frequencies = /bits/ 64 <199200000 210000000 499200000>;
port {
smiapp_ep: endpoint {
data-lanes = <1 2>;
remote-endpoint = <&csi2a_ep>;
};
};
};
};

46
Documentation/devicetree/bindings/media/i2c/ov2680.txt
View File

@ -1,46 +0,0 @@
* Omnivision OV2680 MIPI CSI-2 sensor
Required Properties:
- compatible: should be "ovti,ov2680".
- clocks: reference to the xvclk input clock.
- clock-names: should be "xvclk".
- DOVDD-supply: Digital I/O voltage supply.
- DVDD-supply: Digital core voltage supply.
- AVDD-supply: Analog voltage supply.
Optional Properties:
- reset-gpios: reference to the GPIO connected to the powerdown/reset pin,
if any. This is an active low signal to the OV2680.
The device node must contain one 'port' child node for its digital output
video port, and this port must have a single endpoint in accordance with
the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Endpoint node required properties for CSI-2 connection are:
- remote-endpoint: a phandle to the bus receiver's endpoint node.
- clock-lanes: should be set to <0> (clock lane on hardware lane 0).
- data-lanes: should be set to <1> (one CSI-2 lane supported).
Example:
&i2c2 {
ov2680: camera-sensor@36 {
compatible = "ovti,ov2680";
reg = <0x36>;
clocks = <&osc>;
clock-names = "xvclk";
reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
DOVDD-supply = <&sw2_reg>;
DVDD-supply = <&sw2_reg>;
AVDD-supply = <&reg_peri_3p15v>;
port {
ov2680_to_mipi: endpoint {
remote-endpoint = <&mipi_from_sensor>;
clock-lanes = <0>;
data-lanes = <1>;
};
};
};
};

40
Documentation/devicetree/bindings/media/i2c/ov772x.txt
View File

@ -1,40 +0,0 @@
* Omnivision OV7720/OV7725 CMOS sensor
The Omnivision OV7720/OV7725 sensor supports multiple resolutions output,
such as VGA, QVGA, and any size scaling down from CIF to 40x30. It also can
support the YUV422, RGB565/555/444, GRB422 or raw RGB output formats.
Required Properties:
- compatible: shall be one of
"ovti,ov7720"
"ovti,ov7725"
- clocks: reference to the xclk input clock.
Optional Properties:
- reset-gpios: reference to the GPIO connected to the RSTB pin which is
active low, if any.
- powerdown-gpios: reference to the GPIO connected to the PWDN pin which is
active high, if any.
The device node shall contain one 'port' child node with one child 'endpoint'
subnode for its digital output video port, in accordance with the video
interface bindings defined in Documentation/devicetree/bindings/media/
video-interfaces.txt.
Example:
&i2c0 {
ov772x: camera@21 {
compatible = "ovti,ov7725";
reg = <0x21>;
reset-gpios = <&axi_gpio_0 0 GPIO_ACTIVE_LOW>;
powerdown-gpios = <&axi_gpio_0 1 GPIO_ACTIVE_LOW>;
clocks = <&xclk>;
port {
ov772x_0: endpoint {
remote-endpoint = <&vcap1_in0>;
};
};
};
};

159
Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml Normal file
View File

@ -0,0 +1,159 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright (c) 2020 MediaTek Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
maintainers:
- Dongchun Zhu <dongchun.zhu@mediatek.com>
description: |-
The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
image sensor, which is the latest production derived from Omnivision's CMOS
image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
@ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
sensor output is available via CSI-2 serial data output.
properties:
compatible:
const: ovti,ov02a10
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
description:
External clock for the sensor.
items:
- const: eclk
clock-frequency:
description:
Frequency of the eclk clock in Hz.
dovdd-supply:
description:
Definition of the regulator used as Digital I/O voltage supply.
avdd-supply:
description:
Definition of the regulator used as Analog voltage supply.
dvdd-supply:
description:
Definition of the regulator used as Digital core voltage supply.
powerdown-gpios:
description:
Must be the device tree identifier of the GPIO connected to the
PD_PAD pin. This pin is used to place the OV02A10 into standby mode
or shutdown mode. As the line needs to be high for the powerdown mode
to be active, it should be marked GPIO_ACTIVE_HIGH.
maxItems: 1
reset-gpios:
description:
Must be the device tree identifier of the GPIO connected to the
RST_PD pin. If specified, it will be asserted during driver probe.
As the line needs to be low for the reset to be active, it should be
marked GPIO_ACTIVE_LOW.
maxItems: 1
rotation:
description:
Definition of the sensor's placement.
allOf:
- $ref: "/schemas/types.yaml#/definitions/uint32"
- enum:
- 0 # Sensor Mounted Upright
- 180 # Sensor Mounted Upside Down
default: 0
# See ../video-interfaces.txt for details
port:
type: object
additionalProperties: false
description:
Output port node, single endpoint describing the CSI-2 transmitter.
properties:
endpoint:
type: object
additionalProperties: false
properties:
link-frequencies: true
ovti,mipi-clock-voltage:
allOf:
- $ref: "/schemas/types.yaml#/definitions/uint32"
description:
Definition of MIPI clock voltage unit. This entry corresponds to
the link speed defined by the 'link-frequencies' property.
If present, the value shall be in the range of 0-4.
default: 4
remote-endpoint: true
required:
- link-frequencies
- remote-endpoint
required:
- endpoint
required:
- compatible
- reg
- clocks
- clock-names
- clock-frequency
- dovdd-supply
- avdd-supply
- dvdd-supply
- powerdown-gpios
- reset-gpios
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
ov02a10: camera-sensor@3d {
compatible = "ovti,ov02a10";
reg = <0x3d>;
powerdown-gpios = <&pio 107 GPIO_ACTIVE_HIGH>;
reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
clocks = <&ov02a10_clk>;
clock-names = "eclk";
clock-frequency = <24000000>;
rotation = <180>;
dovdd-supply = <&ov02a10_dovdd>;
avdd-supply = <&ov02a10_avdd>;
dvdd-supply = <&ov02a10_dvdd>;
port {
wcam_out: endpoint {
link-frequencies = /bits/ 64 <390000000>;
ovti,mipi-clock-voltage = <3>;
remote-endpoint = <&mipi_in_wcam>;
};
};
};
};
...

99
Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml Normal file
View File

@ -0,0 +1,99 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ovti,ov2680.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Omnivision OV2680 CMOS Sensor
maintainers:
- Rui Miguel Silva <rmfrfs@gmail.com>
description: |-
The OV2680 color sensor is a low voltage, high performance 1/5 inch UXGA (2
megapixel) CMOS image sensor that provides a single-chip UXGA (1600 x 1200)
camera. It provides full-frame, sub-sampled, or windowed 10-bit images in
various formats via the control of the Serial Camera Control Bus (SCCB)
interface. The OV2680 has an image array capable of operating at up to 30
frames per second (fps) in UXGA resolution.
properties:
compatible:
const: ovti,ov2680
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
const: xvclk
reset-gpios:
description:
The phandle and specifier for the GPIO that controls sensor reset.
This corresponds to the hardware pin XSHUTDOWN which is physically
active low.
maxItems: 1
dovdd-supply:
description:
Definition of the regulator used as interface power supply.
avdd-supply:
description:
Definition of the regulator used as analog power supply.
dvdd-supply:
description:
Definition of the regulator used as digital power supply.
port:
type: object
description:
A node containing an output port node with an endpoint definition
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
required:
- compatible
- reg
- clocks
- clock-names
- dovdd-supply
- avdd-supply
- dvdd-supply
- reset-gpios
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
ov2680: camera-sensor@36 {
compatible = "ovti,ov2680";
reg = <0x36>;
clocks = <&osc>;
clock-names = "xvclk";
reset-gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
dovdd-supply = <&sw2_reg>;
dvdd-supply = <&sw2_reg>;
avdd-supply = <&reg_peri_3p15v>;
port {
ov2680_to_mipi: endpoint {
remote-endpoint = <&mipi_from_sensor>;
};
};
};
};
...

134
Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml Normal file
View File

@ -0,0 +1,134 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/ovti,ov772x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Omnivision OV7720/OV7725 CMOS sensor
maintainers:
- Jacopo Mondi <jacopo@jmondi.org>
description: |
The Omnivision OV7720/OV7725 sensor supports multiple resolutions output,
such as VGA, QVGA, and any size scaling down from CIF to 40x30. It also can
support the YUV422, RGB565/555/444, GRB422 or raw RGB output formats.
properties:
compatible:
enum:
- ovti,ov7720
- ovti,ov7725
reg:
maxItems: 1
clocks:
maxItems: 1
reset-gpios:
description: |
Reference to the GPIO connected to the RSTB pin which is active low.
maxItems: 1
powerdown-gpios:
description: |
Reference to the GPIO connected to the PWDN pin which is active high.
maxItems: 1
port:
type: object
description: |
Video output port. See ../video-interfaces.txt.
properties:
endpoint:
type: object
properties:
bus-type:
enum: [5, 6]
bus-width:
enum: [8, 10]
default: 10
data-shift:
enum: [0, 2]
default: 0
hsync-active:
enum: [0, 1]
default: 1
vsync-active:
enum: [0, 1]
default: 1
pclk-sample:
enum: [0, 1]
default: 1
allOf:
- if:
properties:
bus-type:
const: 6
then:
properties:
hsync-active: false
vsync-active: false
- if:
properties:
bus-width:
const: 10
then:
properties:
data-shift:
const: 0
required:
- bus-type
unevaluatedProperties: false
additionalProperties: false
required:
- compatible
- reg
- clocks
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
ov772x: camera@21 {
compatible = "ovti,ov7725";
reg = <0x21>;
reset-gpios = <&axi_gpio_0 0 GPIO_ACTIVE_LOW>;
powerdown-gpios = <&axi_gpio_0 1 GPIO_ACTIVE_LOW>;
clocks = <&xclk>;
port {
ov772x_0: endpoint {
bus-type = <5>;
vsync-active = <0>;
hsync-active = <0>;
pclk-sample = <0>;
bus-width = <8>;
data-shift = <0>;
remote-endpoint = <&vcap1_in0>;
};
};
};
};
...

53
Documentation/devicetree/bindings/media/i2c/sony,imx214.txt
View File

@ -1,53 +0,0 @@
* Sony 1/3.06-Inch 13.13Mp CMOS Digital Image Sensor
The Sony imx214 is a 1/3.06-inch CMOS active pixel digital image sensor with
an active array size of 4224H x 3200V. It is programmable through an I2C
interface.
Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a maximum
throughput of 1.2Gbps/lane.
Required Properties:
- compatible: Shall be "sony,imx214".
- reg: I2C bus address of the device. Depending on how the sensor is wired,
it shall be <0x10> or <0x1a>;
- enable-gpios: GPIO descriptor for the enable pin.
- vdddo-supply: Chip digital IO regulator (1.8V).
- vdda-supply: Chip analog regulator (2.7V).
- vddd-supply: Chip digital core regulator (1.12V).
- clocks: Reference to the xclk clock.
- clock-frequency: Frequency of the xclk clock.
Optional Properties:
- flash-leds: See ../video-interfaces.txt
- lens-focus: See ../video-interfaces.txt
The imx214 device node shall contain one 'port' child node with
an 'endpoint' subnode. For further reading on port node refer to
Documentation/devicetree/bindings/media/video-interfaces.txt.
Required Properties on endpoint:
- data-lanes: check ../video-interfaces.txt
- link-frequencies: check ../video-interfaces.txt
- remote-endpoint: check ../video-interfaces.txt
Example:
camera-sensor@1a {
compatible = "sony,imx214";
reg = <0x1a>;
vdddo-supply = <&pm8994_lvs1>;
vddd-supply = <&camera_vddd_1v12>;
vdda-supply = <&pm8994_l17>;
lens-focus = <&ad5820>;
enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
clocks = <&mmcc CAMSS_MCLK0_CLK>;
clock-frequency = <24000000>;
port {
imx214_ep: endpoint {
data-lanes = <1 2 3 4>;
link-frequencies = /bits/ 64 <480000000>;
remote-endpoint = <&csiphy0_ep>;
};
};
};

133
Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml Normal file
View File

@ -0,0 +1,133 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/sony,imx214.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sony 1/3.06-Inch 13.13MP CMOS Digital Image Sensor
maintainers:
- Ricardo Ribalda <ribalda@kernel.org>
description: |
The Sony IMX214 is a 1/3.06-inch CMOS active pixel digital image sensor with
an active array size of 4224H x 3200V. It is programmable through an I2C
interface. Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a
maximum throughput of 1.2Gbps/lane.
properties:
compatible:
const: sony,imx214
reg:
enum:
- 0x10
- 0x1a
clocks:
description: Reference to the xclk clock.
maxItems: 1
clock-frequency:
description: Frequency of the xclk clock in Hz.
enable-gpios:
description: GPIO descriptor for the enable pin.
maxItems: 1
vdddo-supply:
description: Chip digital IO regulator (1.8V).
maxItems: 1
vdda-supply:
description: Chip analog regulator (2.7V).
maxItems: 1
vddd-supply:
description: Chip digital core regulator (1.12V).
maxItems: 1
flash-leds:
description: See ../video-interfaces.txt
lens-focus:
description: See ../video-interfaces.txt
port:
type: object
description: |
Video output port. See ../video-interfaces.txt.
properties:
endpoint:
type: object
properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: See ../video-interfaces.txt
anyOf:
- items:
- const: 1
- const: 2
- items:
- const: 1
- const: 2
- const: 3
- const: 4
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: See ../video-interfaces.txt
required:
- data-lanes
- link-frequencies
unevaluatedProperties: false
additionalProperties: false
required:
- compatible
- reg
- clocks
- clock-frequency
- enable-gpios
- vdddo-supply
- vdda-supply
- vddd-supply
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
camera-sensor@1a {
compatible = "sony,imx214";
reg = <0x1a>;
vdddo-supply = <&pm8994_lvs1>;
vddd-supply = <&camera_vddd_1v12>;
vdda-supply = <&pm8994_l17>;
lens-focus = <&ad5820>;
enable-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
clocks = <&camera_clk>;
clock-frequency = <24000000>;
port {
imx214_ep: endpoint {
data-lanes = <1 2 3 4>;
link-frequencies = /bits/ 64 <480000000>;
remote-endpoint = <&csiphy0_ep>;
};
};
};
};
...

42
Documentation/devicetree/bindings/media/imx7-csi.txt
View File

@ -1,42 +0,0 @@
Freescale i.MX7 CMOS Sensor Interface
=====================================
csi node
--------
This is device node for the CMOS Sensor Interface (CSI) which enables the chip
to connect directly to external CMOS image sensors.
Required properties:
- compatible : "fsl,imx7-csi" or "fsl,imx6ul-csi";
- reg : base address and length of the register set for the device;
- interrupts : should contain CSI interrupt;
- clocks : list of clock specifiers, see
Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
- clock-names : must contain "mclk";
The device node shall contain one 'port' child node with one child 'endpoint'
node, according to the bindings defined in:
Documentation/devicetree/bindings/media/video-interfaces.txt.
In the following example a remote endpoint is a video multiplexer.
example:
csi: csi@30710000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx7-csi";
reg = <0x30710000 0x10000>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_CSI_MCLK_ROOT_CLK>;
clock-names = "mclk";
port {
csi_from_csi_mux: endpoint {
remote-endpoint = <&csi_mux_to_csi>;
};
};
};

90
Documentation/devicetree/bindings/media/imx7-mipi-csi2.txt
View File

@ -1,90 +0,0 @@
Freescale i.MX7 Mipi CSI2
=========================
mipi_csi2 node
--------------
This is the device node for the MIPI CSI-2 receiver core in i.MX7 SoC. It is
compatible with previous version of Samsung D-phy.
Required properties:
- compatible : "fsl,imx7-mipi-csi2";
- reg : base address and length of the register set for the device;
- interrupts : should contain MIPI CSIS interrupt;
- clocks : list of clock specifiers, see
Documentation/devicetree/bindings/clock/clock-bindings.txt for details;
- clock-names : must contain "pclk", "wrap" and "phy" entries, matching
entries in the clock property;
- power-domains : a phandle to the power domain, see
Documentation/devicetree/bindings/power/power_domain.txt for details.
- reset-names : should include following entry "mrst";
- resets : a list of phandle, should contain reset entry of
reset-names;
- phy-supply : from the generic phy bindings, a phandle to a regulator that
provides power to MIPI CSIS core;
Optional properties:
- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
value when this property is not specified is 166 MHz;
- fsl,csis-hs-settle : differential receiver (HS-RX) settle time;
The device node should contain two 'port' child nodes with one child 'endpoint'
node, according to the bindings defined in:
Documentation/devicetree/bindings/ media/video-interfaces.txt.
The following are properties specific to those nodes.
port node
---------
- reg : (required) can take the values 0 or 1, where 0 shall be
related to the sink port and port 1 shall be the source
one;
endpoint node
-------------
- data-lanes : (required) an array specifying active physical MIPI-CSI2
data input lanes and their mapping to logical lanes; this
shall only be applied to port 0 (sink port), the array's
content is unused only its length is meaningful,
in this case the maximum length supported is 2;
example:
mipi_csi: mipi-csi@30750000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx7-mipi-csi2";
reg = <0x30750000 0x10000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_IPG_ROOT_CLK>,
<&clks IMX7D_MIPI_CSI_ROOT_CLK>,
<&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
clock-names = "pclk", "wrap", "phy";
clock-frequency = <166000000>;
power-domains = <&pgc_mipi_phy>;
phy-supply = <&reg_1p0d>;
resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
reset-names = "mrst";
fsl,csis-hs-settle = <3>;
port@0 {
reg = <0>;
mipi_from_sensor: endpoint {
remote-endpoint = <&ov2680_to_mipi>;
data-lanes = <1>;
};
};
port@1 {
reg = <1>;
mipi_vc0_to_csi_mux: endpoint {
remote-endpoint = <&csi_mux_from_mipi_vc0>;
};
};
};

71
Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml Normal file
View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/nxp,imx7-csi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX7 CMOS Sensor Interface
maintainers:
- Rui Miguel Silva <rmfrfs@gmail.com>
description: |
This is device node for the CMOS Sensor Interface (CSI) which enables the
chip to connect directly to external CMOS image sensors.
properties:
compatible:
enum:
- fsl,imx7-csi
- fsl,imx6ul-csi
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
items:
- const: mclk
port:
type: object
description:
A node containing input port nodes with endpoint definitions as documented
in Documentation/devicetree/bindings/media/video-interfaces.txt
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx7d-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
csi: csi@30710000 {
compatible = "fsl,imx7-csi";
reg = <0x30710000 0x10000>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_CSI_MCLK_ROOT_CLK>;
clock-names = "mclk";
port {
csi_from_csi_mux: endpoint {
remote-endpoint = <&csi_mux_to_csi>;
};
};
};
...

173
Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml Normal file
View File

@ -0,0 +1,173 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX7 Mipi CSI2
maintainers:
- Rui Miguel Silva <rmfrfs@gmail.com>
description: |
This is the device node for the MIPI CSI-2 receiver core in i.MX7 soc. It is
compatible with previous version of samsung d-phy.
properties:
compatible:
const: fsl,imx7-mipi-csi2
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: pclk
- const: wrap
- const: phy
power-domains:
maxItems: 1
phy-supply:
description:
Phandle to a regulator that provides power to the PHY. This
regulator will be managed during the PHY power on/off sequence.
resets:
maxItems: 1
reset-names:
const: mrst
clock-frequency:
description:
The IP main (system bus) clock frequency in Hertz
default: 166000000
fsl,csis-hs-settle:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Differential receiver (HS-RX) settle time
ports:
type: object
description:
A node containing input and output port nodes with endpoint definitions
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@0:
type: object
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
reg:
const: 0
endpoint:
type: object
properties:
data-lanes:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: See ../video-interfaces.txt
oneOf:
- items:
- const: 1
- items:
- const: 1
- const: 2
remote-endpoint: true
required:
- data-lanes
- remote-endpoint
additionalProperties: false
additionalProperties: false
port@1:
type: object
description:
Output port node
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- power-domains
- phy-supply
- resets
- reset-names
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/imx7d-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/reset/imx7-reset.h>
mipi_csi: mipi-csi@30750000 {
compatible = "fsl,imx7-mipi-csi2";
reg = <0x30750000 0x10000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_IPG_ROOT_CLK>,
<&clks IMX7D_MIPI_CSI_ROOT_CLK>,
<&clks IMX7D_MIPI_DPHY_ROOT_CLK>;
clock-names = "pclk", "wrap", "phy";
clock-frequency = <166000000>;
power-domains = <&pgc_mipi_phy>;
phy-supply = <&reg_1p0d>;
resets = <&src IMX7_RESET_MIPI_PHY_MRST>;
reset-names = "mrst";
fsl,csis-hs-settle = <3>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mipi_from_sensor: endpoint {
remote-endpoint = <&ov2680_to_mipi>;
data-lanes = <1>;
};
};
port@1 {
reg = <1>;
mipi_vc0_to_csi_mux: endpoint {
remote-endpoint = <&csi_mux_from_mipi_vc0>;
};
};
};
};
...

7
Documentation/devicetree/bindings/media/qcom,camss.txt
View File

@ -8,6 +8,7 @@ Qualcomm Camera Subsystem
Definition: Should contain one of:
- "qcom,msm8916-camss"
- "qcom,msm8996-camss"
- "qcom,sdm660-camss"
- reg:
Usage: required
Value type: <prop-encoded-array>
@ -64,30 +65,36 @@ Qualcomm Camera Subsystem
Value type: <stringlist>
Definition: Should contain the following entries:
- "top_ahb"
- "throttle_axi" (660 only)
- "ispif_ahb"
- "csiphy0_timer"
- "csiphy1_timer"
- "csiphy2_timer" (8996 only)
- "csiphy_ahb2crif" (660 only)
- "csi0_ahb"
- "csi0"
- "csi0_phy"
- "csi0_pix"
- "csi0_rdi"
- "cphy_csid0" (660 only)
- "csi1_ahb"
- "csi1"
- "csi1_phy"
- "csi1_pix"
- "csi1_rdi"
- "cphy_csid1" (660 only)
- "csi2_ahb" (8996 only)
- "csi2" (8996 only)
- "csi2_phy" (8996 only)
- "csi2_pix" (8996 only)
- "csi2_rdi" (8996 only)
- "cphy_csid2" (660 only)
- "csi3_ahb" (8996 only)
- "csi3" (8996 only)
- "csi3_phy" (8996 only)
- "csi3_pix" (8996 only)
- "csi3_rdi" (8996 only)
- "cphy_csid3" (660 only)
- "ahb"
- "vfe0"
- "csi_vfe0"

2
Documentation/devicetree/bindings/media/rc.yaml
View File

@ -83,6 +83,7 @@ properties:
- rc-it913x-v2
- rc-kaiomy
- rc-khadas
- rc-khamsin
- rc-kworld-315u
- rc-kworld-pc150u
- rc-kworld-plus-tv-analog
@ -102,6 +103,7 @@ properties:
- rc-npgtech
- rc-odroid
- rc-pctv-sedna
- rc-pine64
- rc-pinnacle-color
- rc-pinnacle-grey
- rc-pinnacle-pctv-hd

81
drivers/staging/media/rkisp1/Documentation/devicetree/bindings/media/rockchip-isp1.yaml → Documentation/devicetree/bindings/media/rockchip-isp1.yaml
View File

@ -23,10 +23,27 @@ properties:
interrupts:
maxItems: 1
iommus:
maxItems: 1
clocks:
minItems: 3
items:
# isp0 and isp1
- description: ISP clock
- description: ISP AXI clock
- description: ISP AHB clock
# only for isp1
- description: ISP Pixel clock
power-domains:
clock-names:
minItems: 3
items:
# isp0 and isp1
- const: isp
- const: aclk
- const: hclk
# only for isp1
- const: pclk_isp
iommus:
maxItems: 1
phys:
@ -36,21 +53,8 @@ properties:
phy-names:
const: dphy
clocks:
items:
- description: ISP clock
- description: ISP AXI clock clock
- description: ISP AXI clock wrapper clock
- description: ISP AHB clock clock
- description: ISP AHB wrapper clock
clock-names:
items:
- const: clk_isp
- const: aclk_isp
- const: aclk_isp_wrap
- const: hclk_isp
- const: hclk_isp_wrap
power-domains:
maxItems: 1
# See ./video-interfaces.txt for details
ports:
@ -94,20 +98,42 @@ properties:
remote-endpoint: true
required:
- reg
- "#address-cells"
- "#size-cells"
required:
- "#address-cells"
- "#size-cells"
- port@0
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- power-domains
- iommus
- phys
- phy-names
- power-domains
- ports
if:
properties:
compatible:
contains:
const: rockchip,rk3399-cif-isp
then:
properties:
clocks:
minItems: 3
maxItems: 4
clock-names:
minItems: 3
maxItems: 4
additionalProperties: false
examples:
@ -117,7 +143,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/rk3399-power.h>
parent0: parent@0 {
parent0: parent {
#address-cells = <2>;
#size-cells = <2>;
@ -126,24 +152,22 @@ examples:
reg = <0x0 0xff910000 0x0 0x4000>;
interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&cru SCLK_ISP0>,
<&cru ACLK_ISP0>, <&cru ACLK_ISP0_WRAPPER>,
<&cru HCLK_ISP0>, <&cru HCLK_ISP0_WRAPPER>;
clock-names = "clk_isp",
"aclk_isp", "aclk_isp_wrap",
"hclk_isp", "hclk_isp_wrap";
power-domains = <&power RK3399_PD_ISP0>;
<&cru ACLK_ISP0_WRAPPER>,
<&cru HCLK_ISP0_WRAPPER>;
clock-names = "isp", "aclk", "hclk";
iommus = <&isp0_mmu>;
phys = <&dphy>;
phy-names = "dphy";
power-domains = <&power RK3399_PD_ISP0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
mipi_in_wcam: endpoint@0 {
reg = <0>;
@ -160,8 +184,7 @@ examples:
};
};
i2c7: i2c@ff160000 {
clock-frequency = <400000>;
i2c7: i2c {
#address-cells = <1>;
#size-cells = <0>;

38
Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
View File

@ -44,6 +44,43 @@ properties:
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
properties:
endpoint:
type: object
properties:
bus-type:
enum: [5, 6]
default: 5
bus-width:
enum: [8, 10, 12, 14]
default: 8
remote-endpoint: true
allOf:
- if:
properties:
bus-type:
const: 6
then:
properties:
hsync-active: false
vsync-active: false
bus-width:
enum: [8]
required:
- remote-endpoint
- bus-type
- pclk-sample
unevaluatedProperties: false
additionalProperties: false
required:
- compatible
- reg
@ -75,6 +112,7 @@ examples:
port {
dcmi_0: endpoint {
remote-endpoint = <&ov5640_0>;
bus-type = <5>;
bus-width = <8>;
hsync-active = <0>;
vsync-active = <0>;

13
Documentation/driver-api/media/camera-sensor.rst
View File

@ -132,3 +132,16 @@ used to obtain device's power state after the power state transition:
The function returns a non-zero value if it succeeded getting the power count or
runtime PM was disabled, in either of which cases the driver may proceed to
access the device.
Controls
--------
For camera sensors that are connected to a bus where transmitter and receiver
require common configuration set by drivers, such as CSI-2 or parallel (BT.601
or BT.656) bus, the ``V4L2_CID_LINK_FREQ`` control is mandatory on transmitter
drivers. Receiver drivers can use the ``V4L2_CID_LINK_FREQ`` to query the
frequency used on the bus.
The transmitter drivers should also implement ``V4L2_CID_PIXEL_RATE`` control in
order to tell the maximum pixel rate to the receiver. This is required on raw
camera sensors.

4
Documentation/driver-api/media/cec-core.rst
View File

@ -143,7 +143,7 @@ To enable/disable the 'monitor all' mode::
int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable);
If enabled, then the adapter should be put in a mode to also monitor messages
that not for us. Not all hardware supports this and this function is only
that are not for us. Not all hardware supports this and this function is only
called if the CEC_CAP_MONITOR_ALL capability is set. This callback is optional
(some hardware may always be in 'monitor all' mode).
@ -335,7 +335,7 @@ So this must work:
$ cat einj.txt >error-inj
The first callback is called when this file is read and it should show the
the current error injection state::
current error injection state::
int (*error_inj_show)(struct cec_adapter *adap, struct seq_file *sf);

7
Documentation/driver-api/media/csi2.rst
View File

@ -28,10 +28,9 @@ interface elements must be present on the sub-device represents the
CSI-2 transmitter.
The V4L2_CID_LINK_FREQ control is used to tell the receiver driver the
frequency (and not the symbol rate) of the link. The
V4L2_CID_PIXEL_RATE is may be used by the receiver to obtain the pixel
rate the transmitter uses. The
:c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an
frequency (and not the symbol rate) of the link. The V4L2_CID_PIXEL_RATE
control may be used by the receiver to obtain the pixel rate the transmitter
uses. The :c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an
ability to start and stop the stream.
The value of the V4L2_CID_PIXEL_RATE is calculated as follows::

1041
Documentation/driver-api/media/drivers/ccs/ccs-regs.asc Normal file
View File

File diff suppressed because it is too large Load Diff

82
Documentation/driver-api/media/drivers/ccs/ccs.rst Normal file
View File

@ -0,0 +1,82 @@
.. SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
.. include:: <isonum.txt>
MIPI CCS camera sensor driver
=============================
The MIPI CCS camera sensor driver is a generic driver for `MIPI CCS
<https://www.mipi.org/specifications/camera-command-set>`_ compliant
camera sensors. It exposes three sub-devices representing the pixel array,
the binner and the scaler.
As the capabilities of individual devices vary, the driver exposes
interfaces based on the capabilities that exist in hardware.
Pixel Array sub-device
----------------------
The pixel array sub-device represents the camera sensor's pixel matrix, as well
as analogue crop functionality present in many compliant devices. The analogue
crop is configured using the ``V4L2_SEL_TGT_CROP`` on the source pad (0) of the
entity. The size of the pixel matrix can be obtained by getting the
``V4L2_SEL_TGT_NATIVE_SIZE`` target.
Binner
------
The binner sub-device represents the binning functionality on the sensor. For
that purpose, selection target ``V4L2_SEL_TGT_COMPOSE`` is supported on the
sink pad (0).
Additionally, if a device has no scaler or digital crop functionality, the
source pad (1) expses another digital crop selection rectangle that can only
crop at the end of the lines and frames.
Scaler
------
The scaler sub-device represents the digital crop and scaling functionality of
the sensor. The V4L2 selection target ``V4L2_SEL_TGT_CROP`` is used to
configure the digital crop on the sink pad (0) when digital crop is supported.
Scaling is configured using selection target ``V4L2_SEL_TGT_COMPOSE`` on the
sink pad (0) as well.
Additionally, if the scaler sub-device exists, its source pad (1) exposes
another digital crop selection rectangle that can only crop at the end of the
lines and frames.
Digital and analogue crop
-------------------------
Digital crop functionality is referred to as cropping that effectively works by
dropping some data on the floor. Analogue crop, on the other hand, means that
the cropped information is never retrieved. In case of camera sensors, the
analogue data is never read from the pixel matrix that are outside the
configured selection rectangle that designates crop. The difference has an
effect in device timing and likely also in power consumption.
Register definition generator
-----------------------------
The ccs-regs.asc file contains MIPI CCS register definitions that are used
to produce C source code files for definitions that can be better used by
programs written in C language. As there are many dependencies between the
produced files, please do not modify them manually as it's error-prone and
in vain, but instead change the script producing them.
Usage
~~~~~
Conventionally the script is called this way to update the CCS driver
definitions:
.. code-block:: none
$ Documentation/driver-api/media/drivers/ccs/mk-ccs-regs -k \
-e drivers/media/i2c/ccs/ccs-regs.h \
-L drivers/media/i2c/ccs/ccs-limits.h \
-l drivers/media/i2c/ccs/ccs-limits.c \
-c Documentation/driver-api/media/drivers/ccs/ccs-regs.asc
**Copyright** |copy| 2020 Intel Corporation

433
Documentation/driver-api/media/drivers/ccs/mk-ccs-regs Executable file
View File

@ -0,0 +1,433 @@
#!/usr/bin/perl -w
# SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause
# Copyright (C) 2019--2020 Intel Corporation
use Getopt::Long qw(:config no_ignore_case);
use File::Basename;
my $ccsregs = "ccs-regs.asc";
my $header;
my $regarray;
my $limitc;
my $limith;
my $kernel;
my $help;
GetOptions("ccsregs|c=s" => \$ccsregs,
"header|e=s" => \$header,
"regarray|r=s" => \$regarray,
"limitc|l=s" => \$limitc,
"limith|L=s" => \$limith,
"kernel|k" => \$kernel,
"help|h" => \$help) or die "can't parse options";
$help = 1 if ! defined $header || ! defined $limitc || ! defined $limith;
if (defined $help) {
print <<EOH
$0 - Create CCS register definitions for C
usage: $0 -c ccs-regs.asc -e header -r regarray -l limit-c -L limit-header [-k]
-c ccs register file
-e header file name
-r register description array file name
-l limit and capability array file name
-L limit and capability header file name
-k generate files for kernel space consumption
EOH
;
exit 0;
}
my $lh_hdr = ! defined $kernel
? '#include "ccs-os.h"' . "\n"
: "#include <linux/bits.h>\n#include <linux/types.h>\n";
my $uint32_t = ! defined $kernel ? 'uint32_t' : 'u32';
my $uint16_t = ! defined $kernel ? 'uint16_t' : 'u16';
open(my $R, "< $ccsregs") or die "can't open $ccsregs";
open(my $H, "> $header") or die "can't open $header";
my $A;
if (defined $regarray) {
open($A, "> $regarray") or die "can't open $regarray";
}
open(my $LC, "> $limitc") or die "can't open $limitc";
open(my $LH, "> $limith") or die "can't open $limith";
my %this;
sub is_limit_reg($) {
my $addr = hex $_[0];
return 0 if $addr < 0x40; # weed out status registers
return 0 if $addr >= 0x100 && $addr < 0xfff; # weed out configuration registers
return 1;
}
my $uc_header = basename uc $header;
$uc_header =~ s/[^A-Z0-9]/_/g;
my $copyright = "/* Copyright (C) 2019--2020 Intel Corporation */\n";
my $license = "SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause";
for my $fh ($A, $LC) {
print $fh "// $license\n$copyright\n" if defined $fh;
}
for my $fh ($H, $LH) {
print $fh "/* $license */\n$copyright\n";
}
sub bit_def($) {
my $bit = shift @_;
return "BIT($bit)" if defined $kernel;
return "(1U << $bit)" if $bit =~ /^[a-zA-Z0-9_]+$/;
return "(1U << ($bit))";
}
print $H <<EOF
#ifndef __${uc_header}__
#define __${uc_header}__
EOF
;
print $H "#include <linux/bits.h>\n\n" if defined $kernel;
print $H <<EOF
#define CCS_FL_BASE 16
EOF
;
print $H "#define CCS_FL_16BIT " . bit_def("CCS_FL_BASE") . "\n";
print $H "#define CCS_FL_32BIT " . bit_def("CCS_FL_BASE + 1") . "\n";
print $H "#define CCS_FL_FLOAT_IREAL " . bit_def("CCS_FL_BASE + 2") . "\n";
print $H "#define CCS_FL_IREAL " . bit_def("CCS_FL_BASE + 3") . "\n";
print $H <<EOF
#define CCS_R_ADDR(r) ((r) & 0xffff)
EOF
;
print $A <<EOF
#include <stdint.h>
#include <stdio.h>
#include "ccs-extra.h"
#include "ccs-regs.h"
EOF
if defined $A;
my $uc_limith = basename uc $limith;
$uc_limith =~ s/[^A-Z0-9]/_/g;
print $LH <<EOF
#ifndef __${uc_limith}__
#define __${uc_limith}__
$lh_hdr
struct ccs_limit {
$uint32_t reg;
$uint16_t size;
$uint16_t flags;
const char *name;
};
EOF
;
print $LH "#define CCS_L_FL_SAME_REG " . bit_def(0) . "\n\n";
print $LH <<EOF
extern const struct ccs_limit ccs_limits[];
EOF
;
print $LC <<EOF
#include "ccs-limits.h"
#include "ccs-regs.h"
const struct ccs_limit ccs_limits[] = {
EOF
;
my $limitcount = 0;
my $argdescs;
my $reglist = "const struct ccs_reg_desc ccs_reg_desc[] = {\n";
sub name_split($$) {
my ($name, $addr) = @_;
my $args;
$name =~ /([^\(]+?)(\(.*)/;
($name, $args) = ($1, $2);
$args = [split /,\s*/, $args];
foreach my $t (@$args) {
$t =~ s/[\(\)]//g;
$t =~ s/\//\\\//g;
}
return ($name, $addr, $args);
}
sub tabconv($) {
$_ = shift;
my @l = split "\n", $_;
map {
s/ {8,8}/\t/g;
s/\t\K +//;
} @l;
return (join "\n", @l) . "\n";
}
sub elem_size(@) {
my @flags = @_;
return 2 if grep /^16$/, @flags;
return 4 if grep /^32$/, @flags;
return 1;
}
sub arr_size($) {
my $this = $_[0];
my $size = $this->{elsize};
my $h = $this->{argparams};
foreach my $arg (@{$this->{args}}) {
my $apref = $h->{$arg};
$size *= $apref->{max} - $apref->{min} + 1;
}
return $size;
}
sub print_args($$$) {
my ($this, $postfix, $is_same_reg) = @_;
my ($args, $argparams, $name) =
($this->{args}, $this->{argparams}, $this->{name});
my $varname = "ccs_reg_arg_" . (lc $name) . $postfix;
my @mins;
my @sorted_args = @{$this->{sorted_args}};
my $lim_arg;
my $size = arr_size($this);
$argdescs .= "static const struct ccs_reg_arg " . $varname . "[] = {\n";
foreach my $sorted_arg (@sorted_args) {
push @mins, $argparams->{$sorted_arg}->{min};
}
foreach my $sorted_arg (@sorted_args) {
my $h = $argparams->{$sorted_arg};
$argdescs .= "\t{ \"$sorted_arg\", $h->{min}, $h->{max}, $h->{elsize} },\n";
$lim_arg .= defined $lim_arg ? ", $h->{min}" : "$h->{min}";
}
$argdescs .= "};\n\n";
$reglist .= "\t{ CCS_R_" . (uc $name) . "(" . (join ",", (@mins)) .
"), $size, sizeof($varname) / sizeof(*$varname)," .
" \"" . (lc $name) . "\", $varname },\n";
print $LC tabconv sprintf "\t{ CCS_R_" . (uc $name) . "($lim_arg), " .
$size . ", " . ($is_same_reg ? "CCS_L_FL_SAME_REG" : "0") .
", \"$name" . (defined $this->{discontig} ? " $lim_arg" : "") . "\" },\n"
if is_limit_reg $this->{base_addr};
}
my $hdr_data;
while (<$R>) {
chop;
s/^\s*//;
next if /^[#;]/ || /^$/;
if (s/^-\s*//) {
if (s/^b\s*//) {
my ($bit, $addr) = split /\t+/;
$bit = uc $bit;
$hdr_data .= sprintf "#define %-62s %s", "CCS_" . (uc ${this{name}}) ."_$bit", bit_def($addr) . "\n";
} elsif (s/^f\s*//) {
s/[,\.-]/_/g;
my @a = split /\s+/;
my ($msb, $lsb, $this_field) = reverse @a;
@a = ( { "name" => "SHIFT", "addr" => $lsb, "fmt" => "%uU", },
{ "name" => "MASK", "addr" => (1 << ($msb + 1)) - 1 - ((1 << $lsb) - 1), "fmt" => "0x%" . join(".", ($this{"elsize"} >> 2) x 2) . "x" } );
$this{"field"} = $this_field;
foreach my $ar (@a) {
#print $ar->{fmt}."\n";
$hdr_data .= sprintf "#define %-62s " . $ar->{"fmt"} . "\n", "CCS_" . (uc $this{"name"}) . (defined $this_field ? "_" . uc $this_field : "") . "_" . $ar->{"name"}, $ar->{"addr"} . "\n";
}
} elsif (s/^e\s*//) {
s/[,\.-]/_/g;
my ($enum, $addr) = split /\s+/;
$enum = uc $enum;
$hdr_data .= sprintf "#define %-62s %s", "CCS_" . (uc ${this{name}}) . (defined $this{"field"} ? "_" . uc $this{"field"} : "") ."_$enum", $addr . ($addr =~ /0x/i ? "" : "U") . "\n";
} elsif (s/^l\s*//) {
my ($arg, $min, $max, $elsize, @discontig) = split /\s+/;
my $size;
foreach my $num ($min, $max) {
$num = hex $num if $num =~ /0x/i;
}
$hdr_data .= sprintf "#define %-62s %s", "CCS_LIM_" . (uc ${this{name}} . "_MIN_$arg"), $min . ($min =~ /0x/i ? "" : "U") . "\n";
$hdr_data .= sprintf "#define %-62s %s", "CCS_LIM_" . (uc ${this{name}} . "_MAX_$arg"), $max . ($max =~ /0x/i ? "" : "U") . "\n";
my $h = $this{argparams};
$h->{$arg} = { "min" => $min,
"max" => $max,
"elsize" => $elsize =~ /^0x/ ? hex $elsize : $elsize,
"discontig" => \@discontig };
$this{discontig} = $arg if @discontig;
next if $#{$this{args}} + 1 != scalar keys %{$this{argparams}};
my $reg_formula = "($this{addr}";
my $lim_formula;
foreach my $arg (@{$this{args}}) {
my $d = $h->{$arg}->{discontig};
my $times = $h->{$arg}->{elsize} != 1 ?
" * " . $h->{$arg}->{elsize} : "";
if (@$d) {
my ($lim, $offset) = split /,/, $d->[0];
$reg_formula .= " + (($arg) < $lim ? ($arg)$times : $offset + (($arg) - $lim)$times)";
} else {
$reg_formula .= " + ($arg)$times";
}
$lim_formula .= (defined $lim_formula ? " + " : "") . "($arg)$times";
}
$reg_formula .= ")\n";
$lim_formula =~ s/^\(([a-z0-9]+)\)$/$1/i;
print $H tabconv sprintf("#define %-62s %s", "CCS_R_" . (uc $this{name}) .
$this{arglist}, $reg_formula);
print $H tabconv $hdr_data;
undef $hdr_data;
# Sort arguments in descending order by size
@{$this{sorted_args}} = sort {
$h->{$a}->{elsize} <= $h->{$b}->{elsize}
} @{$this{args}};
if (defined $this{discontig}) {
my $da = $this{argparams}->{$this{discontig}};
my ($first_discontig) = split /,/, $da->{discontig}->[0];
my $max = $da->{max};
$da->{max} = $first_discontig - 1;
print_args(\%this, "", 0);
$da->{min} = $da->{max} + 1;
$da->{max} = $max;
print_args(\%this, $first_discontig, 1);
} else {
print_args(\%this, "", 0);
}
next unless is_limit_reg $this{base_addr};
print $LH tabconv sprintf "#define %-63s%s\n",
"CCS_L_" . (uc $this{name}) . "_OFFSET(" .
(join ", ", @{$this{args}}) . ")", "($lim_formula)";
}
if (! @{$this{args}}) {
print $H tabconv($hdr_data);
undef $hdr_data;
}
next;
}
my ($name, $addr, @flags) = split /\t+/, $_;
my $args = [];
my $sp;
($name, $addr, $args) = name_split($name, $addr) if /\(.*\)/;
$name =~ s/[,\.-]/_/g;
my $flagstring = "";
my $size = elem_size(@flags);
$flagstring .= "| CCS_FL_16BIT " if $size eq "2";
$flagstring .= "| CCS_FL_32BIT " if $size eq "4";
$flagstring .= "| CCS_FL_FLOAT_IREAL " if grep /^float_ireal$/, @flags;
$flagstring .= "| CCS_FL_IREAL " if grep /^ireal$/, @flags;
$flagstring =~ s/^\| //;
$flagstring =~ s/ $//;
$flagstring = "($flagstring)" if $flagstring =~ /\|/;
my $base_addr = $addr;
$addr = "($addr | $flagstring)" if $flagstring ne "";
my $arglist = @$args ? "(" . (join ", ", @$args) . ")" : "";
$hdr_data .= sprintf "#define %-62s %s\n", "CCS_R_" . (uc $name), $addr
if !@$args;
$name =~ s/\(.*//;
%this = ( name => $name,
addr => $addr,
base_addr => $base_addr,
argparams => {},
args => $args,
arglist => $arglist,
elsize => $size,
);
if (!@$args) {
$reglist .= "\t{ CCS_R_" . (uc $name) . ", 1, 0, \"" . (lc $name) . "\", NULL },\n";
print $H tabconv $hdr_data;
undef $hdr_data;
print $LC tabconv sprintf "\t{ CCS_R_" . (uc $name) . ", " .
$this{elsize} . ", 0, \"$name\" },\n"
if is_limit_reg $this{base_addr};
}
print $LH tabconv sprintf "#define %-63s%s\n",
"CCS_L_" . (uc $this{name}), $limitcount++
if is_limit_reg $this{base_addr};
}
if (defined $A) {
print $A $argdescs, $reglist;
print $A "\t{ 0 }\n";
print $A "};\n";
}
print $H "\n#endif /* __${uc_header}__ */\n";
print $LH tabconv sprintf "#define %-63s%s\n", "CCS_L_LAST", $limitcount;
print $LH "\n#endif /* __${uc_limith}__ */\n";
print $LC "\t{ 0 } /* Guardian */\n";
print $LC "};\n";
close($R);
close($H);
close($A) if defined $A;
close($LC);
close($LH);

1
Documentation/driver-api/media/drivers/index.rst
View File

@ -26,6 +26,7 @@ Video4Linux (V4L) drivers
tuners
vimc-devel
zoran
ccs/ccs
Digital TV drivers

6
Documentation/driver-api/media/dtv-frontend.rst
View File

@ -244,7 +244,7 @@ Carrier Signal to Noise ratio (:ref:`DTV-STAT-CNR`)
Having it available after inner FEC is more common.
Bit counts post-FEC (:ref:`DTV-STAT-POST-ERROR-BIT-COUNT` and :ref:`DTV-STAT-POST-TOTAL-BIT-COUNT`)
- Those counters measure the number of bits and bit errors errors after
- Those counters measure the number of bits and bit errors after
the forward error correction (FEC) on the inner coding block
(after Viterbi, LDPC or other inner code).
@ -253,7 +253,7 @@ Bit counts post-FEC (:ref:`DTV-STAT-POST-ERROR-BIT-COUNT` and :ref:`DTV-STAT-POS
see :c:type:`fe_status`).
Bit counts pre-FEC (:ref:`DTV-STAT-PRE-ERROR-BIT-COUNT` and :ref:`DTV-STAT-PRE-TOTAL-BIT-COUNT`)
- Those counters measure the number of bits and bit errors errors before
- Those counters measure the number of bits and bit errors before
the forward error correction (FEC) on the inner coding block
(before Viterbi, LDPC or other inner code).
@ -263,7 +263,7 @@ Bit counts pre-FEC (:ref:`DTV-STAT-PRE-ERROR-BIT-COUNT` and :ref:`DTV-STAT-PRE-T
after ``FE_HAS_VITERBI``, see :c:type:`fe_status`).
Block counts (:ref:`DTV-STAT-ERROR-BLOCK-COUNT` and :ref:`DTV-STAT-TOTAL-BLOCK-COUNT`)
- Those counters measure the number of blocks and block errors errors after
- Those counters measure the number of blocks and block errors after
the forward error correction (FEC) on the inner coding block
(before Viterbi, LDPC or other inner code).

4
Documentation/driver-api/media/v4l2-controls.rst
View File

@ -335,7 +335,7 @@ current and new values:
union v4l2_ctrl_ptr p_new;
union v4l2_ctrl_ptr p_cur;
If the control has a simple s32 type type, then:
If the control has a simple s32 type, then:
.. code-block:: c
@ -349,7 +349,7 @@ Within the control ops you can freely use these. The val and cur.val speak for
themselves. The p_char pointers point to character buffers of length
ctrl->maximum + 1, and are always 0-terminated.
Unless the control is marked volatile the p_cur field points to the the
Unless the control is marked volatile the p_cur field points to the
current cached control value. When you create a new control this value is made
identical to the default value. After calling v4l2_ctrl_handler_setup() this
value is passed to the hardware. It is generally a good idea to call this

2
Documentation/driver-api/media/v4l2-dev.rst
View File

@ -212,7 +212,7 @@ types exist:
========================== ==================== ==============================
The last argument gives you a certain amount of control over the device
device node number used (i.e. the X in ``videoX``). Normally you will pass -1
node number used (i.e. the X in ``videoX``). Normally you will pass -1
to let the v4l2 framework pick the first free number. But sometimes users
want to select a specific node number. It is common that drivers allow
the user to select a specific device node number through a driver module

2
Documentation/userspace-api/media/cec/cec-ioc-g-mode.rst
View File

@ -188,7 +188,7 @@ Available follower modes are:
in combination with :ref:`CEC_MODE_NO_INITIATOR <CEC-MODE-NO-INITIATOR>`, otherwise
the ``EINVAL`` error code will be returned. In 'monitor all' mode all messages
this CEC device transmits and all messages it receives, including
directed messages for other CEC devices will be reported. This is
directed messages for other CEC devices, will be reported. This is
very useful for debugging, but not all devices support this. This
mode requires that the :ref:`CEC_CAP_MONITOR_ALL <CEC-CAP-MONITOR-ALL>` capability is set,
otherwise the ``EINVAL`` error code is returned. This is only allowed if

2
Documentation/userspace-api/media/dvb/audio.rst
View File

@ -8,7 +8,7 @@ Digital TV Audio Device
The Digital TV audio device controls the MPEG2 audio decoder of the Digital
TV hardware. It can be accessed through ``/dev/dvb/adapter?/audio?``. Data
types and and ioctl definitions can be accessed by including
types and ioctl definitions can be accessed by including
``linux/dvb/audio.h`` in your application.
Please note that some Digital TV cards don’t have their own MPEG decoder, which

2
Documentation/userspace-api/media/dvb/ca.rst
View File

@ -7,7 +7,7 @@ Digital TV CA Device
####################
The Digital TV CA device controls the conditional access hardware. It
can be accessed through ``/dev/dvb/adapter?/ca?``. Data types and and ioctl
can be accessed through ``/dev/dvb/adapter?/ca?``. Data types and ioctl
definitions can be accessed by including ``linux/dvb/ca.h`` in your
application.

2
Documentation/userspace-api/media/dvb/demux.rst
View File

@ -11,7 +11,7 @@ digital TV. If the driver and hardware supports, those filters are
implemented at the hardware. Otherwise, the Kernel provides a software
emulation.
It can be accessed through ``/dev/adapter?/demux?``. Data types and and
It can be accessed through ``/dev/adapter?/demux?``. Data types and
ioctl definitions can be accessed by including ``linux/dvb/dmx.h`` in
your application.

2
Documentation/userspace-api/media/dvb/dmx-qbuf.rst
View File

@ -50,7 +50,7 @@ by a :ref:`DMX_QUERYBUF` ioctl will do as well.
When ``DMX_QBUF`` is called with a pointer to this structure, it locks the
memory pages of the buffer in physical memory, so they cannot be swapped
out to disk. Buffers remain locked until dequeued, until the
the device is closed.
device is closed.
Applications call the ``DMX_DQBUF`` ioctl to dequeue a filled
(capturing) buffer from the driver's outgoing queue.

2
Documentation/userspace-api/media/dvb/net.rst
View File

@ -23,7 +23,7 @@ types that are present on the transport stream. This is done through
virtual ``dvb?_?`` network interfaces, and will be controlled/routed via
the standard ip tools (like ip, route, netstat, ifconfig, etc).
Data types and and ioctl definitions are defined via ``linux/dvb/net.h``
Data types and ioctl definitions are defined via ``linux/dvb/net.h``
header.

2
Documentation/userspace-api/media/dvb/video.rst
View File

@ -8,7 +8,7 @@ Digital TV Video Device
The Digital TV video device controls the MPEG2 video decoder of the Digital
TV hardware. It can be accessed through **/dev/dvb/adapter0/video0**. Data
types and and ioctl definitions can be accessed by including
types and ioctl definitions can be accessed by including
**linux/dvb/video.h** in your application.
Note that the Digital TV video device only controls decoding of the MPEG video

1
Documentation/userspace-api/media/lirc.h.rst.exceptions
View File

@ -64,6 +64,7 @@ ignore symbol RC_PROTO_RCMM12
ignore symbol RC_PROTO_RCMM24
ignore symbol RC_PROTO_RCMM32
ignore symbol RC_PROTO_XBOX_DVD
ignore symbol RC_PROTO_MAX
# Undocumented macros

2
Documentation/userspace-api/media/rc/keytable.c.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
file: uapi/v4l/keytable.c
=========================

13
Documentation/userspace-api/media/rc/lirc-dev-intro.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_dev_intro:
@ -57,12 +57,12 @@ on the following table.
This mode is for both sending and receiving IR.
For transmitting (aka sending), create a ``struct lirc_scancode`` with
For transmitting (aka sending), create a struct lirc_scancode with
the desired scancode set in the ``scancode`` member, :c:type:`rc_proto`
set to the :ref:`IR protocol <Remote_controllers_Protocols>`, and all other
members set to 0. Write this struct to the lirc device.
For receiving, you read ``struct lirc_scancode`` from the LIRC device.
For receiving, you read struct lirc_scancode from the LIRC device.
The ``scancode`` field is set to the received scancode and the
:ref:`IR protocol <Remote_controllers_Protocols>` is set in
:c:type:`rc_proto`. If the scancode maps to a valid key code, this is set
@ -136,6 +136,13 @@ on the following table.
This mode is used only for IR send.
*************************************
Data types used by LIRC_MODE_SCANCODE
*************************************
.. kernel-doc:: include/uapi/linux/lirc.h
:identifiers: lirc_scancode rc_proto
********************
BPF based IR decoder
********************

2
Documentation/userspace-api/media/rc/lirc-dev.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_dev:

2
Documentation/userspace-api/media/rc/lirc-func.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_func:

2
Documentation/userspace-api/media/rc/lirc-get-features.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_features:

2
Documentation/userspace-api/media/rc/lirc-get-rec-mode.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_rec_mode:

2
Documentation/userspace-api/media/rc/lirc-get-rec-resolution.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_rec_resolution:

2
Documentation/userspace-api/media/rc/lirc-get-send-mode.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_send_mode:

2
Documentation/userspace-api/media/rc/lirc-get-timeout.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_get_min_timeout:

2
Documentation/userspace-api/media/rc/lirc-header.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _lirc_header:

2
Documentation/userspace-api/media/rc/lirc-read.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc-read:

2
Documentation/userspace-api/media/rc/lirc-set-measure-carrier-mode.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_measure_carrier_mode:

2
Documentation/userspace-api/media/rc/lirc-set-rec-carrier-range.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_carrier_range:

2
Documentation/userspace-api/media/rc/lirc-set-rec-carrier.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_carrier:

2
Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_timeout_reports:

2
Documentation/userspace-api/media/rc/lirc-set-rec-timeout.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_rec_timeout:

2
Documentation/userspace-api/media/rc/lirc-set-send-carrier.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_send_carrier:

2
Documentation/userspace-api/media/rc/lirc-set-send-duty-cycle.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_send_duty_cycle:

2
Documentation/userspace-api/media/rc/lirc-set-transmitter-mask.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_transmitter_mask:

2
Documentation/userspace-api/media/rc/lirc-set-wideband-receiver.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc_set_wideband_receiver:

2
Documentation/userspace-api/media/rc/lirc-write.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. c:namespace:: RC
.. _lirc-write:

2
Documentation/userspace-api/media/rc/rc-intro.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_Intro:

2
Documentation/userspace-api/media/rc/rc-protos.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_Protocols:

2
Documentation/userspace-api/media/rc/rc-sysfs-nodes.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _remote_controllers_sysfs_nodes:

2
Documentation/userspace-api/media/rc/rc-table-change.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_table_change:

2
Documentation/userspace-api/media/rc/rc-tables.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. _Remote_controllers_tables:

2
Documentation/userspace-api/media/rc/remote_controllers.rst
View File

@ -1,4 +1,4 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
.. include:: <isonum.txt>
.. _remote_controllers:

12
Documentation/userspace-api/media/v4l/biblio.rst
View File

@ -270,7 +270,17 @@ EBU Tech 3213
=============
:title: E.B.U. Standard for Chromaticity Tolerances for Studio Monitors"
:title: E.B.U. Standard for Chromaticity Tolerances for Studio Monitors
:author: European Broadcast Union (http://www.ebu.ch)
.. _tech3321:
EBU Tech 3321
=============
:title: E.B.U. guidelines for Consumer Flat Panel Displays (FPDs)
:author: European Broadcast Union (http://www.ebu.ch)

2
Documentation/userspace-api/media/v4l/buffer.rst
View File

@ -604,7 +604,7 @@ Buffer Flags
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called. Due to
hardware limitations, the last buffer may be empty. In this case
the driver will set the ``bytesused`` field to 0, regardless of
the format. Any Any subsequent call to the
the format. Any subsequent call to the
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
but return an ``EPIPE`` error code.
* .. _`V4L2-BUF-FLAG-REQUEST-FD`:

5
Documentation/userspace-api/media/v4l/colorspaces-details.rst
View File

@ -674,8 +674,9 @@ Colorspace EBU Tech. 3213 (V4L2_COLORSPACE_470_SYSTEM_BG)
=========================================================
The :ref:`tech3213` standard defines the colorspace used by PAL/SECAM
in 1975. In practice this colorspace is obsolete and SMPTE 170M should
be used instead. The default transfer function is
in 1975. Note that this colorspace is not supported by the HDMI interface.
Instead :ref:`tech3321` recommends that Rec. 709 is used instead for HDMI.
The default transfer function is
``V4L2_XFER_FUNC_709``. The default Y'CbCr encoding is
``V4L2_YCBCR_ENC_601``. The default Y'CbCr quantization is limited
range. The chromaticities of the primary colors and the white reference

1
Documentation/userspace-api/media/v4l/common.rst
View File

@ -44,6 +44,7 @@ applicable to all devices.
ext-ctrls-image-source
ext-ctrls-image-process
ext-ctrls-codec
ext-ctrls-codec-stateless
ext-ctrls-jpeg
ext-ctrls-dv
ext-ctrls-rf-tuner

2
Documentation/userspace-api/media/v4l/dev-mem2mem.rst
View File

@ -32,7 +32,7 @@ file handle is visible through another file handle).
One of the most common memory-to-memory device is the codec. Codecs
are more complicated than most and require additional setup for
their codec parameters. This is done through codec controls.
See :ref:`mpeg-controls`. More details on how to use codec memory-to-memory
See :ref:`codec-controls`. More details on how to use codec memory-to-memory
devices are given in the following sections.
.. toctree::

793
Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst Normal file
View File

@ -0,0 +1,793 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _codec-stateless-controls:
*********************************
Stateless Codec Control Reference
*********************************
The Stateless Codec control class is intended to support
stateless decoder and encoders (i.e. hardware accelerators).
These drivers are typically supported by the :ref:`stateless_decoder`,
and deal with parsed pixel formats such as V4L2_PIX_FMT_H264_SLICE.
Stateless Codec Control ID
==========================
.. _codec-stateless-control-id:
``V4L2_CID_CODEC_STATELESS_CLASS (class)``
The Stateless Codec class descriptor.
.. _v4l2-codec-stateless-h264:
``V4L2_CID_STATELESS_H264_SPS (struct)``
Specifies the sequence parameter set (as extracted from the
bitstream) for the associated H264 slice data. This includes the
necessary parameters for configuring a stateless hardware decoding
pipeline for H264. The bitstream parameters are defined according
to :ref:`h264`, section 7.4.2.1.1 "Sequence Parameter Set Data
Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. c:type:: v4l2_ctrl_h264_sps
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_sps
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``profile_idc``
-
* - __u8
- ``constraint_set_flags``
- See :ref:`Sequence Parameter Set Constraints Set Flags <h264_sps_constraints_set_flags>`
* - __u8
- ``level_idc``
-
* - __u8
- ``seq_parameter_set_id``
-
* - __u8
- ``chroma_format_idc``
-
* - __u8
- ``bit_depth_luma_minus8``
-
* - __u8
- ``bit_depth_chroma_minus8``
-
* - __u8
- ``log2_max_frame_num_minus4``
-
* - __u8
- ``pic_order_cnt_type``
-
* - __u8
- ``log2_max_pic_order_cnt_lsb_minus4``
-
* - __u8
- ``max_num_ref_frames``
-
* - __u8
- ``num_ref_frames_in_pic_order_cnt_cycle``
-
* - __s32
- ``offset_for_ref_frame[255]``
-
* - __s32
- ``offset_for_non_ref_pic``
-
* - __s32
- ``offset_for_top_to_bottom_field``
-
* - __u16
- ``pic_width_in_mbs_minus1``
-
* - __u16
- ``pic_height_in_map_units_minus1``
-
* - __u32
- ``flags``
- See :ref:`Sequence Parameter Set Flags <h264_sps_flags>`
.. _h264_sps_constraints_set_flags:
``Sequence Parameter Set Constraints Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SPS_CONSTRAINT_SET0_FLAG``
- 0x00000001
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET1_FLAG``
- 0x00000002
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET2_FLAG``
- 0x00000004
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET3_FLAG``
- 0x00000008
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET4_FLAG``
- 0x00000010
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET5_FLAG``
- 0x00000020
-
.. _h264_sps_flags:
``Sequence Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE``
- 0x00000001
-
* - ``V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS``
- 0x00000002
-
* - ``V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO``
- 0x00000004
-
* - ``V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED``
- 0x00000008
-
* - ``V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY``
- 0x00000010
-
* - ``V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD``
- 0x00000020
-
* - ``V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE``
- 0x00000040
-
``V4L2_CID_STATELESS_H264_PPS (struct)``
Specifies the picture parameter set (as extracted from the
bitstream) for the associated H264 slice data. This includes the
necessary parameters for configuring a stateless hardware decoding
pipeline for H264. The bitstream parameters are defined according
to :ref:`h264`, section 7.4.2.2 "Picture Parameter Set RBSP
Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. c:type:: v4l2_ctrl_h264_pps
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_pps
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``pic_parameter_set_id``
-
* - __u8
- ``seq_parameter_set_id``
-
* - __u8
- ``num_slice_groups_minus1``
-
* - __u8
- ``num_ref_idx_l0_default_active_minus1``
-
* - __u8
- ``num_ref_idx_l1_default_active_minus1``
-
* - __u8
- ``weighted_bipred_idc``
-
* - __s8
- ``pic_init_qp_minus26``
-
* - __s8
- ``pic_init_qs_minus26``
-
* - __s8
- ``chroma_qp_index_offset``
-
* - __s8
- ``second_chroma_qp_index_offset``
-
* - __u16
- ``flags``
- See :ref:`Picture Parameter Set Flags <h264_pps_flags>`
.. _h264_pps_flags:
``Picture Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE``
- 0x00000001
-
* - ``V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT``
- 0x00000002
-
* - ``V4L2_H264_PPS_FLAG_WEIGHTED_PRED``
- 0x00000004
-
* - ``V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
- 0x00000008
-
* - ``V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED``
- 0x00000010
-
* - ``V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT``
- 0x00000020
-
* - ``V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE``
- 0x00000040
-
* - ``V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT``
- 0x00000080
- Indicates that ``V4L2_CID_STATELESS_H264_SCALING_MATRIX``
must be used for this picture.
``V4L2_CID_STATELESS_H264_SCALING_MATRIX (struct)``
Specifies the scaling matrix (as extracted from the bitstream) for
the associated H264 slice data. The bitstream parameters are
defined according to :ref:`h264`, section 7.4.2.1.1.1 "Scaling
List Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. c:type:: v4l2_ctrl_h264_scaling_matrix
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_scaling_matrix
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``scaling_list_4x4[6][16]``
- Scaling matrix after applying the inverse scanning process.
Expected list order is Intra Y, Intra Cb, Intra Cr, Inter Y,
Inter Cb, Inter Cr. The values on each scaling list are
expected in raster scan order.
* - __u8
- ``scaling_list_8x8[6][64]``
- Scaling matrix after applying the inverse scanning process.
Expected list order is Intra Y, Inter Y, Intra Cb, Inter Cb,
Intra Cr, Inter Cr. The values on each scaling list are
expected in raster scan order.
``V4L2_CID_STATELESS_H264_SLICE_PARAMS (struct)``
Specifies the slice parameters (as extracted from the bitstream)
for the associated H264 slice data. This includes the necessary
parameters for configuring a stateless hardware decoding pipeline
for H264. The bitstream parameters are defined according to
:ref:`h264`, section 7.4.3 "Slice Header Semantics". For further
documentation, refer to the above specification, unless there is
an explicit comment stating otherwise.
.. c:type:: v4l2_ctrl_h264_slice_params
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_slice_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u32
- ``header_bit_size``
- Offset in bits to slice_data() from the beginning of this slice.
* - __u32
- ``first_mb_in_slice``
-
* - __u8
- ``slice_type``
-
* - __u8
- ``colour_plane_id``
-
* - __u8
- ``redundant_pic_cnt``
-
* - __u8
- ``cabac_init_idc``
-
* - __s8
- ``slice_qp_delta``
-
* - __s8
- ``slice_qs_delta``
-
* - __u8
- ``disable_deblocking_filter_idc``
-
* - __s8
- ``slice_alpha_c0_offset_div2``
-
* - __s8
- ``slice_beta_offset_div2``
-
* - __u8
- ``num_ref_idx_l0_active_minus1``
- If num_ref_idx_active_override_flag is not set, this field must be
set to the value of num_ref_idx_l0_default_active_minus1.
* - __u8
- ``num_ref_idx_l1_active_minus1``
- If num_ref_idx_active_override_flag is not set, this field must be
set to the value of num_ref_idx_l1_default_active_minus1.
* - __u8
- ``reserved``
- Applications and drivers must set this to zero.
* - struct :c:type:`v4l2_h264_reference`
- ``ref_pic_list0[32]``
- Reference picture list after applying the per-slice modifications
* - struct :c:type:`v4l2_h264_reference`
- ``ref_pic_list1[32]``
- Reference picture list after applying the per-slice modifications
* - __u32
- ``flags``
- See :ref:`Slice Parameter Flags <h264_slice_flags>`
.. _h264_slice_flags:
``Slice Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED``
- 0x00000001
-
* - ``V4L2_H264_SLICE_FLAG_SP_FOR_SWITCH``
- 0x00000002
-
``V4L2_CID_STATELESS_H264_PRED_WEIGHTS (struct)``
Prediction weight table defined according to :ref:`h264`,
section 7.4.3.2 "Prediction Weight Table Semantics".
The prediction weight table must be passed by applications
under the conditions explained in section 7.3.3 "Slice header
syntax".
.. c:type:: v4l2_ctrl_h264_pred_weights
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_pred_weights
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u16
- ``luma_log2_weight_denom``
-
* - __u16
- ``chroma_log2_weight_denom``
-
* - struct :c:type:`v4l2_h264_weight_factors`
- ``weight_factors[2]``
- The weight factors at index 0 are the weight factors for the reference
list 0, the one at index 1 for the reference list 1.
.. c:type:: v4l2_h264_weight_factors
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_weight_factors
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __s16
- ``luma_weight[32]``
-
* - __s16
- ``luma_offset[32]``
-
* - __s16
- ``chroma_weight[32][2]``
-
* - __s16
- ``chroma_offset[32][2]``
-
``Picture Reference``
.. c:type:: v4l2_h264_reference
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_reference
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``fields``
- Specifies how the picture is referenced. See :ref:`Reference Fields <h264_ref_fields>`
* - __u8
- ``index``
- Index into the :c:type:`v4l2_ctrl_h264_decode_params`.dpb array.
.. _h264_ref_fields:
``Reference Fields``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_TOP_FIELD_REF``
- 0x1
- The top field in field pair is used for short-term reference.
* - ``V4L2_H264_BOTTOM_FIELD_REF``
- 0x2
- The bottom field in field pair is used for short-term reference.
* - ``V4L2_H264_FRAME_REF``
- 0x3
- The frame (or the top/bottom fields, if it's a field pair)
is used for short-term reference.
``V4L2_CID_STATELESS_H264_DECODE_PARAMS (struct)``
Specifies the decode parameters (as extracted from the bitstream)
for the associated H264 slice data. This includes the necessary
parameters for configuring a stateless hardware decoding pipeline
for H264. The bitstream parameters are defined according to
:ref:`h264`. For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. c:type:: v4l2_ctrl_h264_decode_params
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_decode_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - struct :c:type:`v4l2_h264_dpb_entry`
- ``dpb[16]``
-
* - __u16
- ``nal_ref_idc``
- NAL reference ID value coming from the NAL Unit header
* - __u16
- ``frame_num``
-
* - __s32
- ``top_field_order_cnt``
- Picture Order Count for the coded top field
* - __s32
- ``bottom_field_order_cnt``
- Picture Order Count for the coded bottom field
* - __u16
- ``idr_pic_id``
-
* - __u16
- ``pic_order_cnt_lsb``
-
* - __s32
- ``delta_pic_order_cnt_bottom``
-
* - __s32
- ``delta_pic_order_cnt0``
-
* - __s32
- ``delta_pic_order_cnt1``
-
* - __u32
- ``dec_ref_pic_marking_bit_size``
- Size in bits of the dec_ref_pic_marking() syntax element.
* - __u32
- ``pic_order_cnt_bit_size``
- Combined size in bits of the picture order count related syntax
elements: pic_order_cnt_lsb, delta_pic_order_cnt_bottom,
delta_pic_order_cnt0, and delta_pic_order_cnt1.
* - __u32
- ``slice_group_change_cycle``
-
* - __u32
- ``reserved``
- Applications and drivers must set this to zero.
* - __u32
- ``flags``
- See :ref:`Decode Parameters Flags <h264_decode_params_flags>`
.. _h264_decode_params_flags:
``Decode Parameters Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_DECODE_PARAM_FLAG_IDR_PIC``
- 0x00000001
- That picture is an IDR picture
* - ``V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC``
- 0x00000002
-
* - ``V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD``
- 0x00000004
-
.. c:type:: v4l2_h264_dpb_entry
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_dpb_entry
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u64
- ``reference_ts``
- Timestamp of the V4L2 capture buffer to use as reference, used
with B-coded and P-coded frames. The timestamp refers to the
``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
:c:func:`v4l2_timeval_to_ns()` function to convert the struct
:c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
* - __u32
- ``pic_num``
-
* - __u16
- ``frame_num``
-
* - __u8
- ``fields``
- Specifies how the DPB entry is referenced. See :ref:`Reference Fields <h264_ref_fields>`
* - __u8
- ``reserved[5]``
- Applications and drivers must set this to zero.
* - __s32
- ``top_field_order_cnt``
-
* - __s32
- ``bottom_field_order_cnt``
-
* - __u32
- ``flags``
- See :ref:`DPB Entry Flags <h264_dpb_flags>`
.. _h264_dpb_flags:
``DPB Entries Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_DPB_ENTRY_FLAG_VALID``
- 0x00000001
- The DPB entry is valid (non-empty) and should be considered.
* - ``V4L2_H264_DPB_ENTRY_FLAG_ACTIVE``
- 0x00000002
- The DPB entry is used for reference.
* - ``V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM``
- 0x00000004
- The DPB entry is used for long-term reference.
* - ``V4L2_H264_DPB_ENTRY_FLAG_FIELD``
- 0x00000008
- The DPB entry is a single field or a complementary field pair.
``V4L2_CID_STATELESS_H264_DECODE_MODE (enum)``
Specifies the decoding mode to use. Currently exposes slice-based and
frame-based decoding but new modes might be added later on.
This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
are required to set this control in order to specify the decoding mode
that is expected for the buffer.
Drivers may expose a single or multiple decoding modes, depending
on what they can support.
.. c:type:: v4l2_stateless_h264_decode_mode
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_STATELESS_H264_DECODE_MODE_SLICE_BASED``
- 0
- Decoding is done at the slice granularity.
The OUTPUT buffer must contain a single slice.
When this mode is selected, the ``V4L2_CID_STATELESS_H264_SLICE_PARAMS``
control shall be set. When multiple slices compose a frame,
use of ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` flag
is required.
* - ``V4L2_STATELESS_H264_DECODE_MODE_FRAME_BASED``
- 1
- Decoding is done at the frame granularity,
The OUTPUT buffer must contain all slices needed to decode the
frame. The OUTPUT buffer must also contain both fields.
This mode will be supported by devices that
parse the slice(s) header(s) in hardware. When this mode is
selected, the ``V4L2_CID_STATELESS_H264_SLICE_PARAMS``
control shall not be set.
``V4L2_CID_STATELESS_H264_START_CODE (enum)``
Specifies the H264 slice start code expected for each slice.
This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
are required to set this control in order to specify the start code
that is expected for the buffer.
Drivers may expose a single or multiple start codes, depending
on what they can support.
.. c:type:: v4l2_stateless_h264_start_code
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_STATELESS_H264_START_CODE_NONE``
- 0
- Selecting this value specifies that H264 slices are passed
to the driver without any start code.
* - ``V4L2_STATELESS_H264_START_CODE_ANNEX_B``
- 1
- Selecting this value specifies that H264 slices are expected
to be prefixed by Annex B start codes. According to :ref:`h264`
valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001.
.. _codec-stateless-fwht:
``V4L2_CID_STATELESS_FWHT_PARAMS (struct)``
Specifies the FWHT (Fast Walsh Hadamard Transform) parameters (as extracted
from the bitstream) for the associated FWHT data. This includes the necessary
parameters for configuring a stateless hardware decoding pipeline for FWHT.
This codec is specific to the vicodec test driver.
.. c:type:: v4l2_ctrl_fwht_params
.. cssclass:: longtable
.. tabularcolumns:: |p{1.4cm}|p{4.3cm}|p{11.8cm}|
.. flat-table:: struct v4l2_ctrl_fwht_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u64
- ``backward_ref_ts``
- Timestamp of the V4L2 capture buffer to use as backward reference, used
with P-coded frames. The timestamp refers to the
``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
:c:func:`v4l2_timeval_to_ns()` function to convert the struct
:c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
* - __u32
- ``version``
- The version of the codec. Set to ``V4L2_FWHT_VERSION``.
* - __u32
- ``width``
- The width of the frame.
* - __u32
- ``height``
- The height of the frame.
* - __u32
- ``flags``
- The flags of the frame, see :ref:`fwht-flags`.
* - __u32
- ``colorspace``
- The colorspace of the frame, from enum :c:type:`v4l2_colorspace`.
* - __u32
- ``xfer_func``
- The transfer function, from enum :c:type:`v4l2_xfer_func`.
* - __u32
- ``ycbcr_enc``
- The Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
* - __u32
- ``quantization``
- The quantization range, from enum :c:type:`v4l2_quantization`.
.. _fwht-flags:
FWHT Flags
==========
.. cssclass:: longtable
.. tabularcolumns:: |p{6.8cm}|p{2.4cm}|p{8.3cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 3 1 4
* - ``V4L2_FWHT_FL_IS_INTERLACED``
- 0x00000001
- Set if this is an interlaced format.
* - ``V4L2_FWHT_FL_IS_BOTTOM_FIRST``
- 0x00000002
- Set if this is a bottom-first (NTSC) interlaced format.
* - ``V4L2_FWHT_FL_IS_ALTERNATE``
- 0x00000004
- Set if each 'frame' contains just one field.
* - ``V4L2_FWHT_FL_IS_BOTTOM_FIELD``
- 0x00000008
- If V4L2_FWHT_FL_IS_ALTERNATE was set, then this is set if this 'frame' is the
bottom field, else it is the top field.
* - ``V4L2_FWHT_FL_LUMA_IS_UNCOMPRESSED``
- 0x00000010
- Set if the Y' (luma) plane is uncompressed.
* - ``V4L2_FWHT_FL_CB_IS_UNCOMPRESSED``
- 0x00000020
- Set if the Cb plane is uncompressed.
* - ``V4L2_FWHT_FL_CR_IS_UNCOMPRESSED``
- 0x00000040
- Set if the Cr plane is uncompressed.
* - ``V4L2_FWHT_FL_CHROMA_FULL_HEIGHT``
- 0x00000080
- Set if the chroma plane has the same height as the luma plane,
else the chroma plane is half the height of the luma plane.
* - ``V4L2_FWHT_FL_CHROMA_FULL_WIDTH``
- 0x00000100
- Set if the chroma plane has the same width as the luma plane,
else the chroma plane is half the width of the luma plane.
* - ``V4L2_FWHT_FL_ALPHA_IS_UNCOMPRESSED``
- 0x00000200
- Set if the alpha plane is uncompressed.
* - ``V4L2_FWHT_FL_I_FRAME``
- 0x00000400
- Set if this is an I-frame.
* - ``V4L2_FWHT_FL_COMPONENTS_NUM_MSK``
- 0x00070000
- The number of color components - 1.
* - ``V4L2_FWHT_FL_PIXENC_MSK``
- 0x00180000
- The mask for the pixel encoding.
* - ``V4L2_FWHT_FL_PIXENC_YUV``
- 0x00080000
- Set if the pixel encoding is YUV.
* - ``V4L2_FWHT_FL_PIXENC_RGB``
- 0x00100000
- Set if the pixel encoding is RGB.
* - ``V4L2_FWHT_FL_PIXENC_HSV``
- 0x00180000
- Set if the pixel encoding is HSV.

817
Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
View File

@ -1,6 +1,6 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _mpeg-controls:
.. _codec-controls:
***********************
Codec Control Reference
@ -26,7 +26,7 @@ Generic Codec Controls
Codec Control IDs
-----------------
``V4L2_CID_MPEG_CLASS (class)``
``V4L2_CID_CODEC_CLASS (class)``
The Codec class descriptor. Calling
:ref:`VIDIOC_QUERYCTRL` for this control will
return a description of this control class. This description can be
@ -1502,698 +1502,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
- Layer number
.. _v4l2-mpeg-h264:
``V4L2_CID_MPEG_VIDEO_H264_SPS (struct)``
Specifies the sequence parameter set (as extracted from the
bitstream) for the associated H264 slice data. This includes the
necessary parameters for configuring a stateless hardware decoding
pipeline for H264. The bitstream parameters are defined according
to :ref:`h264`, section 7.4.2.1.1 "Sequence Parameter Set Data
Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_sps
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_sps
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``profile_idc``
-
* - __u8
- ``constraint_set_flags``
- See :ref:`Sequence Parameter Set Constraints Set Flags <h264_sps_constraints_set_flags>`
* - __u8
- ``level_idc``
-
* - __u8
- ``seq_parameter_set_id``
-
* - __u8
- ``chroma_format_idc``
-
* - __u8
- ``bit_depth_luma_minus8``
-
* - __u8
- ``bit_depth_chroma_minus8``
-
* - __u8
- ``log2_max_frame_num_minus4``
-
* - __u8
- ``pic_order_cnt_type``
-
* - __u8
- ``log2_max_pic_order_cnt_lsb_minus4``
-
* - __u8
- ``max_num_ref_frames``
-
* - __u8
- ``num_ref_frames_in_pic_order_cnt_cycle``
-
* - __s32
- ``offset_for_ref_frame[255]``
-
* - __s32
- ``offset_for_non_ref_pic``
-
* - __s32
- ``offset_for_top_to_bottom_field``
-
* - __u16
- ``pic_width_in_mbs_minus1``
-
* - __u16
- ``pic_height_in_map_units_minus1``
-
* - __u32
- ``flags``
- See :ref:`Sequence Parameter Set Flags <h264_sps_flags>`
.. _h264_sps_constraints_set_flags:
``Sequence Parameter Set Constraints Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SPS_CONSTRAINT_SET0_FLAG``
- 0x00000001
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET1_FLAG``
- 0x00000002
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET2_FLAG``
- 0x00000004
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET3_FLAG``
- 0x00000008
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET4_FLAG``
- 0x00000010
-
* - ``V4L2_H264_SPS_CONSTRAINT_SET5_FLAG``
- 0x00000020
-
.. _h264_sps_flags:
``Sequence Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SPS_FLAG_SEPARATE_COLOUR_PLANE``
- 0x00000001
-
* - ``V4L2_H264_SPS_FLAG_QPPRIME_Y_ZERO_TRANSFORM_BYPASS``
- 0x00000002
-
* - ``V4L2_H264_SPS_FLAG_DELTA_PIC_ORDER_ALWAYS_ZERO``
- 0x00000004
-
* - ``V4L2_H264_SPS_FLAG_GAPS_IN_FRAME_NUM_VALUE_ALLOWED``
- 0x00000008
-
* - ``V4L2_H264_SPS_FLAG_FRAME_MBS_ONLY``
- 0x00000010
-
* - ``V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD``
- 0x00000020
-
* - ``V4L2_H264_SPS_FLAG_DIRECT_8X8_INFERENCE``
- 0x00000040
-
``V4L2_CID_MPEG_VIDEO_H264_PPS (struct)``
Specifies the picture parameter set (as extracted from the
bitstream) for the associated H264 slice data. This includes the
necessary parameters for configuring a stateless hardware decoding
pipeline for H264. The bitstream parameters are defined according
to :ref:`h264`, section 7.4.2.2 "Picture Parameter Set RBSP
Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_pps
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_pps
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``pic_parameter_set_id``
-
* - __u8
- ``seq_parameter_set_id``
-
* - __u8
- ``num_slice_groups_minus1``
-
* - __u8
- ``num_ref_idx_l0_default_active_minus1``
-
* - __u8
- ``num_ref_idx_l1_default_active_minus1``
-
* - __u8
- ``weighted_bipred_idc``
-
* - __s8
- ``pic_init_qp_minus26``
-
* - __s8
- ``pic_init_qs_minus26``
-
* - __s8
- ``chroma_qp_index_offset``
-
* - __s8
- ``second_chroma_qp_index_offset``
-
* - __u16
- ``flags``
- See :ref:`Picture Parameter Set Flags <h264_pps_flags>`
.. _h264_pps_flags:
``Picture Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_PPS_FLAG_ENTROPY_CODING_MODE``
- 0x00000001
-
* - ``V4L2_H264_PPS_FLAG_BOTTOM_FIELD_PIC_ORDER_IN_FRAME_PRESENT``
- 0x00000002
-
* - ``V4L2_H264_PPS_FLAG_WEIGHTED_PRED``
- 0x00000004
-
* - ``V4L2_H264_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT``
- 0x00000008
-
* - ``V4L2_H264_PPS_FLAG_CONSTRAINED_INTRA_PRED``
- 0x00000010
-
* - ``V4L2_H264_PPS_FLAG_REDUNDANT_PIC_CNT_PRESENT``
- 0x00000020
-
* - ``V4L2_H264_PPS_FLAG_TRANSFORM_8X8_MODE``
- 0x00000040
-
* - ``V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT``
- 0x00000080
- Indicates that ``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX``
must be used for this picture.
``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX (struct)``
Specifies the scaling matrix (as extracted from the bitstream) for
the associated H264 slice data. The bitstream parameters are
defined according to :ref:`h264`, section 7.4.2.1.1.1 "Scaling
List Semantics". For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_scaling_matrix
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_scaling_matrix
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``scaling_list_4x4[6][16]``
- Scaling matrix after applying the inverse scanning process.
Expected list order is Intra Y, Intra Cb, Intra Cr, Inter Y,
Inter Cb, Inter Cr. The values on each scaling list are
expected in raster scan order.
* - __u8
- ``scaling_list_8x8[6][64]``
- Scaling matrix after applying the inverse scanning process.
Expected list order is Intra Y, Inter Y, Intra Cb, Inter Cb,
Intra Cr, Inter Cr. The values on each scaling list are
expected in raster scan order.
``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS (struct)``
Specifies the slice parameters (as extracted from the bitstream)
for the associated H264 slice data. This includes the necessary
parameters for configuring a stateless hardware decoding pipeline
for H264. The bitstream parameters are defined according to
:ref:`h264`, section 7.4.3 "Slice Header Semantics". For further
documentation, refer to the above specification, unless there is
an explicit comment stating otherwise.
.. note::
This compound control is not yet part of the public kernel API
and it is expected to change.
.. c:type:: v4l2_ctrl_h264_slice_params
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_slice_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u32
- ``header_bit_size``
- Offset in bits to slice_data() from the beginning of this slice.
* - __u32
- ``first_mb_in_slice``
-
* - __u8
- ``slice_type``
-
* - __u8
- ``colour_plane_id``
-
* - __u8
- ``redundant_pic_cnt``
-
* - __u8
- ``cabac_init_idc``
-
* - __s8
- ``slice_qp_delta``
-
* - __s8
- ``slice_qs_delta``
-
* - __u8
- ``disable_deblocking_filter_idc``
-
* - __s8
- ``slice_alpha_c0_offset_div2``
-
* - __s8
- ``slice_beta_offset_div2``
-
* - __u8
- ``num_ref_idx_l0_active_minus1``
- If num_ref_idx_active_override_flag is not set, this field must be
set to the value of num_ref_idx_l0_default_active_minus1.
* - __u8
- ``num_ref_idx_l1_active_minus1``
- If num_ref_idx_active_override_flag is not set, this field must be
set to the value of num_ref_idx_l1_default_active_minus1.
* - __u8
- ``reserved``
- Applications and drivers must set this to zero.
* - struct :c:type:`v4l2_h264_reference`
- ``ref_pic_list0[32]``
- Reference picture list after applying the per-slice modifications
* - struct :c:type:`v4l2_h264_reference`
- ``ref_pic_list1[32]``
- Reference picture list after applying the per-slice modifications
* - __u32
- ``flags``
- See :ref:`Slice Parameter Flags <h264_slice_flags>`
.. _h264_slice_flags:
``Slice Parameter Set Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_SLICE_FLAG_DIRECT_SPATIAL_MV_PRED``
- 0x00000001
-
* - ``V4L2_H264_SLICE_FLAG_SP_FOR_SWITCH``
- 0x00000002
-
``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS (struct)``
Prediction weight table defined according to :ref:`h264`,
section 7.4.3.2 "Prediction Weight Table Semantics".
The prediction weight table must be passed by applications
under the conditions explained in section 7.3.3 "Slice header
syntax".
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_pred_weights
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_pred_weights
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u16
- ``luma_log2_weight_denom``
-
* - __u16
- ``chroma_log2_weight_denom``
-
* - struct :c:type:`v4l2_h264_weight_factors`
- ``weight_factors[2]``
- The weight factors at index 0 are the weight factors for the reference
list 0, the one at index 1 for the reference list 1.
.. c:type:: v4l2_h264_weight_factors
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_weight_factors
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __s16
- ``luma_weight[32]``
-
* - __s16
- ``luma_offset[32]``
-
* - __s16
- ``chroma_weight[32][2]``
-
* - __s16
- ``chroma_offset[32][2]``
-
``Picture Reference``
.. c:type:: v4l2_h264_reference
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_reference
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u8
- ``fields``
- Specifies how the picture is referenced. See :ref:`Reference Fields <h264_ref_fields>`
* - __u8
- ``index``
- Index into the :c:type:`v4l2_ctrl_h264_decode_params`.dpb array.
.. _h264_ref_fields:
``Reference Fields``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_TOP_FIELD_REF``
- 0x1
- The top field in field pair is used for short-term reference.
* - ``V4L2_H264_BOTTOM_FIELD_REF``
- 0x2
- The bottom field in field pair is used for short-term reference.
* - ``V4L2_H264_FRAME_REF``
- 0x3
- The frame (or the top/bottom fields, if it's a field pair)
is used for short-term reference.
``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)``
Specifies the decode parameters (as extracted from the bitstream)
for the associated H264 slice data. This includes the necessary
parameters for configuring a stateless hardware decoding pipeline
for H264. The bitstream parameters are defined according to
:ref:`h264`. For further documentation, refer to the above
specification, unless there is an explicit comment stating
otherwise.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_h264_decode_params
.. cssclass:: longtable
.. flat-table:: struct v4l2_ctrl_h264_decode_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - struct :c:type:`v4l2_h264_dpb_entry`
- ``dpb[16]``
-
* - __u16
- ``nal_ref_idc``
- NAL reference ID value coming from the NAL Unit header
* - __u16
- ``frame_num``
-
* - __s32
- ``top_field_order_cnt``
- Picture Order Count for the coded top field
* - __s32
- ``bottom_field_order_cnt``
- Picture Order Count for the coded bottom field
* - __u16
- ``idr_pic_id``
-
* - __u16
- ``pic_order_cnt_lsb``
-
* - __s32
- ``delta_pic_order_cnt_bottom``
-
* - __s32
- ``delta_pic_order_cnt0``
-
* - __s32
- ``delta_pic_order_cnt1``
-
* - __u32
- ``dec_ref_pic_marking_bit_size``
- Size in bits of the dec_ref_pic_marking() syntax element.
* - __u32
- ``pic_order_cnt_bit_size``
- Combined size in bits of the picture order count related syntax
elements: pic_order_cnt_lsb, delta_pic_order_cnt_bottom,
delta_pic_order_cnt0, and delta_pic_order_cnt1.
* - __u32
- ``slice_group_change_cycle``
-
* - __u32
- ``reserved``
- Applications and drivers must set this to zero.
* - __u32
- ``flags``
- See :ref:`Decode Parameters Flags <h264_decode_params_flags>`
.. _h264_decode_params_flags:
``Decode Parameters Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_DECODE_PARAM_FLAG_IDR_PIC``
- 0x00000001
- That picture is an IDR picture
* - ``V4L2_H264_DECODE_PARAM_FLAG_FIELD_PIC``
- 0x00000002
-
* - ``V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD``
- 0x00000004
-
.. c:type:: v4l2_h264_dpb_entry
.. cssclass:: longtable
.. flat-table:: struct v4l2_h264_dpb_entry
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u64
- ``reference_ts``
- Timestamp of the V4L2 capture buffer to use as reference, used
with B-coded and P-coded frames. The timestamp refers to the
``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
:c:func:`v4l2_timeval_to_ns()` function to convert the struct
:c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
* - __u32
- ``pic_num``
-
* - __u16
- ``frame_num``
-
* - __u8
- ``fields``
- Specifies how the DPB entry is referenced. See :ref:`Reference Fields <h264_ref_fields>`
* - __u8
- ``reserved[5]``
- Applications and drivers must set this to zero.
* - __s32
- ``top_field_order_cnt``
-
* - __s32
- ``bottom_field_order_cnt``
-
* - __u32
- ``flags``
- See :ref:`DPB Entry Flags <h264_dpb_flags>`
.. _h264_dpb_flags:
``DPB Entries Flags``
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_H264_DPB_ENTRY_FLAG_VALID``
- 0x00000001
- The DPB entry is valid (non-empty) and should be considered.
* - ``V4L2_H264_DPB_ENTRY_FLAG_ACTIVE``
- 0x00000002
- The DPB entry is used for reference.
* - ``V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM``
- 0x00000004
- The DPB entry is used for long-term reference.
* - ``V4L2_H264_DPB_ENTRY_FLAG_FIELD``
- 0x00000008
- The DPB entry is a single field or a complementary field pair.
``V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE (enum)``
Specifies the decoding mode to use. Currently exposes slice-based and
frame-based decoding but new modes might be added later on.
This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
are required to set this control in order to specify the decoding mode
that is expected for the buffer.
Drivers may expose a single or multiple decoding modes, depending
on what they can support.
.. note::
This menu control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_mpeg_video_h264_decode_mode
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_MPEG_VIDEO_H264_DECODE_MODE_SLICE_BASED``
- 0
- Decoding is done at the slice granularity.
The OUTPUT buffer must contain a single slice.
When this mode is selected, the ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS``
control shall be set. When multiple slices compose a frame,
use of ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` flag
is required.
* - ``V4L2_MPEG_VIDEO_H264_DECODE_MODE_FRAME_BASED``
- 1
- Decoding is done at the frame granularity,
The OUTPUT buffer must contain all slices needed to decode the
frame. The OUTPUT buffer must also contain both fields.
This mode will be supported by devices that
parse the slice(s) header(s) in hardware. When this mode is
selected, the ``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS``
control shall not be set.
``V4L2_CID_MPEG_VIDEO_H264_START_CODE (enum)``
Specifies the H264 slice start code expected for each slice.
This control is used as a modifier for V4L2_PIX_FMT_H264_SLICE
pixel format. Applications that support V4L2_PIX_FMT_H264_SLICE
are required to set this control in order to specify the start code
that is expected for the buffer.
Drivers may expose a single or multiple start codes, depending
on what they can support.
.. note::
This menu control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_mpeg_video_h264_start_code
.. cssclass:: longtable
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - ``V4L2_MPEG_VIDEO_H264_START_CODE_NONE``
- 0
- Selecting this value specifies that H264 slices are passed
to the driver without any start code.
* - ``V4L2_MPEG_VIDEO_H264_START_CODE_ANNEX_B``
- 1
- Selecting this value specifies that H264 slices are expected
to be prefixed by Annex B start codes. According to :ref:`h264`
valid start codes can be 3-bytes 0x000001 or 4-bytes 0x00000001.
.. _v4l2-mpeg-mpeg2:
``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)``
@ -2905,127 +2213,6 @@ enum v4l2_mpeg_mfc51_video_force_frame_type -
- Force a non-coded frame.
.. _v4l2-mpeg-fwht:
``V4L2_CID_MPEG_VIDEO_FWHT_PARAMS (struct)``
Specifies the fwht parameters (as extracted from the bitstream) for the
associated FWHT data. This includes the necessary parameters for
configuring a stateless hardware decoding pipeline for FWHT.
.. note::
This compound control is not yet part of the public kernel API and
it is expected to change.
.. c:type:: v4l2_ctrl_fwht_params
.. cssclass:: longtable
.. tabularcolumns:: |p{1.4cm}|p{4.3cm}|p{11.8cm}|
.. flat-table:: struct v4l2_ctrl_fwht_params
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u64
- ``backward_ref_ts``
- Timestamp of the V4L2 capture buffer to use as backward reference, used
with P-coded frames. The timestamp refers to the
``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
:c:func:`v4l2_timeval_to_ns()` function to convert the struct
:c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
* - __u32
- ``version``
- The version of the codec
* - __u32
- ``width``
- The width of the frame
* - __u32
- ``height``
- The height of the frame
* - __u32
- ``flags``
- The flags of the frame, see :ref:`fwht-flags`.
* - __u32
- ``colorspace``
- The colorspace of the frame, from enum :c:type:`v4l2_colorspace`.
* - __u32
- ``xfer_func``
- The transfer function, from enum :c:type:`v4l2_xfer_func`.
* - __u32
- ``ycbcr_enc``
- The Y'CbCr encoding, from enum :c:type:`v4l2_ycbcr_encoding`.
* - __u32
- ``quantization``
- The quantization range, from enum :c:type:`v4l2_quantization`.
.. _fwht-flags:
FWHT Flags
============
.. cssclass:: longtable
.. tabularcolumns:: |p{6.8cm}|p{2.4cm}|p{8.3cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 3 1 4
* - ``FWHT_FL_IS_INTERLACED``
- 0x00000001
- Set if this is an interlaced format
* - ``FWHT_FL_IS_BOTTOM_FIRST``
- 0x00000002
- Set if this is a bottom-first (NTSC) interlaced format
* - ``FWHT_FL_IS_ALTERNATE``
- 0x00000004
- Set if each 'frame' contains just one field
* - ``FWHT_FL_IS_BOTTOM_FIELD``
- 0x00000008
- If FWHT_FL_IS_ALTERNATE was set, then this is set if this 'frame' is the
bottom field, else it is the top field.
* - ``FWHT_FL_LUMA_IS_UNCOMPRESSED``
- 0x00000010
- Set if the luma plane is uncompressed
* - ``FWHT_FL_CB_IS_UNCOMPRESSED``
- 0x00000020
- Set if the cb plane is uncompressed
* - ``FWHT_FL_CR_IS_UNCOMPRESSED``
- 0x00000040
- Set if the cr plane is uncompressed
* - ``FWHT_FL_CHROMA_FULL_HEIGHT``
- 0x00000080
- Set if the chroma plane has the same height as the luma plane,
else the chroma plane is half the height of the luma plane
* - ``FWHT_FL_CHROMA_FULL_WIDTH``
- 0x00000100
- Set if the chroma plane has the same width as the luma plane,
else the chroma plane is half the width of the luma plane
* - ``FWHT_FL_ALPHA_IS_UNCOMPRESSED``
- 0x00000200
- Set if the alpha plane is uncompressed
* - ``FWHT_FL_I_FRAME``
- 0x00000400
- Set if this is an I-frame
* - ``FWHT_FL_COMPONENTS_NUM_MSK``
- 0x00070000
- A 4-values flag - the number of components - 1
* - ``FWHT_FL_PIXENC_YUV``
- 0x00080000
- Set if the pixel encoding is YUV
* - ``FWHT_FL_PIXENC_RGB``
- 0x00100000
- Set if the pixel encoding is RGB
* - ``FWHT_FL_PIXENC_HSV``
- 0x00180000
- Set if the pixel encoding is HSV
CX2341x MPEG Controls
=====================

14
Documentation/userspace-api/media/v4l/ext-ctrls-image-source.rst
View File

@ -58,3 +58,17 @@ Image Source Control IDs
The unit cell consists of the whole area of the pixel, sensitive and
non-sensitive.
This control is required for automatic calibration of sensors/cameras.
.. c:type:: v4l2_area
.. flat-table:: struct v4l2_area
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
* - __u32
- ``width``
- Width of the area.
* - __u32
- ``height``
- Height of the area.

8
Documentation/userspace-api/media/v4l/extended-controls.rst
View File

@ -55,8 +55,8 @@ controls in that array and a control class. Control classes are used to
group similar controls into a single class. For example, control class
``V4L2_CTRL_CLASS_USER`` contains all user controls (i. e. all controls
that can also be set using the old :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>`
ioctl). Control class ``V4L2_CTRL_CLASS_MPEG`` contains all controls
relating to MPEG encoding, etc.
ioctl). Control class ``V4L2_CTRL_CLASS_CODEC`` contains controls
relating to codecs.
All controls in the control array must belong to the specified control
class. An error is returned if this is not the case.
@ -130,9 +130,9 @@ control class is found:
.. code-block:: c
qctrl.id = V4L2_CTRL_CLASS_MPEG | V4L2_CTRL_FLAG_NEXT_CTRL;
qctrl.id = V4L2_CTRL_CLASS_CODEC | V4L2_CTRL_FLAG_NEXT_CTRL;
while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &qctrl)) {
if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_MPEG)
if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_CODEC)
break;
/* ... */
qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;

37
Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
View File

@ -57,18 +57,18 @@ Compressed Formats
- H264 parsed slice data, including slice headers, either with or
without the start code, as extracted from the H264 bitstream.
This format is adapted for stateless video decoders that implement an
H264 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`).
H264 pipeline with the :ref:`stateless_decoder`.
This pixelformat has two modifiers that must be set at least once
through the ``V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE``
and ``V4L2_CID_MPEG_VIDEO_H264_START_CODE`` controls.
through the ``V4L2_CID_STATELESS_H264_DECODE_MODE``
and ``V4L2_CID_STATELESS_H264_START_CODE`` controls.
In addition, metadata associated with the frame to decode are
required to be passed through the ``V4L2_CID_MPEG_VIDEO_H264_SPS``,
``V4L2_CID_MPEG_VIDEO_H264_PPS``,
``V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX``,
``V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS`` and
``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS`` controls. See the
:ref:`associated Codec Control IDs <v4l2-mpeg-h264>`. Exactly
one output and one capture buffer must be provided for use
required to be passed through the ``V4L2_CID_STATELESS_H264_SPS``,
``V4L2_CID_STATELESS_H264_PPS``,
``V4L2_CID_STATELESS_H264_SCALING_MATRIX``,
``V4L2_CID_STATELESS_H264_SLICE_PARAMS`` and
``V4L2_CID_STATELESS_H264_DECODE_PARAMS`` controls. See the
:ref:`associated Codec Control IDs <v4l2-codec-stateless-h264>`.
Exactly one output and one capture buffer must be provided for use
with this pixel format. The output buffer must contain the
appropriate number of macroblocks to decode a full
corresponding frame to the matching capture buffer.
@ -77,11 +77,6 @@ Compressed Formats
7.3.2.8 "Slice layer without partitioning RBSP syntax" and the following
sections.
.. note::
This format is not yet part of the public kernel API and it
is expected to change.
* .. _V4L2-PIX-FMT-H263:
- ``V4L2_PIX_FMT_H263``
@ -196,10 +191,10 @@ Compressed Formats
through the ``V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE``
and ``V4L2_CID_MPEG_VIDEO_HEVC_START_CODE`` controls.
Metadata associated with the frame to decode is required to be passed
through the following controls :
* ``V4L2_CID_MPEG_VIDEO_HEVC_SPS``
* ``V4L2_CID_MPEG_VIDEO_HEVC_PPS``
* ``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS``
through the following controls:
``V4L2_CID_MPEG_VIDEO_HEVC_SPS``,
``V4L2_CID_MPEG_VIDEO_HEVC_PPS``, and
``V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS``.
See the :ref:`associated Codec Control IDs <v4l2-mpeg-hevc>`.
Buffers associated with this pixel format must contain the appropriate
number of macroblocks to decode a full corresponding frame.
@ -222,4 +217,6 @@ Compressed Formats
- ``V4L2_PIX_FMT_FWHT_STATELESS``
- 'SFWH'
- Same format as V4L2_PIX_FMT_FWHT but requires stateless codec implementation.
See the :ref:`associated Codec Control IDs <v4l2-mpeg-fwht>`.
Metadata associated with the frame to decode is required to be passed
through the ``V4L2_CID_STATELESS_FWHT_PARAMS`` control.
See the :ref:`associated Codec Control ID <codec-stateless-fwht>`.

44
Documentation/userspace-api/media/v4l/pixfmt-grey.rst
View File

@ -1,44 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-GREY:
**************************
V4L2_PIX_FMT_GREY ('GREY')
**************************
Grey-scale image
Description
===========
This is a grey-scale image. It is really a degenerate Y'CbCr format
which simply contains no Cb or Cr data.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00`
- Y'\ :sub:`01`
- Y'\ :sub:`02`
- Y'\ :sub:`03`
* - start + 4:
- Y'\ :sub:`10`
- Y'\ :sub:`11`
- Y'\ :sub:`12`
- Y'\ :sub:`13`
* - start + 8:
- Y'\ :sub:`20`
- Y'\ :sub:`21`
- Y'\ :sub:`22`
- Y'\ :sub:`23`
* - start + 12:
- Y'\ :sub:`30`
- Y'\ :sub:`31`
- Y'\ :sub:`32`
- Y'\ :sub:`33`

59
Documentation/userspace-api/media/v4l/pixfmt-m420.rst
View File

@ -67,60 +67,5 @@ Each cell is one byte.
**Color Sample Location:**
.. flat-table::
:header-rows: 0
:stub-columns: 0
* -
- 0
-
- 1
- 2
-
- 3
* - 0
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 1
- Y
-
- Y
- Y
-
- Y
* -
* - 2
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 3
- Y
-
- Y
- Y
-
- Y
Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
horizontally and vertically.

7
Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
View File

@ -1,7 +1,8 @@
.. SPDX-License-Identifier: GPL-2.0
.. _v4l2-meta-fmt-params-rkisp1:
.. _v4l2-meta-fmt-stat-rkisp1:
.. _v4l2-meta-fmt-rk-isp1-params:
.. _v4l2-meta-fmt-rk-isp1-stat-3a:
*****************************************************************************
V4L2_META_FMT_RK_ISP1_PARAMS ('rk1p'), V4L2_META_FMT_RK_ISP1_STAT_3A ('rk1s')
@ -46,4 +47,4 @@ important tuning tools using software control loop.
rkisp1 uAPI data types
======================
.. kernel-doc:: drivers/staging/media/rkisp1/uapi/rkisp1-config.h
.. kernel-doc:: include/uapi/linux/rkisp1-config.h

129
Documentation/userspace-api/media/v4l/pixfmt-nv12.rst
View File

@ -1,129 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-NV12:
.. _V4L2-PIX-FMT-NV21:
******************************************************
V4L2_PIX_FMT_NV12 ('NV12'), V4L2_PIX_FMT_NV21 ('NV21')
******************************************************
V4L2_PIX_FMT_NV21
Formats with ½ horizontal and vertical chroma resolution, also known as
YUV 4:2:0. One luminance and one chrominance plane with alternating
chroma samples as opposed to ``V4L2_PIX_FMT_YVU420``
Description
===========
These are two-plane versions of the YUV 4:2:0 format. The three
components are separated into two sub-images or planes. The Y plane is
first. The Y plane has one byte per pixel. For ``V4L2_PIX_FMT_NV12``, a
combined CbCr plane immediately follows the Y plane in memory. The CbCr
plane is the same width, in bytes, as the Y plane (and of the image),
but is half as tall in pixels. Each CbCr pair belongs to four pixels.
For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`,
Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`. ``V4L2_PIX_FMT_NV21`` is
the same except the Cb and Cr bytes are swapped, the CrCb plane starts
with a Cr byte.
If the Y plane has pad bytes after each row, then the CbCr plane has as
many pad bytes after its rows.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00`
- Y'\ :sub:`01`
- Y'\ :sub:`02`
- Y'\ :sub:`03`
* - start + 4:
- Y'\ :sub:`10`
- Y'\ :sub:`11`
- Y'\ :sub:`12`
- Y'\ :sub:`13`
* - start + 8:
- Y'\ :sub:`20`
- Y'\ :sub:`21`
- Y'\ :sub:`22`
- Y'\ :sub:`23`
* - start + 12:
- Y'\ :sub:`30`
- Y'\ :sub:`31`
- Y'\ :sub:`32`
- Y'\ :sub:`33`
* - start + 16:
- Cb\ :sub:`00`
- Cr\ :sub:`00`
- Cb\ :sub:`01`
- Cr\ :sub:`01`
* - start + 20:
- Cb\ :sub:`10`
- Cr\ :sub:`10`
- Cb\ :sub:`11`
- Cr\ :sub:`11`
**Color Sample Location:**
.. flat-table::
:header-rows: 0
:stub-columns: 0
* -
- 0
-
- 1
- 2
-
- 3
* - 0
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 1
- Y
-
- Y
- Y
-
- Y
* -
* - 2
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 3
- Y
-
- Y
- Y
-
- Y

144
Documentation/userspace-api/media/v4l/pixfmt-nv12m.rst
View File

@ -1,144 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-NV12M:
.. _v4l2-pix-fmt-nv12mt-16x16:
.. _V4L2-PIX-FMT-NV21M:
***********************************************************************************
V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16
***********************************************************************************
V4L2_PIX_FMT_NV21M
V4L2_PIX_FMT_NV12MT_16X16
Variation of ``V4L2_PIX_FMT_NV12`` and ``V4L2_PIX_FMT_NV21`` with planes
non contiguous in memory.
Description
===========
This is a multi-planar, two-plane version of the YUV 4:2:0 format. The
three components are separated into two sub-images or planes.
``V4L2_PIX_FMT_NV12M`` differs from ``V4L2_PIX_FMT_NV12`` in that the
two planes are non-contiguous in memory, i.e. the chroma plane do not
necessarily immediately follows the luma plane. The luminance data
occupies the first plane. The Y plane has one byte per pixel. In the
second plane there is a chrominance data with alternating chroma
samples. The CbCr plane is the same width, in bytes, as the Y plane (and
of the image), but is half as tall in pixels. Each CbCr pair belongs to
four pixels. For example, Cb\ :sub:`0`/Cr\ :sub:`0` belongs to
Y'\ :sub:`00`, Y'\ :sub:`01`, Y'\ :sub:`10`, Y'\ :sub:`11`.
``V4L2_PIX_FMT_NV12MT_16X16`` is the tiled version of
``V4L2_PIX_FMT_NV12M`` with 16x16 macroblock tiles. Here pixels are
arranged in 16x16 2D tiles and tiles are arranged in linear order in
memory. ``V4L2_PIX_FMT_NV21M`` is the same as ``V4L2_PIX_FMT_NV12M``
except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte.
``V4L2_PIX_FMT_NV12M`` is intended to be used only in drivers and
applications that support the multi-planar API, described in
:ref:`planar-apis`.
If the Y plane has pad bytes after each row, then the CbCr plane has as
many pad bytes after its rows.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start0 + 0:
- Y'\ :sub:`00`
- Y'\ :sub:`01`
- Y'\ :sub:`02`
- Y'\ :sub:`03`
* - start0 + 4:
- Y'\ :sub:`10`
- Y'\ :sub:`11`
- Y'\ :sub:`12`
- Y'\ :sub:`13`
* - start0 + 8:
- Y'\ :sub:`20`
- Y'\ :sub:`21`
- Y'\ :sub:`22`
- Y'\ :sub:`23`
* - start0 + 12:
- Y'\ :sub:`30`
- Y'\ :sub:`31`
- Y'\ :sub:`32`
- Y'\ :sub:`33`
* -
* - start1 + 0:
- Cb\ :sub:`00`
- Cr\ :sub:`00`
- Cb\ :sub:`01`
- Cr\ :sub:`01`
* - start1 + 4:
- Cb\ :sub:`10`
- Cr\ :sub:`10`
- Cb\ :sub:`11`
- Cr\ :sub:`11`
**Color Sample Location:**
.. flat-table::
:header-rows: 0
:stub-columns: 0
* -
- 0
-
- 1
- 2
-
- 3
* - 0
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 1
- Y
-
- Y
- Y
-
- Y
* -
* - 2
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
-
- C
-
* - 3
- Y
-
- Y
- Y
-
- Y

60
Documentation/userspace-api/media/v4l/pixfmt-nv12mt.rst
View File

@ -1,60 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-NV12MT:
****************************
V4L2_PIX_FMT_NV12MT ('TM12')
****************************
Formats with ½ horizontal and vertical chroma resolution. This format
has two planes - one for luminance and one for chrominance. Chroma
samples are interleaved. The difference to ``V4L2_PIX_FMT_NV12`` is the
memory layout. Pixels are grouped in macroblocks of 64x32 size. The
order of macroblocks in memory is also not standard.
Description
===========
This is the two-plane versions of the YUV 4:2:0 format where data is
grouped into 64x32 macroblocks. The three components are separated into
two sub-images or planes. The Y plane has one byte per pixel and pixels
are grouped into 64x32 macroblocks. The CbCr plane has the same width,
in bytes, as the Y plane (and the image), but is half as tall in pixels.
The chroma plane is also grouped into 64x32 macroblocks.
Width of the buffer has to be aligned to the multiple of 128, and height
alignment is 32. Every four adjacent buffers - two horizontally and two
vertically are grouped together and are located in memory in Z or
flipped Z order.
Layout of macroblocks in memory is presented in the following figure.
.. _nv12mt:
.. kernel-figure:: nv12mt.svg
:alt: nv12mt.svg
:align: center
V4L2_PIX_FMT_NV12MT macroblock Z shape memory layout
The requirement that width is multiple of 128 is implemented because,
the Z shape cannot be cut in half horizontally. In case the vertical
resolution of macroblocks is odd then the last row of macroblocks is
arranged in a linear order.
In case of chroma the layout is identical. Cb and Cr samples are
interleaved. Height of the buffer is aligned to 32.
.. _nv12mt_ex:
.. kernel-figure:: nv12mt_example.svg
:alt: nv12mt_example.svg
:align: center
Example V4L2_PIX_FMT_NV12MT memory layout of macroblocks
Memory layout of macroblocks of ``V4L2_PIX_FMT_NV12MT`` format in most
extreme case.

153
Documentation/userspace-api/media/v4l/pixfmt-nv16.rst
View File

@ -1,153 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-NV16:
.. _V4L2-PIX-FMT-NV61:
******************************************************
V4L2_PIX_FMT_NV16 ('NV16'), V4L2_PIX_FMT_NV61 ('NV61')
******************************************************
V4L2_PIX_FMT_NV61
Formats with ½ horizontal chroma resolution, also known as YUV 4:2:2.
One luminance and one chrominance plane with alternating chroma samples
as opposed to ``V4L2_PIX_FMT_YVU420``
Description
===========
These are two-plane versions of the YUV 4:2:2 format. The three
components are separated into two sub-images or planes. The Y plane is
first. The Y plane has one byte per pixel. For ``V4L2_PIX_FMT_NV16``, a
combined CbCr plane immediately follows the Y plane in memory. The CbCr
plane is the same width and height, in bytes, as the Y plane (and of the
image). Each CbCr pair belongs to two pixels. For example,
Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`, Y'\ :sub:`01`.
``V4L2_PIX_FMT_NV61`` is the same except the Cb and Cr bytes are
swapped, the CrCb plane starts with a Cr byte.
If the Y plane has pad bytes after each row, then the CbCr plane has as
many pad bytes after its rows.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00`
- Y'\ :sub:`01`
- Y'\ :sub:`02`
- Y'\ :sub:`03`
* - start + 4:
- Y'\ :sub:`10`
- Y'\ :sub:`11`
- Y'\ :sub:`12`
- Y'\ :sub:`13`
* - start + 8:
- Y'\ :sub:`20`
- Y'\ :sub:`21`
- Y'\ :sub:`22`
- Y'\ :sub:`23`
* - start + 12:
- Y'\ :sub:`30`
- Y'\ :sub:`31`
- Y'\ :sub:`32`
- Y'\ :sub:`33`
* - start + 16:
- Cb\ :sub:`00`
- Cr\ :sub:`00`
- Cb\ :sub:`01`
- Cr\ :sub:`01`
* - start + 20:
- Cb\ :sub:`10`
- Cr\ :sub:`10`
- Cb\ :sub:`11`
- Cr\ :sub:`11`
* - start + 24:
- Cb\ :sub:`20`
- Cr\ :sub:`20`
- Cb\ :sub:`21`
- Cr\ :sub:`21`
* - start + 28:
- Cb\ :sub:`30`
- Cr\ :sub:`30`
- Cb\ :sub:`31`
- Cr\ :sub:`31`
**Color Sample Location:**
.. flat-table::
:header-rows: 0
:stub-columns: 0
* -
- 0
-
- 1
- 2
-
- 3
* - 0
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 1
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* -
* - 2
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 3
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-

157
Documentation/userspace-api/media/v4l/pixfmt-nv16m.rst
View File

@ -1,157 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-NV16M:
.. _v4l2-pix-fmt-nv61m:
********************************************************
V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M ('NM61')
********************************************************
V4L2_PIX_FMT_NV61M
Variation of ``V4L2_PIX_FMT_NV16`` and ``V4L2_PIX_FMT_NV61`` with planes
non contiguous in memory.
Description
===========
This is a multi-planar, two-plane version of the YUV 4:2:2 format. The
three components are separated into two sub-images or planes.
``V4L2_PIX_FMT_NV16M`` differs from ``V4L2_PIX_FMT_NV16`` in that the
two planes are non-contiguous in memory, i.e. the chroma plane does not
necessarily immediately follow the luma plane. The luminance data
occupies the first plane. The Y plane has one byte per pixel. In the
second plane there is chrominance data with alternating chroma samples.
The CbCr plane is the same width and height, in bytes, as the Y plane.
Each CbCr pair belongs to two pixels. For example,
Cb\ :sub:`0`/Cr\ :sub:`0` belongs to Y'\ :sub:`00`, Y'\ :sub:`01`.
``V4L2_PIX_FMT_NV61M`` is the same as ``V4L2_PIX_FMT_NV16M`` except the
Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.
``V4L2_PIX_FMT_NV16M`` and ``V4L2_PIX_FMT_NV61M`` are intended to be
used only in drivers and applications that support the multi-planar API,
described in :ref:`planar-apis`.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start0 + 0:
- Y'\ :sub:`00`
- Y'\ :sub:`01`
- Y'\ :sub:`02`
- Y'\ :sub:`03`
* - start0 + 4:
- Y'\ :sub:`10`
- Y'\ :sub:`11`
- Y'\ :sub:`12`
- Y'\ :sub:`13`
* - start0 + 8:
- Y'\ :sub:`20`
- Y'\ :sub:`21`
- Y'\ :sub:`22`
- Y'\ :sub:`23`
* - start0 + 12:
- Y'\ :sub:`30`
- Y'\ :sub:`31`
- Y'\ :sub:`32`
- Y'\ :sub:`33`
* -
* - start1 + 0:
- Cb\ :sub:`00`
- Cr\ :sub:`00`
- Cb\ :sub:`02`
- Cr\ :sub:`02`
* - start1 + 4:
- Cb\ :sub:`10`
- Cr\ :sub:`10`
- Cb\ :sub:`12`
- Cr\ :sub:`12`
* - start1 + 8:
- Cb\ :sub:`20`
- Cr\ :sub:`20`
- Cb\ :sub:`22`
- Cr\ :sub:`22`
* - start1 + 12:
- Cb\ :sub:`30`
- Cr\ :sub:`30`
- Cb\ :sub:`32`
- Cr\ :sub:`32`
**Color Sample Location:**
.. flat-table::
:header-rows: 0
:stub-columns: 0
* -
- 0
-
- 1
- 2
-
- 3
* - 0
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 1
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* -
* - 2
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-
* - 3
- Y
-
- Y
- Y
-
- Y
* -
-
- C
-
-
- C
-

95
Documentation/userspace-api/media/v4l/pixfmt-nv24.rst
View File

@ -1,95 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-NV24:
.. _V4L2-PIX-FMT-NV42:
******************************************************
V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 ('NV42')
******************************************************
V4L2_PIX_FMT_NV42
Formats with full horizontal and vertical chroma resolutions, also known
as YUV 4:4:4. One luminance and one chrominance plane with alternating
chroma samples as opposed to ``V4L2_PIX_FMT_YVU420``
Description
===========
These are two-plane versions of the YUV 4:4:4 format. The three
components are separated into two sub-images or planes. The Y plane is
first, with each Y sample stored in one byte per pixel. For
``V4L2_PIX_FMT_NV24``, a combined CbCr plane immediately follows the Y
plane in memory. The CbCr plane has the same width and height, in
pixels, as the Y plane (and the image). Each line contains one CbCr pair
per pixel, with each Cb and Cr sample stored in one byte.
``V4L2_PIX_FMT_NV42`` is the same except that the Cb and Cr samples are
swapped, the CrCb plane starts with a Cr sample.
If the Y plane has pad bytes after each row, then the CbCr plane has
twice as many pad bytes after its rows.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00`
- Y'\ :sub:`01`
- Y'\ :sub:`02`
- Y'\ :sub:`03`
* - start + 4:
- Y'\ :sub:`10`
- Y'\ :sub:`11`
- Y'\ :sub:`12`
- Y'\ :sub:`13`
* - start + 8:
- Y'\ :sub:`20`
- Y'\ :sub:`21`
- Y'\ :sub:`22`
- Y'\ :sub:`23`
* - start + 12:
- Y'\ :sub:`30`
- Y'\ :sub:`31`
- Y'\ :sub:`32`
- Y'\ :sub:`33`
* - start + 16:
- Cb\ :sub:`00`
- Cr\ :sub:`00`
- Cb\ :sub:`01`
- Cr\ :sub:`01`
- Cb\ :sub:`02`
- Cr\ :sub:`02`
- Cb\ :sub:`03`
- Cr\ :sub:`03`
* - start + 24:
- Cb\ :sub:`10`
- Cr\ :sub:`10`
- Cb\ :sub:`11`
- Cr\ :sub:`11`
- Cb\ :sub:`12`
- Cr\ :sub:`12`
- Cb\ :sub:`13`
- Cr\ :sub:`13`
* - start + 32:
- Cb\ :sub:`20`
- Cr\ :sub:`20`
- Cb\ :sub:`21`
- Cr\ :sub:`21`
- Cb\ :sub:`22`
- Cr\ :sub:`22`
- Cb\ :sub:`23`
- Cr\ :sub:`23`
* - start + 40:
- Cb\ :sub:`30`
- Cr\ :sub:`30`
- Cb\ :sub:`31`
- Cr\ :sub:`31`
- Cb\ :sub:`32`
- Cr\ :sub:`32`
- Cb\ :sub:`33`
- Cr\ :sub:`33`

484
Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst
View File

@ -6,12 +6,32 @@
Packed YUV formats
******************
Description
===========
Similarly to the packed RGB formats, the packed YUV formats store the Y, Cb and
Cr components consecutively in memory. They may apply subsampling to the chroma
components and thus differ in how they interlave the three components.
Similar to the packed RGB formats these formats store the Y, Cb and Cr
component of each pixel in one 16 or 32 bit word.
.. note::
- In all the tables that follow, bit 7 is the most significant bit in a byte.
- 'Y', 'Cb' and 'Cr' denote bits of the luma, blue chroma (also known as
'U') and red chroma (also known as 'V') components respectively. 'A'
denotes bits of the alpha component (if supported by the format), and 'X'
denotes padding bits.
4:4:4 Subsampling
=================
These formats do not subsample the chroma components and store each pixels as a
full triplet of Y, Cb and Cr values.
The next table lists the packed YUV 4:4:4 formats with less than 8 bits per
component. They are named based on the order of the Y, Cb and Cr components as
seen in a 16-bit word, which is then stored in memory in little endian byte
order, and on the number of bits for each component. For instance the YUV565
format stores a pixel in a 16-bit word [15:0] laid out at as [Y'\ :sub:`4-0`
Cb\ :sub:`5-0` Cr\ :sub:`4-0`], and stored in memory in two bytes,
[Cb\ :sub:`2-0` Cr\ :sub:`4-0`] followed by [Y'\ :sub:`4-0` Cb\ :sub:`5-3`].
.. raw:: latex
@ -19,11 +39,9 @@ component of each pixel in one 16 or 32 bit word.
\tiny
\setlength{\tabcolsep}{2pt}
.. _packed-yuv-formats:
.. tabularcolumns:: |p{2.5cm}|p{0.69cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|
.. tabularcolumns:: |p{2.5cm}|p{0.69cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|p{0.31cm}|
.. flat-table:: Packed YUV Image Formats
.. flat-table:: Packed YUV 4:4:4 Image Formats (less than 8bpc)
:header-rows: 2
:stub-columns: 0
@ -34,10 +52,6 @@ component of each pixel in one 16 or 32 bit word.
- :cspan:`7` Byte 1
- :cspan:`7` Byte 2
- :cspan:`7` Byte 3
* -
-
- 7
@ -58,24 +72,6 @@ component of each pixel in one 16 or 32 bit word.
- 1
- 0
- 7
- 6
- 5
- 4
- 3
- 2
- 1
- 0
- 7
- 6
- 5
- 4
- 3
- 2
- 1
- 0
* .. _V4L2-PIX-FMT-YUV444:
- ``V4L2_PIX_FMT_YUV444``
@ -99,8 +95,6 @@ component of each pixel in one 16 or 32 bit word.
- Y'\ :sub:`1`
- Y'\ :sub:`0`
- :cspan:`15`
* .. _V4L2-PIX-FMT-YUV555:
- ``V4L2_PIX_FMT_YUV555``
@ -124,7 +118,6 @@ component of each pixel in one 16 or 32 bit word.
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- :cspan:`15`
* .. _V4L2-PIX-FMT-YUV565:
- ``V4L2_PIX_FMT_YUV565``
@ -148,226 +141,219 @@ component of each pixel in one 16 or 32 bit word.
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- :cspan:`15`
* .. _V4L2-PIX-FMT-YUV32:
- ``V4L2_PIX_FMT_YUV32``
- 'YUV4'
- a\ :sub:`7`
- a\ :sub:`6`
- a\ :sub:`5`
- a\ :sub:`4`
- a\ :sub:`3`
- a\ :sub:`2`
- a\ :sub:`1`
- a\ :sub:`0`
- Y'\ :sub:`7`
- Y'\ :sub:`6`
- Y'\ :sub:`5`
- Y'\ :sub:`4`
- Y'\ :sub:`3`
- Y'\ :sub:`2`
- Y'\ :sub:`1`
- Y'\ :sub:`0`
- Cb\ :sub:`7`
- Cb\ :sub:`6`
- Cb\ :sub:`5`
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- Cb\ :sub:`2`
- Cb\ :sub:`1`
- Cb\ :sub:`0`
- Cr\ :sub:`7`
- Cr\ :sub:`6`
- Cr\ :sub:`5`
- Cr\ :sub:`4`
- Cr\ :sub:`3`
- Cr\ :sub:`2`
- Cr\ :sub:`1`
- Cr\ :sub:`0`
* .. _V4L2-PIX-FMT-AYUV32:
- ``V4L2_PIX_FMT_AYUV32``
- 'AYUV'
- a\ :sub:`7`
- a\ :sub:`6`
- a\ :sub:`5`
- a\ :sub:`4`
- a\ :sub:`3`
- a\ :sub:`2`
- a\ :sub:`1`
- a\ :sub:`0`
- Y'\ :sub:`7`
- Y'\ :sub:`6`
- Y'\ :sub:`5`
- Y'\ :sub:`4`
- Y'\ :sub:`3`
- Y'\ :sub:`2`
- Y'\ :sub:`1`
- Y'\ :sub:`0`
- Cb\ :sub:`7`
- Cb\ :sub:`6`
- Cb\ :sub:`5`
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- Cb\ :sub:`2`
- Cb\ :sub:`1`
- Cb\ :sub:`0`
- Cr\ :sub:`7`
- Cr\ :sub:`6`
- Cr\ :sub:`5`
- Cr\ :sub:`4`
- Cr\ :sub:`3`
- Cr\ :sub:`2`
- Cr\ :sub:`1`
- Cr\ :sub:`0`
* .. _V4L2-PIX-FMT-XYUV32:
- ``V4L2_PIX_FMT_XYUV32``
- 'XYUV'
-
-
-
-
-
-
-
-
- Y'\ :sub:`7`
- Y'\ :sub:`6`
- Y'\ :sub:`5`
- Y'\ :sub:`4`
- Y'\ :sub:`3`
- Y'\ :sub:`2`
- Y'\ :sub:`1`
- Y'\ :sub:`0`
- Cb\ :sub:`7`
- Cb\ :sub:`6`
- Cb\ :sub:`5`
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- Cb\ :sub:`2`
- Cb\ :sub:`1`
- Cb\ :sub:`0`
- Cr\ :sub:`7`
- Cr\ :sub:`6`
- Cr\ :sub:`5`
- Cr\ :sub:`4`
- Cr\ :sub:`3`
- Cr\ :sub:`2`
- Cr\ :sub:`1`
- Cr\ :sub:`0`
* .. _V4L2-PIX-FMT-VUYA32:
- ``V4L2_PIX_FMT_VUYA32``
- 'VUYA'
- Cr\ :sub:`7`
- Cr\ :sub:`6`
- Cr\ :sub:`5`
- Cr\ :sub:`4`
- Cr\ :sub:`3`
- Cr\ :sub:`2`
- Cr\ :sub:`1`
- Cr\ :sub:`0`
- Cb\ :sub:`7`
- Cb\ :sub:`6`
- Cb\ :sub:`5`
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- Cb\ :sub:`2`
- Cb\ :sub:`1`
- Cb\ :sub:`0`
- Y'\ :sub:`7`
- Y'\ :sub:`6`
- Y'\ :sub:`5`
- Y'\ :sub:`4`
- Y'\ :sub:`3`
- Y'\ :sub:`2`
- Y'\ :sub:`1`
- Y'\ :sub:`0`
- a\ :sub:`7`
- a\ :sub:`6`
- a\ :sub:`5`
- a\ :sub:`4`
- a\ :sub:`3`
- a\ :sub:`2`
- a\ :sub:`1`
- a\ :sub:`0`
* .. _V4L2-PIX-FMT-VUYX32:
- ``V4L2_PIX_FMT_VUYX32``
- 'VUYX'
- Cr\ :sub:`7`
- Cr\ :sub:`6`
- Cr\ :sub:`5`
- Cr\ :sub:`4`
- Cr\ :sub:`3`
- Cr\ :sub:`2`
- Cr\ :sub:`1`
- Cr\ :sub:`0`
- Cb\ :sub:`7`
- Cb\ :sub:`6`
- Cb\ :sub:`5`
- Cb\ :sub:`4`
- Cb\ :sub:`3`
- Cb\ :sub:`2`
- Cb\ :sub:`1`
- Cb\ :sub:`0`
- Y'\ :sub:`7`
- Y'\ :sub:`6`
- Y'\ :sub:`5`
- Y'\ :sub:`4`
- Y'\ :sub:`3`
- Y'\ :sub:`2`
- Y'\ :sub:`1`
- Y'\ :sub:`0`
-
-
-
-
-
-
-
-
.. raw:: latex
\endgroup
.. note::
#) Bit 7 is the most significant bit;
For the YUV444 and YUV555 formats, the value of alpha bits is undefined
when reading from the driver, ignored when writing to the driver, except
when alpha blending has been negotiated for a :ref:`Video Overlay
<overlay>` or :ref:`Video Output Overlay <osd>`.
#) The value of a = alpha bits is undefined when reading from the driver,
ignored when writing to the driver, except when alpha blending has
been negotiated for a :ref:`Video Overlay <overlay>` or
:ref:`Video Output Overlay <osd>` for the formats Y444, YUV555 and
YUV4. However, for formats AYUV32 and VUYA32, the alpha component is
expected to contain a meaningful value that can be used by drivers
and applications. And, the formats XYUV32 and VUYX32 contain undefined
alpha values that must be ignored by all applications and drivers.
The next table lists the packed YUV 4:4:4 formats with 8 bits per component.
They are named based on the order of the Y, Cb and Cr components as stored in
memory, and on the total number of bits per pixel. For instance, the VUYX32
format stores a pixel with Cr\ :sub:`7-0` in the first byte, Cb\ :sub:`7-0` in
the second byte and Y'\ :sub:`7-0` in the third byte.
.. flat-table:: Packed YUV Image Formats (8bpc)
:header-rows: 1
:stub-columns: 0
* - Identifier
- Code
- Byte 0
- Byte 1
- Byte 2
- Byte 3
* .. _V4L2-PIX-FMT-YUV32:
- ``V4L2_PIX_FMT_YUV32``
- 'YUV4'
- A\ :sub:`7-0`
- Y'\ :sub:`7-0`
- Cb\ :sub:`7-0`
- Cr\ :sub:`7-0`
* .. _V4L2-PIX-FMT-AYUV32:
- ``V4L2_PIX_FMT_AYUV32``
- 'AYUV'
- A\ :sub:`7-0`
- Y'\ :sub:`7-0`
- Cb\ :sub:`7-0`
- Cr\ :sub:`7-0`
* .. _V4L2-PIX-FMT-XYUV32:
- ``V4L2_PIX_FMT_XYUV32``
- 'XYUV'
- X\ :sub:`7-0`
- Y'\ :sub:`7-0`
- Cb\ :sub:`7-0`
- Cr\ :sub:`7-0`
* .. _V4L2-PIX-FMT-VUYA32:
- ``V4L2_PIX_FMT_VUYA32``
- 'VUYA'
- Cr\ :sub:`7-0`
- Cb\ :sub:`7-0`
- Y'\ :sub:`7-0`
- A\ :sub:`7-0`
* .. _V4L2-PIX-FMT-VUYX32:
- ``V4L2_PIX_FMT_VUYX32``
- 'VUYX'
- Cr\ :sub:`7-0`
- Cb\ :sub:`7-0`
- Y'\ :sub:`7-0`
- X\ :sub:`7-0`
.. note::
- The alpha component is expected to contain a meaningful value that can be
used by drivers and applications.
- The padding bits contain undefined values that must be ignored by all
applications and drivers.
4:2:2 Subsampling
=================
These formats, commonly referred to as YUYV or YUY2, subsample the chroma
components horizontally by 2, storing 2 pixels in 4 bytes.
.. flat-table:: Packed YUV 4:2:2 Formats
:header-rows: 1
:stub-columns: 0
* - Identifier
- Code
- Byte 0
- Byte 1
- Byte 2
- Byte 3
- Byte 4
- Byte 5
- Byte 6
- Byte 7
* .. _V4L2-PIX-FMT-UYVY:
- ``V4L2_PIX_FMT_UYVY``
- 'UYVY'
- Cb\ :sub:`0`
- Y'\ :sub:`0`
- Cr\ :sub:`0`
- Y'\ :sub:`1`
- Cb\ :sub:`2`
- Y'\ :sub:`2`
- Cr\ :sub:`2`
- Y'\ :sub:`3`
* .. _V4L2-PIX-FMT-VYUY:
- ``V4L2_PIX_FMT_VYUY``
- 'VYUY'
- Cr\ :sub:`0`
- Y'\ :sub:`0`
- Cb\ :sub:`0`
- Y'\ :sub:`1`
- Cr\ :sub:`2`
- Y'\ :sub:`2`
- Cb\ :sub:`2`
- Y'\ :sub:`3`
* .. _V4L2-PIX-FMT-YUYV:
- ``V4L2_PIX_FMT_YUYV``
- 'YUYV'
- Y'\ :sub:`0`
- Cb\ :sub:`0`
- Y'\ :sub:`1`
- Cr\ :sub:`0`
- Y'\ :sub:`2`
- Cb\ :sub:`2`
- Y'\ :sub:`3`
- Cr\ :sub:`2`
* .. _V4L2-PIX-FMT-YVYU:
- ``V4L2_PIX_FMT_YVYU``
- 'YVYU'
- Y'\ :sub:`0`
- Cr\ :sub:`0`
- Y'\ :sub:`1`
- Cb\ :sub:`0`
- Y'\ :sub:`2`
- Cr\ :sub:`2`
- Y'\ :sub:`3`
- Cb\ :sub:`2`
**Color Sample Location:**
Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
horizontally.
4:1:1 Subsampling
=================
This format subsamples the chroma components horizontally by 4, storing 8
pixels in 12 bytes.
.. flat-table:: Packed YUV 4:1:1 Formats
:header-rows: 1
:stub-columns: 0
* - Identifier
- Code
- Byte 0
- Byte 1
- Byte 2
- Byte 3
- Byte 4
- Byte 5
- Byte 6
- Byte 7
- Byte 8
- Byte 9
- Byte 10
- Byte 11
* .. _V4L2-PIX-FMT-Y41P:
- ``V4L2_PIX_FMT_Y41P``
- 'Y41P'
- Cb\ :sub:`0`
- Y'\ :sub:`0`
- Cr\ :sub:`0`
- Y'\ :sub:`1`
- Cb\ :sub:`4`
- Y'\ :sub:`2`
- Cr\ :sub:`4`
- Y'\ :sub:`3`
- Y'\ :sub:`4`
- Y'\ :sub:`5`
- Y'\ :sub:`6`
- Y'\ :sub:`7`
.. note::
Do not confuse ``V4L2_PIX_FMT_Y41P`` with
:ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>`. Y41P is derived from
"YUV 4:1:1 *packed*", while YUV411P stands for "YUV 4:1:1 *planar*".
**Color Sample Location:**
Chroma samples are :ref:`interstitially sited<yuv-chroma-centered>`
horizontally.

729
Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
View File

@ -6,13 +6,62 @@
RGB Formats
***********
Description
===========
These formats encode each pixel as a triplet of RGB values. They are packed
formats, meaning that the RGB values for one pixel are stored consecutively in
memory and each pixel consumes an integer number of bytes. When the number of
bits required to store a pixel is not aligned to a byte boundary, the data is
padded with additional bits to fill the remaining byte.
These formats are designed to match the pixel formats of typical PC
graphics frame buffers. They occupy 8, 16, 24 or 32 bits per pixel.
These are all packed-pixel formats, meaning all the data for a pixel lie
next to each other in memory.
The formats differ by the number of bits per RGB component (typically but not
always the same for all components), the order of components in memory, and the
presence of an alpha component or additional padding bits.
The usage and value of the alpha bits in formats that support them (named ARGB
or a permutation thereof, collectively referred to as alpha formats) depend on
the device type and hardware operation. :ref:`Capture <capture>` devices
(including capture queues of mem-to-mem devices) fill the alpha component in
memory. When the device captures an alpha channel the alpha component will have
a meaningful value. Otherwise, when the device doesn't capture an alpha channel
but can set the alpha bit to a user-configurable value, the
:ref:`V4L2_CID_ALPHA_COMPONENT <v4l2-alpha-component>` control is used to
specify that alpha value, and the alpha component of all pixels will be set to
the value specified by that control. Otherwise a corresponding format without
an alpha component (XRGB or XBGR) must be used instead of an alpha format.
:ref:`Output <output>` devices (including output queues of mem-to-mem devices
and :ref:`video output overlay <osd>` devices) read the alpha component from
memory. When the device processes the alpha channel the alpha component must be
filled with meaningful values by applications. Otherwise a corresponding format
without an alpha component (XRGB or XBGR) must be used instead of an alpha
format.
Formats that contain padding bits are named XRGB (or a permutation thereof).
The padding bits contain undefined values and must be ignored by applications,
devices and drivers, for both :ref:`capture` and :ref:`output` devices.
.. note::
- In all the tables that follow, bit 7 is the most significant bit in a byte.
- 'r', 'g' and 'b' denote bits of the red, green and blue components
respectively. 'a' denotes bits of the alpha component (if supported by the
format), and 'x' denotes padding bits.
Less Than 8 Bits Per Component
==============================
These formats store an RGB triplet in one, two or four bytes. They are named
based on the order of the RGB components as seen in a 8-, 16- or 32-bit word,
which is then stored in memory in little endian byte order (unless otherwise
noted by the presence of bit 31 in the 4CC value), and on the number of bits
for each component. For instance, the RGB565 format stores a pixel in a 16-bit
word [15:0] laid out at as [R\ :sub:`4` R\ :sub:`3` R\ :sub:`2` R\ :sub:`1`
R\ :sub:`0` G\ :sub:`5` G\ :sub:`4` G\ :sub:`3` G\ :sub:`2` G\ :sub:`1`
G\ :sub:`0` B\ :sub:`4` B\ :sub:`3` B\ :sub:`2` B\ :sub:`1` B\ :sub:`0`], and
stored in memory in two bytes, [R\ :sub:`4` R\ :sub:`3` R\ :sub:`2` R\ :sub:`1`
R\ :sub:`0` G\ :sub:`5` G\ :sub:`4` G\ :sub:`3`] followed by [G\ :sub:`2`
G\ :sub:`1` G\ :sub:`0` B\ :sub:`4` B\ :sub:`3` B\ :sub:`2` B\ :sub:`1`
B\ :sub:`0`].
.. raw:: latex
@ -23,7 +72,7 @@ next to each other in memory.
.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
.. flat-table:: RGB Image Formats
.. flat-table:: RGB Formats With Less Than 8 Bits Per Component
:header-rows: 2
:stub-columns: 0
@ -121,10 +170,10 @@ next to each other in memory.
- b\ :sub:`1`
- b\ :sub:`0`
- `-`
- `-`
- `-`
- `-`
- x
- x
- x
- x
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
@ -162,10 +211,10 @@ next to each other in memory.
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- `-`
- `-`
- `-`
- `-`
- x
- x
- x
- x
- r\ :sub:`3`
- r\ :sub:`2`
@ -213,10 +262,10 @@ next to each other in memory.
- r\ :sub:`1`
- r\ :sub:`0`
- `-`
- `-`
- `-`
- `-`
- x
- x
- x
- x
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
@ -254,10 +303,10 @@ next to each other in memory.
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- `-`
- `-`
- `-`
- `-`
- x
- x
- x
- x
- b\ :sub:`3`
- b\ :sub:`2`
@ -305,7 +354,7 @@ next to each other in memory.
- b\ :sub:`1`
- b\ :sub:`0`
- `-`
- x
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
@ -349,7 +398,7 @@ next to each other in memory.
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- `-`
- x
- r\ :sub:`4`
- r\ :sub:`3`
@ -397,7 +446,7 @@ next to each other in memory.
- r\ :sub:`1`
- r\ :sub:`0`
- `-`
- x
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
@ -441,7 +490,7 @@ next to each other in memory.
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- `-`
- x
- b\ :sub:`4`
- b\ :sub:`3`
@ -503,7 +552,7 @@ next to each other in memory.
- ``V4L2_PIX_FMT_XRGB555X``
- 'XR15' | (1 << 31)
- `-`
- x
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
@ -544,70 +593,6 @@ next to each other in memory.
- b\ :sub:`1`
- b\ :sub:`0`
-
* .. _V4L2-PIX-FMT-BGR24:
- ``V4L2_PIX_FMT_BGR24``
- 'BGR3'
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
-
* .. _V4L2-PIX-FMT-RGB24:
- ``V4L2_PIX_FMT_RGB24``
- 'RGB3'
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
-
* .. _V4L2-PIX-FMT-BGR666:
- ``V4L2_PIX_FMT_BGR666``
@ -633,449 +618,163 @@ next to each other in memory.
- r\ :sub:`1`
- r\ :sub:`0`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- x
- x
- x
- x
- x
- x
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
* .. _V4L2-PIX-FMT-ABGR32:
- ``V4L2_PIX_FMT_ABGR32``
- 'AR24'
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- a\ :sub:`7`
- a\ :sub:`6`
- a\ :sub:`5`
- a\ :sub:`4`
- a\ :sub:`3`
- a\ :sub:`2`
- a\ :sub:`1`
- a\ :sub:`0`
* .. _V4L2-PIX-FMT-XBGR32:
- ``V4L2_PIX_FMT_XBGR32``
- 'XR24'
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
* .. _V4L2-PIX-FMT-BGRA32:
- ``V4L2_PIX_FMT_BGRA32``
- 'RA24'
- a\ :sub:`7`
- a\ :sub:`6`
- a\ :sub:`5`
- a\ :sub:`4`
- a\ :sub:`3`
- a\ :sub:`2`
- a\ :sub:`1`
- a\ :sub:`0`
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
* .. _V4L2-PIX-FMT-BGRX32:
- ``V4L2_PIX_FMT_BGRX32``
- 'RX24'
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
* .. _V4L2-PIX-FMT-RGBA32:
- ``V4L2_PIX_FMT_RGBA32``
- 'AB24'
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- a\ :sub:`7`
- a\ :sub:`6`
- a\ :sub:`5`
- a\ :sub:`4`
- a\ :sub:`3`
- a\ :sub:`2`
- a\ :sub:`1`
- a\ :sub:`0`
* .. _V4L2-PIX-FMT-RGBX32:
- ``V4L2_PIX_FMT_RGBX32``
- 'XB24'
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
* .. _V4L2-PIX-FMT-ARGB32:
- ``V4L2_PIX_FMT_ARGB32``
- 'BA24'
- a\ :sub:`7`
- a\ :sub:`6`
- a\ :sub:`5`
- a\ :sub:`4`
- a\ :sub:`3`
- a\ :sub:`2`
- a\ :sub:`1`
- a\ :sub:`0`
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
* .. _V4L2-PIX-FMT-XRGB32:
- ``V4L2_PIX_FMT_XRGB32``
- 'BX24'
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- `-`
- r\ :sub:`7`
- r\ :sub:`6`
- r\ :sub:`5`
- r\ :sub:`4`
- r\ :sub:`3`
- r\ :sub:`2`
- r\ :sub:`1`
- r\ :sub:`0`
- g\ :sub:`7`
- g\ :sub:`6`
- g\ :sub:`5`
- g\ :sub:`4`
- g\ :sub:`3`
- g\ :sub:`2`
- g\ :sub:`1`
- g\ :sub:`0`
- b\ :sub:`7`
- b\ :sub:`6`
- b\ :sub:`5`
- b\ :sub:`4`
- b\ :sub:`3`
- b\ :sub:`2`
- b\ :sub:`1`
- b\ :sub:`0`
- x
- x
- x
- x
- x
- x
- x
- x
.. raw:: latex
\endgroup
.. note:: Bit 7 is the most significant bit.
The usage and value of the alpha bits (a) in the ARGB and ABGR formats
(collectively referred to as alpha formats) depend on the device type
and hardware operation. :ref:`Capture <capture>` devices (including
capture queues of mem-to-mem devices) fill the alpha component in
memory. When the device outputs an alpha channel the alpha component
will have a meaningful value. Otherwise, when the device doesn't output
an alpha channel but can set the alpha bit to a user-configurable value,
the :ref:`V4L2_CID_ALPHA_COMPONENT <v4l2-alpha-component>` control
is used to specify that alpha value, and the alpha component of all
pixels will be set to the value specified by that control. Otherwise a
corresponding format without an alpha component (XRGB or XBGR) must be
used instead of an alpha format.
:ref:`Output <output>` devices (including output queues of mem-to-mem
devices and :ref:`video output overlay <osd>` devices) read the alpha
component from memory. When the device processes the alpha channel the
alpha component must be filled with meaningful values by applications.
Otherwise a corresponding format without an alpha component (XRGB or
XBGR) must be used instead of an alpha format.
The XRGB and XBGR formats contain undefined bits (-). Applications,
devices and drivers must ignore those bits, for both
:ref:`capture` and :ref:`output` devices.
**Byte Order.**
Each cell is one byte.
8 Bits Per Component
====================
These formats store an RGB triplet in three or four bytes. They are named based
on the order of the RGB components as stored in memory, and on the total number
of bits per pixel. For instance, RGB24 format stores a pixel with [R\ :sub:`7`
R\ :sub:`6` R\ :sub:`5` R\ :sub:`4` R\ :sub:`3` R\ :sub:`2` R\ :sub:`1`
R\ :sub:`0`] in the first byte, [G\ :sub:`7` G\ :sub:`6` G\ :sub:`5` G\ :sub:`4`
G\ :sub:`3` G\ :sub:`2` G\ :sub:`1` G\ :sub:`0`] in the second byte and
[B\ :sub:`7` B\ :sub:`6` B\ :sub:`5` B\ :sub:`4` B\ :sub:`3` B\ :sub:`2`
B\ :sub:`1` B\ :sub:`0`] in the third byte. This differs from the DRM format
nomenclature that instead use the order of components as seen in a 24- or
32-bit little endian word.
.. raw:: latex
\small
\begingroup
\tiny
\setlength{\tabcolsep}{2pt}
.. tabularcolumns:: |p{3.1cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|p{0.8cm}|
.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|p{2.0cm}|
.. flat-table:: RGB byte order
:header-rows: 0
.. flat-table:: RGB Formats With 8 Bits Per Component
:header-rows: 1
:stub-columns: 0
:widths: 11 3 3 3 3 3 3 3 3 3 3 3 3
* - start + 0:
- B\ :sub:`00`
- G\ :sub:`00`
- R\ :sub:`00`
- B\ :sub:`01`
- G\ :sub:`01`
- R\ :sub:`01`
- B\ :sub:`02`
- G\ :sub:`02`
- R\ :sub:`02`
- B\ :sub:`03`
- G\ :sub:`03`
- R\ :sub:`03`
* - start + 12:
- B\ :sub:`10`
- G\ :sub:`10`
- R\ :sub:`10`
- B\ :sub:`11`
- G\ :sub:`11`
- R\ :sub:`11`
- B\ :sub:`12`
- G\ :sub:`12`
- R\ :sub:`12`
- B\ :sub:`13`
- G\ :sub:`13`
- R\ :sub:`13`
* - start + 24:
- B\ :sub:`20`
- G\ :sub:`20`
- R\ :sub:`20`
- B\ :sub:`21`
- G\ :sub:`21`
- R\ :sub:`21`
- B\ :sub:`22`
- G\ :sub:`22`
- R\ :sub:`22`
- B\ :sub:`23`
- G\ :sub:`23`
- R\ :sub:`23`
* - start + 36:
- B\ :sub:`30`
- G\ :sub:`30`
- R\ :sub:`30`
- B\ :sub:`31`
- G\ :sub:`31`
- R\ :sub:`31`
- B\ :sub:`32`
- G\ :sub:`32`
- R\ :sub:`32`
- B\ :sub:`33`
- G\ :sub:`33`
- R\ :sub:`33`
* - Identifier
- Code
- Byte 0 in memory
- Byte 1
- Byte 2
- Byte 3
* .. _V4L2-PIX-FMT-BGR24:
- ``V4L2_PIX_FMT_BGR24``
- 'BGR3'
- G\ :sub:`7-0`
- B\ :sub:`7-0`
- R\ :sub:`7-0`
-
* .. _V4L2-PIX-FMT-RGB24:
- ``V4L2_PIX_FMT_RGB24``
- 'RGB3'
- R\ :sub:`7-0`
- G\ :sub:`7-0`
- B\ :sub:`7-0`
-
* .. _V4L2-PIX-FMT-ABGR32:
- ``V4L2_PIX_FMT_ABGR32``
- 'AR24'
- B\ :sub:`7-0`
- G\ :sub:`7-0`
- R\ :sub:`7-0`
- A\ :sub:`7-0`
* .. _V4L2-PIX-FMT-XBGR32:
- ``V4L2_PIX_FMT_XBGR32``
- 'XR24'
- B\ :sub:`7-0`
- G\ :sub:`7-0`
- R\ :sub:`7-0`
- X\ :sub:`7-0`
* .. _V4L2-PIX-FMT-BGRA32:
- ``V4L2_PIX_FMT_BGRA32``
- 'RA24'
- A\ :sub:`7-0`
- B\ :sub:`7-0`
- G\ :sub:`7-0`
- R\ :sub:`7-0`
* .. _V4L2-PIX-FMT-BGRX32:
- ``V4L2_PIX_FMT_BGRX32``
- 'RX24'
- X\ :sub:`7-0`
- B\ :sub:`7-0`
- G\ :sub:`7-0`
- R\ :sub:`7-0`
* .. _V4L2-PIX-FMT-RGBA32:
- ``V4L2_PIX_FMT_RGBA32``
- 'AB24'
- R\ :sub:`7-0`
- G\ :sub:`7-0`
- B\ :sub:`7-0`
- A\ :sub:`7-0`
* .. _V4L2-PIX-FMT-RGBX32:
- ``V4L2_PIX_FMT_RGBX32``
- 'XB24'
- R\ :sub:`7-0`
- G\ :sub:`7-0`
- B\ :sub:`7-0`
- X\ :sub:`7-0`
* .. _V4L2-PIX-FMT-ARGB32:
- ``V4L2_PIX_FMT_ARGB32``
- 'BA24'
- A\ :sub:`7-0`
- R\ :sub:`7-0`
- G\ :sub:`7-0`
- B\ :sub:`7-0`
* .. _V4L2-PIX-FMT-XRGB32:
- ``V4L2_PIX_FMT_XRGB32``
- 'BX24'
- X\ :sub:`7-0`
- R\ :sub:`7-0`
- G\ :sub:`7-0`
- B\ :sub:`7-0`
.. raw:: latex
\normalsize
\endgroup
Formats defined in :ref:`pixfmt-rgb-deprecated` are deprecated and
must not be used by new drivers. They are documented here for reference.
The meaning of their alpha bits ``(a)`` are ill-defined and interpreted as in
either the corresponding ARGB or XRGB format, depending on the driver.
Deprecated RGB Formats
======================
Formats defined in :ref:`pixfmt-rgb-deprecated` are deprecated and must not be
used by new drivers. They are documented here for reference. The meaning of
their alpha bits ``(a)`` is ill-defined and they are interpreted as in either
the corresponding ARGB or XRGB format, depending on the driver.
.. raw:: latex

110
Documentation/userspace-api/media/v4l/pixfmt-uyvy.rst
View File

@ -1,110 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-UYVY:
**************************
V4L2_PIX_FMT_UYVY ('UYVY')
**************************
Variation of ``V4L2_PIX_FMT_YUYV`` with different order of samples in
memory
Description
===========
In this format each four bytes is two pixels. Each four bytes is two
Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
belong to both pixels. As you can see, the Cr and Cb components have
half the horizontal resolution of the Y component.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Cb\ :sub:`00`
- Y'\ :sub:`00`
- Cr\ :sub:`00`
- Y'\ :sub:`01`
- Cb\ :sub:`01`
- Y'\ :sub:`02`
- Cr\ :sub:`01`
- Y'\ :sub:`03`
* - start + 8:
- Cb\ :sub:`10`
- Y'\ :sub:`10`
- Cr\ :sub:`10`
- Y'\ :sub:`11`
- Cb\ :sub:`11`
- Y'\ :sub:`12`
- Cr\ :sub:`11`
- Y'\ :sub:`13`
* - start + 16:
- Cb\ :sub:`20`
- Y'\ :sub:`20`
- Cr\ :sub:`20`
- Y'\ :sub:`21`
- Cb\ :sub:`21`
- Y'\ :sub:`22`
- Cr\ :sub:`21`
- Y'\ :sub:`23`
* - start + 24:
- Cb\ :sub:`30`
- Y'\ :sub:`30`
- Cr\ :sub:`30`
- Y'\ :sub:`31`
- Cb\ :sub:`31`
- Y'\ :sub:`32`
- Cr\ :sub:`31`
- Y'\ :sub:`33`
**Color Sample Location:**
.. flat-table::
:header-rows: 0
:stub-columns: 0
* -
- 0
-
- 1
- 2
-
- 3
* - 0
- Y
- C
- Y
- Y
- C
- Y
* - 1
- Y
- C
- Y
- Y
- C
- Y
* - 2
- Y
- C
- Y
- Y
- C
- Y
* - 3
- Y
- C
- Y
- Y
- C
- Y

108
Documentation/userspace-api/media/v4l/pixfmt-vyuy.rst
View File

@ -1,108 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-VYUY:
**************************
V4L2_PIX_FMT_VYUY ('VYUY')
**************************
Variation of ``V4L2_PIX_FMT_YUYV`` with different order of samples in
memory
Description
===========
In this format each four bytes is two pixels. Each four bytes is two
Y's, a Cb and a Cr. Each Y goes to one of the pixels, and the Cb and Cr
belong to both pixels. As you can see, the Cr and Cb components have
half the horizontal resolution of the Y component.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Cr\ :sub:`00`
- Y'\ :sub:`00`
- Cb\ :sub:`00`
- Y'\ :sub:`01`
- Cr\ :sub:`01`
- Y'\ :sub:`02`
- Cb\ :sub:`01`
- Y'\ :sub:`03`
* - start + 8:
- Cr\ :sub:`10`
- Y'\ :sub:`10`
- Cb\ :sub:`10`
- Y'\ :sub:`11`
- Cr\ :sub:`11`
- Y'\ :sub:`12`
- Cb\ :sub:`11`
- Y'\ :sub:`13`
* - start + 16:
- Cr\ :sub:`20`
- Y'\ :sub:`20`
- Cb\ :sub:`20`
- Y'\ :sub:`21`
- Cr\ :sub:`21`
- Y'\ :sub:`22`
- Cb\ :sub:`21`
- Y'\ :sub:`23`
* - start + 24:
- Cr\ :sub:`30`
- Y'\ :sub:`30`
- Cb\ :sub:`30`
- Y'\ :sub:`31`
- Cr\ :sub:`31`
- Y'\ :sub:`32`
- Cb\ :sub:`31`
- Y'\ :sub:`33`
**Color Sample Location:**
.. flat-table::
:header-rows: 0
:stub-columns: 0
* -
- 0
-
- 1
-
- 2
- 3
* - 0
- Y
- C
- Y
- Y
- C
- Y
* - 1
- Y
- C
- Y
- Y
- C
- Y
* - 2
- Y
- C
- Y
- Y
- C
- Y
* - 3
- Y
- C
- Y
- Y
- C
- Y

65
Documentation/userspace-api/media/v4l/pixfmt-y10.rst
View File

@ -1,65 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-Y10:
*************************
V4L2_PIX_FMT_Y10 ('Y10 ')
*************************
Grey-scale image
Description
===========
This is a grey-scale image with a depth of 10 bits per pixel. Pixels are
stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00low`
- Y'\ :sub:`00high`
- Y'\ :sub:`01low`
- Y'\ :sub:`01high`
- Y'\ :sub:`02low`
- Y'\ :sub:`02high`
- Y'\ :sub:`03low`
- Y'\ :sub:`03high`
* - start + 8:
- Y'\ :sub:`10low`
- Y'\ :sub:`10high`
- Y'\ :sub:`11low`
- Y'\ :sub:`11high`
- Y'\ :sub:`12low`
- Y'\ :sub:`12high`
- Y'\ :sub:`13low`
- Y'\ :sub:`13high`
* - start + 16:
- Y'\ :sub:`20low`
- Y'\ :sub:`20high`
- Y'\ :sub:`21low`
- Y'\ :sub:`21high`
- Y'\ :sub:`22low`
- Y'\ :sub:`22high`
- Y'\ :sub:`23low`
- Y'\ :sub:`23high`
* - start + 24:
- Y'\ :sub:`30low`
- Y'\ :sub:`30high`
- Y'\ :sub:`31low`
- Y'\ :sub:`31high`
- Y'\ :sub:`32low`
- Y'\ :sub:`32high`
- Y'\ :sub:`33low`
- Y'\ :sub:`33high`

33
Documentation/userspace-api/media/v4l/pixfmt-y10b.rst
View File

@ -1,33 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-Y10BPACK:
******************************
V4L2_PIX_FMT_Y10BPACK ('Y10B')
******************************
Grey-scale image as a bit-packed array
Description
===========
This is a packed grey-scale image format with a depth of 10 bits per
pixel. Pixels are stored in a bit-packed array of 10bit bits per pixel,
with no padding between them and with the most significant bits coming
first from the left.
**Bit-packed representation.**
pixels cross the byte boundary and have a ratio of 5 bytes for each 4
pixels.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - Y'\ :sub:`00[9:2]`
- Y'\ :sub:`00[1:0]`\ Y'\ :sub:`01[9:4]`
- Y'\ :sub:`01[3:0]`\ Y'\ :sub:`02[9:6]`
- Y'\ :sub:`02[5:0]`\ Y'\ :sub:`03[9:8]`
- Y'\ :sub:`03[7:0]`

43
Documentation/userspace-api/media/v4l/pixfmt-y10p.rst
View File

@ -1,43 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-Y10P:
******************************
V4L2_PIX_FMT_Y10P ('Y10P')
******************************
Grey-scale image as a MIPI RAW10 packed array
Description
===========
This is a packed grey-scale image format with a depth of 10 bits per
pixel. Every four consecutive pixels are packed into 5 bytes. Each of
the first 4 bytes contain the 8 high order bits of the pixels, and
the 5th byte contains the 2 least significants bits of each pixel,
in the same order.
**Bit-packed representation.**
.. raw:: latex
\small
.. tabularcolumns:: |p{1.2cm}||p{1.2cm}||p{1.2cm}||p{1.2cm}|p{3.2cm}|p{3.2cm}|
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 8 8 8 8 64
* - Y'\ :sub:`00[9:2]`
- Y'\ :sub:`01[9:2]`
- Y'\ :sub:`02[9:2]`
- Y'\ :sub:`03[9:2]`
- Y'\ :sub:`03[1:0]`\ (bits 7--6) Y'\ :sub:`02[1:0]`\ (bits 5--4)
Y'\ :sub:`01[1:0]`\ (bits 3--2) Y'\ :sub:`00[1:0]`\ (bits 1--0)
.. raw:: latex
\normalsize

65
Documentation/userspace-api/media/v4l/pixfmt-y12.rst
View File

@ -1,65 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-Y12:
*************************
V4L2_PIX_FMT_Y12 ('Y12 ')
*************************
Grey-scale image
Description
===========
This is a grey-scale image with a depth of 12 bits per pixel. Pixels are
stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00low`
- Y'\ :sub:`00high`
- Y'\ :sub:`01low`
- Y'\ :sub:`01high`
- Y'\ :sub:`02low`
- Y'\ :sub:`02high`
- Y'\ :sub:`03low`
- Y'\ :sub:`03high`
* - start + 8:
- Y'\ :sub:`10low`
- Y'\ :sub:`10high`
- Y'\ :sub:`11low`
- Y'\ :sub:`11high`
- Y'\ :sub:`12low`
- Y'\ :sub:`12high`
- Y'\ :sub:`13low`
- Y'\ :sub:`13high`
* - start + 16:
- Y'\ :sub:`20low`
- Y'\ :sub:`20high`
- Y'\ :sub:`21low`
- Y'\ :sub:`21high`
- Y'\ :sub:`22low`
- Y'\ :sub:`22high`
- Y'\ :sub:`23low`
- Y'\ :sub:`23high`
* - start + 24:
- Y'\ :sub:`30low`
- Y'\ :sub:`30high`
- Y'\ :sub:`31low`
- Y'\ :sub:`31high`
- Y'\ :sub:`32low`
- Y'\ :sub:`32high`
- Y'\ :sub:`33low`
- Y'\ :sub:`33high`

65
Documentation/userspace-api/media/v4l/pixfmt-y14.rst
View File

@ -1,65 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-Y14:
*************************
V4L2_PIX_FMT_Y14 ('Y14 ')
*************************
Grey-scale image
Description
===========
This is a grey-scale image with a depth of 14 bits per pixel. Pixels are
stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00low`
- Y'\ :sub:`00high`
- Y'\ :sub:`01low`
- Y'\ :sub:`01high`
- Y'\ :sub:`02low`
- Y'\ :sub:`02high`
- Y'\ :sub:`03low`
- Y'\ :sub:`03high`
* - start + 8:
- Y'\ :sub:`10low`
- Y'\ :sub:`10high`
- Y'\ :sub:`11low`
- Y'\ :sub:`11high`
- Y'\ :sub:`12low`
- Y'\ :sub:`12high`
- Y'\ :sub:`13low`
- Y'\ :sub:`13high`
* - start + 16:
- Y'\ :sub:`20low`
- Y'\ :sub:`20high`
- Y'\ :sub:`21low`
- Y'\ :sub:`21high`
- Y'\ :sub:`22low`
- Y'\ :sub:`22high`
- Y'\ :sub:`23low`
- Y'\ :sub:`23high`
* - start + 24:
- Y'\ :sub:`30low`
- Y'\ :sub:`30high`
- Y'\ :sub:`31low`
- Y'\ :sub:`31high`
- Y'\ :sub:`32low`
- Y'\ :sub:`32high`
- Y'\ :sub:`33low`
- Y'\ :sub:`33high`

69
Documentation/userspace-api/media/v4l/pixfmt-y16-be.rst
View File

@ -1,69 +0,0 @@
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. _V4L2-PIX-FMT-Y16-BE:
****************************************
V4L2_PIX_FMT_Y16_BE ('Y16 ' | (1 << 31))
****************************************
Grey-scale image
Description
===========
This is a grey-scale image with a depth of 16 bits per pixel. The most
significant byte is stored at lower memory addresses (big-endian).
.. note::
The actual sampling precision may be lower than 16 bits, for
example 10 bits per pixel with values in range 0 to 1023.
**Byte Order.**
Each cell is one byte.
.. flat-table::
:header-rows: 0
:stub-columns: 0
* - start + 0:
- Y'\ :sub:`00high`
- Y'\ :sub:`00low`
- Y'\ :sub:`01high`
- Y'\ :sub:`01low`
- Y'\ :sub:`02high`
- Y'\ :sub:`02low`
- Y'\ :sub:`03high`
- Y'\ :sub:`03low`
* - start + 8:
- Y'\ :sub:`10high`
- Y'\ :sub:`10low`
- Y'\ :sub:`11high`
- Y'\ :sub:`11low`
- Y'\ :sub:`12high`
- Y'\ :sub:`12low`
- Y'\ :sub:`13high`
- Y'\ :sub:`13low`
* - start + 16:
- Y'\ :sub:`20high`
- Y'\ :sub:`20low`
- Y'\ :sub:`21high`
- Y'\ :sub:`21low`
- Y'\ :sub:`22high`
- Y'\ :sub:`22low`
- Y'\ :sub:`23high`
- Y'\ :sub:`23low`
* - start + 24:
- Y'\ :sub:`30high`
- Y'\ :sub:`30low`
- Y'\ :sub:`31high`
- Y'\ :sub:`31low`
- Y'\ :sub:`32high`
- Y'\ :sub:`32low`
- Y'\ :sub:`33high`
- Y'\ :sub:`33low`

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