Merge tag 'staging-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

    <chip> can be "at91sam9260", "at91sam9g45" or "at91sam9x5"

  - reg: Should contain ADC registers location and length

  - interrupts: Should contain the IRQ line for the ADC

  - clock-names: tuple listing input clock names.

	Required elements: "adc_clk", "adc_op_clk".

  - clocks: phandles to input clocks.

  - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this

    device

  - atmel,adc-startup-time: Startup Time of the ADC in microseconds as

	compatible = "atmel,at91sam9260-adc";

	reg = <0xfffb0000 0x100>;

	interrupts = <20 4>;

	clocks = <&adc_clk>, <&adc_op_clk>;

	clock-names = "adc_clk", "adc_op_clk";

	atmel,adc-channel-base = <0x30>;

	atmel,adc-channels-used = <0xff>;

	atmel,adc-drdy-mask = <0x10000>;

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 vf610 Analog to Digital Converter bindings

The devicetree bindings are for the new ADC driver written for

vf610/i.MX6slx and upward SoCs from Freescale.

Required properties:

- compatible: Should contain "fsl,vf610-adc"

- reg: Offset and length of the register set for the device

- interrupts: Should contain the interrupt for the device

- clocks: The clock is needed by the ADC controller, ADC clock source is ipg clock.

- clock-names: Must contain "adc", matching entry in the clocks property.

- vref-supply: The regulator supply ADC refrence voltage.

Example:

adc0: adc@4003b000 {

	compatible = "fsl,vf610-adc";

	reg = <0x4003b000 0x1000>;

	interrupts = <0 53 0x04>;

	clocks = <&clks VF610_CLK_ADC0>;

	clock-names = "adc";

	vref-supply = <&reg_vcc_3v3_mcu>;

};

Xilinx XADC device driver

This binding document describes the bindings for both of them since the

bindings are very similar. The Xilinx XADC is a ADC that can be found in the

series 7 FPGAs from Xilinx. The XADC has a DRP interface for communication.

Currently two different frontends for the DRP interface exist. One that is only

available on the ZYNQ family as a hardmacro in the SoC portion of the ZYNQ. The

other one is available on all series 7 platforms and is a softmacro with a AXI

interface. This binding document describes the bindings for both of them since

the bindings are very similar.

Required properties:

	- compatible: Should be one of

		* "xlnx,zynq-xadc-1.00.a": When using the ZYNQ device

		  configuration interface to interface to the XADC hardmacro.

		* "xlnx,axi-xadc-1.00.a": When using the axi-xadc pcore to

		  interface to the XADC hardmacro.

	- reg: Address and length of the register set for the device

	- interrupts: Interrupt for the XADC control interface.

	- clocks: When using the ZYNQ this must be the ZYNQ PCAP clock,

	  when using the AXI-XADC pcore this must be the clock that provides the

	  clock to the AXI bus interface of the core.

Optional properties:

	- interrupt-parent: phandle to the parent interrupt controller

	- xlnx,external-mux:

		* "none": No external multiplexer is used, this is the default

		  if the property is omitted.

		* "single": External multiplexer mode is used with one

		   multiplexer.

		* "dual": External multiplexer mode is used with two

		  multiplexers for simultaneous sampling.

	- xlnx,external-mux-channel: Configures which pair of pins is used to

	  sample data in external mux mode.

	  Valid values for single external multiplexer mode are:

		0: VP/VN

		1: VAUXP[0]/VAUXN[0]

		2: VAUXP[1]/VAUXN[1]

		...

		16: VAUXP[15]/VAUXN[15]

	  Valid values for dual external multiplexer mode are:

		1: VAUXP[0]/VAUXN[0] - VAUXP[8]/VAUXN[8]

		2: VAUXP[1]/VAUXN[1] - VAUXP[9]/VAUXN[9]

		...

		8: VAUXP[7]/VAUXN[7] - VAUXP[15]/VAUXN[15]

	  This property needs to be present if the device is configured for

	  external multiplexer mode (either single or dual). If the device is

	  not using external multiplexer mode the property is ignored.

	- xnlx,channels: List of external channels that are connected to the ADC

	  Required properties:

		* #address-cells: Should be 1.

		* #size-cells: Should be 0.

	  The child nodes of this node represent the external channels which are

	  connected to the ADC. If the property is no present no external

	  channels will be assumed to be connected.

	  Each child node represents one channel and has the following

	  properties:

		Required properties:

			* reg: Pair of pins the the channel is connected to.

				0: VP/VN

				1: VAUXP[0]/VAUXN[0]

				2: VAUXP[1]/VAUXN[1]

				...

				16: VAUXP[15]/VAUXN[15]

			  Note each channel number should only be used at most

			  once.

		Optional properties:

			* xlnx,bipolar: If set the channel is used in bipolar

			  mode.

Examples:

	xadc@f8007100 {

		compatible = "xlnx,zynq-xadc-1.00.a";

		reg = <0xf8007100 0x20>;

		interrupts = <0 7 4>;

		interrupt-parent = <&gic>;

		clocks = <&pcap_clk>;

		xlnx,channels {

			#address-cells = <1>;

			#size-cells = <0>;

			channel@0 {

				reg = <0>;

			};

			channel@1 {

				reg = <1>;

			};

			channel@8 {

				reg = <8>;

			};

		};

	};

	xadc@43200000 {

		compatible = "xlnx,axi-xadc-1.00.a";

		reg = <0x43200000 0x1000>;

		interrupts = <0 53 4>;

		interrupt-parent = <&gic>;

		clocks = <&fpga1_clk>;

		xlnx,channels {

			#address-cells = <1>;

			#size-cells = <0>;

			channel@0 {

				reg = <0>;

				xlnx,bipolar;

			};

		};

	};

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>;

		};

	};

};