Based on kernel version 6.11
. Page generated on 2024-09-24 08:21 EST
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 | # 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 Properties 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 - 7 # DPI 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, 2 ] description: Sample data on falling (0), rising (1) or both (2) edges 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 uniqueItems: true 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 |