Hi Andrzej, On Fri, 01 Sep 2017 08:28:13 +0200 Andrzej Hajda <a.hajda@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > --- > > 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. Regards, Boris -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
