Merge branch 'imx-drm-staging' of git://ftp.arm.linux.org.uk/~rmk/linux-arm into staging-next

Common bindings for device graphs

General concept

---------------

The hierarchical organisation of the device tree is well suited to describe

control flow to devices, but there can be more complex connections between

devices that work together to form a logical compound device, following an

arbitrarily complex graph.

There already is a simple directed graph between devices tree nodes using

phandle properties pointing to other nodes to describe connections that

can not be inferred from device tree parent-child relationships. The device

tree graph bindings described herein abstract more complex devices that can

have multiple specifiable ports, each of which can be linked to one or more

ports of other devices.

These common bindings do not contain any information about the direction or

type of the connections, they just map their existence. Specific properties

may be described by specialized bindings depending on the type of connection.

To see how this binding applies to video pipelines, for example, see

Documentation/device-tree/bindings/media/video-interfaces.txt.

Here the ports describe data interfaces, and the links between them are

the connecting data buses. A single port with multiple connections can

correspond to multiple devices being connected to the same physical bus.

Organisation of ports and endpoints

-----------------------------------

Ports are described by child 'port' nodes contained in the device node.

Each port node contains an 'endpoint' subnode for each remote device port

connected to this port. If a single port is connected to more than one

remote device, an 'endpoint' child node must be provided for each link.

If more than one port is present in a device node or there is more than one

endpoint at a port, or a port node needs to be associated with a selected

hardware interface, a common scheme using '#address-cells', '#size-cells'

and 'reg' properties is used number the nodes.

device {

        ...

        #address-cells = <1>;

        #size-cells = <0>;

        port@0 {

	        #address-cells = <1>;

	        #size-cells = <0>;

		reg = <0>;

                endpoint@0 {

			reg = <0>;

			...

		};

                endpoint@1 {

			reg = <1>;

			...

		};

        };

        port@1 {

		reg = <1>;

		endpoint { ... };

	};

};

All 'port' nodes can be grouped under an optional 'ports' node, which

allows to specify #address-cells, #size-cells properties for the 'port'

nodes independently from any other child device nodes a device might

have.

device {

        ...

        ports {

                #address-cells = <1>;

                #size-cells = <0>;

                port@0 {

                        ...

                        endpoint@0 { ... };

                        endpoint@1 { ... };

                };

                port@1 { ... };

        };

};

Links between endpoints

-----------------------

Each endpoint should contain a 'remote-endpoint' phandle property that points

to the corresponding endpoint in the port of the remote device. In turn, the

remote endpoint should contain a 'remote-endpoint' property. If it has one,

it must not point to another than the local endpoint. Two endpoints with their

'remote-endpoint' phandles pointing at each other form a link between the

containing ports.

device-1 {

        port {

                device_1_output: endpoint {

                        remote-endpoint = <&device_2_input>;

                };

        };

};

device-2 {

        port {

                device_2_input: endpoint {

                        remote-endpoint = <&device_1_output>;

                };

        };

};

Required properties

-------------------

If there is more than one 'port' or more than one 'endpoint' node or 'reg'

property is present in port and/or endpoint nodes the following properties

are required in a relevant parent node:

 - #address-cells : number of cells required to define port/endpoint

                    identifier, should be 1.

 - #size-cells    : should be zero.

Optional endpoint properties

----------------------------

- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.

Freescale i.MX DRM master device

================================

The freescale i.MX DRM master device is a virtual device needed to list all

IPU or other display interface nodes that comprise the graphics subsystem.

Required properties:

- compatible: Should be "fsl,imx-display-subsystem"

- ports: Should contain a list of phandles pointing to display interface ports

  of IPU devices

example:

display-subsystem {

	compatible = "fsl,display-subsystem";

	ports = <&ipu_di0>;

};

Freescale i.MX IPUv3

====================

  datasheet

- interrupts: Should contain sync interrupt and error interrupt,

  in this order.

- #crtc-cells: 1, See below

- resets: phandle pointing to the system reset controller and

          reset line index, see reset/fsl,imx-src.txt for details

Optional properties:

- port@[0-3]: Port nodes with endpoint definitions as defined in

  Documentation/devicetree/bindings/media/video-interfaces.txt.

  Ports 0 and 1 should correspond to CSI0 and CSI1,

  ports 2 and 3 should correspond to DI0 and DI1, respectively.

example:

ipu: ipu@18000000 {

	#crtc-cells = <1>;

	#address-cells = <1>;

	#size-cells = <0>;

	compatible = "fsl,imx53-ipu";

	reg = <0x18000000 0x080000000>;

	interrupts = <11 10>;

	resets = <&src 2>;

	ipu_di0: port@2 {

		reg = <2>;

		ipu_di0_disp0: endpoint {

			remote-endpoint = <&display_in>;

		};

	};

};

Parallel display support

Required properties:

- compatible: Should be "fsl,imx-parallel-display"

- crtc: the crtc this display is connected to, see below

Optional properties:

- interface_pix_fmt: How this display is connected to the

  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"

  display interface. Currently supported types: "rgb24", "rgb565", "bgr666"

- edid: verbatim EDID data block describing attached display.

- ddc: phandle describing the i2c bus handling the display data

  channel

- port: A port node with endpoint definitions as defined in

  Documentation/devicetree/bindings/media/video-interfaces.txt.

example:

display@di0 {

	compatible = "fsl,imx-parallel-display";

	edid = [edid-data];

	crtc = <&ipu 0>;

	interface-pix-fmt = "rgb24";

	port {

		display_in: endpoint {

			remote-endpoint = <&ipu_di0_disp0>;

		};

	};

};

Device-Tree bindings for HDMI Transmitter

HDMI Transmitter

================

The HDMI Transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP

with accompanying PHY IP.

Required properties:

 - #address-cells : should be <1>

 - #size-cells : should be <0>

 - compatible : should be "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi".

 - gpr : should be <&gpr>.

   The phandle points to the iomuxc-gpr region containing the HDMI

   multiplexer control register.

 - clocks, clock-names : phandles to the HDMI iahb and isrf clocks, as described

   in Documentation/devicetree/bindings/clock/clock-bindings.txt and

   Documentation/devicetree/bindings/clock/imx6q-clock.txt.

 - port@[0-4]: Up to four port nodes with endpoint definitions as defined in

   Documentation/devicetree/bindings/media/video-interfaces.txt,

   corresponding to the four inputs to the HDMI multiplexer.

Optional properties:

 - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing

example:

	gpr: iomuxc-gpr@020e0000 {

		/* ... */

	};

        hdmi: hdmi@0120000 {

                #address-cells = <1>;

                #size-cells = <0>;

                compatible = "fsl,imx6q-hdmi";

                reg = <0x00120000 0x9000>;

                interrupts = <0 115 0x04>;

                gpr = <&gpr>;

                clocks = <&clks 123>, <&clks 124>;

                clock-names = "iahb", "isfr";

                ddc-i2c-bus = <&i2c2>;

                port@0 {

                        reg = <0>;

                        hdmi_mux_0: endpoint {

                                remote-endpoint = <&ipu1_di0_hdmi>;

                        };

                };

                port@1 {

                        reg = <1>;

                        hdmi_mux_1: endpoint {

                                remote-endpoint = <&ipu1_di1_hdmi>;

                        };

                };

        };

Required properties:

 - reg : should be <0> or <1>

 - crtcs : a list of phandles with index pointing to the IPU display interfaces

           that can be used as video source for this channel.

 - fsl,data-mapping : should be "spwg" or "jeida"

                      This describes how the color bits are laid out in the

                      serialized LVDS signal.

 - fsl,data-width : should be <18> or <24>

 - port: A port node with endpoint definitions as defined in

   Documentation/devicetree/bindings/media/video-interfaces.txt.

   On i.MX6, there should be four ports (port@[0-3]) that correspond

   to the four LVDS multiplexer inputs.

example:

	lvds-channel@0 {

		reg = <0>;

		crtcs = <&ipu 0>;

		fsl,data-mapping = "spwg";

		fsl,data-width = <24>;

		display-timings {

			/* ... */

		};

		port {

			lvds0_in: endpoint {

				remote-endpoint = <&ipu_di0_lvds0>;

			};

		};

	};

	lvds-channel@1 {

		reg = <1>;

		crtcs = <&ipu 1>;

		fsl,data-mapping = "spwg";

		fsl,data-width = <24>;

		display-timings {

			/* ... */

		};

		port {

			lvds1_in: endpoint {

				remote-endpoint = <&ipu_di1_lvds1>;

			};

		};

	};

};

	display@di1 {

		compatible = "fsl,imx-parallel-display";

		crtcs = <&ipu 0>;

		interface-pix-fmt = "bgr666";

		pinctrl-names = "default";

		pinctrl-0 = <&pinctrl_ipu_disp1_1>;

				pixelclk-active = <0>;

			};

		};

		port {

			display_in: endpoint {

				remote-endpoint = <&ipu_di0_disp0>;

			};

		};

	};

	gpio-keys {

		};

	};

};

&ipu_di0_disp0 {

	remote-endpoint = <&display_in>;

};