Merge tag 'media/v5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab: - Legacy soc_camera driver was removed from staging - New I2C sensor related drivers: dw9768, ch7322, max9271, rdacm20 - TI vpe driver code was re-organized and had new features added - Added Xilinx MIPI CSI-2 Rx Subsystem driver - Added support for Infrared Toy and IR Droid devices - Lots of random driver fixes, new features and cleanups * tag 'media/v5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (318 commits) media: camss: fix memory leaks on error handling paths in probe media: davinci: vpif_capture: fix potential double free media: radio: remove redundant assignment to variable retval media: allegro: fix potential null dereference on header media: mtk-mdp: Fix a refcounting bug on error in init media: allegro: fix an error pointer vs NULL check media: meye: fix missing pm_mchip_mode field media: cafe-driver: use generic power management media: saa7164: use generic power management media: v4l2-dev/ioctl: Fix document for VIDIOC_QUERYCAP media: v4l2: Correct kernel-doc inconsistency media: v4l2: Correct kernel-doc inconsistency media: dvbdev.h: keep * together with the type media: v4l2-subdev.h: keep * together with the type media: videobuf2: Print videobuf2 buffer state by name media: colorspaces-details.rst: fix V4L2_COLORSPACE_JPEG description media: tw68: use generic power management media: meye: use generic power management media: cx88: use generic power management media: cx25821: use generic power management ...
This commit is contained in:
Linus Torvalds
@@ -2,7 +2,7 @@
|
||||
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
The Samsung S5P/EXYNOS4 FIMC driver
|
||||
The Samsung S5P/Exynos4 FIMC driver
|
||||
===================================
|
||||
|
||||
Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd.
|
||||
@@ -19,7 +19,7 @@ drivers/media/platform/exynos4-is directory.
|
||||
Supported SoCs
|
||||
--------------
|
||||
|
||||
S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210
|
||||
S5PC100 (mem-to-mem only), S5PV210, Exynos4210
|
||||
|
||||
Supported features
|
||||
------------------
|
||||
@@ -45,7 +45,7 @@ Media device interface
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The driver supports Media Controller API as defined at :ref:`media_controller`.
|
||||
The media device driver name is "SAMSUNG S5P FIMC".
|
||||
The media device driver name is "Samsung S5P FIMC".
|
||||
|
||||
The purpose of this interface is to allow changing assignment of FIMC instances
|
||||
to the SoC peripheral camera input at runtime and optionally to control internal
|
||||
|
||||
@@ -293,6 +293,15 @@ all configurable using the following module options:
|
||||
- 0: vmalloc
|
||||
- 1: dma-contig
|
||||
|
||||
- cache_hints:
|
||||
|
||||
specifies if the device should set queues' user-space cache and memory
|
||||
consistency hint capability (V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS).
|
||||
The hints are valid only when using MMAP streaming I/O. Default is 0.
|
||||
|
||||
- 0: forbid hints
|
||||
- 1: allow hints
|
||||
|
||||
Taken together, all these module options allow you to precisely customize
|
||||
the driver behavior and test your application with all sorts of permutations.
|
||||
It is also very suitable to emulate hardware that is not yet available, e.g.
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Chrontel HDMI-CEC Controller
|
||||
|
||||
maintainers:
|
||||
- Jeff Chase <jnchase@google.com>
|
||||
|
||||
description:
|
||||
The Chrontel CH7322 is a discrete HDMI-CEC controller. It is
|
||||
programmable through I2C and drives a single CEC line.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: chrontel,ch7322
|
||||
|
||||
reg:
|
||||
description: I2C device address
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
description:
|
||||
Reference to the GPIO connected to the RESET pin, if any. This
|
||||
pin is active-low.
|
||||
maxItems: 1
|
||||
|
||||
standby-gpios:
|
||||
description:
|
||||
Reference to the GPIO connected to the OE pin, if any. When low
|
||||
the device will respond to power status requests with "standby"
|
||||
if in auto mode.
|
||||
maxItems: 1
|
||||
|
||||
# see ../cec.txt
|
||||
hdmi-phandle:
|
||||
description: phandle to the HDMI controller
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
ch7322@75 {
|
||||
compatible = "chrontel,ch7322";
|
||||
reg = <0x75>;
|
||||
interrupts = <47 IRQ_TYPE_EDGE_RISING>;
|
||||
standby-gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
|
||||
reset-gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
|
||||
hdmi-phandle = <&hdmi>;
|
||||
};
|
||||
};
|
||||
100
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
Normal file
100
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml
Normal file
@@ -0,0 +1,100 @@
|
||||
# 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/dongwoon,dw9768.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Dongchun Zhu <dongchun.zhu@mediatek.com>
|
||||
|
||||
description: |-
|
||||
The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter
|
||||
with 100 mA output current sink capability. VCM current is controlled with
|
||||
a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible)
|
||||
serial interface that operates at clock rates up to 1MHz. This chip
|
||||
integrates Advanced Actuator Control (AAC) technology and is intended for
|
||||
driving voice coil lenses in camera modules.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- dongwoon,dw9768 # for DW9768 VCM
|
||||
- giantec,gt9769 # for GT9769 VCM
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
vin-supply:
|
||||
description:
|
||||
Definition of the regulator used as Digital I/O voltage supply.
|
||||
|
||||
vdd-supply:
|
||||
description:
|
||||
Definition of the regulator used as Digital core voltage supply.
|
||||
|
||||
dongwoon,aac-mode:
|
||||
description:
|
||||
Indication of AAC mode select.
|
||||
allOf:
|
||||
- $ref: "/schemas/types.yaml#/definitions/uint32"
|
||||
- enum:
|
||||
- 1 # AAC2 mode(operation time# 0.48 x Tvib)
|
||||
- 2 # AAC3 mode(operation time# 0.70 x Tvib)
|
||||
- 3 # AAC4 mode(operation time# 0.75 x Tvib)
|
||||
- 5 # AAC8 mode(operation time# 1.13 x Tvib)
|
||||
default: 2
|
||||
|
||||
dongwoon,aac-timing:
|
||||
description:
|
||||
Number of AAC Timing count that controlled by one 6-bit period of
|
||||
vibration register AACT[5:0], the unit of which is 100 us.
|
||||
allOf:
|
||||
- $ref: "/schemas/types.yaml#/definitions/uint32"
|
||||
- default: 0x20
|
||||
minimum: 0x00
|
||||
maximum: 0x3f
|
||||
|
||||
dongwoon,clock-presc:
|
||||
description:
|
||||
Indication of VCM internal clock dividing rate select, as one multiple
|
||||
factor to calculate VCM ring periodic time Tvib.
|
||||
allOf:
|
||||
- $ref: "/schemas/types.yaml#/definitions/uint32"
|
||||
- enum:
|
||||
- 0 # Dividing Rate - 2
|
||||
- 1 # Dividing Rate - 1
|
||||
- 2 # Dividing Rate - 1/2
|
||||
- 3 # Dividing Rate - 1/4
|
||||
- 4 # Dividing Rate - 8
|
||||
- 5 # Dividing Rate - 4
|
||||
default: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- vin-supply
|
||||
- vdd-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
dw9768: camera-lens@c {
|
||||
compatible = "dongwoon,dw9768";
|
||||
reg = <0x0c>;
|
||||
|
||||
vin-supply = <&mt6358_vcamio_reg>;
|
||||
vdd-supply = <&mt6358_vcama2_reg>;
|
||||
dongwoon,aac-timing = <0x39>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@@ -0,0 +1,159 @@
|
||||
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
|
||||
# Copyright (C) 2019 Renesas Electronics Corp.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/imi,rdacm2x-gmsl.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: IMI D&D RDACM20 and RDACM21 Automotive Camera Platforms
|
||||
|
||||
maintainers:
|
||||
- Jacopo Mondi <jacopo+renesas@jmondi.org>
|
||||
- Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
|
||||
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
||||
- Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
|
||||
|
||||
description: -|
|
||||
The IMI D&D RDACM20 and RDACM21 are GMSL-compatible camera designed for
|
||||
automotive applications.
|
||||
|
||||
The RDACM20 camera module encloses a Maxim Integrated MAX9271 GMSL serializer,
|
||||
coupled with an OV10635 image sensor and an embedded MCU. Both the MCU and
|
||||
the image sensor are connected to the serializer local I2C bus and are
|
||||
accessible by the host SoC by direct addressing.
|
||||
|
||||
The RDACM21 camera module encloses the same serializer, coupled with an
|
||||
OV10640 image sensor and an OV490 ISP. Only the OV490 ISP is interfaced to
|
||||
the serializer local I2C bus while the image sensor is not accessible from
|
||||
the host SoC.
|
||||
|
||||
They both connect to a remote GMSL endpoint through a coaxial cable.
|
||||
|
||||
IMI RDACM20
|
||||
+---------------+ +--------------------------------+
|
||||
| GMSL | <- Video Stream | <- Video--------\ |
|
||||
| |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV10635 |
|
||||
| de-serializer | <- I2C messages -> | \<-->MCU |
|
||||
+---------------+ +--------------------------------+
|
||||
|
||||
IMI RDACM21
|
||||
+---------------+ +--------------------------------+
|
||||
| GMSL | <- Video Stream | <- Video--------\ |
|
||||
| |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV490 |
|
||||
| | <- I2C messages -> | | |
|
||||
| de-serializer | | OV10640 <-------| |
|
||||
+---------------+ +--------------------------------+
|
||||
|
||||
Both camera modules serialize video data generated by the embedded camera
|
||||
sensor on the GMSL serial channel to a remote GMSL de-serializer. They also
|
||||
receive and transmit I2C messages encapsulated and transmitted on the GMSL
|
||||
bidirectional control channel.
|
||||
|
||||
All I2C traffic received on the GMSL link not directed to the serializer is
|
||||
propagated on the local I2C bus to the remote device there connected. All the
|
||||
I2C traffic generated on the local I2C bus not directed to the serializer is
|
||||
propagated to the remote de-serializer encapsulated in the GMSL control
|
||||
channel.
|
||||
|
||||
The RDACM20 and RDACM21 DT node should be a direct child of the GMSL
|
||||
deserializer's I2C bus corresponding to the GMSL link that the camera is
|
||||
attached to.
|
||||
|
||||
properties:
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
compatible:
|
||||
enum:
|
||||
- imi,rdacm20
|
||||
- imi,rdacm21
|
||||
|
||||
reg:
|
||||
description: -|
|
||||
I2C device addresses, the first to be assigned to the serializer, the
|
||||
following ones to be assigned to the remote devices.
|
||||
|
||||
For RDACM20 the second entry of the property is assigned to the
|
||||
OV10635 image sensor and the optional third one to the embedded MCU.
|
||||
|
||||
For RDACM21 the second entry is assigned to the OV490 ISP and the optional
|
||||
third one ignored.
|
||||
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
|
||||
port:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
description: -|
|
||||
Connection to the remote GMSL endpoint are modelled using the OF graph
|
||||
bindings in accordance with the video interface bindings defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
The device node contains a single "port" child node with a single
|
||||
"endpoint" sub-device.
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
remote-endpoint:
|
||||
description: -|
|
||||
phandle to the remote GMSL endpoint sub-node in the remote node
|
||||
port.
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- remote-endpoint
|
||||
|
||||
required:
|
||||
- endpoint
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- port
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c@e66d8000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
reg = <0 0xe66d8000>;
|
||||
|
||||
camera@31 {
|
||||
compatible = "imi,rdacm20";
|
||||
reg = <0x31>, <0x41>, <0x51>;
|
||||
|
||||
port {
|
||||
rdacm20_out0: endpoint {
|
||||
remote-endpoint = <&max9286_in0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
i2c@e66d8000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
reg = <0 0xe66d8000>;
|
||||
|
||||
camera@31 {
|
||||
compatible = "imi,rdacm21";
|
||||
reg = <0x31>, <0x41>;
|
||||
|
||||
port {
|
||||
rdacm21_out0: endpoint {
|
||||
remote-endpoint = <&max9286_in0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
366
Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
Normal file
366
Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
Normal file
@@ -0,0 +1,366 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (C) 2019 Renesas Electronics Corp.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/i2c/maxim,max9286.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Maxim Integrated Quad GMSL Deserializer
|
||||
|
||||
maintainers:
|
||||
- Jacopo Mondi <jacopo+renesas@jmondi.org>
|
||||
- Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
|
||||
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
||||
- Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
|
||||
|
||||
description: |
|
||||
The MAX9286 deserializer receives video data on up to 4 Gigabit Multimedia
|
||||
Serial Links (GMSL) and outputs them on a CSI-2 D-PHY port using up to 4 data
|
||||
lanes.
|
||||
|
||||
In addition to video data, the GMSL links carry a bidirectional control
|
||||
channel that encapsulates I2C messages. The MAX9286 forwards all I2C traffic
|
||||
not addressed to itself to the other side of the links, where a GMSL
|
||||
serializer will output it on a local I2C bus. In the other direction all I2C
|
||||
traffic received over GMSL by the MAX9286 is output on the local I2C bus.
|
||||
|
||||
properties:
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
compatible:
|
||||
const: maxim,max9286
|
||||
|
||||
reg:
|
||||
description: I2C device address
|
||||
maxItems: 1
|
||||
|
||||
poc-supply:
|
||||
description: Regulator providing Power over Coax to the cameras
|
||||
maxItems: 1
|
||||
|
||||
enable-gpios:
|
||||
description: GPIO connected to the \#PWDN pin with inverted polarity
|
||||
maxItems: 1
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
'#gpio-cells':
|
||||
const: 2
|
||||
|
||||
ports:
|
||||
type: object
|
||||
description: |
|
||||
The connections to the MAX9286 GMSL and its endpoint nodes are modelled
|
||||
using the OF graph bindings in accordance with the video interface
|
||||
bindings defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
The following table lists the port number corresponding to each device
|
||||
port.
|
||||
|
||||
Port Description
|
||||
----------------------------------------
|
||||
Port 0 GMSL Input 0
|
||||
Port 1 GMSL Input 1
|
||||
Port 2 GMSL Input 2
|
||||
Port 3 GMSL Input 3
|
||||
Port 4 CSI-2 Output
|
||||
|
||||
properties:
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
port@[0-3]:
|
||||
type: object
|
||||
properties:
|
||||
reg:
|
||||
enum: [ 0, 1, 2, 3 ]
|
||||
|
||||
endpoint:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
remote-endpoint:
|
||||
description: |
|
||||
phandle to the remote GMSL source endpoint subnode in the
|
||||
remote node port.
|
||||
|
||||
required:
|
||||
- remote-endpoint
|
||||
|
||||
required:
|
||||
- reg
|
||||
- endpoint
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
port@4:
|
||||
type: object
|
||||
properties:
|
||||
reg:
|
||||
const: 4
|
||||
|
||||
endpoint:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
remote-endpoint:
|
||||
description: phandle to the remote CSI-2 sink endpoint.
|
||||
|
||||
data-lanes:
|
||||
description: array of physical CSI-2 data lane indexes.
|
||||
|
||||
required:
|
||||
- remote-endpoint
|
||||
- data-lanes
|
||||
|
||||
required:
|
||||
- reg
|
||||
- endpoint
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- port@4
|
||||
|
||||
i2c-mux:
|
||||
type: object
|
||||
description: |
|
||||
Each GMSL link is modelled as a child bus of an i2c bus
|
||||
multiplexer/switch, in accordance with bindings described in
|
||||
Documentation/devicetree/bindings/i2c/i2c-mux.txt.
|
||||
|
||||
properties:
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^i2c@[0-3]$":
|
||||
type: object
|
||||
description: |
|
||||
Child node of the i2c bus multiplexer which represents a GMSL link.
|
||||
Each serializer device on the GMSL link remote end is represented with
|
||||
an i2c-mux child node. The MAX9286 chip supports up to 4 GMSL
|
||||
channels.
|
||||
|
||||
properties:
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 0
|
||||
|
||||
reg:
|
||||
description: The index of the GMSL channel.
|
||||
maxItems: 1
|
||||
|
||||
patternProperties:
|
||||
"^camera@[a-f0-9]+$":
|
||||
type: object
|
||||
description: |
|
||||
The remote camera device, composed by a GMSL serializer and a
|
||||
connected video source.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
description: The remote device compatible string.
|
||||
|
||||
reg:
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
description: |
|
||||
The I2C addresses to be assigned to the remote devices through
|
||||
address reprogramming. The number of entries depends on the
|
||||
requirements of the currently connected remote device.
|
||||
|
||||
port:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
remote-endpoint:
|
||||
description: phandle to the MAX9286 sink endpoint.
|
||||
|
||||
required:
|
||||
- remote-endpoint
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- endpoint
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- port
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- ports
|
||||
- i2c-mux
|
||||
- gpio-controller
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c@e66d8000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
reg = <0 0xe66d8000>;
|
||||
|
||||
gmsl-deserializer@2c {
|
||||
compatible = "maxim,max9286";
|
||||
reg = <0x2c>;
|
||||
poc-supply = <&camera_poc_12v>;
|
||||
enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
max9286_in0: endpoint {
|
||||
remote-endpoint = <&rdacm20_out0>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
max9286_in1: endpoint {
|
||||
remote-endpoint = <&rdacm20_out1>;
|
||||
};
|
||||
};
|
||||
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
|
||||
max9286_in2: endpoint {
|
||||
remote-endpoint = <&rdacm20_out2>;
|
||||
};
|
||||
};
|
||||
|
||||
port@3 {
|
||||
reg = <3>;
|
||||
|
||||
max9286_in3: endpoint {
|
||||
remote-endpoint = <&rdacm20_out3>;
|
||||
};
|
||||
};
|
||||
|
||||
port@4 {
|
||||
reg = <4>;
|
||||
|
||||
max9286_out: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
remote-endpoint = <&csi40_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c-mux {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
i2c@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
|
||||
camera@51 {
|
||||
compatible = "imi,rdacm20";
|
||||
reg = <0x51>, <0x61>;
|
||||
|
||||
port {
|
||||
rdacm20_out0: endpoint {
|
||||
remote-endpoint = <&max9286_in0>;
|
||||
};
|
||||
};
|
||||
|
||||
};
|
||||
};
|
||||
|
||||
i2c@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>;
|
||||
|
||||
camera@52 {
|
||||
compatible = "imi,rdacm20";
|
||||
reg = <0x52>, <0x62>;
|
||||
|
||||
port {
|
||||
rdacm20_out1: endpoint {
|
||||
remote-endpoint = <&max9286_in1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c@2 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <2>;
|
||||
|
||||
camera@53 {
|
||||
compatible = "imi,rdacm20";
|
||||
reg = <0x53>, <0x63>;
|
||||
|
||||
port {
|
||||
rdacm20_out2: endpoint {
|
||||
remote-endpoint = <&max9286_in2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
i2c@3 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <3>;
|
||||
|
||||
camera@54 {
|
||||
compatible = "imi,rdacm20";
|
||||
reg = <0x54>, <0x64>;
|
||||
|
||||
port {
|
||||
rdacm20_out3: endpoint {
|
||||
remote-endpoint = <&max9286_in3>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -1,34 +0,0 @@
|
||||
Renesas R-Car Frame Compression Processor (FCP)
|
||||
-----------------------------------------------
|
||||
|
||||
The FCP is a companion module of video processing modules in the Renesas R-Car
|
||||
Gen3 and RZ/G2 SoCs. It provides data compression and decompression, data
|
||||
caching, and conversion of AXI transactions in order to reduce the memory
|
||||
bandwidth.
|
||||
|
||||
There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and FCP
|
||||
for FDP (FCPF). Their configuration and behaviour depend on the module they
|
||||
are paired with. These DT bindings currently support the FCPV and FCPF.
|
||||
|
||||
- compatible: Must be one or more of the following
|
||||
|
||||
- "renesas,fcpv" for generic compatible 'FCP for VSP'
|
||||
- "renesas,fcpf" for generic compatible 'FCP for FDP'
|
||||
|
||||
- reg: the register base and size for the device registers
|
||||
- clocks: Reference to the functional clock
|
||||
|
||||
Optional properties:
|
||||
- power-domains : power-domain property defined with a power domain specifier
|
||||
to respective power domain.
|
||||
|
||||
|
||||
Device node example
|
||||
-------------------
|
||||
|
||||
fcpvd1: fcp@fea2f000 {
|
||||
compatible = "renesas,fcpv";
|
||||
reg = <0 0xfea2f000 0 0x200>;
|
||||
clocks = <&cpg CPG_MOD 602>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VP>;
|
||||
};
|
||||
66
Documentation/devicetree/bindings/media/renesas,fcp.yaml
Normal file
66
Documentation/devicetree/bindings/media/renesas,fcp.yaml
Normal file
@@ -0,0 +1,66 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/renesas,fcp.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas R-Car Frame Compression Processor (FCP)
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
|
||||
description: |
|
||||
The FCP is a companion module of video processing modules in the Renesas
|
||||
R-Car Gen3 and RZ/G2 SoCs. It provides data compression and decompression,
|
||||
data caching, and conversion of AXI transactions in order to reduce the
|
||||
memory bandwidth.
|
||||
|
||||
There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and
|
||||
FCP for FDP (FCPF). Their configuration and behaviour depend on the module
|
||||
they are paired with. These DT bindings currently support the FCPV and FCPF.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- renesas,fcpv # FCP for VSP
|
||||
- renesas,fcpf # FCP for FDP
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- power-domains
|
||||
- resets
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
# R8A7795 (R-Car H3) FCP for VSP-D1
|
||||
- |
|
||||
#include <dt-bindings/clock/renesas-cpg-mssr.h>
|
||||
#include <dt-bindings/power/r8a7795-sysc.h>
|
||||
|
||||
fcp@fea2f000 {
|
||||
compatible = "renesas,fcpv";
|
||||
reg = <0xfea2f000 0x200>;
|
||||
clocks = <&cpg CPG_MOD 602>;
|
||||
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
|
||||
resets = <&cpg 602>;
|
||||
iommus = <&ipmmu_vi0 9>;
|
||||
};
|
||||
...
|
||||
@@ -1,37 +0,0 @@
|
||||
Renesas R-Car Fine Display Processor (FDP1)
|
||||
-------------------------------------------
|
||||
|
||||
The FDP1 is a de-interlacing module which converts interlaced video to
|
||||
progressive video. It is capable of performing pixel format conversion between
|
||||
YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are supported as
|
||||
an input to the module.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: must be "renesas,fdp1"
|
||||
- reg: the register base and size for the device registers
|
||||
- interrupts : interrupt specifier for the FDP1 instance
|
||||
- clocks: reference to the functional clock
|
||||
|
||||
Optional properties:
|
||||
|
||||
- power-domains: reference to the power domain that the FDP1 belongs to, if
|
||||
any.
|
||||
- renesas,fcp: a phandle referencing the FCP that handles memory accesses
|
||||
for the FDP1. Not needed on Gen2, mandatory on Gen3.
|
||||
|
||||
Please refer to the binding documentation for the clock and/or power domain
|
||||
providers for more details.
|
||||
|
||||
|
||||
Device node example
|
||||
-------------------
|
||||
|
||||
fdp1@fe940000 {
|
||||
compatible = "renesas,fdp1";
|
||||
reg = <0 0xfe940000 0 0x2400>;
|
||||
interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 119>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VP>;
|
||||
renesas,fcp = <&fcpf0>;
|
||||
};
|
||||
69
Documentation/devicetree/bindings/media/renesas,fdp1.yaml
Normal file
69
Documentation/devicetree/bindings/media/renesas,fdp1.yaml
Normal file
@@ -0,0 +1,69 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/renesas,fdp1.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas R-Car Fine Display Processor (FDP1)
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
|
||||
description:
|
||||
The FDP1 is a de-interlacing module which converts interlaced video to
|
||||
progressive video. It is capable of performing pixel format conversion
|
||||
between YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are
|
||||
supported as an input to the module.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- renesas,fdp1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
renesas,fcp:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
A phandle referencing the FCP that handles memory accesses for the FDP1.
|
||||
Not allowed on R-Car Gen2, mandatory on R-Car Gen3.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- power-domains
|
||||
- resets
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/renesas-cpg-mssr.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/power/r8a7795-sysc.h>
|
||||
|
||||
fdp1@fe940000 {
|
||||
compatible = "renesas,fdp1";
|
||||
reg = <0xfe940000 0x2400>;
|
||||
interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 119>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VP>;
|
||||
resets = <&cpg 119>;
|
||||
renesas,fcp = <&fcpf0>;
|
||||
};
|
||||
...
|
||||
@@ -1,30 +0,0 @@
|
||||
* Renesas VSP Video Processing Engine
|
||||
|
||||
The VSP is a video processing engine that supports up-/down-scaling, alpha
|
||||
blending, color space conversion and various other image processing features.
|
||||
It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must contain one of the following values
|
||||
- "renesas,vsp1" for the R-Car Gen2 and RZ/G1 VSP1
|
||||
- "renesas,vsp2" for the R-Car Gen3 and RZ/G2 VSP2
|
||||
|
||||
- reg: Base address and length of the registers block for the VSP.
|
||||
- interrupts: VSP interrupt specifier.
|
||||
- clocks: A phandle + clock-specifier pair for the VSP functional clock.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- renesas,fcp: A phandle referencing the FCP that handles memory accesses
|
||||
for the VSP. Not needed on Gen2, mandatory on Gen3.
|
||||
|
||||
|
||||
Example: R8A7790 (R-Car H2) VSP1-S node
|
||||
|
||||
vsp@fe928000 {
|
||||
compatible = "renesas,vsp1";
|
||||
reg = <0 0xfe928000 0 0x8000>;
|
||||
interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>;
|
||||
};
|
||||
97
Documentation/devicetree/bindings/media/renesas,vsp1.yaml
Normal file
97
Documentation/devicetree/bindings/media/renesas,vsp1.yaml
Normal file
@@ -0,0 +1,97 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/renesas,vsp1.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas VSP Video Processing Engine
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
|
||||
description:
|
||||
The VSP is a video processing engine that supports up-/down-scaling, alpha
|
||||
blending, color space conversion and various other image processing features.
|
||||
It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- renesas,vsp1 # R-Car Gen2 and RZ/G1
|
||||
- renesas,vsp2 # R-Car Gen3 and RZ/G2
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
renesas,fcp:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
A phandle referencing the FCP that handles memory accesses for the VSP.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- power-domains
|
||||
- resets
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: renesas,vsp1
|
||||
then:
|
||||
properties:
|
||||
renesas,fcp: false
|
||||
else:
|
||||
required:
|
||||
- renesas,fcp
|
||||
|
||||
examples:
|
||||
# R8A7790 (R-Car H2) VSP1-S
|
||||
- |
|
||||
#include <dt-bindings/clock/renesas-cpg-mssr.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/power/r8a7790-sysc.h>
|
||||
|
||||
vsp@fe928000 {
|
||||
compatible = "renesas,vsp1";
|
||||
reg = <0xfe928000 0x8000>;
|
||||
interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 131>;
|
||||
power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
|
||||
resets = <&cpg 131>;
|
||||
};
|
||||
|
||||
# R8A77951 (R-Car H3) VSP2-BC
|
||||
- |
|
||||
#include <dt-bindings/clock/renesas-cpg-mssr.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/power/r8a7795-sysc.h>
|
||||
|
||||
vsp@fe920000 {
|
||||
compatible = "renesas,vsp2";
|
||||
reg = <0xfe920000 0x8000>;
|
||||
interrupts = <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 624>;
|
||||
power-domains = <&sysc R8A7795_PD_A3VP>;
|
||||
resets = <&cpg 624>;
|
||||
|
||||
renesas,fcp = <&fcpvb1>;
|
||||
};
|
||||
...
|
||||
@@ -0,0 +1,237 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Xilinx MIPI CSI-2 Receiver Subsystem
|
||||
|
||||
maintainers:
|
||||
- Vishal Sagar <vishal.sagar@xilinx.com>
|
||||
|
||||
description: |
|
||||
The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI CSI-2
|
||||
traffic from compliant camera sensors and send the output as AXI4 Stream
|
||||
video data for image processing.
|
||||
The subsystem consists of a MIPI D-PHY in slave mode which captures the
|
||||
data packets. This is passed along the MIPI CSI-2 Rx IP which extracts the
|
||||
packet data. The optional Video Format Bridge (VFB) converts this data to
|
||||
AXI4 Stream video data.
|
||||
For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver Subsystem.
|
||||
Please note that this bindings includes only the MIPI CSI-2 Rx controller
|
||||
and Video Format Bridge and not D-PHY.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- xlnx,mipi-csi2-rx-subsystem-5.0
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
description: List of clock specifiers
|
||||
items:
|
||||
- description: AXI Lite clock
|
||||
- description: Video clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: lite_aclk
|
||||
- const: video_aclk
|
||||
|
||||
xlnx,csi-pxl-format:
|
||||
description: |
|
||||
This denotes the CSI Data type selected in hw design.
|
||||
Packets other than this data type (except for RAW8 and
|
||||
User defined data types) will be filtered out.
|
||||
Possible values are as below -
|
||||
0x1e - YUV4228B
|
||||
0x1f - YUV42210B
|
||||
0x20 - RGB444
|
||||
0x21 - RGB555
|
||||
0x22 - RGB565
|
||||
0x23 - RGB666
|
||||
0x24 - RGB888
|
||||
0x28 - RAW6
|
||||
0x29 - RAW7
|
||||
0x2a - RAW8
|
||||
0x2b - RAW10
|
||||
0x2c - RAW12
|
||||
0x2d - RAW14
|
||||
0x2e - RAW16
|
||||
0x2f - RAW20
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/uint32
|
||||
- anyOf:
|
||||
- minimum: 0x1e
|
||||
- maximum: 0x24
|
||||
- minimum: 0x28
|
||||
- maximum: 0x2f
|
||||
|
||||
xlnx,vfb:
|
||||
type: boolean
|
||||
description: Present when Video Format Bridge is enabled in IP configuration
|
||||
|
||||
xlnx,en-csi-v2-0:
|
||||
type: boolean
|
||||
description: Present if CSI v2 is enabled in IP configuration.
|
||||
|
||||
xlnx,en-vcx:
|
||||
type: boolean
|
||||
description: |
|
||||
When present, there are maximum 16 virtual channels, else only 4.
|
||||
|
||||
xlnx,en-active-lanes:
|
||||
type: boolean
|
||||
description: |
|
||||
Present if the number of active lanes can be re-configured at
|
||||
runtime in the Protocol Configuration Register. Otherwise all lanes,
|
||||
as set in IP configuration, are always active.
|
||||
|
||||
video-reset-gpios:
|
||||
description: Optional specifier for a GPIO that asserts video_aresetn.
|
||||
maxItems: 1
|
||||
|
||||
ports:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
port@0:
|
||||
type: object
|
||||
description: |
|
||||
Input / sink port node, single endpoint describing the
|
||||
CSI-2 transmitter.
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0
|
||||
|
||||
endpoint:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
|
||||
data-lanes:
|
||||
description: |
|
||||
This is required only in the sink port 0 endpoint which
|
||||
connects to MIPI CSI-2 source like sensor.
|
||||
The possible values are -
|
||||
1 - For 1 lane enabled in IP.
|
||||
1 2 - For 2 lanes enabled in IP.
|
||||
1 2 3 - For 3 lanes enabled in IP.
|
||||
1 2 3 4 - For 4 lanes enabled in IP.
|
||||
items:
|
||||
- const: 1
|
||||
- const: 2
|
||||
- const: 3
|
||||
- const: 4
|
||||
|
||||
remote-endpoint: true
|
||||
|
||||
required:
|
||||
- data-lanes
|
||||
- remote-endpoint
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
port@1:
|
||||
type: object
|
||||
description: |
|
||||
Output / source port node, endpoint describing modules
|
||||
connected the CSI-2 receiver.
|
||||
|
||||
properties:
|
||||
|
||||
reg:
|
||||
const: 1
|
||||
|
||||
endpoint:
|
||||
type: object
|
||||
|
||||
properties:
|
||||
|
||||
remote-endpoint: true
|
||||
|
||||
required:
|
||||
- remote-endpoint
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- ports
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
required:
|
||||
- xlnx,vfb
|
||||
then:
|
||||
required:
|
||||
- xlnx,csi-pxl-format
|
||||
else:
|
||||
properties:
|
||||
xlnx,csi-pxl-format: false
|
||||
|
||||
- if:
|
||||
not:
|
||||
required:
|
||||
- xlnx,en-csi-v2-0
|
||||
then:
|
||||
properties:
|
||||
xlnx,en-vcx: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
xcsi2rxss_1: csi2rx@a0020000 {
|
||||
compatible = "xlnx,mipi-csi2-rx-subsystem-5.0";
|
||||
reg = <0xa0020000 0x10000>;
|
||||
interrupt-parent = <&gic>;
|
||||
interrupts = <0 95 4>;
|
||||
xlnx,csi-pxl-format = <0x2a>;
|
||||
xlnx,vfb;
|
||||
xlnx,en-active-lanes;
|
||||
xlnx,en-csi-v2-0;
|
||||
xlnx,en-vcx;
|
||||
clock-names = "lite_aclk", "video_aclk";
|
||||
clocks = <&misc_clk_0>, <&misc_clk_1>;
|
||||
video-reset-gpios = <&gpio 86 GPIO_ACTIVE_LOW>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
/* Sink port */
|
||||
reg = <0>;
|
||||
csiss_in: endpoint {
|
||||
data-lanes = <1 2 3 4>;
|
||||
/* MIPI CSI-2 Camera handle */
|
||||
remote-endpoint = <&camera_out>;
|
||||
};
|
||||
};
|
||||
port@1 {
|
||||
/* Source port */
|
||||
reg = <1>;
|
||||
csiss_out: endpoint {
|
||||
remote-endpoint = <&vproc_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@@ -473,6 +473,8 @@ patternProperties:
|
||||
description: ILI Technology Corporation (ILITEK)
|
||||
"^img,.*":
|
||||
description: Imagination Technologies Ltd.
|
||||
"^imi,.*":
|
||||
description: Integrated Micro-Electronics Inc.
|
||||
"^incircuit,.*":
|
||||
description: In-Circuit GmbH
|
||||
"^inet-tek,.*":
|
||||
|
||||
@@ -20,7 +20,7 @@ last known snapshot and evolved the driver to the state it is in
|
||||
here.
|
||||
|
||||
More information on this driver can be found at:
|
||||
http://www.isely.net/pvrusb2.html
|
||||
https://www.isely.net/pvrusb2.html
|
||||
|
||||
|
||||
This driver has a strong separation of layers. They are very
|
||||
|
||||
@@ -18,7 +18,7 @@ These differ mainly by the bandswitch byte.
|
||||
Tuner Manufacturers
|
||||
-------------------
|
||||
|
||||
- SAMSUNG Tuner identification: (e.g. TCPM9091PD27)
|
||||
- Samsung Tuner identification: (e.g. TCPM9091PD27)
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
||||
@@ -57,6 +57,9 @@ returns the information to the application. The ioctl never fails.
|
||||
- ``name[32]``
|
||||
- The name of this CEC adapter. The combination ``driver`` and
|
||||
``name`` must be unique.
|
||||
* - __u32
|
||||
- ``available_log_addrs``
|
||||
- The maximum number of logical addresses that can be configured.
|
||||
* - __u32
|
||||
- ``capabilities``
|
||||
- The capabilities of the CEC adapter, see
|
||||
|
||||
@@ -34,8 +34,7 @@ Arguments
|
||||
File descriptor returned by :ref:`open() <frontend_f_open>`.
|
||||
|
||||
``argp``
|
||||
pointer to struct struct
|
||||
:c:type:`dvb_frontend_info`
|
||||
pointer to struct :c:type:`dvb_frontend_info`
|
||||
|
||||
|
||||
Description
|
||||
|
||||
@@ -23,8 +23,8 @@ argument to the :ref:`VIDIOC_QUERYBUF`,
|
||||
:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
|
||||
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. In the multi-planar API,
|
||||
some plane-specific members of struct :c:type:`v4l2_buffer`,
|
||||
such as pointers and sizes for each plane, are stored in struct
|
||||
struct :c:type:`v4l2_plane` instead. In that case, struct
|
||||
such as pointers and sizes for each plane, are stored in
|
||||
struct :c:type:`v4l2_plane` instead. In that case,
|
||||
struct :c:type:`v4l2_buffer` contains an array of plane structures.
|
||||
|
||||
Dequeued video buffers come with timestamps. The driver decides at which
|
||||
@@ -577,7 +577,10 @@ Buffer Flags
|
||||
applications shall use this flag if the data captured in the
|
||||
buffer is not going to be touched by the CPU, instead the buffer
|
||||
will, probably, be passed on to a DMA-capable hardware unit for
|
||||
further processing or output.
|
||||
further processing or output. This flag is ignored unless the
|
||||
queue is used for :ref:`memory mapping <mmap>` streaming I/O and
|
||||
reports :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
|
||||
<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
|
||||
* .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`:
|
||||
|
||||
- ``V4L2_BUF_FLAG_NO_CACHE_CLEAN``
|
||||
@@ -585,7 +588,10 @@ Buffer Flags
|
||||
- Caches do not have to be cleaned for this buffer. Typically
|
||||
applications shall use this flag for output buffers if the data in
|
||||
this buffer has not been created by the CPU but by some
|
||||
DMA-capable unit, in which case caches have not been used.
|
||||
DMA-capable unit, in which case caches have not been used. This flag
|
||||
is ignored unless the queue is used for :ref:`memory mapping <mmap>`
|
||||
streaming I/O and reports :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
|
||||
<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
|
||||
* .. _`V4L2-BUF-FLAG-M2M-HOLD-CAPTURE-BUF`:
|
||||
|
||||
- ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF``
|
||||
@@ -681,6 +687,36 @@ Buffer Flags
|
||||
|
||||
\normalsize
|
||||
|
||||
.. _memory-flags:
|
||||
|
||||
Memory Consistency Flags
|
||||
========================
|
||||
|
||||
.. tabularcolumns:: |p{7.0cm}|p{2.2cm}|p{8.3cm}|
|
||||
|
||||
.. cssclass:: longtable
|
||||
|
||||
.. flat-table::
|
||||
:header-rows: 0
|
||||
:stub-columns: 0
|
||||
:widths: 3 1 4
|
||||
|
||||
* .. _`V4L2-FLAG-MEMORY-NON-CONSISTENT`:
|
||||
|
||||
- ``V4L2_FLAG_MEMORY_NON_CONSISTENT``
|
||||
- 0x00000001
|
||||
- A buffer is allocated either in consistent (it will be automatically
|
||||
coherent between the CPU and the bus) or non-consistent memory. The
|
||||
latter can provide performance gains, for instance the CPU cache
|
||||
sync/flush operations can be avoided if the buffer is accessed by the
|
||||
corresponding device only and the CPU does not read/write to/from that
|
||||
buffer. However, this requires extra care from the driver -- it must
|
||||
guarantee memory consistency by issuing a cache flush/sync when
|
||||
consistency is needed. If this flag is set V4L2 will attempt to
|
||||
allocate the buffer in non-consistent memory. The flag takes effect
|
||||
only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the
|
||||
queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
|
||||
<V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability.
|
||||
|
||||
.. c:type:: v4l2_memory
|
||||
|
||||
|
||||
@@ -767,8 +767,8 @@ scaled to [-128…128] and then clipped to [-128…127].
|
||||
information. So if something other than sRGB is used, then the driver
|
||||
will have to set that information explicitly. Effectively
|
||||
``V4L2_COLORSPACE_JPEG`` can be considered to be an abbreviation for
|
||||
``V4L2_COLORSPACE_SRGB``, ``V4L2_YCBCR_ENC_601`` and
|
||||
``V4L2_QUANTIZATION_FULL_RANGE``.
|
||||
``V4L2_COLORSPACE_SRGB``, ``V4L2_XFER_FUNC_SRGB``, ``V4L2_YCBCR_ENC_601``
|
||||
and ``V4L2_QUANTIZATION_FULL_RANGE``.
|
||||
|
||||
***************************************
|
||||
Detailed Transfer Function Descriptions
|
||||
|
||||
@@ -247,7 +247,7 @@ Querying Capabilities
|
||||
Initialization
|
||||
==============
|
||||
|
||||
1. Set the coded format on ``OUTPUT`` via :c:func:`VIDIOC_S_FMT`
|
||||
1. Set the coded format on ``OUTPUT`` via :c:func:`VIDIOC_S_FMT`.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
@@ -803,7 +803,7 @@ it may be affected as per normal decoder operation.
|
||||
* The decoder will drop all the pending ``OUTPUT`` buffers and they must be
|
||||
treated as returned to the client (following standard semantics).
|
||||
|
||||
2. Restart the ``OUTPUT`` queue via :c:func:`VIDIOC_STREAMON`
|
||||
2. Restart the ``OUTPUT`` queue via :c:func:`VIDIOC_STREAMON`.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
@@ -906,7 +906,9 @@ reflected by corresponding queries):
|
||||
|
||||
* visible resolution (selection rectangles),
|
||||
|
||||
* the minimum number of buffers needed for decoding.
|
||||
* the minimum number of buffers needed for decoding,
|
||||
|
||||
* bit-depth of the bitstream has been changed.
|
||||
|
||||
Whenever that happens, the decoder must proceed as follows:
|
||||
|
||||
@@ -1059,7 +1061,7 @@ sequence was started.
|
||||
``V4L2_DEC_CMD_STOP`` again while the drain sequence is in progress and they
|
||||
will fail with -EBUSY error code if attempted.
|
||||
|
||||
Although mandatory, the availability of decoder commands may be queried
|
||||
Although not mandatory, the availability of decoder commands may be queried
|
||||
using :c:func:`VIDIOC_TRY_DECODER_CMD`.
|
||||
|
||||
End of Stream
|
||||
|
||||
753
Documentation/userspace-api/media/v4l/dev-encoder.rst
Normal file
753
Documentation/userspace-api/media/v4l/dev-encoder.rst
Normal file
@@ -0,0 +1,753 @@
|
||||
.. This file is dual-licensed: you can use it either under the terms
|
||||
.. of the GPL 2.0 or the GFDL 1.1+ license, at your option. Note that this
|
||||
.. dual licensing only applies to this file, and not this project as a
|
||||
.. whole.
|
||||
..
|
||||
.. a) This file is free software; you can redistribute it and/or
|
||||
.. modify it under the terms of the GNU General Public License as
|
||||
.. published by the Free Software Foundation version 2 of
|
||||
.. the License.
|
||||
..
|
||||
.. This file is distributed in the hope that it will be useful,
|
||||
.. but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
.. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
.. GNU General Public License for more details.
|
||||
..
|
||||
.. Or, alternatively,
|
||||
..
|
||||
.. b) Permission is granted to copy, distribute and/or modify this
|
||||
.. document under the terms of the GNU Free Documentation License,
|
||||
.. Version 1.1 or any later version published by the Free Software
|
||||
.. Foundation, with no Invariant Sections, no Front-Cover Texts
|
||||
.. and no Back-Cover Texts. A copy of the license is included at
|
||||
.. Documentation/userspace-api/media/fdl-appendix.rst.
|
||||
..
|
||||
.. TODO: replace it to GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections
|
||||
|
||||
.. _encoder:
|
||||
|
||||
*************************************************
|
||||
Memory-to-Memory Stateful Video Encoder Interface
|
||||
*************************************************
|
||||
|
||||
A stateful video encoder takes raw video frames in display order and encodes
|
||||
them into a bytestream. It generates complete chunks of the bytestream, including
|
||||
all metadata, headers, etc. The resulting bytestream does not require any
|
||||
further post-processing by the client.
|
||||
|
||||
Performing software stream processing, header generation etc. in the driver
|
||||
in order to support this interface is strongly discouraged. In case such
|
||||
operations are needed, use of the Stateless Video Encoder Interface (in
|
||||
development) is strongly advised.
|
||||
|
||||
Conventions and Notations Used in This Document
|
||||
===============================================
|
||||
|
||||
1. The general V4L2 API rules apply if not specified in this document
|
||||
otherwise.
|
||||
|
||||
2. The meaning of words "must", "may", "should", etc. is as per `RFC
|
||||
2119 <https://tools.ietf.org/html/rfc2119>`_.
|
||||
|
||||
3. All steps not marked "optional" are required.
|
||||
|
||||
4. :c:func:`VIDIOC_G_EXT_CTRLS` and :c:func:`VIDIOC_S_EXT_CTRLS` may be used
|
||||
interchangeably with :c:func:`VIDIOC_G_CTRL` and :c:func:`VIDIOC_S_CTRL`,
|
||||
unless specified otherwise.
|
||||
|
||||
5. Single-planar API (see :ref:`planar-apis`) and applicable structures may be
|
||||
used interchangeably with multi-planar API, unless specified otherwise,
|
||||
depending on encoder capabilities and following the general V4L2 guidelines.
|
||||
|
||||
6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i =
|
||||
[0..2]: i = 0, 1, 2.
|
||||
|
||||
7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE``
|
||||
queue containing data that resulted from processing buffer A.
|
||||
|
||||
Glossary
|
||||
========
|
||||
|
||||
Refer to :ref:`decoder-glossary`.
|
||||
|
||||
State Machine
|
||||
=============
|
||||
|
||||
.. kernel-render:: DOT
|
||||
:alt: DOT digraph of encoder state machine
|
||||
:caption: Encoder State Machine
|
||||
|
||||
digraph encoder_state_machine {
|
||||
node [shape = doublecircle, label="Encoding"] Encoding;
|
||||
|
||||
node [shape = circle, label="Initialization"] Initialization;
|
||||
node [shape = circle, label="Stopped"] Stopped;
|
||||
node [shape = circle, label="Drain"] Drain;
|
||||
node [shape = circle, label="Reset"] Reset;
|
||||
|
||||
node [shape = point]; qi
|
||||
qi -> Initialization [ label = "open()" ];
|
||||
|
||||
Initialization -> Encoding [ label = "Both queues streaming" ];
|
||||
|
||||
Encoding -> Drain [ label = "V4L2_ENC_CMD_STOP" ];
|
||||
Encoding -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
|
||||
Encoding -> Stopped [ label = "VIDIOC_STREAMOFF(OUTPUT)" ];
|
||||
Encoding -> Encoding;
|
||||
|
||||
Drain -> Stopped [ label = "All CAPTURE\nbuffers dequeued\nor\nVIDIOC_STREAMOFF(OUTPUT)" ];
|
||||
Drain -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
|
||||
|
||||
Reset -> Encoding [ label = "VIDIOC_STREAMON(CAPTURE)" ];
|
||||
Reset -> Initialization [ label = "VIDIOC_REQBUFS(OUTPUT, 0)" ];
|
||||
|
||||
Stopped -> Encoding [ label = "V4L2_ENC_CMD_START\nor\nVIDIOC_STREAMON(OUTPUT)" ];
|
||||
Stopped -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ];
|
||||
}
|
||||
|
||||
Querying Capabilities
|
||||
=====================
|
||||
|
||||
1. To enumerate the set of coded formats supported by the encoder, the
|
||||
client may call :c:func:`VIDIOC_ENUM_FMT` on ``CAPTURE``.
|
||||
|
||||
* The full set of supported formats will be returned, regardless of the
|
||||
format set on ``OUTPUT``.
|
||||
|
||||
2. To enumerate the set of supported raw formats, the client may call
|
||||
:c:func:`VIDIOC_ENUM_FMT` on ``OUTPUT``.
|
||||
|
||||
* Only the formats supported for the format currently active on ``CAPTURE``
|
||||
will be returned.
|
||||
|
||||
* In order to enumerate raw formats supported by a given coded format,
|
||||
the client must first set that coded format on ``CAPTURE`` and then
|
||||
enumerate the formats on ``OUTPUT``.
|
||||
|
||||
3. The client may use :c:func:`VIDIOC_ENUM_FRAMESIZES` to detect supported
|
||||
resolutions for a given format, passing the desired pixel format in
|
||||
:c:type:`v4l2_frmsizeenum` ``pixel_format``.
|
||||
|
||||
* Values returned by :c:func:`VIDIOC_ENUM_FRAMESIZES` for a coded pixel
|
||||
format will include all possible coded resolutions supported by the
|
||||
encoder for the given coded pixel format.
|
||||
|
||||
* Values returned by :c:func:`VIDIOC_ENUM_FRAMESIZES` for a raw pixel format
|
||||
will include all possible frame buffer resolutions supported by the
|
||||
encoder for the given raw pixel format and coded format currently set on
|
||||
``CAPTURE``.
|
||||
|
||||
4. The client may use :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` to detect supported
|
||||
frame intervals for a given format and resolution, passing the desired pixel
|
||||
format in :c:type:`v4l2_frmsizeenum` ``pixel_format`` and the resolution
|
||||
in :c:type:`v4l2_frmsizeenum` ``width`` and :c:type:`v4l2_frmsizeenum`
|
||||
``height``.
|
||||
|
||||
* Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a coded pixel
|
||||
format and coded resolution will include all possible frame intervals
|
||||
supported by the encoder for the given coded pixel format and resolution.
|
||||
|
||||
* Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a raw pixel
|
||||
format and resolution will include all possible frame intervals supported
|
||||
by the encoder for the given raw pixel format and resolution and for the
|
||||
coded format, coded resolution and coded frame interval currently set on
|
||||
``CAPTURE``.
|
||||
|
||||
* Support for :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` is optional. If it is
|
||||
not implemented, then there are no special restrictions other than the
|
||||
limits of the codec itself.
|
||||
|
||||
5. Supported profiles and levels for the coded format currently set on
|
||||
``CAPTURE``, if applicable, may be queried using their respective controls
|
||||
via :c:func:`VIDIOC_QUERYCTRL`.
|
||||
|
||||
6. Any additional encoder capabilities may be discovered by querying
|
||||
their respective controls.
|
||||
|
||||
Initialization
|
||||
==============
|
||||
|
||||
1. Set the coded format on the ``CAPTURE`` queue via :c:func:`VIDIOC_S_FMT`.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
|
||||
|
||||
``pixelformat``
|
||||
the coded format to be produced.
|
||||
|
||||
``sizeimage``
|
||||
desired size of ``CAPTURE`` buffers; the encoder may adjust it to
|
||||
match hardware requirements.
|
||||
|
||||
``width``, ``height``
|
||||
ignored (read-only).
|
||||
|
||||
other fields
|
||||
follow standard semantics.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``sizeimage``
|
||||
adjusted size of ``CAPTURE`` buffers.
|
||||
|
||||
``width``, ``height``
|
||||
the coded size selected by the encoder based on current state, e.g.
|
||||
``OUTPUT`` format, selection rectangles, etc. (read-only).
|
||||
|
||||
.. important::
|
||||
|
||||
Changing the ``CAPTURE`` format may change the currently set ``OUTPUT``
|
||||
format. How the new ``OUTPUT`` format is determined is up to the encoder
|
||||
and the client must ensure it matches its needs afterwards.
|
||||
|
||||
2. **Optional.** Enumerate supported ``OUTPUT`` formats (raw formats for
|
||||
source) for the selected coded format via :c:func:`VIDIOC_ENUM_FMT`.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
|
||||
|
||||
other fields
|
||||
follow standard semantics.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``pixelformat``
|
||||
raw format supported for the coded format currently selected on
|
||||
the ``CAPTURE`` queue.
|
||||
|
||||
other fields
|
||||
follow standard semantics.
|
||||
|
||||
3. Set the raw source format on the ``OUTPUT`` queue via
|
||||
:c:func:`VIDIOC_S_FMT`.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
|
||||
|
||||
``pixelformat``
|
||||
raw format of the source.
|
||||
|
||||
``width``, ``height``
|
||||
source resolution.
|
||||
|
||||
other fields
|
||||
follow standard semantics.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``width``, ``height``
|
||||
may be adjusted to match encoder minimums, maximums and alignment
|
||||
requirements, as required by the currently selected formats, as
|
||||
reported by :c:func:`VIDIOC_ENUM_FRAMESIZES`.
|
||||
|
||||
other fields
|
||||
follow standard semantics.
|
||||
|
||||
* Setting the ``OUTPUT`` format will reset the selection rectangles to their
|
||||
default values, based on the new resolution, as described in the next
|
||||
step.
|
||||
|
||||
4. Set the raw frame interval on the ``OUTPUT`` queue via
|
||||
:c:func:`VIDIOC_S_PARM`. This also sets the coded frame interval on the
|
||||
``CAPTURE`` queue to the same value.
|
||||
|
||||
* ** Required fields:**
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
|
||||
|
||||
``parm.output``
|
||||
set all fields except ``parm.output.timeperframe`` to 0.
|
||||
|
||||
``parm.output.timeperframe``
|
||||
the desired frame interval; the encoder may adjust it to
|
||||
match hardware requirements.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``parm.output.timeperframe``
|
||||
the adjusted frame interval.
|
||||
|
||||
.. important::
|
||||
|
||||
Changing the ``OUTPUT`` frame interval *also* sets the framerate that
|
||||
the encoder uses to encode the video. So setting the frame interval
|
||||
to 1/24 (or 24 frames per second) will produce a coded video stream
|
||||
that can be played back at that speed. The frame interval for the
|
||||
``OUTPUT`` queue is just a hint, the application may provide raw
|
||||
frames at a different rate. It can be used by the driver to help
|
||||
schedule multiple encoders running in parallel.
|
||||
|
||||
In the next step the ``CAPTURE`` frame interval can optionally be
|
||||
changed to a different value. This is useful for off-line encoding
|
||||
were the coded frame interval can be different from the rate at
|
||||
which raw frames are supplied.
|
||||
|
||||
.. important::
|
||||
|
||||
``timeperframe`` deals with *frames*, not fields. So for interlaced
|
||||
formats this is the time per two fields, since a frame consists of
|
||||
a top and a bottom field.
|
||||
|
||||
.. note::
|
||||
|
||||
It is due to historical reasons that changing the ``OUTPUT`` frame
|
||||
interval also changes the coded frame interval on the ``CAPTURE``
|
||||
queue. Ideally these would be independent settings, but that would
|
||||
break the existing API.
|
||||
|
||||
5. **Optional** Set the coded frame interval on the ``CAPTURE`` queue via
|
||||
:c:func:`VIDIOC_S_PARM`. This is only necessary if the coded frame
|
||||
interval is different from the raw frame interval, which is typically
|
||||
the case for off-line encoding. Support for this feature is signalled
|
||||
by the :ref:`V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL <fmtdesc-flags>` format flag.
|
||||
|
||||
* ** Required fields:**
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``.
|
||||
|
||||
``parm.capture``
|
||||
set all fields except ``parm.capture.timeperframe`` to 0.
|
||||
|
||||
``parm.capture.timeperframe``
|
||||
the desired coded frame interval; the encoder may adjust it to
|
||||
match hardware requirements.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``parm.capture.timeperframe``
|
||||
the adjusted frame interval.
|
||||
|
||||
.. important::
|
||||
|
||||
Changing the ``CAPTURE`` frame interval sets the framerate for the
|
||||
coded video. It does *not* set the rate at which buffers arrive on the
|
||||
``CAPTURE`` queue, that depends on how fast the encoder is and how
|
||||
fast raw frames are queued on the ``OUTPUT`` queue.
|
||||
|
||||
.. important::
|
||||
|
||||
``timeperframe`` deals with *frames*, not fields. So for interlaced
|
||||
formats this is the time per two fields, since a frame consists of
|
||||
a top and a bottom field.
|
||||
|
||||
.. note::
|
||||
|
||||
Not all drivers support this functionality, in that case just set
|
||||
the desired coded frame interval for the ``OUTPUT`` queue.
|
||||
|
||||
However, drivers that can schedule multiple encoders based on the
|
||||
``OUTPUT`` frame interval must support this optional feature.
|
||||
|
||||
6. **Optional.** Set the visible resolution for the stream metadata via
|
||||
:c:func:`VIDIOC_S_SELECTION` on the ``OUTPUT`` queue if it is desired
|
||||
to be different than the full OUTPUT resolution.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
|
||||
|
||||
``target``
|
||||
set to ``V4L2_SEL_TGT_CROP``.
|
||||
|
||||
``r.left``, ``r.top``, ``r.width``, ``r.height``
|
||||
visible rectangle; this must fit within the `V4L2_SEL_TGT_CROP_BOUNDS`
|
||||
rectangle and may be subject to adjustment to match codec and
|
||||
hardware constraints.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``r.left``, ``r.top``, ``r.width``, ``r.height``
|
||||
visible rectangle adjusted by the encoder.
|
||||
|
||||
* The following selection targets are supported on ``OUTPUT``:
|
||||
|
||||
``V4L2_SEL_TGT_CROP_BOUNDS``
|
||||
equal to the full source frame, matching the active ``OUTPUT``
|
||||
format.
|
||||
|
||||
``V4L2_SEL_TGT_CROP_DEFAULT``
|
||||
equal to ``V4L2_SEL_TGT_CROP_BOUNDS``.
|
||||
|
||||
``V4L2_SEL_TGT_CROP``
|
||||
rectangle within the source buffer to be encoded into the
|
||||
``CAPTURE`` stream; defaults to ``V4L2_SEL_TGT_CROP_DEFAULT``.
|
||||
|
||||
.. note::
|
||||
|
||||
A common use case for this selection target is encoding a source
|
||||
video with a resolution that is not a multiple of a macroblock,
|
||||
e.g. the common 1920x1080 resolution may require the source
|
||||
buffers to be aligned to 1920x1088 for codecs with 16x16 macroblock
|
||||
size. To avoid encoding the padding, the client needs to explicitly
|
||||
configure this selection target to 1920x1080.
|
||||
|
||||
.. warning::
|
||||
|
||||
The encoder may adjust the crop/compose rectangles to the nearest
|
||||
supported ones to meet codec and hardware requirements. The client needs
|
||||
to check the adjusted rectangle returned by :c:func:`VIDIOC_S_SELECTION`.
|
||||
|
||||
7. Allocate buffers for both ``OUTPUT`` and ``CAPTURE`` via
|
||||
:c:func:`VIDIOC_REQBUFS`. This may be performed in any order.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
``count``
|
||||
requested number of buffers to allocate; greater than zero.
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT`` or
|
||||
``CAPTURE``.
|
||||
|
||||
other fields
|
||||
follow standard semantics.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``count``
|
||||
actual number of buffers allocated.
|
||||
|
||||
.. warning::
|
||||
|
||||
The actual number of allocated buffers may differ from the ``count``
|
||||
given. The client must check the updated value of ``count`` after the
|
||||
call returns.
|
||||
|
||||
.. note::
|
||||
|
||||
To allocate more than the minimum number of OUTPUT buffers (for pipeline
|
||||
depth), the client may query the ``V4L2_CID_MIN_BUFFERS_FOR_OUTPUT``
|
||||
control to get the minimum number of buffers required, and pass the
|
||||
obtained value plus the number of additional buffers needed in the
|
||||
``count`` field to :c:func:`VIDIOC_REQBUFS`.
|
||||
|
||||
Alternatively, :c:func:`VIDIOC_CREATE_BUFS` can be used to have more
|
||||
control over buffer allocation.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
``count``
|
||||
requested number of buffers to allocate; greater than zero.
|
||||
|
||||
``type``
|
||||
a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``.
|
||||
|
||||
other fields
|
||||
follow standard semantics.
|
||||
|
||||
* **Return fields:**
|
||||
|
||||
``count``
|
||||
adjusted to the number of allocated buffers.
|
||||
|
||||
8. Begin streaming on both ``OUTPUT`` and ``CAPTURE`` queues via
|
||||
:c:func:`VIDIOC_STREAMON`. This may be performed in any order. The actual
|
||||
encoding process starts when both queues start streaming.
|
||||
|
||||
.. note::
|
||||
|
||||
If the client stops the ``CAPTURE`` queue during the encode process and then
|
||||
restarts it again, the encoder will begin generating a stream independent
|
||||
from the stream generated before the stop. The exact constraints depend
|
||||
on the coded format, but may include the following implications:
|
||||
|
||||
* encoded frames produced after the restart must not reference any
|
||||
frames produced before the stop, e.g. no long term references for
|
||||
H.264/HEVC,
|
||||
|
||||
* any headers that must be included in a standalone stream must be
|
||||
produced again, e.g. SPS and PPS for H.264/HEVC.
|
||||
|
||||
Encoding
|
||||
========
|
||||
|
||||
This state is reached after the `Initialization` sequence finishes
|
||||
successfully. In this state, the client queues and dequeues buffers to both
|
||||
queues via :c:func:`VIDIOC_QBUF` and :c:func:`VIDIOC_DQBUF`, following the
|
||||
standard semantics.
|
||||
|
||||
The content of encoded ``CAPTURE`` buffers depends on the active coded pixel
|
||||
format and may be affected by codec-specific extended controls, as stated
|
||||
in the documentation of each format.
|
||||
|
||||
Both queues operate independently, following standard behavior of V4L2 buffer
|
||||
queues and memory-to-memory devices. In addition, the order of encoded frames
|
||||
dequeued from the ``CAPTURE`` queue may differ from the order of queuing raw
|
||||
frames to the ``OUTPUT`` queue, due to properties of the selected coded format,
|
||||
e.g. frame reordering.
|
||||
|
||||
The client must not assume any direct relationship between ``CAPTURE`` and
|
||||
``OUTPUT`` buffers and any specific timing of buffers becoming
|
||||
available to dequeue. Specifically:
|
||||
|
||||
* a buffer queued to ``OUTPUT`` may result in more than one buffer produced on
|
||||
``CAPTURE`` (for example, if returning an encoded frame allowed the encoder
|
||||
to return a frame that preceded it in display, but succeeded it in the decode
|
||||
order; however, there may be other reasons for this as well),
|
||||
|
||||
* a buffer queued to ``OUTPUT`` may result in a buffer being produced on
|
||||
``CAPTURE`` later into encode process, and/or after processing further
|
||||
``OUTPUT`` buffers, or be returned out of order, e.g. if display
|
||||
reordering is used,
|
||||
|
||||
* buffers may become available on the ``CAPTURE`` queue without additional
|
||||
buffers queued to ``OUTPUT`` (e.g. during drain or ``EOS``), because of the
|
||||
``OUTPUT`` buffers queued in the past whose encoding results are only
|
||||
available at later time, due to specifics of the encoding process,
|
||||
|
||||
* buffers queued to ``OUTPUT`` may not become available to dequeue instantly
|
||||
after being encoded into a corresponding ``CAPTURE`` buffer, e.g. if the
|
||||
encoder needs to use the frame as a reference for encoding further frames.
|
||||
|
||||
.. note::
|
||||
|
||||
To allow matching encoded ``CAPTURE`` buffers with ``OUTPUT`` buffers they
|
||||
originated from, the client can set the ``timestamp`` field of the
|
||||
:c:type:`v4l2_buffer` struct when queuing an ``OUTPUT`` buffer. The
|
||||
``CAPTURE`` buffer(s), which resulted from encoding that ``OUTPUT`` buffer
|
||||
will have their ``timestamp`` field set to the same value when dequeued.
|
||||
|
||||
In addition to the straightforward case of one ``OUTPUT`` buffer producing
|
||||
one ``CAPTURE`` buffer, the following cases are defined:
|
||||
|
||||
* one ``OUTPUT`` buffer generates multiple ``CAPTURE`` buffers: the same
|
||||
``OUTPUT`` timestamp will be copied to multiple ``CAPTURE`` buffers,
|
||||
|
||||
* the encoding order differs from the presentation order (i.e. the
|
||||
``CAPTURE`` buffers are out-of-order compared to the ``OUTPUT`` buffers):
|
||||
``CAPTURE`` timestamps will not retain the order of ``OUTPUT`` timestamps.
|
||||
|
||||
.. note::
|
||||
|
||||
To let the client distinguish between frame types (keyframes, intermediate
|
||||
frames; the exact list of types depends on the coded format), the
|
||||
``CAPTURE`` buffers will have corresponding flag bits set in their
|
||||
:c:type:`v4l2_buffer` struct when dequeued. See the documentation of
|
||||
:c:type:`v4l2_buffer` and each coded pixel format for exact list of flags
|
||||
and their meanings.
|
||||
|
||||
Should an encoding error occur, it will be reported to the client with the level
|
||||
of details depending on the encoder capabilities. Specifically:
|
||||
|
||||
* the ``CAPTURE`` buffer (if any) that contains the results of the failed encode
|
||||
operation will be returned with the ``V4L2_BUF_FLAG_ERROR`` flag set,
|
||||
|
||||
* if the encoder is able to precisely report the ``OUTPUT`` buffer(s) that triggered
|
||||
the error, such buffer(s) will be returned with the ``V4L2_BUF_FLAG_ERROR`` flag
|
||||
set.
|
||||
|
||||
.. note::
|
||||
|
||||
If a ``CAPTURE`` buffer is too small then it is just returned with the
|
||||
``V4L2_BUF_FLAG_ERROR`` flag set. More work is needed to detect that this
|
||||
error occurred because the buffer was too small, and to provide support to
|
||||
free existing buffers that were too small.
|
||||
|
||||
In case of a fatal failure that does not allow the encoding to continue, any
|
||||
further operations on corresponding encoder file handle will return the -EIO
|
||||
error code. The client may close the file handle and open a new one, or
|
||||
alternatively reinitialize the instance by stopping streaming on both queues,
|
||||
releasing all buffers and performing the Initialization sequence again.
|
||||
|
||||
Encoding Parameter Changes
|
||||
==========================
|
||||
|
||||
The client is allowed to use :c:func:`VIDIOC_S_CTRL` to change encoder
|
||||
parameters at any time. The availability of parameters is encoder-specific
|
||||
and the client must query the encoder to find the set of available controls.
|
||||
|
||||
The ability to change each parameter during encoding is encoder-specific, as
|
||||
per the standard semantics of the V4L2 control interface. The client may
|
||||
attempt to set a control during encoding and if the operation fails with the
|
||||
-EBUSY error code, the ``CAPTURE`` queue needs to be stopped for the
|
||||
configuration change to be allowed. To do this, it may follow the `Drain`
|
||||
sequence to avoid losing the already queued/encoded frames.
|
||||
|
||||
The timing of parameter updates is encoder-specific, as per the standard
|
||||
semantics of the V4L2 control interface. If the client needs to apply the
|
||||
parameters exactly at specific frame, using the Request API
|
||||
(:ref:`media-request-api`) should be considered, if supported by the encoder.
|
||||
|
||||
Drain
|
||||
=====
|
||||
|
||||
To ensure that all the queued ``OUTPUT`` buffers have been processed and the
|
||||
related ``CAPTURE`` buffers are given to the client, the client must follow the
|
||||
drain sequence described below. After the drain sequence ends, the client has
|
||||
received all encoded frames for all ``OUTPUT`` buffers queued before the
|
||||
sequence was started.
|
||||
|
||||
1. Begin the drain sequence by issuing :c:func:`VIDIOC_ENCODER_CMD`.
|
||||
|
||||
* **Required fields:**
|
||||
|
||||
``cmd``
|
||||
set to ``V4L2_ENC_CMD_STOP``.
|
||||
|
||||
``flags``
|
||||
set to 0.
|
||||
|
||||
``pts``
|
||||
set to 0.
|
||||
|
||||
.. warning::
|
||||
|
||||
The sequence can be only initiated if both ``OUTPUT`` and ``CAPTURE``
|
||||
queues are streaming. For compatibility reasons, the call to
|
||||
:c:func:`VIDIOC_ENCODER_CMD` will not fail even if any of the queues is
|
||||
not streaming, but at the same time it will not initiate the `Drain`
|
||||
sequence and so the steps described below would not be applicable.
|
||||
|
||||
2. Any ``OUTPUT`` buffers queued by the client before the
|
||||
:c:func:`VIDIOC_ENCODER_CMD` was issued will be processed and encoded as
|
||||
normal. The client must continue to handle both queues independently,
|
||||
similarly to normal encode operation. This includes:
|
||||
|
||||
* queuing and dequeuing ``CAPTURE`` buffers, until a buffer marked with the
|
||||
``V4L2_BUF_FLAG_LAST`` flag is dequeued,
|
||||
|
||||
.. warning::
|
||||
|
||||
The last buffer may be empty (with :c:type:`v4l2_buffer`
|
||||
``bytesused`` = 0) and in that case it must be ignored by the client,
|
||||
as it does not contain an encoded frame.
|
||||
|
||||
.. note::
|
||||
|
||||
Any attempt to dequeue more ``CAPTURE`` buffers beyond the buffer
|
||||
marked with ``V4L2_BUF_FLAG_LAST`` will result in a -EPIPE error from
|
||||
:c:func:`VIDIOC_DQBUF`.
|
||||
|
||||
* dequeuing processed ``OUTPUT`` buffers, until all the buffers queued
|
||||
before the ``V4L2_ENC_CMD_STOP`` command are dequeued,
|
||||
|
||||
* dequeuing the ``V4L2_EVENT_EOS`` event, if the client subscribes to it.
|
||||
|
||||
.. note::
|
||||
|
||||
For backwards compatibility, the encoder will signal a ``V4L2_EVENT_EOS``
|
||||
event when the last frame has been encoded and all frames are ready to be
|
||||
dequeued. It is deprecated behavior and the client must not rely on it.
|
||||
The ``V4L2_BUF_FLAG_LAST`` buffer flag should be used instead.
|
||||
|
||||
3. Once all ``OUTPUT`` buffers queued before the ``V4L2_ENC_CMD_STOP`` call are
|
||||
dequeued and the last ``CAPTURE`` buffer is dequeued, the encoder is stopped
|
||||
and it will accept, but not process any newly queued ``OUTPUT`` buffers
|
||||
until the client issues any of the following operations:
|
||||
|
||||
* ``V4L2_ENC_CMD_START`` - the encoder will not be reset and will resume
|
||||
operation normally, with all the state from before the drain,
|
||||
|
||||
* a pair of :c:func:`VIDIOC_STREAMOFF` and :c:func:`VIDIOC_STREAMON` on the
|
||||
``CAPTURE`` queue - the encoder will be reset (see the `Reset` sequence)
|
||||
and then resume encoding,
|
||||
|
||||
* a pair of :c:func:`VIDIOC_STREAMOFF` and :c:func:`VIDIOC_STREAMON` on the
|
||||
``OUTPUT`` queue - the encoder will resume operation normally, however any
|
||||
source frames queued to the ``OUTPUT`` queue between ``V4L2_ENC_CMD_STOP``
|
||||
and :c:func:`VIDIOC_STREAMOFF` will be discarded.
|
||||
|
||||
.. note::
|
||||
|
||||
Once the drain sequence is initiated, the client needs to drive it to
|
||||
completion, as described by the steps above, unless it aborts the process by
|
||||
issuing :c:func:`VIDIOC_STREAMOFF` on any of the ``OUTPUT`` or ``CAPTURE``
|
||||
queues. The client is not allowed to issue ``V4L2_ENC_CMD_START`` or
|
||||
``V4L2_ENC_CMD_STOP`` again while the drain sequence is in progress and they
|
||||
will fail with -EBUSY error code if attempted.
|
||||
|
||||
For reference, handling of various corner cases is described below:
|
||||
|
||||
* In case of no buffer in the ``OUTPUT`` queue at the time the
|
||||
``V4L2_ENC_CMD_STOP`` command was issued, the drain sequence completes
|
||||
immediately and the encoder returns an empty ``CAPTURE`` buffer with the
|
||||
``V4L2_BUF_FLAG_LAST`` flag set.
|
||||
|
||||
* In case of no buffer in the ``CAPTURE`` queue at the time the drain
|
||||
sequence completes, the next time the client queues a ``CAPTURE`` buffer
|
||||
it is returned at once as an empty buffer with the ``V4L2_BUF_FLAG_LAST``
|
||||
flag set.
|
||||
|
||||
* If :c:func:`VIDIOC_STREAMOFF` is called on the ``CAPTURE`` queue in the
|
||||
middle of the drain sequence, the drain sequence is canceled and all
|
||||
``CAPTURE`` buffers are implicitly returned to the client.
|
||||
|
||||
* If :c:func:`VIDIOC_STREAMOFF` is called on the ``OUTPUT`` queue in the
|
||||
middle of the drain sequence, the drain sequence completes immediately and
|
||||
next ``CAPTURE`` buffer will be returned empty with the
|
||||
``V4L2_BUF_FLAG_LAST`` flag set.
|
||||
|
||||
Although not mandatory, the availability of encoder commands may be queried
|
||||
using :c:func:`VIDIOC_TRY_ENCODER_CMD`.
|
||||
|
||||
Reset
|
||||
=====
|
||||
|
||||
The client may want to request the encoder to reinitialize the encoding, so
|
||||
that the following stream data becomes independent from the stream data
|
||||
generated before. Depending on the coded format, that may imply that:
|
||||
|
||||
* encoded frames produced after the restart must not reference any frames
|
||||
produced before the stop, e.g. no long term references for H.264/HEVC,
|
||||
|
||||
* any headers that must be included in a standalone stream must be produced
|
||||
again, e.g. SPS and PPS for H.264/HEVC.
|
||||
|
||||
This can be achieved by performing the reset sequence.
|
||||
|
||||
1. Perform the `Drain` sequence to ensure all the in-flight encoding finishes
|
||||
and respective buffers are dequeued.
|
||||
|
||||
2. Stop streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMOFF`. This
|
||||
will return all currently queued ``CAPTURE`` buffers to the client, without
|
||||
valid frame data.
|
||||
|
||||
3. Start streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMON` and
|
||||
continue with regular encoding sequence. The encoded frames produced into
|
||||
``CAPTURE`` buffers from now on will contain a standalone stream that can be
|
||||
decoded without the need for frames encoded before the reset sequence,
|
||||
starting at the first ``OUTPUT`` buffer queued after issuing the
|
||||
`V4L2_ENC_CMD_STOP` of the `Drain` sequence.
|
||||
|
||||
This sequence may be also used to change encoding parameters for encoders
|
||||
without the ability to change the parameters on the fly.
|
||||
|
||||
Commit Points
|
||||
=============
|
||||
|
||||
Setting formats and allocating buffers triggers changes in the behavior of the
|
||||
encoder.
|
||||
|
||||
1. Setting the format on the ``CAPTURE`` queue may change the set of formats
|
||||
supported/advertised on the ``OUTPUT`` queue. In particular, it also means
|
||||
that the ``OUTPUT`` format may be reset and the client must not rely on the
|
||||
previously set format being preserved.
|
||||
|
||||
2. Enumerating formats on the ``OUTPUT`` queue always returns only formats
|
||||
supported for the current ``CAPTURE`` format.
|
||||
|
||||
3. Setting the format on the ``OUTPUT`` queue does not change the list of
|
||||
formats available on the ``CAPTURE`` queue. An attempt to set the ``OUTPUT``
|
||||
format that is not supported for the currently selected ``CAPTURE`` format
|
||||
will result in the encoder adjusting the requested ``OUTPUT`` format to a
|
||||
supported one.
|
||||
|
||||
4. Enumerating formats on the ``CAPTURE`` queue always returns the full set of
|
||||
supported coded formats, irrespective of the current ``OUTPUT`` format.
|
||||
|
||||
5. While buffers are allocated on any of the ``OUTPUT`` or ``CAPTURE`` queues,
|
||||
the client must not change the format on the ``CAPTURE`` queue. Drivers will
|
||||
return the -EBUSY error code for any such format change attempt.
|
||||
|
||||
To summarize, setting formats and allocation must always start with the
|
||||
``CAPTURE`` queue and the ``CAPTURE`` queue is the master that governs the
|
||||
set of supported formats for the ``OUTPUT`` queue.
|
||||
@@ -46,4 +46,5 @@ devices are given in the following sections.
|
||||
:maxdepth: 1
|
||||
|
||||
dev-decoder
|
||||
dev-encoder
|
||||
dev-stateless-decoder
|
||||
|
||||
@@ -51,7 +51,7 @@ other information, the physical address of the framebuffer in the
|
||||
``base`` field of struct :c:type:`v4l2_framebuffer`.
|
||||
The framebuffer device ioctl ``FBIOGET_FSCREENINFO`` returns the same
|
||||
address in the ``smem_start`` field of struct
|
||||
struct :c:type:`fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO``
|
||||
:c:type:`fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO``
|
||||
ioctl and struct :c:type:`fb_fix_screeninfo` are defined in
|
||||
the ``linux/fb.h`` header file.
|
||||
|
||||
|
||||
@@ -78,7 +78,7 @@ field of a struct :c:type:`v4l2_format` to
|
||||
``V4L2_BUF_TYPE_SDR_CAPTURE`` or ``V4L2_BUF_TYPE_SDR_OUTPUT`` and use
|
||||
the struct :c:type:`v4l2_sdr_format` ``sdr`` member
|
||||
of the ``fmt`` union as needed per the desired operation. Currently
|
||||
there is two fields, ``pixelformat`` and ``buffersize``, of struct
|
||||
there are two fields, ``pixelformat`` and ``buffersize``, of
|
||||
struct :c:type:`v4l2_sdr_format` which are used.
|
||||
Content of the ``pixelformat`` is V4L2 FourCC code of the data format.
|
||||
The ``buffersize`` field is maximum buffer size in bytes required for
|
||||
|
||||
@@ -43,7 +43,7 @@ transmission arguments.
|
||||
1998-09-28: Revamped video standard. Made video controls individually
|
||||
enumerable.
|
||||
|
||||
1998-10-02: The ``id`` field was removed from struct
|
||||
1998-10-02: The ``id`` field was removed from
|
||||
struct ``video_standard`` and the color subcarrier fields were
|
||||
renamed. The :ref:`VIDIOC_QUERYSTD` ioctl was
|
||||
renamed to :ref:`VIDIOC_ENUMSTD`,
|
||||
@@ -260,7 +260,7 @@ multiple tuners into account.)
|
||||
|
||||
2000-09-18: ``V4L2_BUF_TYPE_VBI`` was added. This may *break
|
||||
compatibility* as the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
|
||||
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls may fail now if the struct
|
||||
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls may fail now if the
|
||||
struct ``v4l2_fmt`` ``type`` field does not contain
|
||||
``V4L2_BUF_TYPE_VBI``. In the documentation of the struct
|
||||
:c:type:`v4l2_vbi_format` ``offset`` field the
|
||||
|
||||
@@ -69,37 +69,37 @@ Each cell is one byte.
|
||||
|
||||
B\ :sub:`00low bits 5--0`\ (bits 5--0)
|
||||
|
||||
- R\ :sub:`02low bits 3--0`\ (bits 7--4)
|
||||
- B\ :sub:`02low bits 3--0`\ (bits 7--4)
|
||||
|
||||
G\ :sub:`01low bits 5--2`\ (bits 3--0)
|
||||
|
||||
- G\ :sub:`03low bits 5--0`\ (bits 7--2)
|
||||
|
||||
R\ :sub:`02low bits 5--4`\ (bits 1--0)
|
||||
B\ :sub:`02low bits 5--4`\ (bits 1--0)
|
||||
|
||||
- .. row 2
|
||||
|
||||
- start + 7
|
||||
|
||||
- G\ :sub:`00high`
|
||||
- G\ :sub:`10high`
|
||||
|
||||
- R\ :sub:`01high`
|
||||
- R\ :sub:`11high`
|
||||
|
||||
- G\ :sub:`02high`
|
||||
- G\ :sub:`12high`
|
||||
|
||||
- R\ :sub:`03high`
|
||||
- R\ :sub:`13high`
|
||||
|
||||
- R\ :sub:`01low bits 1--0`\ (bits 7--6)
|
||||
- R\ :sub:`11low bits 1--0`\ (bits 7--6)
|
||||
|
||||
G\ :sub:`00low bits 5--0`\ (bits 5--0)
|
||||
G\ :sub:`10low bits 5--0`\ (bits 5--0)
|
||||
|
||||
- G\ :sub:`02low bits 3--0`\ (bits 7--4)
|
||||
- G\ :sub:`12low bits 3--0`\ (bits 7--4)
|
||||
|
||||
R\ :sub:`01low bits 5--2`\ (bits 3--0)
|
||||
R\ :sub:`11low bits 5--2`\ (bits 3--0)
|
||||
|
||||
- R\ :sub:`03low bits 5--0`\ (bits 7--2)
|
||||
- R\ :sub:`13low bits 5--0`\ (bits 7--2)
|
||||
|
||||
G\ :sub:`02low bits 5--4`\ (bits 1--0)
|
||||
G\ :sub:`12low bits 5--4`\ (bits 1--0)
|
||||
|
||||
- .. row 3
|
||||
|
||||
@@ -117,13 +117,13 @@ Each cell is one byte.
|
||||
|
||||
B\ :sub:`20low bits 5--0`\ (bits 5--0)
|
||||
|
||||
- R\ :sub:`22low bits 3--0`\ (bits 7--4)
|
||||
- B\ :sub:`22low bits 3--0`\ (bits 7--4)
|
||||
|
||||
G\ :sub:`21low bits 5--2`\ (bits 3--0)
|
||||
|
||||
- G\ :sub:`23low bits 5--0`\ (bits 7--2)
|
||||
|
||||
R\ :sub:`22low bits 5--4`\ (bits 1--0)
|
||||
B\ :sub:`22low bits 5--4`\ (bits 1--0)
|
||||
|
||||
- .. row 4
|
||||
|
||||
|
||||
@@ -44,6 +44,11 @@ Single-planar format structure
|
||||
inside the stream, when fed to a stateful mem2mem decoder, the fields
|
||||
may be zero to rely on the decoder to detect the right values. For more
|
||||
details see :ref:`decoder` and format descriptions.
|
||||
|
||||
For compressed formats on the CAPTURE side of a stateful mem2mem
|
||||
encoder, the fields must be zero, since the coded size is expected to
|
||||
be calculated internally by the encoder itself, based on the OUTPUT
|
||||
side. For more details see :ref:`encoder` and format descriptions.
|
||||
* - __u32
|
||||
- ``pixelformat``
|
||||
- The pixel format or type of compression, set by the application.
|
||||
|
||||
@@ -63,6 +63,7 @@ Authors, in alphabetical order:
|
||||
- Figa, Tomasz <tfiga@chromium.org>
|
||||
|
||||
- Documented the memory-to-memory decoder interface.
|
||||
- Documented the memory-to-memory encoder interface.
|
||||
|
||||
- H Schimek, Michael <mschimek@gmx.at>
|
||||
|
||||
@@ -75,6 +76,7 @@ Authors, in alphabetical order:
|
||||
- Osciak, Pawel <posciak@chromium.org>
|
||||
|
||||
- Documented the memory-to-memory decoder interface.
|
||||
- Documented the memory-to-memory encoder interface.
|
||||
|
||||
- Osciak, Pawel <pawel@osciak.com>
|
||||
|
||||
|
||||
@@ -121,7 +121,12 @@ than the number requested.
|
||||
other changes, then set ``count`` to 0, ``memory`` to
|
||||
``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type.
|
||||
* - __u32
|
||||
- ``reserved``\ [7]
|
||||
- ``flags``
|
||||
- Specifies additional buffer management attributes.
|
||||
See :ref:`memory-flags`.
|
||||
|
||||
* - __u32
|
||||
- ``reserved``\ [6]
|
||||
- A place holder for future extensions. Drivers and applications
|
||||
must set the array to zero.
|
||||
|
||||
|
||||
@@ -260,7 +260,7 @@ call.
|
||||
:ref:`v4l2_queryctrl <v4l2-queryctrl>`.
|
||||
* - __s32
|
||||
- ``default_value``
|
||||
- The default value value of the control. See struct
|
||||
- The default value of the control. See struct
|
||||
:ref:`v4l2_queryctrl <v4l2-queryctrl>`.
|
||||
|
||||
|
||||
|
||||
@@ -51,25 +51,26 @@ To send a command applications must initialize all fields of a struct
|
||||
``VIDIOC_ENCODER_CMD`` or ``VIDIOC_TRY_ENCODER_CMD`` with a pointer to
|
||||
this structure.
|
||||
|
||||
The ``cmd`` field must contain the command code. The ``flags`` field is
|
||||
currently only used by the STOP command and contains one bit: If the
|
||||
``V4L2_ENC_CMD_STOP_AT_GOP_END`` flag is set, encoding will continue
|
||||
until the end of the current *Group Of Pictures*, otherwise it will stop
|
||||
immediately.
|
||||
The ``cmd`` field must contain the command code. Some commands use the
|
||||
``flags`` field for additional information.
|
||||
|
||||
A :ref:`read() <func-read>` or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
|
||||
call sends an implicit START command to the encoder if it has not been
|
||||
started yet. After a STOP command, :ref:`read() <func-read>` calls will read
|
||||
After a STOP command, :ref:`read() <func-read>` calls will read
|
||||
the remaining data buffered by the driver. When the buffer is empty,
|
||||
:ref:`read() <func-read>` will return zero and the next :ref:`read() <func-read>`
|
||||
call will restart the encoder.
|
||||
|
||||
A :ref:`read() <func-read>` or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
|
||||
call sends an implicit START command to the encoder if it has not been
|
||||
started yet. Applies to both queues of mem2mem encoders.
|
||||
|
||||
A :ref:`close() <func-close>` or :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>`
|
||||
call of a streaming file descriptor sends an implicit immediate STOP to
|
||||
the encoder, and all buffered data is discarded.
|
||||
the encoder, and all buffered data is discarded. Applies to both queues of
|
||||
mem2mem encoders.
|
||||
|
||||
These ioctls are optional, not all drivers may support them. They were
|
||||
introduced in Linux 2.6.21.
|
||||
introduced in Linux 2.6.21. They are, however, mandatory for stateful mem2mem
|
||||
encoders (as further documented in :ref:`encoder`).
|
||||
|
||||
|
||||
.. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
|
||||
@@ -109,21 +110,24 @@ introduced in Linux 2.6.21.
|
||||
- 0
|
||||
- Start the encoder. When the encoder is already running or paused,
|
||||
this command does nothing. No flags are defined for this command.
|
||||
|
||||
For a device implementing the :ref:`encoder`, once the drain sequence
|
||||
is initiated with the ``V4L2_ENC_CMD_STOP`` command, it must be driven
|
||||
to completion before this command can be invoked. Any attempt to
|
||||
invoke the command while the drain sequence is in progress will trigger
|
||||
an ``EBUSY`` error code. See :ref:`encoder` for more details.
|
||||
* - ``V4L2_ENC_CMD_STOP``
|
||||
- 1
|
||||
- Stop the encoder. When the ``V4L2_ENC_CMD_STOP_AT_GOP_END`` flag
|
||||
is set, encoding will continue until the end of the current *Group
|
||||
Of Pictures*, otherwise encoding will stop immediately. When the
|
||||
encoder is already stopped, this command does nothing. mem2mem
|
||||
encoders will send a ``V4L2_EVENT_EOS`` event when the last frame
|
||||
has been encoded and all frames are ready to be dequeued and will
|
||||
set the ``V4L2_BUF_FLAG_LAST`` buffer flag on the last buffer of
|
||||
the capture queue to indicate there will be no new buffers
|
||||
produced to dequeue. This buffer may be empty, indicated by the
|
||||
driver setting the ``bytesused`` field to 0. Once the
|
||||
``V4L2_BUF_FLAG_LAST`` flag was set, the
|
||||
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
|
||||
but return an ``EPIPE`` error code.
|
||||
encoder is already stopped, this command does nothing.
|
||||
|
||||
For a device implementing the :ref:`encoder`, the command will initiate
|
||||
the drain sequence as documented in :ref:`encoder`. No flags or other
|
||||
arguments are accepted in this case. Any attempt to invoke the command
|
||||
again before the sequence completes will trigger an ``EBUSY`` error
|
||||
code.
|
||||
* - ``V4L2_ENC_CMD_PAUSE``
|
||||
- 2
|
||||
- Pause the encoder. When the encoder has not been started yet, the
|
||||
@@ -152,6 +156,8 @@ introduced in Linux 2.6.21.
|
||||
- Stop encoding at the end of the current *Group Of Pictures*,
|
||||
rather than immediately.
|
||||
|
||||
Does not apply to :ref:`encoder`.
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
@@ -160,6 +166,11 @@ On success 0 is returned, on error -1 and the ``errno`` variable is set
|
||||
appropriately. The generic error codes are described at the
|
||||
:ref:`Generic Error Codes <gen-errors>` chapter.
|
||||
|
||||
EBUSY
|
||||
A drain sequence of a device implementing the :ref:`encoder` is still in
|
||||
progress. It is not allowed to issue another encoder command until it
|
||||
completes.
|
||||
|
||||
EINVAL
|
||||
The ``cmd`` field is invalid.
|
||||
|
||||
|
||||
@@ -167,17 +167,37 @@ the ``mbus_code`` field is handled differently:
|
||||
- The hardware decoder for this compressed bytestream format (aka coded
|
||||
format) is capable of parsing a continuous bytestream. Applications do
|
||||
not need to parse the bytestream themselves to find the boundaries
|
||||
between frames/fields. This flag can only be used in combination with
|
||||
the ``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to compressed
|
||||
between frames/fields.
|
||||
|
||||
This flag can only be used in combination with the
|
||||
``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to compressed
|
||||
formats only. This flag is valid for stateful decoders only.
|
||||
* - ``V4L2_FMT_FLAG_DYN_RESOLUTION``
|
||||
- 0x0008
|
||||
- Dynamic resolution switching is supported by the device for this
|
||||
compressed bytestream format (aka coded format). It will notify the user
|
||||
via the event ``V4L2_EVENT_SOURCE_CHANGE`` when changes in the video
|
||||
parameters are detected. This flag can only be used in combination
|
||||
with the ``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to
|
||||
compressed formats only. It is also only applies to stateful codecs.
|
||||
parameters are detected.
|
||||
|
||||
This flag can only be used in combination with the
|
||||
``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to
|
||||
compressed formats only. This flag is valid for stateful codecs only.
|
||||
* - ``V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL``
|
||||
- 0x0010
|
||||
- The hardware encoder supports setting the ``CAPTURE`` coded frame
|
||||
interval separately from the ``OUTPUT`` raw frame interval.
|
||||
Setting the ``OUTPUT`` raw frame interval with :ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>`
|
||||
also sets the ``CAPTURE`` coded frame interval to the same value.
|
||||
If this flag is set, then the ``CAPTURE`` coded frame interval can be
|
||||
set to a different value afterwards. This is typically used for
|
||||
offline encoding where the ``OUTPUT`` raw frame interval is used as
|
||||
a hint for reserving hardware encoder resources and the ``CAPTURE`` coded
|
||||
frame interval is the actual frame rate embedded in the encoded video
|
||||
stream.
|
||||
|
||||
This flag can only be used in combination with the
|
||||
``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to
|
||||
compressed formats only. This flag is valid for stateful encoders only.
|
||||
|
||||
|
||||
Return Value
|
||||
|
||||
@@ -42,12 +42,13 @@ Arguments
|
||||
Description
|
||||
===========
|
||||
|
||||
The current video standard determines a nominal number of frames per
|
||||
second. If less than this number of frames is to be captured or output,
|
||||
applications can request frame skipping or duplicating on the driver
|
||||
side. This is especially useful when using the :ref:`read() <func-read>` or
|
||||
:ref:`write() <func-write>`, which are not augmented by timestamps or sequence
|
||||
counters, and to avoid unnecessary data copying.
|
||||
Applications can request a different frame interval. The capture or
|
||||
output device will be reconfigured to support the requested frame
|
||||
interval if possible. Optionally drivers may choose to skip or
|
||||
repeat frames to achieve the requested frame interval.
|
||||
|
||||
For stateful encoders (see :ref:`encoder`) this represents the
|
||||
frame interval that is typically embedded in the encoded video stream.
|
||||
|
||||
Changing the frame interval shall never change the format. Changing the
|
||||
format, on the other hand, may change the frame interval.
|
||||
@@ -57,7 +58,8 @@ internally by a driver in read/write mode. For implications see the
|
||||
section discussing the :ref:`read() <func-read>` function.
|
||||
|
||||
To get and set the streaming parameters applications call the
|
||||
:ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and :ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctl, respectively. They take a
|
||||
:ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and
|
||||
:ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctl, respectively. They take a
|
||||
pointer to a struct :c:type:`v4l2_streamparm` which contains a
|
||||
union holding separate parameters for input and output devices.
|
||||
|
||||
@@ -113,14 +115,21 @@ union holding separate parameters for input and output devices.
|
||||
* - struct :c:type:`v4l2_fract`
|
||||
- ``timeperframe``
|
||||
- This is the desired period between successive frames captured by
|
||||
the driver, in seconds. The field is intended to skip frames on
|
||||
the driver side, saving I/O bandwidth.
|
||||
the driver, in seconds.
|
||||
* - :cspan:`2`
|
||||
|
||||
This will configure the speed at which the video source (e.g. a sensor)
|
||||
generates video frames. If the speed is fixed, then the driver may
|
||||
choose to skip or repeat frames in order to achieve the requested
|
||||
frame rate.
|
||||
|
||||
For stateful encoders (see :ref:`encoder`) this represents the
|
||||
frame interval that is typically embedded in the encoded video stream.
|
||||
|
||||
Applications store here the desired frame period, drivers return
|
||||
the actual frame period, which must be greater or equal to the
|
||||
nominal frame period determined by the current video standard
|
||||
(struct :c:type:`v4l2_standard` ``frameperiod``
|
||||
field). Changing the video standard (also implicitly by switching
|
||||
the actual frame period.
|
||||
|
||||
Changing the video standard (also implicitly by switching
|
||||
the video input) may reset this parameter to the nominal frame
|
||||
period. To reset manually applications can just set this field to
|
||||
zero.
|
||||
@@ -173,11 +182,15 @@ union holding separate parameters for input and output devices.
|
||||
:ref:`write() <func-write>` mode (in streaming mode timestamps
|
||||
can be used to throttle the output), saving I/O bandwidth.
|
||||
|
||||
For stateful encoders (see :ref:`encoder`) this represents the
|
||||
frame interval that is typically embedded in the encoded video stream
|
||||
and it provides a hint to the encoder of the speed at which raw
|
||||
frames are queued up to the encoder.
|
||||
|
||||
Applications store here the desired frame period, drivers return
|
||||
the actual frame period, which must be greater or equal to the
|
||||
nominal frame period determined by the current video standard
|
||||
(struct :c:type:`v4l2_standard` ``frameperiod``
|
||||
field). Changing the video standard (also implicitly by switching
|
||||
the actual frame period.
|
||||
|
||||
Changing the video standard (also implicitly by switching
|
||||
the video output) may reset this parameter to the nominal frame
|
||||
period. To reset manually applications can just set this field to
|
||||
zero.
|
||||
@@ -216,8 +229,8 @@ union holding separate parameters for input and output devices.
|
||||
|
||||
* - ``V4L2_CAP_TIMEPERFRAME``
|
||||
- 0x1000
|
||||
- The frame skipping/repeating controlled by the ``timeperframe``
|
||||
field is supported.
|
||||
- The frame period can be modified by setting the ``timeperframe``
|
||||
field.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -168,11 +168,11 @@ specification the ioctl returns an ``EINVAL`` error code.
|
||||
- The device supports the :ref:`multi-planar API <planar-apis>`
|
||||
through the :ref:`Video Output <output>` interface.
|
||||
* - ``V4L2_CAP_VIDEO_M2M``
|
||||
- 0x00004000
|
||||
- 0x00008000
|
||||
- The device supports the single-planar API through the Video
|
||||
Memory-To-Memory interface.
|
||||
* - ``V4L2_CAP_VIDEO_M2M_MPLANE``
|
||||
- 0x00008000
|
||||
- 0x00004000
|
||||
- The device supports the :ref:`multi-planar API <planar-apis>`
|
||||
through the Video Memory-To-Memory interface.
|
||||
* - ``V4L2_CAP_VIDEO_OVERLAY``
|
||||
|
||||
@@ -112,10 +112,17 @@ aborting or finishing any DMA in progress, an implicit
|
||||
``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will
|
||||
free any previously allocated buffers, so this is typically something
|
||||
that will be done at the start of the application.
|
||||
* - union {
|
||||
- (anonymous)
|
||||
* - __u32
|
||||
- ``flags``
|
||||
- Specifies additional buffer management attributes.
|
||||
See :ref:`memory-flags`.
|
||||
* - __u32
|
||||
- ``reserved``\ [1]
|
||||
- A place holder for future extensions. Drivers and applications
|
||||
must set the array to zero.
|
||||
- Kept for backwards compatibility. Use ``flags`` instead.
|
||||
* - }
|
||||
-
|
||||
|
||||
.. tabularcolumns:: |p{6.1cm}|p{2.2cm}|p{8.7cm}|
|
||||
|
||||
@@ -126,6 +133,7 @@ aborting or finishing any DMA in progress, an implicit
|
||||
.. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
|
||||
.. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS:
|
||||
.. _V4L2-BUF-CAP-SUPPORTS-M2M-HOLD-CAPTURE-BUF:
|
||||
.. _V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS:
|
||||
|
||||
.. cssclass:: longtable
|
||||
|
||||
@@ -156,6 +164,15 @@ aborting or finishing any DMA in progress, an implicit
|
||||
- Only valid for stateless decoders. If set, then userspace can set the
|
||||
``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag to hold off on returning the
|
||||
capture buffer until the OUTPUT timestamp changes.
|
||||
* - ``V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS``
|
||||
- 0x00000040
|
||||
- This capability is set by the driver to indicate that the queue supports
|
||||
cache and memory management hints. However, it's only valid when the
|
||||
queue is used for :ref:`memory mapping <mmap>` streaming I/O. See
|
||||
:ref:`V4L2_FLAG_MEMORY_NON_CONSISTENT <V4L2-FLAG-MEMORY-NON-CONSISTENT>`,
|
||||
:ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE <V4L2-BUF-FLAG-NO-CACHE-INVALIDATE>` and
|
||||
:ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN <V4L2-BUF-FLAG-NO-CACHE-CLEAN>`.
|
||||
|
||||
|
||||
Return Value
|
||||
============
|
||||
|
||||
@@ -187,6 +187,7 @@ replace define V4L2_FMT_FLAG_COMPRESSED fmtdesc-flags
|
||||
replace define V4L2_FMT_FLAG_EMULATED fmtdesc-flags
|
||||
replace define V4L2_FMT_FLAG_CONTINUOUS_BYTESTREAM fmtdesc-flags
|
||||
replace define V4L2_FMT_FLAG_DYN_RESOLUTION fmtdesc-flags
|
||||
replace define V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL fmtdesc-flags
|
||||
|
||||
# V4L2 timecode types
|
||||
replace define V4L2_TC_TYPE_24FPS timecode-type
|
||||
|
||||
Reference in New Issue
Block a user