|
| 1 | +# Copyright 2024 NXP |
| 2 | +# SPDX-License-Identifier: Apache-2.0 |
| 3 | + |
| 4 | +# Common properties for video interface endpoints. |
| 5 | + |
| 6 | +description: | |
| 7 | + A video pipeline usually consists of several devices, e.g. camera sensors, video |
| 8 | + data receivers, video data processors, etc. Data interfaces on these devices are |
| 9 | + described by their child 'port' nodes. Configuration of a port depends on other |
| 10 | + devices in the pipeline and is described by 'endpoint' subnodes. |
| 11 | +
|
| 12 | + If a port can be configured to work with more than one remote device on the same |
| 13 | + bus, an 'endpoint' child node must be provided for each of them. If more than one |
| 14 | + port is present in a device node or there is more than one endpoint at a port, or |
| 15 | + port node needs to be associated with a selected hardware interface, a common |
| 16 | + scheme using '#address-cells', '#size-cells' and 'reg' properties is used. |
| 17 | +
|
| 18 | + All 'port' nodes can be grouped under an optional 'ports' node, which allows to |
| 19 | + specify #address-cells, #size-cells properties independently for the 'port' and |
| 20 | + 'endpoint' nodes. For example: |
| 21 | +
|
| 22 | + video_device { |
| 23 | + ... |
| 24 | + ports { |
| 25 | + #address-cells = <1>; |
| 26 | + #size-cells = <0>; |
| 27 | +
|
| 28 | + port@0 { |
| 29 | + ... |
| 30 | + endpoint@0 { ... }; |
| 31 | + endpoint@1 { ... }; |
| 32 | + }; |
| 33 | + port@1 { ... }; |
| 34 | + }; |
| 35 | + }; |
| 36 | +
|
| 37 | + Two 'endpoint' nodes must be linked with each other via their 'remote-endpoint' |
| 38 | + phandles. However, Zephyr does not allow circular dependency, so direct phandle |
| 39 | + references are currently not possible. A 'remote-endpoint-label' string is used |
| 40 | + instead to be able to specify, at least, the label of the peer remote-endpoint. |
| 41 | + For example: |
| 42 | +
|
| 43 | + source: endpoint { |
| 44 | + compatible = "zephyr,video-interfaces"; |
| 45 | + remote-endpoint-label = "sink"; |
| 46 | + }; |
| 47 | +
|
| 48 | + sink: endpoint{ |
| 49 | + compatible = "zephyr,video-interfaces"; |
| 50 | + remote-endpoint-label = "source"; |
| 51 | + }; |
| 52 | +
|
| 53 | + This binding contains the most common properties needed to configure an endpoint |
| 54 | + subnode for data exchange with other device. In most cases, properties at the |
| 55 | + peer 'endpoint' node will be identical, however they might be different when |
| 56 | + there is any signal modifications on the bus between two devices, e.g. there are |
| 57 | + logic signal inverters on the lines. |
| 58 | +
|
| 59 | +properties: |
| 60 | + remote-endpoint-label: |
| 61 | + required: true |
| 62 | + type: string |
| 63 | + description: | |
| 64 | + Label of the 'remote-endpoint' subnode that interfaces with this endpoint. |
| 65 | + This property is used as a 'work-around' to be able to declare the remote |
| 66 | + endpoint and should be replaced by a "remote-endpoint" phandle property when |
| 67 | + Zephyr devicetree supports circular dependency in the future. |
| 68 | +
|
| 69 | + bus-type: |
| 70 | + type: int |
| 71 | + enum: |
| 72 | + - 1 # MIPI CSI-2 C-PHY |
| 73 | + - 2 # MIPI CSI1 |
| 74 | + - 3 # CCP2 |
| 75 | + - 4 # MIPI CSI-2 D-PHY |
| 76 | + - 5 # Parallel |
| 77 | + - 6 # BT.656 |
| 78 | + description: | |
| 79 | + Data bus type. |
| 80 | +
|
| 81 | + data-shift: |
| 82 | + type: int |
| 83 | + description: | |
| 84 | + On parallel data busses, if bus-width is used to specify the number of |
| 85 | + data lines, data-shift can be used to specify which data lines are used, |
| 86 | + e.g. "bus-width=<8>; data-shift=<2>;" means, that lines 9:2 are used. |
| 87 | +
|
| 88 | + hsync-active: |
| 89 | + type: int |
| 90 | + enum: |
| 91 | + - 0 # low |
| 92 | + - 1 # high |
| 93 | + description: | |
| 94 | + Active state of the HSYNC signal |
| 95 | +
|
| 96 | + vsync-active: |
| 97 | + type: int |
| 98 | + enum: |
| 99 | + - 0 # low |
| 100 | + - 1 # high |
| 101 | + description: | |
| 102 | + Active state of the VSYNC signal. |
| 103 | +
|
| 104 | + pclk-sample: |
| 105 | + type: int |
| 106 | + enum: |
| 107 | + - 0 # falling |
| 108 | + - 1 # rising |
| 109 | + - 2 # both |
| 110 | + description: | |
| 111 | + Sample data on falling, rising or both edges of the pixel clock signal. |
| 112 | +
|
| 113 | + link-frequencies: |
| 114 | + type: array |
| 115 | + description: | |
| 116 | + Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the |
| 117 | + actual frequency of the bus, not bits per clock per lane value. |
| 118 | +
|
| 119 | +# For serial bus only |
| 120 | + clock-lane: |
| 121 | + type: int |
| 122 | + description: | |
| 123 | + Physical clock lane index. Position of an entry determines the logical |
| 124 | + lane number, while the value of an entry indicates physical lane, e.g. for |
| 125 | + a MIPI CSI-2 bus we could have "clock-lane = <0>;", which places the |
| 126 | + clock lane on hardware lane 0. This property is valid for serial busses |
| 127 | + only (e.g. MIPI CSI-2). |
| 128 | +
|
| 129 | + data-lanes: |
| 130 | + type: array |
| 131 | + description: | |
| 132 | + An array of physical data lane indexes. Position of an entry determines |
| 133 | + the logical lane number, while the value of an entry indicates physical |
| 134 | + lane, e.g. for 2-lane MIPI CSI-2 bus we could have "data-lanes = <1 2>;", |
| 135 | + assuming the clock lane is on hardware lane 0. If the hardware does not |
| 136 | + support lane reordering, monotonically incremented values shall be used |
| 137 | + from 0 or 1 onwards, depending on whether or not there is also a clock |
| 138 | + lane. This property is valid for serial busses only (e.g. MIPI CSI-2). |
| 139 | +
|
| 140 | +# For parallel bus only |
| 141 | + bus-width: |
| 142 | + type: int |
| 143 | + description: | |
| 144 | + Number of data lines actively used, only valid for parallel busses. |
0 commit comments