[PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Archit Taneja]

Hi,

On 06/02/2017 05:34 PM, Boris Brezillon wrote:
> Document the bindings used for the Cadence DSI bridge.
>
> Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
> ---
>  .../bindings/display/bridge/cdns,dsi.txt           | 55 ++++++++++++++++++++++
>  1 file changed, 55 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..770c5c5b1e93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> @@ -0,0 +1,55 @@
> +Cadence DSI bridge
> +==================
> +
> +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.

Is this a separate chip, or an IP integrated into SoCs? If it's the 
latter, I don't think DPI on the its input side is the right term to 
use. Maybe RGB would be more appropriate here.

> +
> +Required properties:
> +- compatible: should be set to "cdns,dsi".

Would it be better to take a dw-hdmi like approach here? I.e, the
binding should be specific to the SoC that integrates this DSI
bridge?

> +- 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.
> +  Currently contains a single input port at address 0 representing the DPI
> +  input. Other ports will be added later to support the SDI inputs.
> +  Port 0 should be connected to a DPI encoder output.

The output of the DSI bridge may be another bridge, which could be i2c
controlled. In that case, it won't be a child of the DSI bridge. For
such scenarios, we might want to define an output port for the bridge.

Thanks,
Archit

> +- one subnode per DSI device connected on the DSI bus. Each DSI device should
> +  contain a reg property encoding its address on the bus.
> +
> +Example:
> +
> +	dsi0: dsi at fd0c0000 {
> +		compatible = "cdns,dsi";
> +		reg = <0x0 0xfd0c0000 0x0 0x1000>;
> +		clocks = <&pclk>, <&sysclk>;
> +		clock-names = "pclk", "hclk";
> +		interrupts = <1>;
> +		phys = <&dphy1>;
> +		phy-names = "dphy";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				dsi0_dpi_input: endpoint {
> +					remote-endpoint = <&xxx_dpi_output>;
> +				};
> +			};
> +		};
> +
> +		panel: dsi-dev at 0 {
> +			compatible = "<vendor,panel>";
> +			reg = <0>;
> +		};
> +	};
> +
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project