* [PATCH v4 0/2] dt-bindings: media: Convert video-interfaces.txt to schemas
@ 2021-01-04 16:58 Rob Herring
2021-01-04 16:58 ` [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties " Rob Herring
2021-01-04 16:58 ` [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas Rob Herring
0 siblings, 2 replies; 9+ messages in thread
From: Rob Herring @ 2021-01-04 16:58 UTC (permalink / raw)
To: Guennadi Liakhovetski, Guennadi Liakhovetski, Sakari Ailus,
Maxime Ripard, Mauro Carvalho Chehab, Jacopo Mondi,
Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media
This series converts video-interfaces.txt to DT schema which in turn is
based on converting the graph binding to a schema. All the media users
are converted to use the graph and video-interfaces schemas.
Based on v5.11-rc2. Ideally this should be applied before anything else
for 5.12 and subsequent schemas use the graph and video-interfaces schemas.
Rob
Rob Herring (2):
media: dt-bindings: Convert video-interfaces.txt properties to schemas
dt-bindings: media: Use graph and video-interfaces schemas
.../media/allwinner,sun4i-a10-csi.yaml | 11 +-
.../media/allwinner,sun6i-a31-csi.yaml | 12 +-
.../bindings/media/i2c/adv7180.yaml | 36 +-
.../bindings/media/i2c/adv7604.yaml | 37 +-
.../bindings/media/i2c/aptina,mt9v111.yaml | 4 +-
.../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 +-
.../devicetree/bindings/media/i2c/imx219.yaml | 21 +-
.../bindings/media/i2c/maxim,max9286.yaml | 101 +--
.../bindings/media/i2c/mipi-ccs.yaml | 17 +-
.../devicetree/bindings/media/i2c/ov5647.yaml | 20 +-
.../devicetree/bindings/media/i2c/ov8856.yaml | 22 +-
.../bindings/media/i2c/ovti,ov02a10.yaml | 29 +-
.../bindings/media/i2c/ovti,ov2680.yaml | 6 +-
.../bindings/media/i2c/ovti,ov772x.yaml | 9 +-
.../bindings/media/i2c/sony,imx214.yaml | 25 +-
.../bindings/media/i2c/sony,imx274.yaml | 3 +-
.../bindings/media/marvell,mmp2-ccic.yaml | 15 +-
.../bindings/media/nxp,imx7-csi.yaml | 5 +-
.../bindings/media/nxp,imx7-mipi-csi2.yaml | 32 +-
.../bindings/media/renesas,ceu.yaml | 17 +-
.../bindings/media/renesas,csi2.yaml | 54 +-
.../bindings/media/renesas,vin.yaml | 113 +---
.../bindings/media/rockchip-isp1.yaml | 40 +-
.../bindings/media/st,stm32-dcmi.yaml | 18 +-
.../devicetree/bindings/media/ti,cal.yaml | 55 +-
.../media/video-interface-devices.yaml | 406 +++++++++++
.../bindings/media/video-interfaces.txt | 640 +-----------------
.../bindings/media/video-interfaces.yaml | 344 ++++++++++
.../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +-
29 files changed, 923 insertions(+), 1238 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/video-interface-devices.yaml
create mode 100644 Documentation/devicetree/bindings/media/video-interfaces.yaml
--
2.27.0
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas
2021-01-04 16:58 [PATCH v4 0/2] dt-bindings: media: Convert video-interfaces.txt to schemas Rob Herring
@ 2021-01-04 16:58 ` Rob Herring
2021-01-22 16:23 ` Rob Herring
2021-01-04 16:58 ` [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas Rob Herring
1 sibling, 1 reply; 9+ messages in thread
From: Rob Herring @ 2021-01-04 16:58 UTC (permalink / raw)
To: Guennadi Liakhovetski, Guennadi Liakhovetski, Sakari Ailus,
Maxime Ripard, Mauro Carvalho Chehab, Jacopo Mondi,
Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media, Hans Verkuil, Laurent Pinchart
Convert video-interfaces.txt to DT schema. As it contains a mixture of
device level and endpoint properties, split it up into 2 schemas.
Binding schemas will need to reference both the graph.yaml and
video-interfaces.yaml schemas. The exact schema depends on how many
ports and endpoints for the binding. A single port with a single
endpoint looks similar to this:
port:
$ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
properties:
bus-width:
enum: [ 8, 10, 12, 16 ]
pclk-sample: true
hsync-active: true
vsync-active: true
required:
- bus-width
additionalProperties: false
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
v4:
- drop graph.txt ref
- s/Bt.656/BT.656/
- Replace Guennadi with Laurent as maintainer
v3:
- Support up to 9 physical lanes
- Set lane-polarities array bounds
---
.../media/video-interface-devices.yaml | 406 +++++++++++
.../bindings/media/video-interfaces.txt | 640 +-----------------
.../bindings/media/video-interfaces.yaml | 344 ++++++++++
3 files changed, 751 insertions(+), 639 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/video-interface-devices.yaml
create mode 100644 Documentation/devicetree/bindings/media/video-interfaces.yaml
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
new file mode 100644
index 000000000000..4527f56a5a6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -0,0 +1,406 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/video-interface-devices.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for video receiver and transmitter devices
+
+maintainers:
+ - Jacopo Mondi <jacopo@jmondi.org>
+ - Sakari Ailus <sakari.ailus@linux.intel.com>
+
+properties:
+ flash-leds:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ An array of phandles, each referring to a flash LED, a sub-node of the LED
+ driver device node.
+
+ lens-focus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle to the node of the focus lens controller.
+
+ rotation:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 90, 180, 270 ]
+ description: |
+ The camera rotation is expressed as the angular difference in degrees
+ between two reference systems, one relative to the camera module, and one
+ defined on the external world scene to be captured when projected on the
+ image sensor pixel array.
+
+ A camera sensor has a 2-dimensional reference system 'Rc' defined by its
+ pixel array read-out order. The origin is set to the first pixel being
+ read out, the X-axis points along the column read-out direction towards
+ the last columns, and the Y-axis along the row read-out direction towards
+ the last row.
+
+ A typical example for a sensor with a 2592x1944 pixel array matrix
+ observed from the front is:
+
+ 2591 X-axis 0
+ <------------------------+ 0
+ .......... ... ..........!
+ .......... ... ..........! Y-axis
+ ... !
+ .......... ... ..........!
+ .......... ... ..........! 1943
+ V
+
+ The external world scene reference system 'Rs' is a 2-dimensional
+ reference system on the focal plane of the camera module. The origin is
+ placed on the top-left corner of the visible scene, the X-axis points
+ towards the right, and the Y-axis points towards the bottom of the scene.
+ The top, bottom, left and right directions are intentionally not defined
+ and depend on the environment in which the camera is used.
+
+ A typical example of a (very common) picture of a shark swimming from left
+ to right, as seen from the camera, is:
+
+ 0 X-axis
+ 0 +------------------------------------->
+ !
+ !
+ !
+ ! |\____)\___
+ ! ) _____ __`<
+ ! |/ )/
+ !
+ !
+ !
+ V
+ Y-axis
+
+ with the reference system 'Rs' placed on the camera focal plane:
+
+ ¸.·˙!
+ ¸.·˙ !
+ _ ¸.·˙ !
+ +-/ \-+¸.·˙ !
+ | (o) | ! Camera focal plane
+ +-----+˙·.¸ !
+ ˙·.¸ !
+ ˙·.¸ !
+ ˙·.¸!
+
+ When projected on the sensor's pixel array, the image and the associated
+ reference system 'Rs' are typically (but not always) inverted, due to the
+ camera module's lens optical inversion effect.
+
+ Assuming the above represented scene of the swimming shark, the lens
+ inversion projects the scene and its reference system onto the sensor
+ pixel array, seen from the front of the camera sensor, as follows:
+
+ Y-axis
+ ^
+ !
+ !
+ !
+ ! |\_____)\__
+ ! ) ____ ___.<
+ ! |/ )/
+ !
+ !
+ !
+ 0 +------------------------------------->
+ 0 X-axis
+
+ Note the shark being upside-down.
+
+ The resulting projected reference system is named 'Rp'.
+
+ The camera rotation property is then defined as the angular difference in
+ the counter-clockwise direction between the camera reference system 'Rc'
+ and the projected scene reference system 'Rp'. It is expressed in degrees
+ as a number in the range [0, 360[.
+
+ Examples
+
+ 0 degrees camera rotation:
+
+
+ Y-Rp
+ ^
+ Y-Rc !
+ ^ !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ 0 +------------------------------------->
+ 0 X-Rc
+
+
+ X-Rc 0
+ <------------------------------------+ 0
+ X-Rp 0 !
+ <------------------------------------+ 0 !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ V
+ Y-Rp
+
+ 90 degrees camera rotation:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! Y-Rp
+ ! ^
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+ 180 degrees camera rotation:
+
+ 0
+ <------------------------------------+ 0
+ X-Rc !
+ Y-Rp !
+ ^ !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ 0 +------------------------------------->
+ 0 X-Rp
+
+ 270 degrees camera rotation:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! 0
+ ! <-----------------------------------+ 0
+ ! X-Rp !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! !
+ ! V
+ ! Y-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+
+ Example one - Webcam
+
+ A camera module installed on the user facing part of a laptop screen
+ casing used for video calls. The captured images are meant to be displayed
+ in landscape mode (width > height) on the laptop screen.
+
+ The camera is typically mounted upside-down to compensate the lens optical
+ inversion effect:
+
+ Y-Rp
+ Y-Rc ^
+ ^ !
+ ! !
+ ! ! |\_____)\__
+ ! ! ) ____ ___.<
+ ! ! |/ )/
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ 0 +------------------------------------->
+ 0 X-Rc
+
+ The two reference systems are aligned, the resulting camera rotation is
+ 0 degrees, no rotation correction needs to be applied to the resulting
+ image once captured to memory buffers to correctly display it to users:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! |\____)\___ !
+ ! ) _____ __`< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ If the camera sensor is not mounted upside-down to compensate for the lens
+ optical inversion, the two reference systems will not be aligned, with
+ 'Rp' being rotated 180 degrees relatively to 'Rc':
+
+
+ X-Rc 0
+ <------------------------------------+ 0
+ !
+ Y-Rp !
+ ^ !
+ ! !
+ ! |\_____)\__ !
+ ! ) ____ ___.< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! V
+ ! Y-Rc
+ 0 +------------------------------------->
+ 0 X-Rp
+
+ The image once captured to memory will then be rotated by 180 degrees:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! __/(_____/| !
+ ! >.___ ____ ( !
+ ! \( \| !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ A software rotation correction of 180 degrees should be applied to
+ correctly display the image:
+
+ +--------------------------------------+
+ ! !
+ ! !
+ ! !
+ ! |\____)\___ !
+ ! ) _____ __`< !
+ ! |/ )/ !
+ ! !
+ ! !
+ ! !
+ +--------------------------------------+
+
+ Example two - Phone camera
+
+ A camera installed on the back side of a mobile device facing away from
+ the user. The captured images are meant to be displayed in portrait mode
+ (height > width) to match the device screen orientation and the device
+ usage orientation used when taking the picture.
+
+ The camera sensor is typically mounted with its pixel array longer side
+ aligned to the device longer side, upside-down mounted to compensate for
+ the lens optical inversion effect:
+
+ 0 Y-Rc
+ 0 +-------------------->
+ ! Y-Rp
+ ! ^
+ ! !
+ ! !
+ ! !
+ ! ! |\_____)\__
+ ! ! ) ____ ___.<
+ ! ! |/ )/
+ ! !
+ ! !
+ ! !
+ ! 0 +------------------------------------->
+ ! 0 X-Rp
+ !
+ !
+ !
+ !
+ V
+ X-Rc
+
+ The two reference systems are not aligned and the 'Rp' reference system is
+ rotated by 90 degrees in the counter-clockwise direction relatively to the
+ 'Rc' reference system.
+
+ The image once captured to memory will be rotated:
+
+ +-------------------------------------+
+ | _ _ |
+ | \ / |
+ | | | |
+ | | | |
+ | | > |
+ | < | |
+ | | | |
+ | . |
+ | V |
+ +-------------------------------------+
+
+ A correction of 90 degrees in counter-clockwise direction has to be
+ applied to correctly display the image in portrait mode on the device
+ screen:
+
+ +--------------------+
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |\____)\___ |
+ | ) _____ __`< |
+ | |/ )/ |
+ | |
+ | |
+ | |
+ | |
+ | |
+ +--------------------+
+
+ orientation:
+ description:
+ The orientation of a device (typically an image sensor or a flash LED)
+ describing its mounting position relative to the usage orientation of the
+ system where the device is installed on.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ # Front. The device is mounted on the front facing side of the system. For
+ # mobile devices such as smartphones, tablets and laptops the front side
+ # is the user facing side.
+ - 0
+ # Back. The device is mounted on the back side of the system, which is
+ # defined as the opposite side of the front facing one.
+ - 1
+ # External. The device is not attached directly to the system but is
+ # attached in a way that allows it to move freely.
+ - 2
+
+additionalProperties: true
+
+...
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
index 3920f25a9123..8fcf5f52bf5b 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -1,639 +1 @@
-Common bindings for video receiver and transmitter interfaces
-
-General concept
----------------
-
-Video data pipelines usually consist of external devices, e.g. camera sensors,
-controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
-video DMA engines and video data processors.
-
-SoC internal blocks are described by DT nodes, placed similarly to other SoC
-blocks. External devices are represented as child nodes of their respective
-bus controller nodes, e.g. I2C.
-
-Data interfaces on all video devices are described by their child 'port' nodes.
-Configuration of a port depends on other devices participating in the data
-transfer and is described by 'endpoint' subnodes.
-
-device {
- ...
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- ...
- endpoint@0 { ... };
- endpoint@1 { ... };
- };
- port@1 { ... };
- };
-};
-
-If a port can be configured to work with more than one remote device on the same
-bus, an 'endpoint' child node must be provided for each of them. If more than
-one port is present in a device node or there is more than one endpoint at a
-port, or port node needs to be associated with a selected hardware interface,
-a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
-used.
-
-All 'port' nodes can be grouped under optional 'ports' node, which allows to
-specify #address-cells, #size-cells properties independently for the 'port'
-and 'endpoint' nodes and any child device nodes a device might have.
-
-Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
-phandles. An endpoint subnode of a device contains all properties needed for
-configuration of this device for data exchange with other device. In most
-cases properties at the peer 'endpoint' nodes will be identical, however they
-might need to be different when there is any signal modifications on the bus
-between two devices, e.g. there are logic signal inverters on the lines.
-
-It is allowed for multiple endpoints at a port to be active simultaneously,
-where supported by a device. For example, in case where a data interface of
-a device is partitioned into multiple data busses, e.g. 16-bit input port
-divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
-and data-shift properties can be used to assign physical data lines to each
-endpoint node (logical bus).
-
-Documenting bindings for devices
---------------------------------
-
-All required and optional bindings the device supports shall be explicitly
-documented in device DT binding documentation. This also includes port and
-endpoint nodes for the device, including unit-addresses and reg properties where
-relevant.
-
-Please also see Documentation/devicetree/bindings/graph.txt .
-
-Required properties
--------------------
-
-If there is more than one 'port' or more than one 'endpoint' node or 'reg'
-property is present in port and/or endpoint nodes the following properties
-are required in a relevant parent node:
-
- - #address-cells : number of cells required to define port/endpoint
- identifier, should be 1.
- - #size-cells : should be zero.
-
-
-Optional properties
--------------------
-
-- flash-leds: An array of phandles, each referring to a flash LED, a sub-node
- of the LED driver device node.
-
-- lens-focus: A phandle to the node of the focus lens controller.
-
-- rotation: The camera rotation is expressed as the angular difference in
- degrees between two reference systems, one relative to the camera module, and
- one defined on the external world scene to be captured when projected on the
- image sensor pixel array.
-
- A camera sensor has a 2-dimensional reference system 'Rc' defined by
- its pixel array read-out order. The origin is set to the first pixel
- being read out, the X-axis points along the column read-out direction
- towards the last columns, and the Y-axis along the row read-out
- direction towards the last row.
-
- A typical example for a sensor with a 2592x1944 pixel array matrix
- observed from the front is:
-
- 2591 X-axis 0
- <------------------------+ 0
- .......... ... ..........!
- .......... ... ..........! Y-axis
- ... !
- .......... ... ..........!
- .......... ... ..........! 1943
- V
-
- The external world scene reference system 'Rs' is a 2-dimensional
- reference system on the focal plane of the camera module. The origin is
- placed on the top-left corner of the visible scene, the X-axis points
- towards the right, and the Y-axis points towards the bottom of the
- scene. The top, bottom, left and right directions are intentionally not
- defined and depend on the environment in which the camera is used.
-
- A typical example of a (very common) picture of a shark swimming from
- left to right, as seen from the camera, is:
-
- 0 X-axis
- 0 +------------------------------------->
- !
- !
- !
- ! |\____)\___
- ! ) _____ __`<
- ! |/ )/
- !
- !
- !
- V
- Y-axis
-
- with the reference system 'Rs' placed on the camera focal plane:
-
- ¸.·˙!
- ¸.·˙ !
- _ ¸.·˙ !
- +-/ \-+¸.·˙ !
- | (o) | ! Camera focal plane
- +-----+˙·.¸ !
- ˙·.¸ !
- ˙·.¸ !
- ˙·.¸!
-
- When projected on the sensor's pixel array, the image and the associated
- reference system 'Rs' are typically (but not always) inverted, due to
- the camera module's lens optical inversion effect.
-
- Assuming the above represented scene of the swimming shark, the lens
- inversion projects the scene and its reference system onto the sensor
- pixel array, seen from the front of the camera sensor, as follows:
-
- Y-axis
- ^
- !
- !
- !
- ! |\_____)\__
- ! ) ____ ___.<
- ! |/ )/
- !
- !
- !
- 0 +------------------------------------->
- 0 X-axis
-
- Note the shark being upside-down.
-
- The resulting projected reference system is named 'Rp'.
-
- The camera rotation property is then defined as the angular difference
- in the counter-clockwise direction between the camera reference system
- 'Rc' and the projected scene reference system 'Rp'. It is expressed in
- degrees as a number in the range [0, 360[.
-
- Examples
-
- 0 degrees camera rotation:
-
-
- Y-Rp
- ^
- Y-Rc !
- ^ !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- 0 +------------------------------------->
- 0 X-Rc
-
-
- X-Rc 0
- <------------------------------------+ 0
- X-Rp 0 !
- <------------------------------------+ 0 !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rc
- V
- Y-Rp
-
- 90 degrees camera rotation:
-
- 0 Y-Rc
- 0 +-------------------->
- ! Y-Rp
- ! ^
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- !
- !
- !
- !
- V
- X-Rc
-
- 180 degrees camera rotation:
-
- 0
- <------------------------------------+ 0
- X-Rc !
- Y-Rp !
- ^ !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rc
- 0 +------------------------------------->
- 0 X-Rp
-
- 270 degrees camera rotation:
-
- 0 Y-Rc
- 0 +-------------------->
- ! 0
- ! <-----------------------------------+ 0
- ! X-Rp !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! !
- ! V
- ! Y-Rp
- !
- !
- !
- !
- V
- X-Rc
-
-
- Example one - Webcam
-
- A camera module installed on the user facing part of a laptop screen
- casing used for video calls. The captured images are meant to be
- displayed in landscape mode (width > height) on the laptop screen.
-
- The camera is typically mounted upside-down to compensate the lens
- optical inversion effect:
-
- Y-Rp
- Y-Rc ^
- ^ !
- ! !
- ! ! |\_____)\__
- ! ! ) ____ ___.<
- ! ! |/ )/
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- 0 +------------------------------------->
- 0 X-Rc
-
- The two reference systems are aligned, the resulting camera rotation is
- 0 degrees, no rotation correction needs to be applied to the resulting
- image once captured to memory buffers to correctly display it to users:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! |\____)\___ !
- ! ) _____ __`< !
- ! |/ )/ !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- If the camera sensor is not mounted upside-down to compensate for the
- lens optical inversion, the two reference systems will not be aligned,
- with 'Rp' being rotated 180 degrees relatively to 'Rc':
-
-
- X-Rc 0
- <------------------------------------+ 0
- !
- Y-Rp !
- ^ !
- ! !
- ! |\_____)\__ !
- ! ) ____ ___.< !
- ! |/ )/ !
- ! !
- ! !
- ! V
- ! Y-Rc
- 0 +------------------------------------->
- 0 X-Rp
-
- The image once captured to memory will then be rotated by 180 degrees:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! __/(_____/| !
- ! >.___ ____ ( !
- ! \( \| !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- A software rotation correction of 180 degrees should be applied to
- correctly display the image:
-
- +--------------------------------------+
- ! !
- ! !
- ! !
- ! |\____)\___ !
- ! ) _____ __`< !
- ! |/ )/ !
- ! !
- ! !
- ! !
- +--------------------------------------+
-
- Example two - Phone camera
-
- A camera installed on the back side of a mobile device facing away from
- the user. The captured images are meant to be displayed in portrait mode
- (height > width) to match the device screen orientation and the device
- usage orientation used when taking the picture.
-
- The camera sensor is typically mounted with its pixel array longer side
- aligned to the device longer side, upside-down mounted to compensate for
- the lens optical inversion effect:
-
- 0 Y-Rc
- 0 +-------------------->
- ! Y-Rp
- ! ^
- ! !
- ! !
- ! !
- ! ! |\_____)\__
- ! ! ) ____ ___.<
- ! ! |/ )/
- ! !
- ! !
- ! !
- ! 0 +------------------------------------->
- ! 0 X-Rp
- !
- !
- !
- !
- V
- X-Rc
-
- The two reference systems are not aligned and the 'Rp' reference
- system is rotated by 90 degrees in the counter-clockwise direction
- relatively to the 'Rc' reference system.
-
- The image once captured to memory will be rotated:
-
- +-------------------------------------+
- | _ _ |
- | \ / |
- | | | |
- | | | |
- | | > |
- | < | |
- | | | |
- | . |
- | V |
- +-------------------------------------+
-
- A correction of 90 degrees in counter-clockwise direction has to be
- applied to correctly display the image in portrait mode on the device
- screen:
-
- +--------------------+
- | |
- | |
- | |
- | |
- | |
- | |
- | |\____)\___ |
- | ) _____ __`< |
- | |/ )/ |
- | |
- | |
- | |
- | |
- | |
- +--------------------+
-
-- orientation: The orientation of a device (typically an image sensor or a flash
- LED) describing its mounting position relative to the usage orientation of the
- system where the device is installed on.
- Possible values are:
- 0 - Front. The device is mounted on the front facing side of the system.
- For mobile devices such as smartphones, tablets and laptops the front side is
- the user facing side.
- 1 - Back. The device is mounted on the back side of the system, which is
- defined as the opposite side of the front facing one.
- 2 - External. The device is not attached directly to the system but is
- attached in a way that allows it to move freely.
-
-Optional endpoint properties
-----------------------------
-
-- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
-- slave-mode: a boolean property indicating that the link is run in slave mode.
- The default when this property is not specified is master mode. In the slave
- mode horizontal and vertical synchronization signals are provided to the
- slave device (data source) by the master device (data sink). In the master
- mode the data source device is also the source of the synchronization signals.
-- bus-type: data bus type. Possible values are:
- 1 - MIPI CSI-2 C-PHY
- 2 - MIPI CSI1
- 3 - CCP2
- 4 - MIPI CSI-2 D-PHY
- 5 - Parallel
- 6 - Bt.656
-- bus-width: number of data lines actively used, valid for the parallel busses.
-- data-shift: on the parallel data busses, if bus-width is used to specify the
- number of data lines, data-shift can be used to specify which data lines are
- used, e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
-- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
-- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
- Note, that if HSYNC and VSYNC polarities are not specified, embedded
- synchronization may be required, where supported.
-- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
-- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
- signal polarity.
-- field-even-active: field signal level during the even field data transmission.
-- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
- signal.
-- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for
- LOW/HIGH respectively.
-- data-lanes: an array of physical data lane indexes. Position of an entry
- determines the logical lane number, while the value of an entry indicates
- physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
- "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
- If the hardware does not support lane reordering, monotonically
- incremented values shall be used from 0 or 1 onwards, depending on
- whether or not there is also a clock lane. This property is valid for
- serial busses only (e.g. MIPI CSI-2).
-- clock-lanes: an array of physical clock lane indexes. Position of an entry
- determines the logical lane number, while the value of an entry indicates
- physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
- which places the clock lane on hardware lane 0. This property is valid for
- serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
- array contains only one entry.
-- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
- clock mode.
-- link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for
- instance, this is the actual frequency of the bus, not bits per clock per
- lane value. An array of 64-bit unsigned integers.
-- lane-polarities: an array of polarities of the lanes starting from the clock
- lane and followed by the data lanes in the same order as in data-lanes.
- Valid values are 0 (normal) and 1 (inverted). The length of the array
- should be the combined length of data-lanes and clock-lanes properties.
- If the lane-polarities property is omitted, the value must be interpreted
- as 0 (normal). This property is valid for serial busses only.
-- strobe: Whether the clock signal is used as clock (0) or strobe (1). Used
- with CCP2, for instance.
-
-Example
--------
-
-The example snippet below describes two data pipelines. ov772x and imx074 are
-camera sensors with a parallel and serial (MIPI CSI-2) video bus respectively.
-Both sensors are on the I2C control bus corresponding to the i2c0 controller
-node. ov772x sensor is linked directly to the ceu0 video host interface.
-imx074 is linked to ceu0 through the MIPI CSI-2 receiver (csi2). ceu0 has a
-(single) DMA engine writing captured data to memory. ceu0 node has a single
-'port' node which may indicate that at any time only one of the following data
-pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
-
- ceu0: ceu@fe910000 {
- compatible = "renesas,sh-mobile-ceu";
- reg = <0xfe910000 0xa0>;
- interrupts = <0x880>;
-
- mclk: master_clock {
- compatible = "renesas,ceu-clock";
- #clock-cells = <1>;
- clock-frequency = <50000000>; /* Max clock frequency */
- clock-output-names = "mclk";
- };
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- /* Parallel bus endpoint */
- ceu0_1: endpoint@1 {
- reg = <1>; /* Local endpoint # */
- remote = <&ov772x_1_1>; /* Remote phandle */
- bus-width = <8>; /* Used data lines */
- data-shift = <2>; /* Lines 9:2 are used */
-
- /* If hsync-active/vsync-active are missing,
- embedded BT.656 sync is used */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- data-active = <1>; /* Active high */
- pclk-sample = <1>; /* Rising */
- };
-
- /* MIPI CSI-2 bus endpoint */
- ceu0_0: endpoint@0 {
- reg = <0>;
- remote = <&csi2_2>;
- };
- };
- };
-
- i2c0: i2c@fff20000 {
- ...
- ov772x_1: camera@21 {
- compatible = "ovti,ov772x";
- reg = <0x21>;
- vddio-supply = <®ulator1>;
- vddcore-supply = <®ulator2>;
-
- clock-frequency = <20000000>;
- clocks = <&mclk 0>;
- clock-names = "xclk";
-
- port {
- /* With 1 endpoint per port no need for addresses. */
- ov772x_1_1: endpoint {
- bus-width = <8>;
- remote-endpoint = <&ceu0_1>;
- hsync-active = <1>;
- vsync-active = <0>; /* Who came up with an
- inverter here ?... */
- data-active = <1>;
- pclk-sample = <1>;
- };
- };
- };
-
- imx074: camera@1a {
- compatible = "sony,imx074";
- reg = <0x1a>;
- vddio-supply = <®ulator1>;
- vddcore-supply = <®ulator2>;
-
- clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
- clocks = <&mclk 0>;
- clock-names = "sysclk"; /* Assuming this is the
- name in the datasheet */
- port {
- imx074_1: endpoint {
- clock-lanes = <0>;
- data-lanes = <1 2>;
- remote-endpoint = <&csi2_1>;
- };
- };
- };
- };
-
- csi2: csi2@ffc90000 {
- compatible = "renesas,sh-mobile-csi2";
- reg = <0xffc90000 0x1000>;
- interrupts = <0x17a0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
- reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
- PHY_M has port address 0,
- is unused. */
- csi2_1: endpoint {
- clock-lanes = <0>;
- data-lanes = <2 1>;
- remote-endpoint = <&imx074_1>;
- };
- };
- port@2 {
- reg = <2>; /* port 2: link to the CEU */
-
- csi2_2: endpoint {
- remote-endpoint = <&ceu0_0>;
- };
- };
- };
+This file has moved to video-interfaces.yaml and video-interface-devices.yaml.
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml
new file mode 100644
index 000000000000..0a7a73fd59f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml
@@ -0,0 +1,344 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/video-interfaces.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for video receiver and transmitter interface endpoints
+
+maintainers:
+ - Sakari Ailus <sakari.ailus@linux.intel.com>
+ - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+ Video data pipelines usually consist of external devices, e.g. camera sensors,
+ controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
+ video DMA engines and video data processors.
+
+ SoC internal blocks are described by DT nodes, placed similarly to other SoC
+ blocks. External devices are represented as child nodes of their respective
+ bus controller nodes, e.g. I2C.
+
+ Data interfaces on all video devices are described by their child 'port' nodes.
+ Configuration of a port depends on other devices participating in the data
+ transfer and is described by 'endpoint' subnodes.
+
+ device {
+ ...
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ ...
+ endpoint@0 { ... };
+ endpoint@1 { ... };
+ };
+ port@1 { ... };
+ };
+ };
+
+ If a port can be configured to work with more than one remote device on the same
+ bus, an 'endpoint' child node must be provided for each of them. If more than
+ one port is present in a device node or there is more than one endpoint at a
+ port, or port node needs to be associated with a selected hardware interface,
+ a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
+ used.
+
+ All 'port' nodes can be grouped under optional 'ports' node, which allows to
+ specify #address-cells, #size-cells properties independently for the 'port'
+ and 'endpoint' nodes and any child device nodes a device might have.
+
+ Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
+ phandles. An endpoint subnode of a device contains all properties needed for
+ configuration of this device for data exchange with other device. In most
+ cases properties at the peer 'endpoint' nodes will be identical, however they
+ might need to be different when there is any signal modifications on the bus
+ between two devices, e.g. there are logic signal inverters on the lines.
+
+ It is allowed for multiple endpoints at a port to be active simultaneously,
+ where supported by a device. For example, in case where a data interface of
+ a device is partitioned into multiple data busses, e.g. 16-bit input port
+ divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
+ and data-shift properties can be used to assign physical data lines to each
+ endpoint node (logical bus).
+
+ Documenting bindings for devices
+ --------------------------------
+
+ All required and optional bindings the device supports shall be explicitly
+ documented in device DT binding documentation. This also includes port and
+ endpoint nodes for the device, including unit-addresses and reg properties
+ where relevant.
+
+allOf:
+ - $ref: /schemas/graph.yaml#/$defs/endpoint-base
+
+properties:
+ slave-mode:
+ type: boolean
+ description:
+ Indicates that the link is run in slave mode. The default when this
+ property is not specified is master mode. In the slave mode horizontal and
+ vertical synchronization signals are provided to the slave device (data
+ source) by the master device (data sink). In the master mode the data
+ source device is also the source of the synchronization signals.
+
+ bus-type:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 1 # MIPI CSI-2 C-PHY
+ - 2 # MIPI CSI1
+ - 3 # CCP2
+ - 4 # MIPI CSI-2 D-PHY
+ - 5 # Parallel
+ - 6 # BT.656
+ description:
+ Data bus type.
+
+ bus-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 64
+ description:
+ Number of data lines actively used, valid for the parallel busses.
+
+ data-shift:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 64
+ description:
+ On the parallel data busses, if bus-width is used to specify the number of
+ data lines, data-shift can be used to specify which data lines are used,
+ e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
+
+ hsync-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
+
+ vsync-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. Note,
+ that if HSYNC and VSYNC polarities are not specified, embedded
+ synchronization may be required, where supported.
+
+ data-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Similar to HSYNC and VSYNC, specifies data line polarity.
+
+ data-enable-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Similar to HSYNC and VSYNC, specifies the data enable signal polarity.
+
+ field-even-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Field signal level during the even field data transmission.
+
+ pclk-sample:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Sample data on rising (1) or falling (0) edge of the pixel clock signal.
+
+ sync-on-green-active:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively.
+
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+ items:
+ # Assume up to 9 physical lane indices
+ maximum: 8
+ description:
+ An array of physical data lane indexes. Position of an entry determines
+ the logical lane number, while the value of an entry indicates physical
+ lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;",
+ assuming the clock lane is on hardware lane 0. If the hardware does not
+ support lane reordering, monotonically incremented values shall be used
+ from 0 or 1 onwards, depending on whether or not there is also a clock
+ lane. This property is valid for serial busses only (e.g. MIPI CSI-2).
+
+ clock-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ # Assume up to 9 physical lane indices
+ maximum: 8
+ description:
+ Physical clock lane index. Position of an entry determines the logical
+ lane number, while the value of an entry indicates physical lane, e.g. for
+ a MIPI CSI-2 bus we could have "clock-lanes = <0>;", which places the
+ clock lane on hardware lane 0. This property is valid for serial busses
+ only (e.g. MIPI CSI-2).
+
+ clock-noncontinuous:
+ type: boolean
+ description:
+ Allow MIPI CSI-2 non-continuous clock mode.
+
+ link-frequencies:
+ $ref: /schemas/types.yaml#/definitions/uint64-array
+ description:
+ Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the
+ actual frequency of the bus, not bits per clock per lane value. An array
+ of 64-bit unsigned integers.
+
+ lane-polarities:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 9
+ items:
+ enum: [ 0, 1 ]
+ description:
+ An array of polarities of the lanes starting from the clock lane and
+ followed by the data lanes in the same order as in data-lanes. Valid
+ values are 0 (normal) and 1 (inverted). The length of the array should be
+ the combined length of data-lanes and clock-lanes properties. If the
+ lane-polarities property is omitted, the value must be interpreted as 0
+ (normal). This property is valid for serial busses only.
+
+ strobe:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+ description:
+ Whether the clock signal is used as clock (0) or strobe (1). Used with
+ CCP2, for instance.
+
+additionalProperties: true
+
+examples:
+ # The example snippet below describes two data pipelines. ov772x and imx074
+ # are camera sensors with a parallel and serial (MIPI CSI-2) video bus
+ # respectively. Both sensors are on the I2C control bus corresponding to the
+ # i2c0 controller node. ov772x sensor is linked directly to the ceu0 video
+ # host interface. imx074 is linked to ceu0 through the MIPI CSI-2 receiver
+ # (csi2). ceu0 has a (single) DMA engine writing captured data to memory.
+ # ceu0 node has a single 'port' node which may indicate that at any time
+ # only one of the following data pipelines can be active:
+ # ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
+ - |
+ ceu@fe910000 {
+ compatible = "renesas,sh-mobile-ceu";
+ reg = <0xfe910000 0xa0>;
+ interrupts = <0x880>;
+
+ mclk: master_clock {
+ compatible = "renesas,ceu-clock";
+ #clock-cells = <1>;
+ clock-frequency = <50000000>; /* Max clock frequency */
+ clock-output-names = "mclk";
+ };
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Parallel bus endpoint */
+ ceu0_1: endpoint@1 {
+ reg = <1>; /* Local endpoint # */
+ remote-endpoint = <&ov772x_1_1>; /* Remote phandle */
+ bus-width = <8>; /* Used data lines */
+ data-shift = <2>; /* Lines 9:2 are used */
+
+ /* If hsync-active/vsync-active are missing,
+ embedded BT.656 sync is used */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+
+ /* MIPI CSI-2 bus endpoint */
+ ceu0_0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&csi2_2>;
+ };
+ };
+ };
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ camera@21 {
+ compatible = "ovti,ov772x";
+ reg = <0x21>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <20000000>;
+ clocks = <&mclk 0>;
+ clock-names = "xclk";
+
+ port {
+ /* With 1 endpoint per port no need for addresses. */
+ ov772x_1_1: endpoint {
+ bus-width = <8>;
+ remote-endpoint = <&ceu0_1>;
+ hsync-active = <1>;
+ vsync-active = <0>; /* Who came up with an
+ inverter here ?... */
+ data-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
+ camera@1a {
+ compatible = "sony,imx074";
+ reg = <0x1a>;
+ vddio-supply = <®ulator1>;
+ vddcore-supply = <®ulator2>;
+
+ clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
+ clocks = <&mclk 0>;
+ clock-names = "sysclk"; /* Assuming this is the
+ name in the datasheet */
+ port {
+ imx074_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ remote-endpoint = <&csi2_1>;
+ };
+ };
+ };
+ };
+
+ csi2: csi2@ffc90000 {
+ compatible = "renesas,sh-mobile-csi2";
+ reg = <0xffc90000 0x1000>;
+ interrupts = <0x17a0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
+ reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
+ PHY_M has port address 0,
+ is unused. */
+ csi2_1: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <2 1>;
+ remote-endpoint = <&imx074_1>;
+ };
+ };
+ port@2 {
+ reg = <2>; /* port 2: link to the CEU */
+
+ csi2_2: endpoint {
+ remote-endpoint = <&ceu0_0>;
+ };
+ };
+ };
+
+...
--
2.27.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas
2021-01-04 16:58 [PATCH v4 0/2] dt-bindings: media: Convert video-interfaces.txt to schemas Rob Herring
2021-01-04 16:58 ` [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties " Rob Herring
@ 2021-01-04 16:58 ` Rob Herring
2021-01-05 4:59 ` Laurent Pinchart
` (2 more replies)
1 sibling, 3 replies; 9+ messages in thread
From: Rob Herring @ 2021-01-04 16:58 UTC (permalink / raw)
To: Guennadi Liakhovetski, Guennadi Liakhovetski, Sakari Ailus,
Maxime Ripard, Mauro Carvalho Chehab, Jacopo Mondi,
Laurent Pinchart
Cc: devicetree, linux-kernel, linux-media
Now that we have graph and video-interfaces schemas, rework the media
related schemas to use them.
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Jacopo Mondi <jacopo@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
v4:
- Fix incorrect ref 'video-interface-device.yaml' in ovti,ov02a10.yaml
- Explicitly list common properties used in mipi-ccs and ovti,ov02a10
- Add back description of link-frequencies driver limitations in ov8856
v3:
- Add mipi-ccs.yaml, ovti,ov02a10.yaml
v2:
- Update based on graph schema changes and addition of video-interfaces
schemas
---
.../media/allwinner,sun4i-a10-csi.yaml | 11 +-
.../media/allwinner,sun6i-a31-csi.yaml | 12 +-
.../bindings/media/i2c/adv7180.yaml | 36 ++----
.../bindings/media/i2c/adv7604.yaml | 37 ++----
.../bindings/media/i2c/aptina,mt9v111.yaml | 4 +-
.../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 +----
.../devicetree/bindings/media/i2c/imx219.yaml | 21 ++--
.../bindings/media/i2c/maxim,max9286.yaml | 101 ++++------------
.../bindings/media/i2c/mipi-ccs.yaml | 17 ++-
.../devicetree/bindings/media/i2c/ov5647.yaml | 20 +---
.../devicetree/bindings/media/i2c/ov8856.yaml | 22 ++--
.../bindings/media/i2c/ovti,ov02a10.yaml | 29 ++---
.../bindings/media/i2c/ovti,ov2680.yaml | 6 +-
.../bindings/media/i2c/ovti,ov772x.yaml | 9 +-
.../bindings/media/i2c/sony,imx214.yaml | 25 ++--
.../bindings/media/i2c/sony,imx274.yaml | 3 +-
.../bindings/media/marvell,mmp2-ccic.yaml | 15 +--
.../bindings/media/nxp,imx7-csi.yaml | 5 +-
.../bindings/media/nxp,imx7-mipi-csi2.yaml | 32 +----
.../bindings/media/renesas,ceu.yaml | 17 +--
.../bindings/media/renesas,csi2.yaml | 54 ++-------
.../bindings/media/renesas,vin.yaml | 113 +++---------------
.../bindings/media/rockchip-isp1.yaml | 40 +------
.../bindings/media/st,stm32-dcmi.yaml | 18 +--
.../devicetree/bindings/media/ti,cal.yaml | 55 ++-------
.../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +-----
26 files changed, 172 insertions(+), 599 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
index 09318830db47..6ced94064215 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-csi.yaml
@@ -67,14 +67,14 @@ properties:
interconnect-names:
const: dma-mem
- # See ./video-interfaces.txt for details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-width:
@@ -83,7 +83,6 @@ properties:
data-active: true
hsync-active: true
pclk-sample: true
- remote-endpoint: true
vsync-active: true
required:
@@ -91,12 +90,8 @@ properties:
- data-active
- hsync-active
- pclk-sample
- - remote-endpoint
- vsync-active
- required:
- - endpoint
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..8b568072a069 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -40,17 +40,15 @@ properties:
resets:
maxItems: 1
- # See ./video-interfaces.txt for details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint: true
-
bus-width:
enum: [ 8, 10, 12, 16 ]
@@ -60,10 +58,6 @@ properties:
required:
- bus-width
- - remote-endpoint
-
- required:
- - endpoint
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
index d8c54f9d9506..bcfd93739b4f 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml
@@ -36,17 +36,9 @@ properties:
maxItems: 1
port:
- type: object
- description:
- A node containing a single endpoint as doucmented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
-
- ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/port
+
+ ports: true
additionalProperties: false
@@ -80,25 +72,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@3:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-2]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@3
- additionalProperties: false
-
required:
- ports
@@ -110,25 +97,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@6:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-5]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@6
- additionalProperties: false
-
required:
- ports
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
index 407baddfaa1d..df634b0c1f8c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml
@@ -64,16 +64,12 @@ properties:
description:
Select which input is selected after reset.
- ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ ports: true
required:
- compatible
- reg
+ - ports
additionalProperties: false
@@ -86,26 +82,19 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
+
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
required:
- port@1
- additionalProperties: false
-
- required:
- - ports
-
- if:
properties:
compatible:
@@ -114,28 +103,20 @@ allOf:
then:
properties:
ports:
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
- '#size-cells':
- const: 0
port@2:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Output port
patternProperties:
"^port@[0-1]$":
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: Input port
required:
- port@2
- additionalProperties: false
-
- required:
- - ports
-
examples:
- |
#include <dt-bindings/gpio/gpio.h>
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
index ff9546e95d05..e53b8d65f381 100644
--- a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.yaml
@@ -41,9 +41,9 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description: |
- Output video port. See ../video-interfaces.txt.
+ Output video port.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
index 3dc06c628e64..e57575c44930 100644
--- a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml
@@ -86,33 +86,9 @@ properties:
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
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Connection to the remote GMSL endpoint.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/imx219.yaml b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
index dfc4d29a4f04..012c0565d8ae 100644
--- a/Documentation/devicetree/bindings/media/i2c/imx219.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/imx219.yaml
@@ -44,12 +44,15 @@ properties:
Reference to the GPIO connected to the xclr pin, if any.
Must be released (set high) after all supplies are applied.
- # See ../video-interfaces.txt for more details
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
properties:
data-lanes:
description: |-
@@ -60,16 +63,8 @@ properties:
- const: 1
- const: 2
- clock-noncontinuous:
- type: boolean
- description: |-
- MIPI CSI-2 clock is non-continuous if this property is present,
- otherwise it's continuous.
-
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description:
- Allowed data bus frequencies.
+ clock-noncontinuous: true
+ link-frequencies: true
required:
- link-frequencies
diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
index 68ee8c7d9e79..bf4fa56ffcc7 100644
--- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
@@ -51,81 +51,41 @@ properties:
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
+ $ref: /schemas/graph.yaml#/properties/ports
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.
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 0
- required:
- - remote-endpoint
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 1
- required:
- - reg
- - endpoint
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 2
- additionalProperties: false
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GMSL Input 3
port@4:
- type: object
- properties:
- reg:
- const: 4
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI-2 Output
+ properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint:
- description: phandle to the remote CSI-2 sink endpoint.
-
- data-lanes:
- description: array of physical CSI-2 data lane indexes.
+ data-lanes: true
required:
- - remote-endpoint
- data-lanes
- required:
- - reg
- - endpoint
-
- additionalProperties: false
-
required:
- port@4
@@ -183,25 +143,8 @@ properties:
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
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Connection to the MAX9286 sink.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
index bb3528315f20..701f4e0d138f 100644
--- a/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml
@@ -71,19 +71,18 @@ properties:
enum: [ 0, 180 ]
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ additionalProperties: false
+
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
properties:
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description: List of allowed data link frequencies.
- data-lanes:
- minItems: 1
- maxItems: 8
+ link-frequencies: true
+ data-lanes: true
bus-type:
- description: The type of the data bus.
oneOf:
- const: 1 # CSI-2 C-PHY
- const: 3 # CCP2
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.yaml b/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
index 280c62afae13..3b1ea9da437a 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ov5647.yaml
@@ -31,27 +31,15 @@ properties:
maxItems: 1
port:
- type: object
- description: |-
- Should contain one endpoint sub-node used to model connection to the
- video receiver according to the specification defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ $ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- remote-endpoint:
- description: |-
- phandle to the video receiver input port.
-
- clock-noncontinuous:
- type: boolean
- description: |-
- Set to true to allow MIPI CSI-2 non-continuous clock operations.
-
- additionalProperties: false
+ clock-noncontinuous: true
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
index cde85553fd01..baf92aaaf049 100644
--- a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml
@@ -57,16 +57,13 @@ properties:
active low.
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
- description:
- A node containing an output port node with an endpoint definition
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
@@ -79,18 +76,14 @@ properties:
- const: 4
link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description:
- Allowed data bus frequencies. 360000000, 180000000 Hz or both
- are supported by the driver.
-
+ description: Frequencies listed are driver, not h/w limitations.
+ maxItems: 2
+ items:
+ enum: [ 360000000, 180000000 ]
required:
- link-frequencies
- required:
- - endpoint
-
required:
- compatible
- reg
@@ -139,4 +132,3 @@ examples:
};
};
...
-
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
index 1c3879ec4122..63a040944f3d 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -17,6 +17,9 @@ description: |-
@ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
sensor output is available via CSI-2 serial data output.
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
properties:
compatible:
const: ovti,ov02a10
@@ -66,42 +69,34 @@ properties:
maxItems: 1
rotation:
- description:
- Definition of the sensor's placement.
- allOf:
- - $ref: "/schemas/types.yaml#/definitions/uint32"
- - enum:
- - 0 # Sensor Mounted Upright
- - 180 # Sensor Mounted Upside Down
- default: 0
-
- # See ../video-interfaces.txt for details
+ enum:
+ - 0 # Sensor Mounted Upright
+ - 180 # Sensor Mounted Upside Down
+ default: 0
+
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
description:
Output port node, single endpoint describing the CSI-2 transmitter.
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
link-frequencies: true
ovti,mipi-clock-voltage:
- allOf:
- - $ref: "/schemas/types.yaml#/definitions/uint32"
+ $ref: "/schemas/types.yaml#/definitions/uint32"
description:
Definition of MIPI clock voltage unit. This entry corresponds to
the link speed defined by the 'link-frequencies' property.
If present, the value shall be in the range of 0-4.
default: 4
- remote-endpoint: true
required:
- link-frequencies
- - remote-endpoint
required:
- endpoint
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
index 43bf749807e1..cf456f8d9ddc 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2680.yaml
@@ -50,11 +50,9 @@ properties:
Definition of the regulator used as digital power supply.
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
- A node containing an output port node with an endpoint definition
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ A node containing an output port node.
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
index 6866c2cdac50..44529425ce3a 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml
@@ -37,13 +37,14 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
- Video output port. See ../video-interfaces.txt.
+ Video output port.
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-type:
@@ -91,8 +92,6 @@ properties:
required:
- bus-type
- unevaluatedProperties: false
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
index eb12526a462f..c9760f895b3e 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml
@@ -15,6 +15,9 @@ description: |
interface. Image data is sent through MIPI CSI-2, through 2 or 4 lanes at a
maximum throughput of 1.2Gbps/lane.
+allOf:
+ - $ref: ../video-interface-devices.yaml#
+
properties:
compatible:
const: sony,imx214
@@ -44,25 +47,21 @@ properties:
vddd-supply:
description: Chip digital core regulator (1.12V).
- flash-leds:
- description: See ../video-interfaces.txt
-
- lens-focus:
- description: See ../video-interfaces.txt
+ flash-leds: true
+ lens-focus: true
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
- Video output port. See ../video-interfaces.txt.
+ Video output port.
properties:
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: See ../video-interfaces.txt
anyOf:
- items:
- const: 1
@@ -73,16 +72,12 @@ properties:
- const: 3
- const: 4
- link-frequencies:
- $ref: /schemas/types.yaml#/definitions/uint64-array
- description: See ../video-interfaces.txt
+ link-frequencies: true
required:
- data-lanes
- link-frequencies
- unevaluatedProperties: false
-
additionalProperties: false
required:
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
index a66acb20d59b..4271fc3cc623 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml
@@ -41,8 +41,7 @@ properties:
description: Sensor digital IO 1.2 V supply.
port:
- type: object
- description: Output video port. See ../video-interfaces.txt.
+ $ref: /schemas/graph.yaml#/properties/port
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
index 49bff738aca5..9e85c70d1a1f 100644
--- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
+++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
@@ -24,29 +24,20 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
- # Properties described in
- # Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
- remote-endpoint: true
hsync-active: true
vsync-active: true
pclk-sample: true
bus-type: true
- required:
- - remote-endpoint
-
- required:
- - endpoint
-
clocks:
minItems: 1
maxItems: 3
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
index 4e81a47e60ac..d91575b8ebb9 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml
@@ -33,10 +33,7 @@ properties:
- const: mclk
port:
- type: object
- description:
- A node containing input port nodes with endpoint definitions as documented
- in Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/port
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
index 0668332959e7..be47a7b62ca9 100644
--- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml
@@ -58,35 +58,22 @@ properties:
Differential receiver (HS-RX) settle time
ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
data-lanes:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- description: See ../video-interfaces.txt
oneOf:
- items:
- const: 1
@@ -94,18 +81,11 @@ properties:
- const: 1
- const: 2
- remote-endpoint: true
-
required:
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Output port node
diff --git a/Documentation/devicetree/bindings/media/renesas,ceu.yaml b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
index c7e1e4fe67e6..50e0740af15a 100644
--- a/Documentation/devicetree/bindings/media/renesas,ceu.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,ceu.yaml
@@ -34,18 +34,15 @@ properties:
maxItems: 1
port:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
properties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
- # Properties described in
- # Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
- remote-endpoint: true
hsync-active: true
vsync-active: true
field-even-active: false
@@ -53,12 +50,6 @@ properties:
enum: [8, 16]
default: 8
- required:
- - remote-endpoint
-
- required:
- - endpoint
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
index 533c2f181db7..20396f1be999 100644
--- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml
@@ -46,24 +46,19 @@ properties:
maxItems: 1
ports:
- type: object
- description:
- A node containing input and output port nodes with endpoint definitions
- as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -72,50 +67,19 @@ properties:
data-lanes:
maxItems: 1
- remote-endpoint: true
-
required:
- clock-lanes
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Output port node, multiple endpoints describing all the R-Car VIN
modules connected the CSI-2 receiver.
- properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- reg:
- const: 1
-
- patternProperties:
- "^endpoint@[0-9a-f]$":
- type: object
-
- properties:
- reg:
- maxItems: 1
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
+ required:
+ - port@0
+ - port@1
required:
- compatible
diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml
index ad2fe660364b..fe7c4cbfe4ba 100644
--- a/Documentation/devicetree/bindings/media/renesas,vin.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml
@@ -69,15 +69,15 @@ properties:
#The per-board settings for Gen2 and RZ/G1 platforms:
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
- A node containing a parallel input with a single endpoint definitions as
- documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ A node containing a parallel input
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
hsync-active:
@@ -106,15 +106,6 @@ properties:
data-active: true
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- additionalProperties: false
-
#The per-board settings for Gen3 and RZ/G2 platforms:
renesas,id:
description: VIN channel number
@@ -123,23 +114,18 @@ properties:
maximum: 15
ports:
- type: object
- description:
- A node containing input nodes with endpoint definitions as documented in
- Documentation/devicetree/bindings/media/video-interfaces.txt
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Input port node, single endpoint describing a parallel input source.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
hsync-active:
@@ -168,98 +154,29 @@ properties:
data-active: true
- remote-endpoint: true
-
- required:
- - remote-endpoint
-
- additionalProperties: false
-
- required:
- - endpoint
-
- additionalProperties: false
-
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
description:
Input port node, multiple endpoints describing all the R-Car CSI-2
modules connected the VIN.
properties:
- '#address-cells':
- const: 1
-
- '#size-cells':
- const: 0
-
- reg:
- const: 1
-
endpoint@0:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI20.
- properties:
- reg:
- const: 0
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI21.
- properties:
- reg:
- const: 1
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@2:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI40.
- properties:
- reg:
- const: 2
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
endpoint@3:
- type: object
+ $ref: /schemas/graph.yaml#/properties/endpoint
description: Endpoint connected to CSI41.
- properties:
- reg:
- const: 3
-
- remote-endpoint: true
-
- required:
- - reg
- - remote-endpoint
-
- additionalProperties: false
-
anyOf:
- required:
- endpoint@0
@@ -270,8 +187,6 @@ properties:
- required:
- endpoint@3
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
index 2004c054ed1a..a6b1eff879ed 100644
--- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
@@ -56,56 +56,26 @@ properties:
power-domains:
maxItems: 1
- # See ./video-interfaces.txt for details
ports:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description: connection point for sensors at MIPI-DPHY RX0
- additionalProperties: false
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
- reg:
- const: 0
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
- reg:
- maxItems: 1
-
data-lanes:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
- - "#address-cells"
- - "#size-cells"
-
required:
- - "#address-cells"
- - "#size-cells"
- port@0
required:
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index c18574bb3e81..41e1d0cd80e5 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -37,16 +37,15 @@ properties:
maxItems: 1
port:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
- DCMI supports a single port node with parallel bus. It should contain
- one 'port' child node with child 'endpoint' node. Please refer to the
- bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ DCMI supports a single port node with parallel bus.
properties:
endpoint:
- type: object
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
bus-type:
@@ -57,8 +56,6 @@ properties:
enum: [8, 10, 12, 14]
default: 8
- remote-endpoint: true
-
allOf:
- if:
properties:
@@ -73,14 +70,9 @@ properties:
enum: [8]
required:
- - remote-endpoint
- bus-type
- pclk-sample
- unevaluatedProperties: false
-
- additionalProperties: false
-
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml
index 5e066629287d..65177cd69514 100644
--- a/Documentation/devicetree/bindings/media/ti,cal.yaml
+++ b/Documentation/devicetree/bindings/media/ti,cal.yaml
@@ -15,10 +15,7 @@ description: |-
processing capability to connect CSI2 image-sensor modules to the
DRA72x device.
- CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
- should contain a 'port' child node with child 'endpoint' node. Please
- refer to the bindings defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
+ CAL supports 2 camera port nodes on MIPI bus.
properties:
compatible:
@@ -67,31 +64,19 @@ properties:
Documentation/devicetree/bindings/power/power_domain.txt
maxItems: 1
- # See ./video-interfaces.txt for details
ports:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
- "#address-cells":
- const: 1
-
- "#size-cells":
- const: 0
-
port@0:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI2 Port #0
properties:
- reg:
- const: 0
- description: CSI2 Port #0
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -101,24 +86,15 @@ properties:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
-
port@1:
- type: object
- additionalProperties: false
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: CSI2 Port #1
properties:
- reg:
- const: 1
- description: CSI2 Port #1
-
- patternProperties:
endpoint:
- type: object
- additionalProperties: false
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
clock-lanes:
@@ -128,14 +104,7 @@ properties:
minItems: 1
maxItems: 4
- remote-endpoint: true
-
- required:
- - reg
-
required:
- - "#address-cells"
- - "#size-cells"
- port@0
required:
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
index 2961a5b6872f..7d77823dbb7a 100644
--- a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
@@ -97,24 +97,21 @@ properties:
maxItems: 1
ports:
- type: object
+ $ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
- type: object
+ $ref: /schemas/graph.yaml#/$defs/port-base
description: |
Input / sink port node, single endpoint describing the
CSI-2 transmitter.
properties:
- reg:
- const: 0
-
endpoint:
- type: object
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
properties:
-
data-lanes:
description: |
This is required only in the sink port 0 endpoint which
@@ -130,41 +127,17 @@ properties:
- const: 3
- const: 4
- remote-endpoint: true
-
required:
- data-lanes
- - remote-endpoint
-
- additionalProperties: false
- additionalProperties: false
+ unevaluatedProperties: false
port@1:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
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
--
2.27.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas
2021-01-04 16:58 ` [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas Rob Herring
@ 2021-01-05 4:59 ` Laurent Pinchart
2021-01-05 8:59 ` Maxime Ripard
2021-01-05 9:09 ` Sakari Ailus
2 siblings, 0 replies; 9+ messages in thread
From: Laurent Pinchart @ 2021-01-05 4:59 UTC (permalink / raw)
To: Rob Herring
Cc: Guennadi Liakhovetski, Guennadi Liakhovetski, Sakari Ailus,
Maxime Ripard, Mauro Carvalho Chehab, Jacopo Mondi,
Laurent Pinchart, devicetree, linux-kernel, linux-media
Hi Rob,
Thank you for the patch.
On Mon, Jan 04, 2021 at 09:58:08AM -0700, Rob Herring wrote:
> Now that we have graph and video-interfaces schemas, rework the media
> related schemas to use them.
>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Jacopo Mondi <jacopo@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
I'm very happy to see this landing in v5.12 :-)
> ---
> v4:
> - Fix incorrect ref 'video-interface-device.yaml' in ovti,ov02a10.yaml
> - Explicitly list common properties used in mipi-ccs and ovti,ov02a10
> - Add back description of link-frequencies driver limitations in ov8856
>
> v3:
> - Add mipi-ccs.yaml, ovti,ov02a10.yaml
>
> v2:
> - Update based on graph schema changes and addition of video-interfaces
> schemas
> ---
> .../media/allwinner,sun4i-a10-csi.yaml | 11 +-
> .../media/allwinner,sun6i-a31-csi.yaml | 12 +-
> .../bindings/media/i2c/adv7180.yaml | 36 ++----
> .../bindings/media/i2c/adv7604.yaml | 37 ++----
> .../bindings/media/i2c/aptina,mt9v111.yaml | 4 +-
> .../bindings/media/i2c/imi,rdacm2x-gmsl.yaml | 30 +----
> .../devicetree/bindings/media/i2c/imx219.yaml | 21 ++--
> .../bindings/media/i2c/maxim,max9286.yaml | 101 ++++------------
> .../bindings/media/i2c/mipi-ccs.yaml | 17 ++-
> .../devicetree/bindings/media/i2c/ov5647.yaml | 20 +---
> .../devicetree/bindings/media/i2c/ov8856.yaml | 22 ++--
> .../bindings/media/i2c/ovti,ov02a10.yaml | 29 ++---
> .../bindings/media/i2c/ovti,ov2680.yaml | 6 +-
> .../bindings/media/i2c/ovti,ov772x.yaml | 9 +-
> .../bindings/media/i2c/sony,imx214.yaml | 25 ++--
> .../bindings/media/i2c/sony,imx274.yaml | 3 +-
> .../bindings/media/marvell,mmp2-ccic.yaml | 15 +--
> .../bindings/media/nxp,imx7-csi.yaml | 5 +-
> .../bindings/media/nxp,imx7-mipi-csi2.yaml | 32 +----
> .../bindings/media/renesas,ceu.yaml | 17 +--
> .../bindings/media/renesas,csi2.yaml | 54 ++-------
> .../bindings/media/renesas,vin.yaml | 113 +++---------------
> .../bindings/media/rockchip-isp1.yaml | 40 +------
> .../bindings/media/st,stm32-dcmi.yaml | 18 +--
> .../devicetree/bindings/media/ti,cal.yaml | 55 ++-------
> .../bindings/media/xilinx/xlnx,csi2rxss.yaml | 39 +-----
> 26 files changed, 172 insertions(+), 599 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas
2021-01-04 16:58 ` [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas Rob Herring
2021-01-05 4:59 ` Laurent Pinchart
@ 2021-01-05 8:59 ` Maxime Ripard
2021-01-05 9:09 ` Sakari Ailus
2 siblings, 0 replies; 9+ messages in thread
From: Maxime Ripard @ 2021-01-05 8:59 UTC (permalink / raw)
To: Rob Herring
Cc: Guennadi Liakhovetski, Guennadi Liakhovetski, Sakari Ailus,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart,
devicetree, linux-kernel, linux-media
On Mon, Jan 04, 2021 at 09:58:08AM -0700, Rob Herring wrote:
> Now that we have graph and video-interfaces schemas, rework the media
> related schemas to use them.
>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Jacopo Mondi <jacopo@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Thanks!
Maxime
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas
2021-01-04 16:58 ` [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas Rob Herring
2021-01-05 4:59 ` Laurent Pinchart
2021-01-05 8:59 ` Maxime Ripard
@ 2021-01-05 9:09 ` Sakari Ailus
2 siblings, 0 replies; 9+ messages in thread
From: Sakari Ailus @ 2021-01-05 9:09 UTC (permalink / raw)
To: Rob Herring
Cc: Guennadi Liakhovetski, Guennadi Liakhovetski, Maxime Ripard,
Mauro Carvalho Chehab, Jacopo Mondi, Laurent Pinchart,
devicetree, linux-kernel, linux-media
Hi Rob,
On Mon, Jan 04, 2021 at 09:58:08AM -0700, Rob Herring wrote:
> Now that we have graph and video-interfaces schemas, rework the media
> related schemas to use them.
>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Jacopo Mondi <jacopo@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
Thanks, this really cleans things up!
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Sakari Ailus
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas
2021-01-04 16:58 ` [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties " Rob Herring
@ 2021-01-22 16:23 ` Rob Herring
2021-01-22 17:01 ` Sakari Ailus
0 siblings, 1 reply; 9+ messages in thread
From: Rob Herring @ 2021-01-22 16:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart
Cc: devicetree, linux-kernel, Linux Media Mailing List, Hans Verkuil,
Laurent Pinchart, Guennadi Liakhovetski, Guennadi Liakhovetski,
Maxime Ripard, Jacopo Mondi
On Mon, Jan 4, 2021 at 10:58 AM Rob Herring <robh@kernel.org> wrote:
>
> Convert video-interfaces.txt to DT schema. As it contains a mixture of
> device level and endpoint properties, split it up into 2 schemas.
Ping!
Can this please be applied to the media tree so I can tell folks to
use it in reviews of media bindings.
> Binding schemas will need to reference both the graph.yaml and
> video-interfaces.yaml schemas. The exact schema depends on how many
> ports and endpoints for the binding. A single port with a single
> endpoint looks similar to this:
>
> port:
> $ref: /schemas/graph.yaml#/$defs/port-base
>
> properties:
> endpoint:
> $ref: video-interfaces.yaml#
> unevaluatedProperties: false
>
> properties:
> bus-width:
> enum: [ 8, 10, 12, 16 ]
>
> pclk-sample: true
> hsync-active: true
> vsync-active: true
>
> required:
> - bus-width
>
> additionalProperties: false
>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Acked-by: Jacopo Mondi <jacopo@jmondi.org>
> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>
> v4:
> - drop graph.txt ref
> - s/Bt.656/BT.656/
> - Replace Guennadi with Laurent as maintainer
>
> v3:
> - Support up to 9 physical lanes
> - Set lane-polarities array bounds
> ---
> .../media/video-interface-devices.yaml | 406 +++++++++++
> .../bindings/media/video-interfaces.txt | 640 +-----------------
> .../bindings/media/video-interfaces.yaml | 344 ++++++++++
> 3 files changed, 751 insertions(+), 639 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/video-interface-devices.yaml
> create mode 100644 Documentation/devicetree/bindings/media/video-interfaces.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> new file mode 100644
> index 000000000000..4527f56a5a6e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> @@ -0,0 +1,406 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/video-interface-devices.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common bindings for video receiver and transmitter devices
> +
> +maintainers:
> + - Jacopo Mondi <jacopo@jmondi.org>
> + - Sakari Ailus <sakari.ailus@linux.intel.com>
> +
> +properties:
> + flash-leds:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description:
> + An array of phandles, each referring to a flash LED, a sub-node of the LED
> + driver device node.
> +
> + lens-focus:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + A phandle to the node of the focus lens controller.
> +
> + rotation:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 90, 180, 270 ]
> + description: |
> + The camera rotation is expressed as the angular difference in degrees
> + between two reference systems, one relative to the camera module, and one
> + defined on the external world scene to be captured when projected on the
> + image sensor pixel array.
> +
> + A camera sensor has a 2-dimensional reference system 'Rc' defined by its
> + pixel array read-out order. The origin is set to the first pixel being
> + read out, the X-axis points along the column read-out direction towards
> + the last columns, and the Y-axis along the row read-out direction towards
> + the last row.
> +
> + A typical example for a sensor with a 2592x1944 pixel array matrix
> + observed from the front is:
> +
> + 2591 X-axis 0
> + <------------------------+ 0
> + .......... ... ..........!
> + .......... ... ..........! Y-axis
> + ... !
> + .......... ... ..........!
> + .......... ... ..........! 1943
> + V
> +
> + The external world scene reference system 'Rs' is a 2-dimensional
> + reference system on the focal plane of the camera module. The origin is
> + placed on the top-left corner of the visible scene, the X-axis points
> + towards the right, and the Y-axis points towards the bottom of the scene.
> + The top, bottom, left and right directions are intentionally not defined
> + and depend on the environment in which the camera is used.
> +
> + A typical example of a (very common) picture of a shark swimming from left
> + to right, as seen from the camera, is:
> +
> + 0 X-axis
> + 0 +------------------------------------->
> + !
> + !
> + !
> + ! |\____)\___
> + ! ) _____ __`<
> + ! |/ )/
> + !
> + !
> + !
> + V
> + Y-axis
> +
> + with the reference system 'Rs' placed on the camera focal plane:
> +
> + ¸.·˙!
> + ¸.·˙ !
> + _ ¸.·˙ !
> + +-/ \-+¸.·˙ !
> + | (o) | ! Camera focal plane
> + +-----+˙·.¸ !
> + ˙·.¸ !
> + ˙·.¸ !
> + ˙·.¸!
> +
> + When projected on the sensor's pixel array, the image and the associated
> + reference system 'Rs' are typically (but not always) inverted, due to the
> + camera module's lens optical inversion effect.
> +
> + Assuming the above represented scene of the swimming shark, the lens
> + inversion projects the scene and its reference system onto the sensor
> + pixel array, seen from the front of the camera sensor, as follows:
> +
> + Y-axis
> + ^
> + !
> + !
> + !
> + ! |\_____)\__
> + ! ) ____ ___.<
> + ! |/ )/
> + !
> + !
> + !
> + 0 +------------------------------------->
> + 0 X-axis
> +
> + Note the shark being upside-down.
> +
> + The resulting projected reference system is named 'Rp'.
> +
> + The camera rotation property is then defined as the angular difference in
> + the counter-clockwise direction between the camera reference system 'Rc'
> + and the projected scene reference system 'Rp'. It is expressed in degrees
> + as a number in the range [0, 360[.
> +
> + Examples
> +
> + 0 degrees camera rotation:
> +
> +
> + Y-Rp
> + ^
> + Y-Rc !
> + ^ !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! 0 +------------------------------------->
> + ! 0 X-Rp
> + 0 +------------------------------------->
> + 0 X-Rc
> +
> +
> + X-Rc 0
> + <------------------------------------+ 0
> + X-Rp 0 !
> + <------------------------------------+ 0 !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! V
> + ! Y-Rc
> + V
> + Y-Rp
> +
> + 90 degrees camera rotation:
> +
> + 0 Y-Rc
> + 0 +-------------------->
> + ! Y-Rp
> + ! ^
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! 0 +------------------------------------->
> + ! 0 X-Rp
> + !
> + !
> + !
> + !
> + V
> + X-Rc
> +
> + 180 degrees camera rotation:
> +
> + 0
> + <------------------------------------+ 0
> + X-Rc !
> + Y-Rp !
> + ^ !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! V
> + ! Y-Rc
> + 0 +------------------------------------->
> + 0 X-Rp
> +
> + 270 degrees camera rotation:
> +
> + 0 Y-Rc
> + 0 +-------------------->
> + ! 0
> + ! <-----------------------------------+ 0
> + ! X-Rp !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! !
> + ! V
> + ! Y-Rp
> + !
> + !
> + !
> + !
> + V
> + X-Rc
> +
> +
> + Example one - Webcam
> +
> + A camera module installed on the user facing part of a laptop screen
> + casing used for video calls. The captured images are meant to be displayed
> + in landscape mode (width > height) on the laptop screen.
> +
> + The camera is typically mounted upside-down to compensate the lens optical
> + inversion effect:
> +
> + Y-Rp
> + Y-Rc ^
> + ^ !
> + ! !
> + ! ! |\_____)\__
> + ! ! ) ____ ___.<
> + ! ! |/ )/
> + ! !
> + ! !
> + ! !
> + ! 0 +------------------------------------->
> + ! 0 X-Rp
> + 0 +------------------------------------->
> + 0 X-Rc
> +
> + The two reference systems are aligned, the resulting camera rotation is
> + 0 degrees, no rotation correction needs to be applied to the resulting
> + image once captured to memory buffers to correctly display it to users:
> +
> + +--------------------------------------+
> + ! !
> + ! !
> + ! !
> + ! |\____)\___ !
> + ! ) _____ __`< !
> + ! |/ )/ !
> + ! !
> + ! !
> + ! !
> + +--------------------------------------+
> +
> + If the camera sensor is not mounted upside-down to compensate for the lens
> + optical inversion, the two reference systems will not be aligned, with
> + 'Rp' being rotated 180 degrees relatively to 'Rc':
> +
> +
> + X-Rc 0
> + <------------------------------------+ 0
> + !
> + Y-Rp !
> + ^ !
> + ! !
> + ! |\_____)\__ !
> + ! ) ____ ___.< !
> + ! |/ )/ !
> + ! !
> + ! !
> + ! V
> + ! Y-Rc
> + 0 +------------------------------------->
> + 0 X-Rp
> +
> + The image once captured to memory will then be rotated by 180 degrees:
> +
> + +--------------------------------------+
> + ! !
> + ! !
> + ! !
> + ! __/(_____/| !
> + ! >.___ ____ ( !
> + ! \( \| !
> + ! !
> + ! !
> + ! !
> + +--------------------------------------+
> +
> + A software rotation correction of 180 degrees should be applied to
> + correctly display the image:
> +
> + +--------------------------------------+
> + ! !
> + ! !
> + ! !
> + ! |\____)\___ !
> + ! ) _____ __`< !
> + ! |/ )/ !
> + ! !
> + ! !
> + ! !
> + +--------------------------------------+
> +
> + Example two - Phone camera
> +
> + A camera installed on the back side of a mobile device facing away from
> + the user. The captured images are meant to be displayed in portrait mode
> + (height > width) to match the device screen orientation and the device
> + usage orientation used when taking the picture.
> +
> + The camera sensor is typically mounted with its pixel array longer side
> + aligned to the device longer side, upside-down mounted to compensate for
> + the lens optical inversion effect:
> +
> + 0 Y-Rc
> + 0 +-------------------->
> + ! Y-Rp
> + ! ^
> + ! !
> + ! !
> + ! !
> + ! ! |\_____)\__
> + ! ! ) ____ ___.<
> + ! ! |/ )/
> + ! !
> + ! !
> + ! !
> + ! 0 +------------------------------------->
> + ! 0 X-Rp
> + !
> + !
> + !
> + !
> + V
> + X-Rc
> +
> + The two reference systems are not aligned and the 'Rp' reference system is
> + rotated by 90 degrees in the counter-clockwise direction relatively to the
> + 'Rc' reference system.
> +
> + The image once captured to memory will be rotated:
> +
> + +-------------------------------------+
> + | _ _ |
> + | \ / |
> + | | | |
> + | | | |
> + | | > |
> + | < | |
> + | | | |
> + | . |
> + | V |
> + +-------------------------------------+
> +
> + A correction of 90 degrees in counter-clockwise direction has to be
> + applied to correctly display the image in portrait mode on the device
> + screen:
> +
> + +--------------------+
> + | |
> + | |
> + | |
> + | |
> + | |
> + | |
> + | |\____)\___ |
> + | ) _____ __`< |
> + | |/ )/ |
> + | |
> + | |
> + | |
> + | |
> + | |
> + +--------------------+
> +
> + orientation:
> + description:
> + The orientation of a device (typically an image sensor or a flash LED)
> + describing its mounting position relative to the usage orientation of the
> + system where the device is installed on.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum:
> + # Front. The device is mounted on the front facing side of the system. For
> + # mobile devices such as smartphones, tablets and laptops the front side
> + # is the user facing side.
> + - 0
> + # Back. The device is mounted on the back side of the system, which is
> + # defined as the opposite side of the front facing one.
> + - 1
> + # External. The device is not attached directly to the system but is
> + # attached in a way that allows it to move freely.
> + - 2
> +
> +additionalProperties: true
> +
> +...
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt
> index 3920f25a9123..8fcf5f52bf5b 100644
> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
> @@ -1,639 +1 @@
> -Common bindings for video receiver and transmitter interfaces
> -
> -General concept
> ----------------
> -
> -Video data pipelines usually consist of external devices, e.g. camera sensors,
> -controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
> -video DMA engines and video data processors.
> -
> -SoC internal blocks are described by DT nodes, placed similarly to other SoC
> -blocks. External devices are represented as child nodes of their respective
> -bus controller nodes, e.g. I2C.
> -
> -Data interfaces on all video devices are described by their child 'port' nodes.
> -Configuration of a port depends on other devices participating in the data
> -transfer and is described by 'endpoint' subnodes.
> -
> -device {
> - ...
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - ...
> - endpoint@0 { ... };
> - endpoint@1 { ... };
> - };
> - port@1 { ... };
> - };
> -};
> -
> -If a port can be configured to work with more than one remote device on the same
> -bus, an 'endpoint' child node must be provided for each of them. If more than
> -one port is present in a device node or there is more than one endpoint at a
> -port, or port node needs to be associated with a selected hardware interface,
> -a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
> -used.
> -
> -All 'port' nodes can be grouped under optional 'ports' node, which allows to
> -specify #address-cells, #size-cells properties independently for the 'port'
> -and 'endpoint' nodes and any child device nodes a device might have.
> -
> -Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
> -phandles. An endpoint subnode of a device contains all properties needed for
> -configuration of this device for data exchange with other device. In most
> -cases properties at the peer 'endpoint' nodes will be identical, however they
> -might need to be different when there is any signal modifications on the bus
> -between two devices, e.g. there are logic signal inverters on the lines.
> -
> -It is allowed for multiple endpoints at a port to be active simultaneously,
> -where supported by a device. For example, in case where a data interface of
> -a device is partitioned into multiple data busses, e.g. 16-bit input port
> -divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
> -and data-shift properties can be used to assign physical data lines to each
> -endpoint node (logical bus).
> -
> -Documenting bindings for devices
> ---------------------------------
> -
> -All required and optional bindings the device supports shall be explicitly
> -documented in device DT binding documentation. This also includes port and
> -endpoint nodes for the device, including unit-addresses and reg properties where
> -relevant.
> -
> -Please also see Documentation/devicetree/bindings/graph.txt .
> -
> -Required properties
> --------------------
> -
> -If there is more than one 'port' or more than one 'endpoint' node or 'reg'
> -property is present in port and/or endpoint nodes the following properties
> -are required in a relevant parent node:
> -
> - - #address-cells : number of cells required to define port/endpoint
> - identifier, should be 1.
> - - #size-cells : should be zero.
> -
> -
> -Optional properties
> --------------------
> -
> -- flash-leds: An array of phandles, each referring to a flash LED, a sub-node
> - of the LED driver device node.
> -
> -- lens-focus: A phandle to the node of the focus lens controller.
> -
> -- rotation: The camera rotation is expressed as the angular difference in
> - degrees between two reference systems, one relative to the camera module, and
> - one defined on the external world scene to be captured when projected on the
> - image sensor pixel array.
> -
> - A camera sensor has a 2-dimensional reference system 'Rc' defined by
> - its pixel array read-out order. The origin is set to the first pixel
> - being read out, the X-axis points along the column read-out direction
> - towards the last columns, and the Y-axis along the row read-out
> - direction towards the last row.
> -
> - A typical example for a sensor with a 2592x1944 pixel array matrix
> - observed from the front is:
> -
> - 2591 X-axis 0
> - <------------------------+ 0
> - .......... ... ..........!
> - .......... ... ..........! Y-axis
> - ... !
> - .......... ... ..........!
> - .......... ... ..........! 1943
> - V
> -
> - The external world scene reference system 'Rs' is a 2-dimensional
> - reference system on the focal plane of the camera module. The origin is
> - placed on the top-left corner of the visible scene, the X-axis points
> - towards the right, and the Y-axis points towards the bottom of the
> - scene. The top, bottom, left and right directions are intentionally not
> - defined and depend on the environment in which the camera is used.
> -
> - A typical example of a (very common) picture of a shark swimming from
> - left to right, as seen from the camera, is:
> -
> - 0 X-axis
> - 0 +------------------------------------->
> - !
> - !
> - !
> - ! |\____)\___
> - ! ) _____ __`<
> - ! |/ )/
> - !
> - !
> - !
> - V
> - Y-axis
> -
> - with the reference system 'Rs' placed on the camera focal plane:
> -
> - ¸.·˙!
> - ¸.·˙ !
> - _ ¸.·˙ !
> - +-/ \-+¸.·˙ !
> - | (o) | ! Camera focal plane
> - +-----+˙·.¸ !
> - ˙·.¸ !
> - ˙·.¸ !
> - ˙·.¸!
> -
> - When projected on the sensor's pixel array, the image and the associated
> - reference system 'Rs' are typically (but not always) inverted, due to
> - the camera module's lens optical inversion effect.
> -
> - Assuming the above represented scene of the swimming shark, the lens
> - inversion projects the scene and its reference system onto the sensor
> - pixel array, seen from the front of the camera sensor, as follows:
> -
> - Y-axis
> - ^
> - !
> - !
> - !
> - ! |\_____)\__
> - ! ) ____ ___.<
> - ! |/ )/
> - !
> - !
> - !
> - 0 +------------------------------------->
> - 0 X-axis
> -
> - Note the shark being upside-down.
> -
> - The resulting projected reference system is named 'Rp'.
> -
> - The camera rotation property is then defined as the angular difference
> - in the counter-clockwise direction between the camera reference system
> - 'Rc' and the projected scene reference system 'Rp'. It is expressed in
> - degrees as a number in the range [0, 360[.
> -
> - Examples
> -
> - 0 degrees camera rotation:
> -
> -
> - Y-Rp
> - ^
> - Y-Rc !
> - ^ !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! 0 +------------------------------------->
> - ! 0 X-Rp
> - 0 +------------------------------------->
> - 0 X-Rc
> -
> -
> - X-Rc 0
> - <------------------------------------+ 0
> - X-Rp 0 !
> - <------------------------------------+ 0 !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! V
> - ! Y-Rc
> - V
> - Y-Rp
> -
> - 90 degrees camera rotation:
> -
> - 0 Y-Rc
> - 0 +-------------------->
> - ! Y-Rp
> - ! ^
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! 0 +------------------------------------->
> - ! 0 X-Rp
> - !
> - !
> - !
> - !
> - V
> - X-Rc
> -
> - 180 degrees camera rotation:
> -
> - 0
> - <------------------------------------+ 0
> - X-Rc !
> - Y-Rp !
> - ^ !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! V
> - ! Y-Rc
> - 0 +------------------------------------->
> - 0 X-Rp
> -
> - 270 degrees camera rotation:
> -
> - 0 Y-Rc
> - 0 +-------------------->
> - ! 0
> - ! <-----------------------------------+ 0
> - ! X-Rp !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! !
> - ! V
> - ! Y-Rp
> - !
> - !
> - !
> - !
> - V
> - X-Rc
> -
> -
> - Example one - Webcam
> -
> - A camera module installed on the user facing part of a laptop screen
> - casing used for video calls. The captured images are meant to be
> - displayed in landscape mode (width > height) on the laptop screen.
> -
> - The camera is typically mounted upside-down to compensate the lens
> - optical inversion effect:
> -
> - Y-Rp
> - Y-Rc ^
> - ^ !
> - ! !
> - ! ! |\_____)\__
> - ! ! ) ____ ___.<
> - ! ! |/ )/
> - ! !
> - ! !
> - ! !
> - ! 0 +------------------------------------->
> - ! 0 X-Rp
> - 0 +------------------------------------->
> - 0 X-Rc
> -
> - The two reference systems are aligned, the resulting camera rotation is
> - 0 degrees, no rotation correction needs to be applied to the resulting
> - image once captured to memory buffers to correctly display it to users:
> -
> - +--------------------------------------+
> - ! !
> - ! !
> - ! !
> - ! |\____)\___ !
> - ! ) _____ __`< !
> - ! |/ )/ !
> - ! !
> - ! !
> - ! !
> - +--------------------------------------+
> -
> - If the camera sensor is not mounted upside-down to compensate for the
> - lens optical inversion, the two reference systems will not be aligned,
> - with 'Rp' being rotated 180 degrees relatively to 'Rc':
> -
> -
> - X-Rc 0
> - <------------------------------------+ 0
> - !
> - Y-Rp !
> - ^ !
> - ! !
> - ! |\_____)\__ !
> - ! ) ____ ___.< !
> - ! |/ )/ !
> - ! !
> - ! !
> - ! V
> - ! Y-Rc
> - 0 +------------------------------------->
> - 0 X-Rp
> -
> - The image once captured to memory will then be rotated by 180 degrees:
> -
> - +--------------------------------------+
> - ! !
> - ! !
> - ! !
> - ! __/(_____/| !
> - ! >.___ ____ ( !
> - ! \( \| !
> - ! !
> - ! !
> - ! !
> - +--------------------------------------+
> -
> - A software rotation correction of 180 degrees should be applied to
> - correctly display the image:
> -
> - +--------------------------------------+
> - ! !
> - ! !
> - ! !
> - ! |\____)\___ !
> - ! ) _____ __`< !
> - ! |/ )/ !
> - ! !
> - ! !
> - ! !
> - +--------------------------------------+
> -
> - Example two - Phone camera
> -
> - A camera installed on the back side of a mobile device facing away from
> - the user. The captured images are meant to be displayed in portrait mode
> - (height > width) to match the device screen orientation and the device
> - usage orientation used when taking the picture.
> -
> - The camera sensor is typically mounted with its pixel array longer side
> - aligned to the device longer side, upside-down mounted to compensate for
> - the lens optical inversion effect:
> -
> - 0 Y-Rc
> - 0 +-------------------->
> - ! Y-Rp
> - ! ^
> - ! !
> - ! !
> - ! !
> - ! ! |\_____)\__
> - ! ! ) ____ ___.<
> - ! ! |/ )/
> - ! !
> - ! !
> - ! !
> - ! 0 +------------------------------------->
> - ! 0 X-Rp
> - !
> - !
> - !
> - !
> - V
> - X-Rc
> -
> - The two reference systems are not aligned and the 'Rp' reference
> - system is rotated by 90 degrees in the counter-clockwise direction
> - relatively to the 'Rc' reference system.
> -
> - The image once captured to memory will be rotated:
> -
> - +-------------------------------------+
> - | _ _ |
> - | \ / |
> - | | | |
> - | | | |
> - | | > |
> - | < | |
> - | | | |
> - | . |
> - | V |
> - +-------------------------------------+
> -
> - A correction of 90 degrees in counter-clockwise direction has to be
> - applied to correctly display the image in portrait mode on the device
> - screen:
> -
> - +--------------------+
> - | |
> - | |
> - | |
> - | |
> - | |
> - | |
> - | |\____)\___ |
> - | ) _____ __`< |
> - | |/ )/ |
> - | |
> - | |
> - | |
> - | |
> - | |
> - +--------------------+
> -
> -- orientation: The orientation of a device (typically an image sensor or a flash
> - LED) describing its mounting position relative to the usage orientation of the
> - system where the device is installed on.
> - Possible values are:
> - 0 - Front. The device is mounted on the front facing side of the system.
> - For mobile devices such as smartphones, tablets and laptops the front side is
> - the user facing side.
> - 1 - Back. The device is mounted on the back side of the system, which is
> - defined as the opposite side of the front facing one.
> - 2 - External. The device is not attached directly to the system but is
> - attached in a way that allows it to move freely.
> -
> -Optional endpoint properties
> -----------------------------
> -
> -- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
> -- slave-mode: a boolean property indicating that the link is run in slave mode.
> - The default when this property is not specified is master mode. In the slave
> - mode horizontal and vertical synchronization signals are provided to the
> - slave device (data source) by the master device (data sink). In the master
> - mode the data source device is also the source of the synchronization signals.
> -- bus-type: data bus type. Possible values are:
> - 1 - MIPI CSI-2 C-PHY
> - 2 - MIPI CSI1
> - 3 - CCP2
> - 4 - MIPI CSI-2 D-PHY
> - 5 - Parallel
> - 6 - Bt.656
> -- bus-width: number of data lines actively used, valid for the parallel busses.
> -- data-shift: on the parallel data busses, if bus-width is used to specify the
> - number of data lines, data-shift can be used to specify which data lines are
> - used, e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
> -- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
> -- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively.
> - Note, that if HSYNC and VSYNC polarities are not specified, embedded
> - synchronization may be required, where supported.
> -- data-active: similar to HSYNC and VSYNC, specifies data line polarity.
> -- data-enable-active: similar to HSYNC and VSYNC, specifies the data enable
> - signal polarity.
> -- field-even-active: field signal level during the even field data transmission.
> -- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
> - signal.
> -- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for
> - LOW/HIGH respectively.
> -- data-lanes: an array of physical data lane indexes. Position of an entry
> - determines the logical lane number, while the value of an entry indicates
> - physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have
> - "data-lanes = <1 2>;", assuming the clock lane is on hardware lane 0.
> - If the hardware does not support lane reordering, monotonically
> - incremented values shall be used from 0 or 1 onwards, depending on
> - whether or not there is also a clock lane. This property is valid for
> - serial busses only (e.g. MIPI CSI-2).
> -- clock-lanes: an array of physical clock lane indexes. Position of an entry
> - determines the logical lane number, while the value of an entry indicates
> - physical lane, e.g. for a MIPI CSI-2 bus we could have "clock-lanes = <0>;",
> - which places the clock lane on hardware lane 0. This property is valid for
> - serial busses only (e.g. MIPI CSI-2). Note that for the MIPI CSI-2 bus this
> - array contains only one entry.
> -- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
> - clock mode.
> -- link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for
> - instance, this is the actual frequency of the bus, not bits per clock per
> - lane value. An array of 64-bit unsigned integers.
> -- lane-polarities: an array of polarities of the lanes starting from the clock
> - lane and followed by the data lanes in the same order as in data-lanes.
> - Valid values are 0 (normal) and 1 (inverted). The length of the array
> - should be the combined length of data-lanes and clock-lanes properties.
> - If the lane-polarities property is omitted, the value must be interpreted
> - as 0 (normal). This property is valid for serial busses only.
> -- strobe: Whether the clock signal is used as clock (0) or strobe (1). Used
> - with CCP2, for instance.
> -
> -Example
> --------
> -
> -The example snippet below describes two data pipelines. ov772x and imx074 are
> -camera sensors with a parallel and serial (MIPI CSI-2) video bus respectively.
> -Both sensors are on the I2C control bus corresponding to the i2c0 controller
> -node. ov772x sensor is linked directly to the ceu0 video host interface.
> -imx074 is linked to ceu0 through the MIPI CSI-2 receiver (csi2). ceu0 has a
> -(single) DMA engine writing captured data to memory. ceu0 node has a single
> -'port' node which may indicate that at any time only one of the following data
> -pipelines can be active: ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
> -
> - ceu0: ceu@fe910000 {
> - compatible = "renesas,sh-mobile-ceu";
> - reg = <0xfe910000 0xa0>;
> - interrupts = <0x880>;
> -
> - mclk: master_clock {
> - compatible = "renesas,ceu-clock";
> - #clock-cells = <1>;
> - clock-frequency = <50000000>; /* Max clock frequency */
> - clock-output-names = "mclk";
> - };
> -
> - port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - /* Parallel bus endpoint */
> - ceu0_1: endpoint@1 {
> - reg = <1>; /* Local endpoint # */
> - remote = <&ov772x_1_1>; /* Remote phandle */
> - bus-width = <8>; /* Used data lines */
> - data-shift = <2>; /* Lines 9:2 are used */
> -
> - /* If hsync-active/vsync-active are missing,
> - embedded BT.656 sync is used */
> - hsync-active = <0>; /* Active low */
> - vsync-active = <0>; /* Active low */
> - data-active = <1>; /* Active high */
> - pclk-sample = <1>; /* Rising */
> - };
> -
> - /* MIPI CSI-2 bus endpoint */
> - ceu0_0: endpoint@0 {
> - reg = <0>;
> - remote = <&csi2_2>;
> - };
> - };
> - };
> -
> - i2c0: i2c@fff20000 {
> - ...
> - ov772x_1: camera@21 {
> - compatible = "ovti,ov772x";
> - reg = <0x21>;
> - vddio-supply = <®ulator1>;
> - vddcore-supply = <®ulator2>;
> -
> - clock-frequency = <20000000>;
> - clocks = <&mclk 0>;
> - clock-names = "xclk";
> -
> - port {
> - /* With 1 endpoint per port no need for addresses. */
> - ov772x_1_1: endpoint {
> - bus-width = <8>;
> - remote-endpoint = <&ceu0_1>;
> - hsync-active = <1>;
> - vsync-active = <0>; /* Who came up with an
> - inverter here ?... */
> - data-active = <1>;
> - pclk-sample = <1>;
> - };
> - };
> - };
> -
> - imx074: camera@1a {
> - compatible = "sony,imx074";
> - reg = <0x1a>;
> - vddio-supply = <®ulator1>;
> - vddcore-supply = <®ulator2>;
> -
> - clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
> - clocks = <&mclk 0>;
> - clock-names = "sysclk"; /* Assuming this is the
> - name in the datasheet */
> - port {
> - imx074_1: endpoint {
> - clock-lanes = <0>;
> - data-lanes = <1 2>;
> - remote-endpoint = <&csi2_1>;
> - };
> - };
> - };
> - };
> -
> - csi2: csi2@ffc90000 {
> - compatible = "renesas,sh-mobile-csi2";
> - reg = <0xffc90000 0x1000>;
> - interrupts = <0x17a0>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@1 {
> - compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
> - reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
> - PHY_M has port address 0,
> - is unused. */
> - csi2_1: endpoint {
> - clock-lanes = <0>;
> - data-lanes = <2 1>;
> - remote-endpoint = <&imx074_1>;
> - };
> - };
> - port@2 {
> - reg = <2>; /* port 2: link to the CEU */
> -
> - csi2_2: endpoint {
> - remote-endpoint = <&ceu0_0>;
> - };
> - };
> - };
> +This file has moved to video-interfaces.yaml and video-interface-devices.yaml.
> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml
> new file mode 100644
> index 000000000000..0a7a73fd59f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml
> @@ -0,0 +1,344 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/video-interfaces.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common bindings for video receiver and transmitter interface endpoints
> +
> +maintainers:
> + - Sakari Ailus <sakari.ailus@linux.intel.com>
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + Video data pipelines usually consist of external devices, e.g. camera sensors,
> + controlled over an I2C, SPI or UART bus, and SoC internal IP blocks, including
> + video DMA engines and video data processors.
> +
> + SoC internal blocks are described by DT nodes, placed similarly to other SoC
> + blocks. External devices are represented as child nodes of their respective
> + bus controller nodes, e.g. I2C.
> +
> + Data interfaces on all video devices are described by their child 'port' nodes.
> + Configuration of a port depends on other devices participating in the data
> + transfer and is described by 'endpoint' subnodes.
> +
> + device {
> + ...
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + ...
> + endpoint@0 { ... };
> + endpoint@1 { ... };
> + };
> + port@1 { ... };
> + };
> + };
> +
> + If a port can be configured to work with more than one remote device on the same
> + bus, an 'endpoint' child node must be provided for each of them. If more than
> + one port is present in a device node or there is more than one endpoint at a
> + port, or port node needs to be associated with a selected hardware interface,
> + a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
> + used.
> +
> + All 'port' nodes can be grouped under optional 'ports' node, which allows to
> + specify #address-cells, #size-cells properties independently for the 'port'
> + and 'endpoint' nodes and any child device nodes a device might have.
> +
> + Two 'endpoint' nodes are linked with each other through their 'remote-endpoint'
> + phandles. An endpoint subnode of a device contains all properties needed for
> + configuration of this device for data exchange with other device. In most
> + cases properties at the peer 'endpoint' nodes will be identical, however they
> + might need to be different when there is any signal modifications on the bus
> + between two devices, e.g. there are logic signal inverters on the lines.
> +
> + It is allowed for multiple endpoints at a port to be active simultaneously,
> + where supported by a device. For example, in case where a data interface of
> + a device is partitioned into multiple data busses, e.g. 16-bit input port
> + divided into two separate ITU-R BT.656 8-bit busses. In such case bus-width
> + and data-shift properties can be used to assign physical data lines to each
> + endpoint node (logical bus).
> +
> + Documenting bindings for devices
> + --------------------------------
> +
> + All required and optional bindings the device supports shall be explicitly
> + documented in device DT binding documentation. This also includes port and
> + endpoint nodes for the device, including unit-addresses and reg properties
> + where relevant.
> +
> +allOf:
> + - $ref: /schemas/graph.yaml#/$defs/endpoint-base
> +
> +properties:
> + slave-mode:
> + type: boolean
> + description:
> + Indicates that the link is run in slave mode. The default when this
> + property is not specified is master mode. In the slave mode horizontal and
> + vertical synchronization signals are provided to the slave device (data
> + source) by the master device (data sink). In the master mode the data
> + source device is also the source of the synchronization signals.
> +
> + bus-type:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum:
> + - 1 # MIPI CSI-2 C-PHY
> + - 2 # MIPI CSI1
> + - 3 # CCP2
> + - 4 # MIPI CSI-2 D-PHY
> + - 5 # Parallel
> + - 6 # BT.656
> + description:
> + Data bus type.
> +
> + bus-width:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 64
> + description:
> + Number of data lines actively used, valid for the parallel busses.
> +
> + data-shift:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 64
> + description:
> + On the parallel data busses, if bus-width is used to specify the number of
> + data lines, data-shift can be used to specify which data lines are used,
> + e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used.
> +
> + hsync-active:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Active state of the HSYNC signal, 0/1 for LOW/HIGH respectively.
> +
> + vsync-active:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. Note,
> + that if HSYNC and VSYNC polarities are not specified, embedded
> + synchronization may be required, where supported.
> +
> + data-active:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Similar to HSYNC and VSYNC, specifies data line polarity.
> +
> + data-enable-active:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Similar to HSYNC and VSYNC, specifies the data enable signal polarity.
> +
> + field-even-active:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Field signal level during the even field data transmission.
> +
> + pclk-sample:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Sample data on rising (1) or falling (0) edge of the pixel clock signal.
> +
> + sync-on-green-active:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively.
> +
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 8
> + items:
> + # Assume up to 9 physical lane indices
> + maximum: 8
> + description:
> + An array of physical data lane indexes. Position of an entry determines
> + the logical lane number, while the value of an entry indicates physical
> + lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;",
> + assuming the clock lane is on hardware lane 0. If the hardware does not
> + support lane reordering, monotonically incremented values shall be used
> + from 0 or 1 onwards, depending on whether or not there is also a clock
> + lane. This property is valid for serial busses only (e.g. MIPI CSI-2).
> +
> + clock-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + # Assume up to 9 physical lane indices
> + maximum: 8
> + description:
> + Physical clock lane index. Position of an entry determines the logical
> + lane number, while the value of an entry indicates physical lane, e.g. for
> + a MIPI CSI-2 bus we could have "clock-lanes = <0>;", which places the
> + clock lane on hardware lane 0. This property is valid for serial busses
> + only (e.g. MIPI CSI-2).
> +
> + clock-noncontinuous:
> + type: boolean
> + description:
> + Allow MIPI CSI-2 non-continuous clock mode.
> +
> + link-frequencies:
> + $ref: /schemas/types.yaml#/definitions/uint64-array
> + description:
> + Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the
> + actual frequency of the bus, not bits per clock per lane value. An array
> + of 64-bit unsigned integers.
> +
> + lane-polarities:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 9
> + items:
> + enum: [ 0, 1 ]
> + description:
> + An array of polarities of the lanes starting from the clock lane and
> + followed by the data lanes in the same order as in data-lanes. Valid
> + values are 0 (normal) and 1 (inverted). The length of the array should be
> + the combined length of data-lanes and clock-lanes properties. If the
> + lane-polarities property is omitted, the value must be interpreted as 0
> + (normal). This property is valid for serial busses only.
> +
> + strobe:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 0, 1 ]
> + description:
> + Whether the clock signal is used as clock (0) or strobe (1). Used with
> + CCP2, for instance.
> +
> +additionalProperties: true
> +
> +examples:
> + # The example snippet below describes two data pipelines. ov772x and imx074
> + # are camera sensors with a parallel and serial (MIPI CSI-2) video bus
> + # respectively. Both sensors are on the I2C control bus corresponding to the
> + # i2c0 controller node. ov772x sensor is linked directly to the ceu0 video
> + # host interface. imx074 is linked to ceu0 through the MIPI CSI-2 receiver
> + # (csi2). ceu0 has a (single) DMA engine writing captured data to memory.
> + # ceu0 node has a single 'port' node which may indicate that at any time
> + # only one of the following data pipelines can be active:
> + # ov772x -> ceu0 or imx074 -> csi2 -> ceu0.
> + - |
> + ceu@fe910000 {
> + compatible = "renesas,sh-mobile-ceu";
> + reg = <0xfe910000 0xa0>;
> + interrupts = <0x880>;
> +
> + mclk: master_clock {
> + compatible = "renesas,ceu-clock";
> + #clock-cells = <1>;
> + clock-frequency = <50000000>; /* Max clock frequency */
> + clock-output-names = "mclk";
> + };
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Parallel bus endpoint */
> + ceu0_1: endpoint@1 {
> + reg = <1>; /* Local endpoint # */
> + remote-endpoint = <&ov772x_1_1>; /* Remote phandle */
> + bus-width = <8>; /* Used data lines */
> + data-shift = <2>; /* Lines 9:2 are used */
> +
> + /* If hsync-active/vsync-active are missing,
> + embedded BT.656 sync is used */
> + hsync-active = <0>; /* Active low */
> + vsync-active = <0>; /* Active low */
> + data-active = <1>; /* Active high */
> + pclk-sample = <1>; /* Rising */
> + };
> +
> + /* MIPI CSI-2 bus endpoint */
> + ceu0_0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&csi2_2>;
> + };
> + };
> + };
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@21 {
> + compatible = "ovti,ov772x";
> + reg = <0x21>;
> + vddio-supply = <®ulator1>;
> + vddcore-supply = <®ulator2>;
> +
> + clock-frequency = <20000000>;
> + clocks = <&mclk 0>;
> + clock-names = "xclk";
> +
> + port {
> + /* With 1 endpoint per port no need for addresses. */
> + ov772x_1_1: endpoint {
> + bus-width = <8>;
> + remote-endpoint = <&ceu0_1>;
> + hsync-active = <1>;
> + vsync-active = <0>; /* Who came up with an
> + inverter here ?... */
> + data-active = <1>;
> + pclk-sample = <1>;
> + };
> + };
> + };
> +
> + camera@1a {
> + compatible = "sony,imx074";
> + reg = <0x1a>;
> + vddio-supply = <®ulator1>;
> + vddcore-supply = <®ulator2>;
> +
> + clock-frequency = <30000000>; /* Shared clock with ov772x_1 */
> + clocks = <&mclk 0>;
> + clock-names = "sysclk"; /* Assuming this is the
> + name in the datasheet */
> + port {
> + imx074_1: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1 2>;
> + remote-endpoint = <&csi2_1>;
> + };
> + };
> + };
> + };
> +
> + csi2: csi2@ffc90000 {
> + compatible = "renesas,sh-mobile-csi2";
> + reg = <0xffc90000 0x1000>;
> + interrupts = <0x17a0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + compatible = "renesas,csi2c"; /* One of CSI2I and CSI2C. */
> + reg = <1>; /* CSI-2 PHY #1 of 2: PHY_S,
> + PHY_M has port address 0,
> + is unused. */
> + csi2_1: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <2 1>;
> + remote-endpoint = <&imx074_1>;
> + };
> + };
> + port@2 {
> + reg = <2>; /* port 2: link to the CEU */
> +
> + csi2_2: endpoint {
> + remote-endpoint = <&ceu0_0>;
> + };
> + };
> + };
> +
> +...
> --
> 2.27.0
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas
2021-01-22 16:23 ` Rob Herring
@ 2021-01-22 17:01 ` Sakari Ailus
2021-01-22 21:43 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 9+ messages in thread
From: Sakari Ailus @ 2021-01-22 17:01 UTC (permalink / raw)
To: Rob Herring
Cc: Mauro Carvalho Chehab, Laurent Pinchart, devicetree,
linux-kernel, Linux Media Mailing List, Hans Verkuil,
Laurent Pinchart, Guennadi Liakhovetski, Guennadi Liakhovetski,
Maxime Ripard, Jacopo Mondi
Hi Rob,
On Fri, Jan 22, 2021 at 10:23:44AM -0600, Rob Herring wrote:
> On Mon, Jan 4, 2021 at 10:58 AM Rob Herring <robh@kernel.org> wrote:
> >
> > Convert video-interfaces.txt to DT schema. As it contains a mixture of
> > device level and endpoint properties, split it up into 2 schemas.
>
> Ping!
>
> Can this please be applied to the media tree so I can tell folks to
> use it in reviews of media bindings.
Yes, it can. It's in my tree now.
--
Kind regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties to schemas
2021-01-22 17:01 ` Sakari Ailus
@ 2021-01-22 21:43 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 9+ messages in thread
From: Mauro Carvalho Chehab @ 2021-01-22 21:43 UTC (permalink / raw)
To: Rob Herring
Cc: Sakari Ailus, Laurent Pinchart, devicetree, linux-kernel,
Linux Media Mailing List, Hans Verkuil, Laurent Pinchart,
Guennadi Liakhovetski, Guennadi Liakhovetski, Maxime Ripard,
Jacopo Mondi
Em Fri, 22 Jan 2021 19:01:44 +0200
Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> Hi Rob,
>
> On Fri, Jan 22, 2021 at 10:23:44AM -0600, Rob Herring wrote:
> > On Mon, Jan 4, 2021 at 10:58 AM Rob Herring <robh@kernel.org> wrote:
> > >
> > > Convert video-interfaces.txt to DT schema. As it contains a mixture of
> > > device level and endpoint properties, split it up into 2 schemas.
> >
> > Ping!
> >
> > Can this please be applied to the media tree so I can tell folks to
> > use it in reviews of media bindings.
Just merged both patches.
> Yes, it can. It's in my tree now.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-01-22 21:44 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-04 16:58 [PATCH v4 0/2] dt-bindings: media: Convert video-interfaces.txt to schemas Rob Herring
2021-01-04 16:58 ` [PATCH v4 1/2] media: dt-bindings: Convert video-interfaces.txt properties " Rob Herring
2021-01-22 16:23 ` Rob Herring
2021-01-22 17:01 ` Sakari Ailus
2021-01-22 21:43 ` Mauro Carvalho Chehab
2021-01-04 16:58 ` [PATCH v4 2/2] dt-bindings: media: Use graph and video-interfaces schemas Rob Herring
2021-01-05 4:59 ` Laurent Pinchart
2021-01-05 8:59 ` Maxime Ripard
2021-01-05 9:09 ` Sakari Ailus
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.