Merge tag 'drivers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

- compatible: Should be "atmel,at91rm9200-sdramc",

			"atmel,at91sam9260-sdramc",

			"atmel,at91sam9g45-ddramc",

			"atmel,sama5d3-ddramc",

- reg: Should contain registers location and length

  For at91sam9263 and at91sam9g45 you must specify 2 entries.

Examples:

		reg = <0xffffe800 0x200>;

	};

	ramc0: ramc@ffffe400 {

		compatible = "atmel,at91sam9g45-ddramc";

		reg = <0xffffe400 0x200

		       0xffffe600 0x200>;

	};

SHDWC Shutdown Controller

required properties:

Device Tree Bindings for Register Bit LEDs

Register bit leds are used with syscon multifunctional devices

where single bits in a certain register can turn on/off a

single LED. The register bit LEDs appear as children to the

syscon device, with the proper compatible string. For the

syscon bindings see:

Documentation/devicetree/bindings/mfd/syscon.txt

Each LED is represented as a sub-node of the syscon device. Each

node's name represents the name of the corresponding LED.

LED sub-node properties:

Required properties:

- compatible : must be "register-bit-led"

- offset : register offset to the register controlling this LED

- mask : bit mask for the bit controlling this LED in the register

  typically 0x01, 0x02, 0x04 ...

Optional properties:

- label : (optional)

  see Documentation/devicetree/bindings/leds/common.txt

- linux,default-trigger : (optional)

  see Documentation/devicetree/bindings/leds/common.txt

- default-state: (optional) The initial state of the LED. Valid

  values are "on", "off", and "keep". If the LED is already on or off

  and the default-state property is set the to same value, then no

  glitch should be produced where the LED momentarily turns off (or

  on). The "keep" setting will keep the LED at whatever its current

  state is, without producing a glitch.  The default is off if this

  property is not present.

Example:

syscon: syscon@10000000 {

	compatible = "arm,realview-pb1176-syscon", "syscon";

	reg = <0x10000000 0x1000>;

	led@08.0 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x01>;

		label = "versatile:0";

		linux,default-trigger = "heartbeat";

		default-state = "on";

	};

	led@08.1 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x02>;

		label = "versatile:1";

		linux,default-trigger = "mmc0";

		default-state = "off";

	};

	led@08.2 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x04>;

		label = "versatile:2";

		linux,default-trigger = "cpu0";

		default-state = "off";

	};

	led@08.3 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x08>;

		label = "versatile:3";

		default-state = "off";

	};

	led@08.4 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x10>;

		label = "versatile:4";

		default-state = "off";

	};

	led@08.5 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x20>;

		label = "versatile:5";

		default-state = "off";

	};

	led@08.6 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x40>;

		label = "versatile:6";

		default-state = "off";

	};

	led@08.7 {

		compatible = "register-bit-led";

		offset = <0x08>;

		mask = <0x80>;

		label = "versatile:7";

		default-state = "off";

	};

};

OMAP2+ Mailbox Driver

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

The OMAP mailbox hardware facilitates communication between different processors

using a queued mailbox interrupt mechanism. The IP block is external to the

various processor subsystems and is connected on an interconnect bus. The

communication is achieved through a set of registers for message storage and

interrupt configuration registers.

Each mailbox IP block has a certain number of h/w fifo queues and output

interrupt lines. An output interrupt line is routed to an interrupt controller

within a processor subsystem, and there can be more than one line going to a

specific processor's interrupt controller. The interrupt line connections are

fixed for an instance and are dictated by the IP integration into the SoC

(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is

programmable through a set of interrupt configuration registers, and have a rx

and tx interrupt source per h/w fifo. Communication between different processors

is achieved through the appropriate programming of the rx and tx interrupt

sources on the appropriate interrupt lines.

The number of h/w fifo queues and interrupt lines dictate the usable registers.

All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP

instance. DRA7xx has multiple instances with different number of h/w fifo queues

and interrupt lines between different instances. The interrupt lines can also be

routed to different processor sub-systems on DRA7xx as they are routed through

the Crossbar, a kind of interrupt router/multiplexer.

Mailbox Device Node:

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

A Mailbox device node is used to represent a Mailbox IP instance within a SoC.

The sub-mailboxes are represented as child nodes of this parent node.

Required properties:

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

- compatible:		Should be one of the following,

			    "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs

			    "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs

			    "ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx,

						   AM43xx and DRA7xx SoCs

- reg:			Contains the mailbox register address range (base

			address and length)

- interrupts:		Contains the interrupt information for the mailbox

			device. The format is dependent on which interrupt

			controller the OMAP device uses

- ti,hwmods:		Name of the hwmod associated with the mailbox

- ti,mbox-num-users:	Number of targets (processor devices) that the mailbox

			device can interrupt

- ti,mbox-num-fifos:	Number of h/w fifo queues within the mailbox IP block

Child Nodes:

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

A child node is used for representing the actual sub-mailbox device that is

used for the communication between the host processor and a remote processor.

Each child node should have a unique node name across all the different

mailbox device nodes.

Required properties:

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

- ti,mbox-tx:		sub-mailbox descriptor property defining a Tx fifo

- ti,mbox-rx:		sub-mailbox descriptor property defining a Rx fifo

Sub-mailbox Descriptor Data

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

Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of

data that represent the following:

    Cell #1 (fifo_id) - mailbox fifo id used either for transmitting

                        (ti,mbox-tx) or for receiving (ti,mbox-rx)

    Cell #2 (irq_id)  - irq identifier index number to use from the parent's

                        interrupts data. Should be 0 for most of the cases, a

                        positive index value is seen only on mailboxes that have

                        multiple interrupt lines connected to the MPU processor.

    Cell #3 (usr_id)  - mailbox user id for identifying the interrupt line

                        associated with generating a tx/rx fifo interrupt.

Example:

--------

/* OMAP4 */

mailbox: mailbox@4a0f4000 {

	compatible = "ti,omap4-mailbox";

	reg = <0x4a0f4000 0x200>;

	interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;

	ti,hwmods = "mailbox";

	ti,mbox-num-users = <3>;

	ti,mbox-num-fifos = <8>;

	mbox_ipu: mbox_ipu {

		ti,mbox-tx = <0 0 0>;

		ti,mbox-rx = <1 0 0>;

	};

	mbox_dsp: mbox_dsp {

		ti,mbox-tx = <3 0 0>;

		ti,mbox-rx = <2 0 0>;

	};

};

/* AM33xx */

mailbox: mailbox@480C8000 {

	compatible = "ti,omap4-mailbox";

	reg = <0x480C8000 0x200>;

	interrupts = <77>;

	ti,hwmods = "mailbox";

	ti,mbox-num-users = <4>;

	ti,mbox-num-fifos = <8>;

	mbox_wkupm3: wkup_m3 {

		ti,mbox-tx = <0 0 0>;

		ti,mbox-rx = <0 0 3>;

	};

};

* sun6i Real Time Clock

RTC controller for the Allwinner A31

Required properties:

- compatible	: Should be "allwinner,sun6i-a31-rtc"

- reg		: physical base address of the controller and length of

		  memory mapped region.

- interrupts	: IRQ lines for the RTC alarm 0 and alarm 1, in that order.

Example:

rtc: rtc@01f00000 {

	compatible = "allwinner,sun6i-a31-rtc";

	reg = <0x01f00000 0x54>;

	interrupts = <0 40 4>, <0 41 4>;

};

Keystone Navigator DMA Controller

This document explains the device tree bindings for the packet dma

on keystone devices. The Keystone Navigator DMA driver sets up the dma

channels and flows for the QMSS(Queue Manager SubSystem) who triggers

the actual data movements across clients using destination queues. Every

client modules like  NETCP(Network Coprocessor), SRIO(Serial Rapid IO),

CRYPTO Engines etc has its own instance of dma hardware. QMSS has also

an internal packet DMA module which is used as an infrastructure DMA

with zero copy.

Navigator DMA cloud layout:

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

	| Navigator DMAs |

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

		|

		|-> DMA instance #0

		|

		|-> DMA instance #1

			.

			.

		|

		|-> DMA instance #n

Navigator DMA properties:

Required properties:

 - compatible: Should be "ti,keystone-navigator-dma"

 - clocks: phandle to dma instances clocks. The clock handles can be as

	many as the dma instances. The order should be maintained as per

	the dma instances.

 - ti,navigator-cloud-address: Should contain base address for the multi-core

	navigator cloud and number of addresses depends on SOC integration

	configuration.. Navigator cloud global address needs to be programmed

	into DMA and the DMA uses it as the physical addresses to reach queue

	managers. Note that these addresses though points to queue managers,

	they are relevant only from DMA perspective. The QMSS may not choose to

	use them since it has a different address space view to reach all

	its components.

DMA instance properties:

Required properties:

 - reg: Should contain register location and length of the following dma

	register regions. Register regions should be specified in the following

	order.

	- Global control register region (global).

	- Tx DMA channel configuration register region (txchan).

	- Rx DMA channel configuration register region (rxchan).

	- Tx DMA channel Scheduler configuration register region (txsched).

	- Rx DMA flow configuration register region (rxflow).

Optional properties:

 - reg-names: Names for the register regions.

 - ti,enable-all: Enable all DMA channels vs clients opening specific channels

	what they need. This property is useful for the userspace fast path

	case where the linux drivers enables the channels used by userland

	stack.

 - ti,loop-back: To loopback Tx streaming I/F to Rx streaming I/F. Used for

	      infrastructure transfers.

 - ti,rx-retry-timeout: Number of dma cycles to wait before retry on buffer

		     starvation.

Example:

	knav_dmas: knav_dmas@0 {

		compatible = "ti,keystone-navigator-dma";

		clocks = <&papllclk>, <&clkxge>;

		#address-cells = <1>;

		#size-cells = <1>;

		ranges;

		ti,navigator-cloud-address = <0x23a80000 0x23a90000

					   0x23aa0000 0x23ab0000>;

		dma_gbe: dma_gbe@0 {

			reg = <0x2004000 0x100>,

				  <0x2004400 0x120>,

				  <0x2004800 0x300>,

				  <0x2004c00 0x120>,

				  <0x2005000 0x400>;

			reg-names = "global", "txchan", "rxchan",

					"txsched", "rxflow";

		};

		dma_xgbe: dma_xgbe@0 {

			reg = <0x2fa1000 0x100>,

				<0x2fa1400 0x200>,

				<0x2fa1800 0x200>,

				<0x2fa1c00 0x200>,

				<0x2fa2000 0x400>;

			reg-names = "global", "txchan", "rxchan",

					"txsched", "rxflow";

		};

	};

Navigator DMA client:

Required properties:

 - ti,navigator-dmas: List of one or more DMA specifiers, each consisting of

			- A phandle pointing to DMA instance node

			- A DMA channel number as a phandle arg.

 - ti,navigator-dma-names: Contains dma channel name for each DMA specifier in

			the 'ti,navigator-dmas' property.

Example:

	netcp: netcp@2090000 {

		..

		ti,navigator-dmas = <&dma_gbe 22>,

				<&dma_gbe 23>,

				<&dma_gbe 8>;

		ti,navigator-dma-names = "netrx0", "netrx1", "nettx";

		..

	};