Merge tag 'imx-soc-3.10' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/soc2

	usb_phy_podf		23

	cpu_podf		24

	di_pred			25

	tve_di			26

	tve_s			27

	uart1_ipg_gate		28

	uart1_per_gate		29

	can1_serial_gate	157

	can1_ipg_gate		158

	owire_gate		159

	gpu3d_s			160

	gpu2d_s			161

	gpu3d_gate		162

	gpu2d_gate		163

	garb_gate		164

	cko1_sel		165

	cko1_podf		166

	cko1			167

	cko2_sel		168

	cko2_podf		169

	cko2			170

	srtc_gate		171

	pata_gate		172

Examples (for mx53):

	enet_ref		190

	usbphy1_gate		191

	usbphy2_gate		192

	pll4_post_div		193

	pll5_post_div		194

	pll5_video_div		195

Examples:

Freescale i.MX System Reset Controller

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

Please also refer to reset.txt in this directory for common reset

controller binding usage.

Required properties:

- compatible: Should be "fsl,<chip>-src"

- reg: should be register base and length as documented in the

  datasheet

- interrupts: Should contain SRC interrupt and CPU WDOG interrupt,

  in this order.

- #reset-cells: 1, see below

example:

src: src@020d8000 {

        compatible = "fsl,imx6q-src";

        reg = <0x020d8000 0x4000>;

        interrupts = <0 91 0x04 0 96 0x04>;

        #reset-cells = <1>;

};

Specifying reset lines connected to IP modules

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

The system reset controller can be used to reset the GPU, VPU,

IPU, and OpenVG IP modules on i.MX5 and i.MX6 ICs. Those device

nodes should specify the reset line on the SRC in their resets

property, containing a phandle to the SRC device node and a

RESET_INDEX specifying which module to reset, as described in

reset.txt

example:

        ipu1: ipu@02400000 {

                resets = <&src 2>;

        };

        ipu2: ipu@02800000 {

                resets = <&src 4>;

        };

The following RESET_INDEX values are valid for i.MX5:

GPU_RESET     0

VPU_RESET     1

IPU1_RESET    2

OPEN_VG_RESET 3

The following additional RESET_INDEX value is valid for i.MX6:

IPU2_RESET    4

= Reset Signal Device Tree Bindings =

This binding is intended to represent the hardware reset signals present

internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole

standalone chips are most likely better represented as GPIOs, although there

are likely to be exceptions to this rule.

Hardware blocks typically receive a reset signal. This signal is generated by

a reset provider (e.g. power management or clock module) and received by a

reset consumer (the module being reset, or a module managing when a sub-

ordinate module is reset). This binding exists to represent the provider and

consumer, and provide a way to couple the two together.

A reset signal is represented by the phandle of the provider, plus a reset

specifier - a list of DT cells that represents the reset signal within the

provider. The length (number of cells) and semantics of the reset specifier

are dictated by the binding of the reset provider, although common schemes

are described below.

A word on where to place reset signal consumers in device tree: It is possible

in hardware for a reset signal to affect multiple logically separate HW blocks

at once. In this case, it would be unwise to represent this reset signal in

the DT node of each affected HW block, since if activated, an unrelated block

may be reset. Instead, reset signals should be represented in the DT node

where it makes most sense to control it; this may be a bus node if all

children of the bus are affected by the reset signal, or an individual HW

block node for dedicated reset signals. The intent of this binding is to give

appropriate software access to the reset signals in order to manage the HW,

rather than to slavishly enumerate the reset signal that affects each HW

block.

= Reset providers =

Required properties:

#reset-cells:	Number of cells in a reset specifier; Typically 0 for nodes

		with a single reset output and 1 for nodes with multiple

		reset outputs.

For example:

	rst: reset-controller {

		#reset-cells = <1>;

	};

= Reset consumers =

Required properties:

resets:		List of phandle and reset specifier pairs, one pair

		for each reset signal that affects the device, or that the

		device manages. Note: if the reset provider specifies '0' for

		#reset-cells, then only the phandle portion of the pair will

		appear.

Optional properties:

reset-names:	List of reset signal name strings sorted in the same order as

		the resets property. Consumers drivers will use reset-names to

		match reset signal names with reset specifiers.

For example:

	device {

		resets = <&rst 20>;

		reset-names = "reset";

	};

This represents a device with a single reset signal named "reset".

	bus {

		resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;

		reset-names = "i2s1", "i2s2", "dma", "mixer";

	};

This represents a bus that controls the reset signal of each of four sub-

ordinate devices. Consider for example a bus that fails to operate unless no

child device has reset asserted.

- 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

example:

	compatible = "fsl,imx53-ipu";

	reg = <0x18000000 0x080000000>;

	interrupts = <11 10>;

	resets = <&src 2>;

};

Parallel display support