On 01.09.2017 09:06, Boris Brezillon wrote:
Hi Andrzej,
On Fri, 01 Sep 2017 08:28:13 +0200 Andrzej Hajda a.hajda@samsung.com wrote:
On 31.08.2017 17:55, Boris Brezillon wrote:
Document the bindings used for the Cadence DSI bridge.
Signed-off-by: Boris Brezillon boris.brezillon@free-electrons.com
Changes in v3:
- Fix clock names in the example
- Document how to represent DSI devices that are controller through an external bus like I2C or SPI
Changes in v2:
- None
.../bindings/display/bridge/cdns,dsi.txt | 109 +++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt new file mode 100644 index 000000000000..c70008bd8c0d --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt @@ -0,0 +1,109 @@ +Cadence DSI bridge +==================
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+Required properties: +- compatible: should be set to "cdns,dsi-1.3.1". +- reg: physical base address and length of the controller's registers. +- interrupts: interrupt line connected to the DSI bridge. +- clocks: DSI bridge clocks. +- clock-names: must contain "pclk" and "sysclk". +- phys: phandle link to the MIPI D-PHY controller. +- phy-names: must contain "dphy". +- #address-cells: must be set to 1. +- #size-cells: must be set to 0.
+Required subnodes: +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
- 2 ports are available:
- port 0: this port is only needed if some of your DSI devices are
controlled through an external bus like I2C or SPI. Can have at
most 4 endpoints. The endpoint number is directly encoding the
DSI virtual channel used by this device.
- port 1: represents the DPI input.
- Other ports will be added later to support the new kind of inputs.
I think usual practice is to use lower numbers for input ports, higher for output ports. Is there a reason to do it this way?
The main reason I did that is because we only have one output port and can have 1, 2 or 3 input ports: one is the DPI and the 2 others are called SDI (some kind of serial input). I thought it would be better to have all inputs using contiguous port numbers, and if we put inputs first that means having a hole between the input and output port (port 0 would be the DPI input and port 3 the DSI output).
Honestly, that's just a detail, so if you prefer to have the input ports start at 0 I'm fine with that.
No serious preferences, just curiosity. In fact port numbering schema is private thing of the device node.
Regards Andrzej
Regards,
Boris