On 12/07/2017 03:09 AM, Rob Herring wrote:
On Tue, Dec 05, 2017 at 04:03:55PM +0530, Archit Taneja wrote:
Add a section that describes dt-bindings for peripherals that support MIPI DSI, but have a different bus as the primary control bus. Add an example for such peripherals.
Signed-off-by: Archit Taneja architt@codeaurora.org
.../devicetree/bindings/display/mipi-dsi-bus.txt | 75 ++++++++++++++++++++-- 1 file changed, 68 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index 973c27273772..77a7cec15f5b 100644 --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt @@ -16,7 +16,7 @@ The following assumes that only a single peripheral is connected to a DSI host. Experience shows that this is true for the large majority of setups.
DSI host
+========
In addition to the standard properties and those defined by the parent bus of a DSI host, the following properties apply to a node representing a DSI host. @@ -30,11 +30,15 @@ Required properties: different value here. See below.
DSI peripheral
+==============
-Peripherals are represented as child nodes of the DSI host's node. Properties -described here apply to all DSI peripherals, but individual bindings may want -to define additional, device-specific properties. +Peripherals with DSI as control bus +------------------------------------
+Peripherals with the DSI bus as the primary control path are represented as +child nodes of the DSI host's node. Properties described here apply to all DSI +peripherals, but individual bindings may want to define additional, +device-specific properties.
Are there any panels with no control bus? I've never seen one, but it should be possible if LVDS panels can power on without commands.
DSI panels generally require sending at least a couple of DCS commands to be exit sleep mode and get powered on. I guess I can rewrite the above paragraph to include peripherals which have no control bus at all.
Required properties:
- reg: The virtual channel number of a DSI peripheral. Must be in the range
@@ -49,9 +53,25 @@ case two alternative representations can be chosen: property is the number of the first virtual channel and the second cell is the number of consecutive virtual channels.
-Example
+Peripherals with a different control bus +----------------------------------------
+There are peripherals that have I2C/SPI (or some other non-DSI bus) as the +primary control bus, but are also connected to a DSI bus (mostly for the data +path). Connections between such peripherals and a DSI host can be represented +using the graph bindings [1], [2].
+[1] Documentation/devicetree/bindings/graph.txt +[2] Documentation/devicetree/bindings/media/video-interfaces.txt
+Examples +======== +- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
- with different virtual channel configurations.
+- (4) is an example of a peripheral on a I2C control bus connected with to
- a DSI host using of-graph bindings.
+1) dsi-host { ...
@@ -67,6 +87,7 @@ Example ... };
+2) dsi-host { ...
@@ -82,6 +103,7 @@ Example ... };
+3) dsi-host { ...
@@ -96,3 +118,42 @@ Example
...};
+4)
- i2c-host {
...dsi-bridge@35 {compatible = "...";reg = <0x35>;ports {#address-cells = <1>;#size-cells = <0>;...port@0 {Drop unit-address and #*-cells.
bridge_mipi_in: endpoint {remote-endpoint = <&host_mipi_out>;};};};};- };
- dsi-host {
...ports {#address-cells = <1>;#size-cells = <0>;...port@0 {Drop unit-address and #*-cells.
Thanks, I'll fix these and the similar comments in the second patch.
Archit