code:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/summit,smb347-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Battery charger driver for SMB345, SMB347 and SMB358

maintainers:
  - David Heidelberg <david@ixit.cz>
  - Dmitry Osipenko <digetx@gmail.com>

properties:
  compatible:
    enum:
      - summit,smb345
      - summit,smb347
      - summit,smb358

  reg:
    maxItems: 1

  interrupts:
    maxItems: 1

  monitored-battery:
    description: phandle to the battery node
    $ref: /schemas/types.yaml#/definitions/phandle

  summit,enable-usb-charging:
    type: boolean
    description: Enable charging through USB.

  summit,enable-otg-charging:
    type: boolean
    description: Provide power for USB OTG

  summit,enable-mains-charging:
    type: boolean
    description: Enable charging through mains

  summit,enable-charge-control:
    description: Enable charging control
    $ref: /schemas/types.yaml#/definitions/uint32
    enum:
      - 0 # SMB3XX_CHG_ENABLE_SW SW (I2C interface)
      - 1 # SMB3XX_CHG_ENABLE_PIN_ACTIVE_LOW Pin control (Active Low)
      - 2 # SMB3XX_CHG_ENABLE_PIN_ACTIVE_HIGH Pin control (Active High)

  summit,fast-voltage-threshold-microvolt:
    description: Voltage threshold to transit to fast charge mode (in uV)
    minimum: 2400000
    maximum: 3000000

  summit,mains-current-limit-microamp:
    description: Maximum input current from AC/DC input (in uA)

  summit,usb-current-limit-microamp:
    description: Maximum input current from USB input (in uA)

  summit,charge-current-compensation-microamp:
    description: Charge current compensation (in uA)

  summit,chip-temperature-threshold-celsius:
    description: Chip temperature for thermal regulation in °C.
    enum: [100, 110, 120, 130]

  summit,soft-compensation-method:
    description: Soft temperature limit compensation method
    $ref: /schemas/types.yaml#/definitions/uint32
    enum:
      - 0 # SMB3XX_SOFT_TEMP_COMPENSATE_NONE Compensation none
      - 1 # SMB3XX_SOFT_TEMP_COMPENSATE_CURRENT Current compensation
      - 2 # SMB3XX_SOFT_TEMP_COMPENSATE_VOLTAGE Voltage compensation

  summit,inok-polarity:
    description: |
      Polarity of INOK signal indicating presence of external power supply.
    $ref: /schemas/types.yaml#/definitions/uint32
    enum:
      - 0 # SMB3XX_SYSOK_INOK_ACTIVE_LOW
      - 1 # SMB3XX_SYSOK_INOK_ACTIVE_HIGH

  usb-vbus:
    $ref: /schemas/regulator/regulator.yaml#
    type: object

    properties:
      summit,needs-inok-toggle:
        type: boolean
        description: INOK signal is fixed and polarity needs to be toggled
                     in order to enable/disable output mode.

    unevaluatedProperties: false

allOf:
  - if:
      properties:
        compatible:
          enum:
            - summit,smb345
            - summit,smb358

    then:
      properties:
        summit,mains-current-limit-microamp:
          enum: [ 300000, 500000, 700000, 1000000,
                  1500000, 1800000, 2000000]

        summit,usb-current-limit-microamp:
          enum: [ 300000, 500000, 700000, 1000000,
                  1500000, 1800000, 2000000]

        summit,charge-current-compensation-microamp:
          enum: [200000, 450000, 600000, 900000]

    else:
      properties:
        summit,mains-current-limit-microamp:
          enum: [ 300000, 500000, 700000, 900000, 1200000,
                  1500000, 1800000, 2000000, 2200000, 2500000]

        summit,usb-current-limit-microamp:
          enum: [ 300000, 500000, 700000, 900000, 1200000,
                  1500000, 1800000, 2000000, 2200000, 2500000]

        summit,charge-current-compensation-microamp:
          enum: [250000, 700000, 900000, 1200000]

required:
  - compatible
  - reg

anyOf:
  - required:
      - summit,enable-usb-charging
  - required:
      - summit,enable-otg-charging
  - required:
      - summit,enable-mains-charging

additionalProperties: false

examples:
  - |
    #include <dt-bindings/power/summit,smb347-charger.h>

    i2c {
        #address-cells = <1>;
        #size-cells = <0>;

        charger@7f {
            compatible = "summit,smb347";
            reg = <0x7f>;

            summit,enable-charge-control = <SMB3XX_CHG_ENABLE_PIN_ACTIVE_HIGH>;
            summit,inok-polarity = <SMB3XX_SYSOK_INOK_ACTIVE_LOW>;
            summit,chip-temperature-threshold-celsius = <110>;
            summit,mains-current-limit-microamp = <2000000>;
            summit,usb-current-limit-microamp = <500000>;
            summit,enable-usb-charging;
            summit,enable-mains-charging;

            monitored-battery = <&battery>;

            usb-vbus {
                regulator-name = "usb_vbus";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
                regulator-min-microamp = <750000>;
                regulator-max-microamp = <750000>;
                summit,needs-inok-toggle;
            };
        };
    };

    battery: battery-cell {
        compatible = "simple-battery";
        constant-charge-current-max-microamp = <1800000>;
        operating-range-celsius = <0 45>;
        alert-celsius = <3 42>;
    };


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/ti,lp8727.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Binding for TI/National Semiconductor LP8727 Charger

maintainers:
  - Sebastian Reichel <sre@kernel.org>

allOf:
  - $ref: power-supply.yaml#

properties:
  compatible:
    const: ti,lp8727

  reg:
    const: 0x27

  interrupts:
    maxItems: 1

  debounce-ms:
    description: interrupt debounce time in ms

patternProperties:
  '^(ac|usb)$':
    type: object
    description: USB/AC charging parameters
    properties:
      charger-type:
        enum:
          - ac
          - usb

      eoc-level:
        $ref: /schemas/types.yaml#/definitions/uint8
        minimum: 0
        maximum: 6
        description: |
          End of Charge Percentage with the following mapping:
          0 = 5%, 1 = 10%, 2 = 16%, 3 = 20%, 4 = 25%, 5 = 33%, 6 = 50%

      charging-current:
        $ref: /schemas/types.yaml#/definitions/uint8
        minimum: 0
        maximum: 9
        description: |
          Charging current with the following mapping:
          0 = 90mA, 1 = 100mA, 2 = 400mA, 3 = 450mA, 4 = 500mA, 5 = 600mA,
          6 = 700mA, 7 = 800mA, 8 = 900mA, 9 = 1000mA

required:
  - compatible
  - reg

additionalProperties: false

examples:
  - |
    #include <dt-bindings/interrupt-controller/irq.h>
    i2c0 {
      #address-cells = <1>;
      #size-cells = <0>;

      lp8727: charger@27 {
        compatible = "ti,lp8727";
        reg = <0x27>;
        interrupt-parent = <&gpio5>;
        interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
        debounce-ms = <300>;

        /* AC charger: 5% EOC and 500mA charging current */
        ac {
          charger-type = "ac";
          eoc-level = /bits/ 8 <0>;
          charging-current = /bits/ 8 <4>;
        };

        /* USB charger: 10% EOC and 400mA charging current */
        usb {
          charger-type = "usb";
          eoc-level = /bits/ 8 <1>;
          charging-current = /bits/ 8 <2>;
        };
      };
    };

repo_name: angery/linux


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/tps65090-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: TPS65090 Frontend PMU with Switchmode Charger

maintainers:
  - Sebastian Reichel <sre@kernel.org>

allOf:
  - $ref: power-supply.yaml#

properties:
  compatible:
    const: ti,tps65090-charger

  ti,enable-low-current-chrg:
    type: boolean
    description: |
      Enables charging when a low current is detected while the default logic is to stop charging.

required:
  - compatible

additionalProperties: false

examples:
  - |
    pmic {
      charger {
        compatible = "ti,tps65090-charger";
        ti,enable-low-current-chrg;
      };
    };


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/tps65217-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: TPS65217 Charger

maintainers:
  - Sebastian Reichel <sre@kernel.org>

allOf:
  - $ref: power-supply.yaml#

properties:
  compatible:
    const: ti,tps65217-charger

  interrupts:
    minItems: 2
    maxItems: 2

  interrupt-names:
    items:
      - const: USB
      - const: AC

required:
  - compatible
  - interrupts
  - interrupt-names

additionalProperties: false

examples:
  - |
    pmic {
      charger {
        compatible = "ti,tps65217-charger";
        interrupts = <0>, <1>;
        interrupt-names = "USB", "AC";
      };
    };


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/twl4030-charger.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: TWL4030 BCI (Battery Charger Interface)

description: |
  The battery charger needs to interact with the USB phy in order to know when
  charging is permissible, and when there is a connection or disconnection.

  The choice of phy cannot be configured at a hardware level, so there is no
  value in explicit configuration in device-tree. Rather if there is a sibling
  of the BCI node which is compatible with "ti,twl4030-usb", then that is used
  to determine when and how use USB power for charging.

maintainers:
  - Sebastian Reichel <sre@kernel.org>

allOf:
  - $ref: power-supply.yaml#

properties:
  compatible:
    const: ti,twl4030-bci

  interrupts:
    minItems: 2
    maxItems: 2

  ti,bb-uvolt:
    $ref: /schemas/types.yaml#/definitions/uint32
    description: microvolts for charging the backup battery

  ti,bb-uamp:
    $ref: /schemas/types.yaml#/definitions/uint32
    description: microamps for charging the backup battery

  io-channels:
    items:
      - description: Accessory Charger Voltage Channel

  io-channel-names:
    items:
      - const: vac

  bci3v1-supply:
    description: 3.1V USB regulator

required:
  - compatible
  - interrupts

additionalProperties: false

examples:
  - |
    pmic {
      charger {
        compatible = "ti,twl4030-bci";
        interrupts = <9>, <2>;
        ti,bb-uvolt = <3200000>;
        ti,bb-uamp = <150>;
        io-channels = <&twl_madc 11>;
        io-channel-names = "vac";
      };
    };


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/x-powers,axp20x-ac-power-supply.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: AXP20x AC power-supply

description: |
  The AXP20X can read the current current and voltage supplied by AC by
  reading ADC channels from the AXP20X ADC. The AXP22X is only able to
  tell if an AC power supply is present and usable. AXP813/AXP803 are
  able to limit current and supply voltage

maintainers:
  - Chen-Yu Tsai <wens@csie.org>
  - Sebastian Reichel <sre@kernel.org>

allOf:
  - $ref: power-supply.yaml#

properties:
  compatible:
    oneOf:
      - const: x-powers,axp202-ac-power-supply
      - const: x-powers,axp221-ac-power-supply
      - items:
          - const: x-powers,axp803-ac-power-supply
          - const: x-powers,axp813-ac-power-supply
      - const: x-powers,axp813-ac-power-supply

required:
  - compatible

additionalProperties: false


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/x-powers,axp20x-battery-power-supply.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: AXP20x Battery power-supply

description: |
  The supported devices can read the battery voltage, charge and discharge
  currents of the battery by reading ADC channels from the ADC.

maintainers:
  - Chen-Yu Tsai <wens@csie.org>
  - Sebastian Reichel <sre@kernel.org>

allOf:
  - $ref: power-supply.yaml#

properties:
  compatible:
    oneOf:
      - const: x-powers,axp202-battery-power-supply
      - const: x-powers,axp209-battery-power-supply
      - const: x-powers,axp221-battery-power-supply
      - items:
          - const: x-powers,axp803-battery-power-supply
          - const: x-powers,axp813-battery-power-supply
      - const: x-powers,axp813-battery-power-supply

required:
  - compatible

additionalProperties: false


code:
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/power/supply/x-powers,axp20x-usb-power-supply.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: AXP20x USB power-supply

description: |
  The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
  variations such as the former being able to set the VBUS power supply max
  current to 100mA, unlike the latter.

maintainers:
  - Chen-Yu Tsai <wens@csie.org>
  - Sebastian Reichel <sre@kernel.org>

allOf:
  - $ref: power-supply.yaml#

properties:
  compatible:
    oneOf:
      - enum:
          - x-powers,axp202-usb-power-supply
          - x-powers,axp221-usb-power-supply
          - x-powers,axp223-usb-power-supply
          - x-powers,axp813-usb-power-supply
      - items:
          - const: x-powers,axp803-usb-power-supply
          - const: x-powers,axp813-usb-power-supply

required:
  - compatible

additionalProperties: false


code:
Texas Instruments SmartReflex binding

SmartReflex is used to set and adjust the SoC operating points.

Required properties:

compatible: Shall be one of the following:
	    "ti,omap3-smartreflex-core"
	    "ti,omap3-smartreflex-mpu-iva"
	    "ti,omap4-smartreflex-core"
	    "ti,omap4-smartreflex-mpu"
	    "ti,omap4-smartreflex-iva"

reg: Shall contain the device instance IO range

interrupts: Shall contain the device instance interrupt

Optional properties:

ti,hwmods: Shall contain the TI interconnect module name if needed
	   by the SoC

Example:

	smartreflex_iva: smartreflex@4a0db000 {
		compatible = "ti,omap4-smartreflex-iva";
		reg = <0x4a0db000 0x80>;
		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
		ti,hwmods = "smartreflex_iva";
	};

	smartreflex_core: smartreflex@4a0dd000 {
		compatible = "ti,omap4-smartreflex-core";
		reg = <0x4a0dd000 0x80>;
		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
		ti,hwmods = "smartreflex_core";
	};

	smartreflex_mpu: smartreflex@4a0d9000 {
		compatible = "ti,omap4-smartreflex-mpu";
		reg = <0x4a0d9000 0x80>;
		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
		ti,hwmods = "smartreflex_mpu";
	};


code:
Specifying wakeup capability for devices
============================================

Any device nodes
----------------
Nodes that describe devices which has wakeup capability must contain an
"wakeup-source" boolean property.

Also, if device is marked as a wakeup source, then all the primary
interrupt(s) can be used as wakeup interrupt(s).

However if the devices have dedicated interrupt as the wakeup source
then they need to specify/identify the same using device specific
interrupt name. In such cases only that interrupt can be used as wakeup
interrupt.

List of legacy properties and respective binding document
---------------------------------------------------------

1. "gpio-key,wakeup"		Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt
2. "has-tpo"			Documentation/devicetree/bindings/rtc/rtc-opal.txt
3. "linux,wakeup"		Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
				Documentation/devicetree/bindings/mfd/tc3589x.txt
				Documentation/devicetree/bindings/input/touchscreen/ads7846.txt
4. "linux,keypad-wakeup"	Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
5. "linux,input-wakeup"		Documentation/devicetree/bindings/input/samsung-keypad.txt
6. "nvidia,wakeup-source"	Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt

Examples
--------

1. With "wakeup" interrupt name

	device@10000 {
		compatible	= "vendor,device-id";
		reg		= <0x10000 0x1000>;
		interrupts	= <0 19 4>, <0 21 4>, <0 22 4>;
		interrupt-names	= "ack", "err", "wakeup";
		wakeup-source;
	};

2. Without "wakeup" interrupt name

	embedded-controller {
		compatible = "google,cros-ec-i2c";
		reg = <0x1e>;
		interrupts = <6 0>;
		interrupt-parent = <&gpx1>;
		pinctrl-names = "default";
		pinctrl-0 = <&ec_irq>;
		wakeup-source;
	};

3. Without interrupts

	gpio_keys {
		compatible = "gpio-keys";
		#address-cells = <1>;
		#size-cells = <0>;

		button@1 {
			debounce-interval = <50>;
			wakeup-source;
			linux,code = <116>;
			label = "POWER";
			gpios = <&iofpga_gpio0 0 0x4>;
		};
		[....]
	};


code:
-----------------------------------------------------------
Device Tree Bindings for the Xilinx Zynq MPSoC PM domains
-----------------------------------------------------------
The binding for zynqmp-power-controller follow the common
generic PM domain binding[1].

[1] Documentation/devicetree/bindings/power/power-domain.yaml

== Zynq MPSoC Generic PM Domain Node ==

Required property:
 - Below property should be in zynqmp-firmware node.
 - #power-domain-cells:	Number of cells in a PM domain specifier. Must be 1.

Power domain ID indexes are mentioned in
include/dt-bindings/power/xlnx-zynqmp-power.h.

-------
Example
-------

firmware {
	zynqmp_firmware: zynqmp-firmware {
		...
		#power-domain-cells = <1>;
		...
	};
};

sata {
	...
	power-domains = <&zynqmp_firmware 28>;
	...
};


code:
IBM Akebono board device tree
=============================

The IBM Akebono board is a development board for the PPC476GTR SoC.

0) The root node

   Required properties:

   - model : "ibm,akebono".
   - compatible : "ibm,akebono" , "ibm,476gtr".

1.a) The Secure Digital Host Controller Interface (SDHCI) node

  Represent the Secure Digital Host Controller Interfaces.

  Required properties:

   - compatible : should be "ibm,476gtr-sdhci","generic-sdhci".
   - reg : should contain the SDHCI registers location and length.
   - interrupts : should contain the SDHCI interrupt.

1.b) The Advanced Host Controller Interface (AHCI) SATA node

  Represents the advanced host controller SATA interface.

  Required properties:

   - compatible : should be "ibm,476gtr-ahci".
   - reg : should contain the AHCI registers location and length.
   - interrupts : should contain the AHCI interrupt.

1.c) The FPGA node

  The Akebono board stores some board information such as the revision
  number in an FPGA which is represented by this node.

  Required properties:

   - compatible : should be "ibm,akebono-fpga".
   - reg : should contain the FPGA registers location and length.

1.d) The AVR node

  The Akebono board has an Atmel AVR microprocessor attached to the I2C
  bus as a power controller for the board.

  Required properties:

   - compatible : should be "ibm,akebono-avr".
   - reg : should contain the I2C bus address for the AVR.


code:
PPC4xx Clock Power Management (CPM) node

Required properties:
	- compatible		: compatible list, currently only "ibm,cpm"
	- dcr-access-method	: "native"
	- dcr-reg		: < DCR register range >

Optional properties:
	- er-offset		: All 4xx SoCs with a CPM controller have
				  one of two different order for the CPM
				  registers. Some have the CPM registers
				  in the following order (ER,FR,SR). The
				  others have them in the following order
				  (SR,ER,FR). For the second case set
				  er-offset = <1>.
	- unused-units		: specifier consist of one cell. For each
				  bit in the cell, the corresponding bit
				  in CPM will be set to turn off unused
				  devices.
	- idle-doze		: specifier consist of one cell. For each
				  bit in the cell, the corresponding bit
				  in CPM will be set to turn off unused
				  devices. This is usually just CPM[CPU].
	- standby		: specifier consist of one cell. For each
				  bit in the cell, the corresponding bit
				  in CPM will be set on standby and
				  restored on resume.
	- suspend		: specifier consist of one cell. For each
				  bit in the cell, the corresponding bit
				  in CPM will be set on suspend (mem) and
				  restored on resume. Note, for standby
				  and suspend the corresponding bits can
				  be different or the same. Usually for
				  standby only class 2 and 3 units are set.
				  However, the interface does not care.
				  If they are the same, the additional
				  power saving will be seeing if support
				  is available to put the DDR in self
				  refresh mode and any additional power
				  saving techniques for the specific SoC.

Example:
	CPM0: cpm {
		compatible = "ibm,cpm";
		dcr-access-method = "native";
		dcr-reg = <0x160 0x003>;
		er-offset = <0>;
		unused-units = <0x00000100>;
		idle-doze = <0x02000000>;
		standby = <0xfeff0000>;
		suspend = <0xfeff791d>;
};


code:
ppc476gtr High Speed Serial Assist (HSTA) node
==============================================

The 476gtr SoC contains a high speed serial assist module attached
between the plb4 and plb6 system buses to provide high speed data
transfer between memory and system peripherals as well as support for
PCI message signalled interrupts.

Currently only the MSI support is used by Linux using the following
device tree entries:

Require properties:
- compatible		: "ibm,476gtr-hsta-msi", "ibm,hsta-msi"
- reg			: register mapping for the HSTA MSI space
- interrupts		: ordered interrupt mapping for each MSI in the register
			  space. The first interrupt should be associated with a
			  register offset of 0x00, the second to 0x10, etc.


code:
PPC440SPe DMA/XOR (DMA Controller and XOR Accelerator)

Device nodes needed for operation of the ppc440spe-adma driver
are specified hereby. These are I2O/DMA, DMA and XOR nodes
for DMA engines and Memory Queue Module node. The latter is used
by ADMA driver for configuration of RAID-6 H/W capabilities of
the PPC440SPe. In addition to the nodes and properties described
below, the ranges property of PLB node must specify ranges for
DMA devices.

 i) The I2O node

 Required properties:

 - compatible		: "ibm,i2o-440spe";
 - reg			: <registers mapping>
 - dcr-reg		: <DCR registers range>

 Example:

	I2O: i2o@400100000 {
		compatible = "ibm,i2o-440spe";
		reg = <0x00000004 0x00100000 0x100>;
		dcr-reg = <0x060 0x020>;
	};

 ii) The DMA node

 Required properties:

 - compatible		: "ibm,dma-440spe";
 - cell-index		: 1 cell, hardware index of the DMA engine
			  (typically 0x0 and 0x1 for DMA0 and DMA1)
 - reg			: <registers mapping>
 - dcr-reg		: <DCR registers range>
 - interrupts		: <interrupt mapping for DMA0/1 interrupts sources:
			   2 sources: DMAx CS FIFO Needs Service IRQ (on UIC0)
			   and DMA Error IRQ (on UIC1). The latter is common
			   for both DMA engines>.

 Example:

	DMA0: dma0@400100100 {
		compatible = "ibm,dma-440spe";
		cell-index = <0>;
		reg = <0x00000004 0x00100100 0x100>;
		dcr-reg = <0x060 0x020>;
		interrupt-parent = <&DMA0>;
		interrupts = <0 1>;
		#interrupt-cells = <1>;
		#address-cells = <0>;
		#size-cells = <0>;
		interrupt-map = <
			0 &UIC0 0x14 4
			1 &UIC1 0x16 4>;
	};

 iii) XOR Accelerator node

 Required properties:

 - compatible		: "amcc,xor-accelerator";
 - reg			: <registers mapping>
 - interrupts		: <interrupt mapping for XOR interrupt source>

 Example:

	xor-accel@400200000 {
		compatible = "amcc,xor-accelerator";
		reg = <0x00000004 0x00200000 0x400>;
		interrupt-parent = <&UIC1>;
		interrupts = <0x1f 4>;
	};

 iv) Memory Queue Module node

 Required properties:

 - compatible		: "ibm,mq-440spe";
 - dcr-reg		: <DCR registers range>

 Example:

	MQ0: mq {
		compatible = "ibm,mq-440spe";
		dcr-reg = <0x040 0x020>;
	};


code:
Reboot property to control system reboot on PPC4xx systems:

By setting "reset_type" to one of the following values, the default
software reset mechanism may be overridden. Here the possible values of
"reset_type":

      1 - PPC4xx core reset
      2 - PPC4xx chip reset
      3 - PPC4xx system reset (default)

Example:

		cpu@0 {
			device_type = "cpu";
			model = "PowerPC,440SPe";
			...
			reset-type = <2>;	/* Use chip-reset */
		};


code:
Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding

DESCRIPTION

The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure
that enables the implementation of coherent, multicore systems.

Required properties:

- compatible: <string list>
		fsl,corenet1-cf - CoreNet coherency fabric version 1.
		Example chips: T4240, B4860

		fsl,corenet2-cf - CoreNet coherency fabric version 2.
		Example chips: P5040, P5020, P4080, P3041, P2041

		fsl,corenet-cf - Used to represent the common registers
		between CCF version 1 and CCF version 2.  This compatible
		is retained for compatibility reasons, as it was already
		used for both CCF version 1 chips and CCF version 2
		chips.  It should be specified after either
		"fsl,corenet1-cf" or "fsl,corenet2-cf".

- reg: <prop-encoded-array>
		A standard property. Represents the CCF registers.

- interrupts: <prop-encoded-array>
		Interrupt mapping for CCF error interrupt.

- fsl,ccf-num-csdids: <u32>
		Specifies the number of Coherency Subdomain ID Port Mapping
		Registers that are supported by the CCF.

- fsl,ccf-num-snoopids: <u32>
		Specifies the number of Snoop ID Port Mapping Registers that
		are supported by CCF.

Example:

	corenet-cf@18000 {
		compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
		reg = <0x18000 0x1000>;
		interrupts = <16 2 1 31>;
		fsl,ccf-num-csdids = <32>;
		fsl,ccf-num-snoopids = <32>;
	};


code:
===================================================================
Power Architecture CPU Binding
Copyright 2013 Freescale Semiconductor Inc.

Power Architecture CPUs in Freescale SOCs are represented in device trees as
per the definition in the Devicetree Specification.

In addition to the Devicetree Specification definitions, the properties
defined below may be present on CPU nodes.

PROPERTIES

   - fsl,eref-*
        Usage: optional
        Value type: <empty>
        Definition: The EREF (EREF: A Programmer.s Reference Manual for
	Freescale Power Architecture) defines the architecture for Freescale
	Power CPUs.  The EREF defines some architecture categories not defined
	by the Power ISA.  For these EREF-specific categories, the existence of
	a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
	name with all uppercase letters converted to lowercase, indicates that
	the category is supported by the implementation.

    - fsl,portid-mapping
	Usage: optional
	Value type: <u32>
	Definition: The Coherency Subdomain ID Port Mapping Registers and
	Snoop ID Port Mapping registers, which are part of the CoreNet
	Coherency fabric (CCF), provide a CoreNet Coherency Subdomain
	ID/CoreNet Snoop ID to cpu mapping functions.  Certain bits from
	these registers should be set if the coresponding CPU should be
	snooped.  This property defines a bitmask which selects the bit
	that should be set if this cpu should be snooped.


code:
===================================================================
Debug Control and Status Register (DCSR) Binding
Copyright 2011 Freescale Semiconductor Inc.

NOTE: The bindings described in this document are preliminary and subject
to change.  Some of the compatible strings that contain only generic names
may turn out to be inappropriate, or need additional properties to describe
the integration of the block with the rest of the chip.

=====================================================================
Debug Control and Status Register Memory Map

Description

This node defines the base address and range for the
defined DCSR Memory Map. Child nodes will describe the individual
debug blocks defined within this memory space.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,dcsr" and "simple-bus".
	The DCSR space exists in the memory-mapped bus.

	- #address-cells
	Usage: required
	Value type: <u32>
	Definition: A standard property.  Defines the number of cells
	or representing physical addresses in child nodes.

	- #size-cells
	Usage: required
	Value type: <u32>
	Definition: A standard property.  Defines the number of cells
	or representing the size of physical addresses in
	child nodes.

	- ranges
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property. Specifies the physical address
	range of the DCSR space.

EXAMPLE
	dcsr: dcsr@f00000000 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "fsl,dcsr", "simple-bus";
		ranges = <0x00000000 0xf 0x00000000 0x01008000>;
	};

=====================================================================
Event Processing Unit

This node represents the region of DCSR space allocated to the EPU

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,dcsr-epu"

	- interrupts
	Usage: required
	Value type: <prop_encoded-array>
	Definition:  Specifies the interrupts generated by the EPU.
	The value of the interrupts property consists of three
	interrupt specifiers. The format of the specifier is defined
	by the binding document describing the node's interrupt parent.

	The EPU counters can be configured to assert the performance
	monitor interrupt signal based on either counter overflow or value
	match. Which counter asserted the interrupt is captured in an EPU
	Counter Interrupt Status Register (EPCPUISR).

	The EPU unit can also be configured to assert either or both of
	two interrupt signals based on debug event sources within the SoC.
	The interrupt signals are epu_xt_int0 and epu_xt_int1.
	Which event source asserted the interrupt is captured in an EPU
	Interrupt Status Register (EPISR0,EPISR1).

	Interrupt numbers are listed in order (perfmon, event0, event1).

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
	dcsr-epu@0 {
		compatible = "fsl,dcsr-epu";
		interrupts = <52 2 0 0
			      84 2 0 0
			      85 2 0 0>;
		interrupt-parent = <&mpic>;
		reg = <0x0 0x1000>;
	};

=======================================================================
Nexus Port Controller

This node represents the region of DCSR space allocated to the NPC

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,dcsr-npc"

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.
	The Nexus Port controller occupies two regions in the DCSR space
	with distinct functionality.

	The first register range describes the Nexus Port Controller
	control and status registers.

	The second register range describes the Nexus Port Controller
	internal trace buffer. The NPC trace buffer is a small memory buffer
	which stages the nexus trace data for transmission via the Aurora port
	or to a DDR based trace buffer. In some configurations the NPC trace
	buffer can be the only trace buffer used.

EXAMPLE
		dcsr-npc {
			compatible = "fsl,dcsr-npc";
			reg = <0x1000 0x1000 0x1000000 0x8000>;
		};

=======================================================================
Nexus Concentrator

This node represents the region of DCSR space allocated to the NXC

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,dcsr-nxc"

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
		dcsr-nxc@2000 {
			compatible = "fsl,dcsr-nxc";
			reg = <0x2000 0x1000>;
		};
=======================================================================
CoreNet Debug Controller

This node represents the region of DCSR space allocated to
the CoreNet Debug controller.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,dcsr-corenet"

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.
	The CoreNet Debug controller occupies two regions in the DCSR space
	with distinct functionality.

	The first register range describes the CoreNet Debug Controller
	functionalty to perform transaction and transaction attribute matches.

	The second register range describes the CoreNet Debug Controller
	functionalty to trigger event notifications and debug traces.

EXAMPLE
		dcsr-corenet {
			compatible = "fsl,dcsr-corenet";
			reg = <0x8000 0x1000 0xB0000 0x1000>;
		};

=======================================================================
Data Path Debug controller

This node represents the region of DCSR space allocated to
the DPAA Debug Controller. This controller controls debug configuration
for the QMAN and FMAN blocks.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include both an identifier specific to the SoC
	or Debug IP of the form "fsl,<soc>-dcsr-dpaa" in addition to the
	generic compatible string "fsl,dcsr-dpaa".

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
		dcsr-dpaa@9000 {
			compatible = "fsl,p4080-dcsr-dpaa", "fsl,dcsr-dpaa";
			reg = <0x9000 0x1000>;
		};

=======================================================================
OCeaN Debug controller

This node represents the region of DCSR space allocated to
the OCN Debug Controller.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include both an identifier specific to the SoC
	or Debug IP of the form "fsl,<soc>-dcsr-ocn" in addition to the
	generic compatible string "fsl,dcsr-ocn".

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
		dcsr-ocn@11000 {
			compatible = "fsl,p4080-dcsr-ocn", "fsl,dcsr-ocn";
			reg = <0x11000 0x1000>;
		};

=======================================================================
DDR Controller Debug controller

This node represents the region of DCSR space allocated to
the OCN Debug Controller.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,dcsr-ddr"

	- dev-handle
	Usage: required
	Definition: A phandle to associate this debug node with its
	component controller.

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
		dcsr-ddr@12000 {
			compatible = "fsl,dcsr-ddr";
			dev-handle = <&ddr1>;
			reg = <0x12000 0x1000>;
		};

=======================================================================
Nexus Aurora Link Controller

This node represents the region of DCSR space allocated to
the NAL Controller.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include both an identifier specific to the SoC
	or Debug IP of the form "fsl,<soc>-dcsr-nal" in addition to the
	generic compatible string "fsl,dcsr-nal".

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
		dcsr-nal@18000 {
			compatible = "fsl,p4080-dcsr-nal", "fsl,dcsr-nal";
			reg = <0x18000 0x1000>;
		};

=======================================================================
Run Control and Power Management

This node represents the region of DCSR space allocated to
the RCPM Debug Controller. This functionlity is limited to the
control the debug operations of the SoC and cores.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include both an identifier specific to the SoC
	or Debug IP of the form "fsl,<soc>-dcsr-rcpm" in addition to the
	generic compatible string "fsl,dcsr-rcpm".

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
		dcsr-rcpm@22000 {
			compatible = "fsl,p4080-dcsr-rcpm", "fsl,dcsr-rcpm";
			reg = <0x22000 0x1000>;
		};

=======================================================================
Core Service Bridge Proxy

This node represents the region of DCSR space allocated to
the Core Service Bridge Proxies.
There is one Core Service Bridge Proxy device for each CPU in the system.
This functionlity provides access to the debug operations of the CPU.

PROPERTIES

	- compatible
	Usage: required
	Value type: <string>
	Definition: Must include both an identifier specific to the cpu
	of the form "fsl,dcsr-<cpu>-sb-proxy" in addition to the
	generic compatible string "fsl,dcsr-cpu-sb-proxy".

	- cpu-handle
	Usage: required
	Definition: A phandle to associate this debug node with its cpu.

	- reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  Specifies the physical address
	offset and length of the DCSR space registers of the device
	configuration block.

EXAMPLE
		dcsr-cpu-sb-proxy@40000 {
			compatible = "fsl,dcsr-e500mc-sb-proxy",
				     "fsl,dcsr-cpu-sb-proxy";
			cpu-handle = <&cpu0>;
			reg = <0x40000 0x1000>;
		};
		dcsr-cpu-sb-proxy@41000 {
			compatible = "fsl,dcsr-e500mc-sb-proxy",
				     "fsl,dcsr-cpu-sb-proxy";
			cpu-handle = <&cpu1>;
			reg = <0x41000 0x1000>;
		};

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


code:
* Freescale Display Interface Unit

The Freescale DIU is a LCD controller, with proper hardware, it can also
drive DVI monitors.

Required properties:
- compatible : should be "fsl,diu" or "fsl,mpc5121-diu".
- reg : should contain at least address and length of the DIU register
  set.
- interrupts : one DIU interrupt should be described here.

Optional properties:
- edid : verbatim EDID data block describing attached display.
  Data from the detailed timing descriptor will be used to
  program the display controller.

Example (MPC8610HPCD):
	display@2c000 {
		compatible = "fsl,diu";
		reg = <0x2c000 100>;
		interrupts = <72 2>;
		interrupt-parent = <&mpic>;
	};

Example for MPC5121:
	display@2100 {
		compatible = "fsl,mpc5121-diu";
		reg = <0x2100 0x100>;
		interrupts = <64 0x8>;
		interrupt-parent = <&ipic>;
		edid = [edid-data];
	};


code:
* Freescale DMA Controllers

** Freescale Elo DMA Controller
   This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx
   series chips such as mpc8315, mpc8349, mpc8379 etc.

Required properties:

- compatible        : must include "fsl,elo-dma"
- reg               : DMA General Status Register, i.e. DGSR which contains
                      status for all the 4 DMA channels
- ranges            : describes the mapping between the address space of the
                      DMA channels and the address space of the DMA controller
- cell-index        : controller index.  0 for controller @ 0x8100
- interrupts        : interrupt specifier for DMA IRQ

- DMA channel nodes:
        - compatible        : must include "fsl,elo-dma-channel"
                              However, see note below.
        - reg               : DMA channel specific registers
        - cell-index        : DMA channel index starts at 0.

Optional properties:
        - interrupts        : interrupt specifier for DMA channel IRQ
                              (on 83xx this is expected to be identical to
                              the interrupts property of the parent node)

Example:
	dma@82a8 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
		reg = <0x82a8 4>;
		ranges = <0 0x8100 0x1a4>;
		interrupt-parent = <&ipic>;
		interrupts = <71 8>;
		cell-index = <0>;
		dma-channel@0 {
			compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
			cell-index = <0>;
			reg = <0 0x80>;
			interrupt-parent = <&ipic>;
			interrupts = <71 8>;
		};
		dma-channel@80 {
			compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
			cell-index = <1>;
			reg = <0x80 0x80>;
			interrupt-parent = <&ipic>;
			interrupts = <71 8>;
		};
		dma-channel@100 {
			compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
			cell-index = <2>;
			reg = <0x100 0x80>;
			interrupt-parent = <&ipic>;
			interrupts = <71 8>;
		};
		dma-channel@180 {
			compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
			cell-index = <3>;
			reg = <0x180 0x80>;
			interrupt-parent = <&ipic>;
			interrupts = <71 8>;
		};
	};

** Freescale EloPlus DMA Controller
   This is a 4-channel DMA controller with extended addresses and chaining,
   mainly used in Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as
   mpc8540, mpc8641 p4080, bsc9131 etc.

Required properties:

- compatible        : must include "fsl,eloplus-dma"
- reg               : DMA General Status Register, i.e. DGSR which contains
                      status for all the 4 DMA channels
- cell-index        : controller index.  0 for controller @ 0x21000,
                                         1 for controller @ 0xc000
- ranges            : describes the mapping between the address space of the
                      DMA channels and the address space of the DMA controller

- DMA channel nodes:
        - compatible        : must include "fsl,eloplus-dma-channel"
                              However, see note below.
        - cell-index        : DMA channel index starts at 0.
        - reg               : DMA channel specific registers
        - interrupts        : interrupt specifier for DMA channel IRQ

Example:
	dma@21300 {
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
		reg = <0x21300 4>;
		ranges = <0 0x21100 0x200>;
		cell-index = <0>;
		dma-channel@0 {
			compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
			reg = <0 0x80>;
			cell-index = <0>;
			interrupt-parent = <&mpic>;
			interrupts = <20 2>;
		};
		dma-channel@80 {
			compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
			reg = <0x80 0x80>;
			cell-index = <1>;
			interrupt-parent = <&mpic>;
			interrupts = <21 2>;
		};
		dma-channel@100 {
			compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
			reg = <0x100 0x80>;
			cell-index = <2>;
			interrupt-parent = <&mpic>;
			interrupts = <22 2>;
		};
		dma-channel@180 {
			compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
			reg = <0x180 0x80>;
			cell-index = <3>;
			interrupt-parent = <&mpic>;
			interrupts = <23 2>;
		};
	};

** Freescale Elo3 DMA Controller
   DMA controller which has same function as EloPlus except that Elo3 has 8
   channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
   series chips, such as t1040, t4240, b4860.

Required properties:

- compatible        : must include "fsl,elo3-dma"
- reg               : contains two entries for DMA General Status Registers,
                      i.e. DGSR0 which includes status for channel 1~4, and
                      DGSR1 for channel 5~8
- ranges            : describes the mapping between the address space of the
                      DMA channels and the address space of the DMA controller

- DMA channel nodes:
        - compatible        : must include "fsl,eloplus-dma-channel"
        - reg               : DMA channel specific registers
        - interrupts        : interrupt specifier for DMA channel IRQ

Example:
dma@100300 {
	#address-cells = <1>;
	#size-cells = <1>;
	compatible = "fsl,elo3-dma";
	reg = <0x100300 0x4>,
	      <0x100600 0x4>;
	ranges = <0x0 0x100100 0x500>;
	dma-channel@0 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x0 0x80>;
		interrupts = <28 2 0 0>;
	};
	dma-channel@80 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x80 0x80>;
		interrupts = <29 2 0 0>;
	};
	dma-channel@100 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x100 0x80>;
		interrupts = <30 2 0 0>;
	};
	dma-channel@180 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x180 0x80>;
		interrupts = <31 2 0 0>;
	};
	dma-channel@300 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x300 0x80>;
		interrupts = <76 2 0 0>;
	};
	dma-channel@380 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x380 0x80>;
		interrupts = <77 2 0 0>;
	};
	dma-channel@400 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x400 0x80>;
		interrupts = <78 2 0 0>;
	};
	dma-channel@480 {
		compatible = "fsl,eloplus-dma-channel";
		reg = <0x480 0x80>;
		interrupts = <79 2 0 0>;
	};
};

Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma).  Any DMA channel used by fsldma cannot be used by another
DMA driver, such as the SSI sound drivers for the MPC8610.  Therefore, any DMA
channel that should be used for another driver should not use
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel".  For the SSI drivers, for
example, the compatible property should be "fsl,ssi-dma-channel".  See ssi.txt
for more information.


code:
=====================================================================
E500 LAW & Coherency Module Device Tree Binding
Copyright (C) 2009 Freescale Semiconductor Inc.
=====================================================================

Local Access Window (LAW) Node

The LAW node represents the region of CCSR space where local access
windows are configured.  For ECM based devices this is the first 4k
of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some
number of local access windows as specified by fsl,num-laws.

PROPERTIES

  - compatible
      Usage: required
      Value type: <string>
      Definition: Must include "fsl,ecm-law"

  - reg
      Usage: required
      Value type: <prop-encoded-array>
      Definition: A standard property.  The value specifies the
          physical address offset and length of the CCSR space
          registers.

  - fsl,num-laws
      Usage: required
      Value type: <u32>
      Definition: The value specifies the number of local access
          windows for this device.

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

E500 Coherency Module Node

The E500 LAW node represents the region of CCSR space where ECM config
and error reporting registers exist, this is the second 4k (0x1000)
of CCSR space.

PROPERTIES

  - compatible
      Usage: required
      Value type: <string>
      Definition: Must include "fsl,CHIP-ecm", "fsl,ecm" where
      CHIP is the processor (mpc8572, mpc8544, etc.)

  - reg
      Usage: required
      Value type: <prop-encoded-array>
      Definition: A standard property.  The value specifies the
          physical address offset and length of the CCSR space
          registers.

   - interrupts
      Usage: required
      Value type: <prop-encoded-array>

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


code:
===============================================================================
Freescale Interlaken Look-Aside Controller Device Bindings
Copyright 2012 Freescale Semiconductor Inc.

CONTENTS
  - Interlaken Look-Aside Controller (LAC) Node
  - Example LAC Node
  - Interlaken Look-Aside Controller (LAC) Software Portal Node
  - Interlaken Look-Aside Controller (LAC) Software Portal Child Nodes
  - Example LAC SWP Node with Child Nodes

==============================================================================
Interlaken Look-Aside Controller (LAC) Node

DESCRIPTION

The Interlaken is a narrow, high speed channelized chip-to-chip interface. To
facilitate interoperability between a data path device and a look-aside
co-processor, the Interlaken Look-Aside protocol is defined for short
transaction-related transfers. Although based on the Interlaken protocol,
Interlaken Look-Aside is not directly compatible with Interlaken and can be
considered a different operation mode.

The Interlaken LA controller connects internal platform to Interlaken serial
interface. It accepts LA command through software portals, which are system
memory mapped 4KB spaces. The LA commands are then translated into the
Interlaken control words and data words, which are sent on TX side to TCAM
through SerDes lanes.

There are two 4KiB spaces defined within the LAC global register memory map.
There is a full register set at 0x0000-0x0FFF (also known as the "hypervisor"
version), and a subset at 0x1000-0x1FFF.  The former is a superset of the
latter, and includes certain registers that should not be accessible to
partitioned software.  Separate nodes are used for each region, with a phandle
linking the hypervisor node to the normal operating node.

PROPERTIES

  - compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,interlaken-lac". This represents only
		those LAC CCSR registers not protected in partitioned
		software. The version of the device is determined by the LAC
		IP Block Revision Register (IPBRR0) at offset 0x0BF8.

		Table of correspondences between IPBRR0 values and example
		chips:
			Value		Device
			-----------	-------
			0x02000100	T4240

		The Hypervisor node has a different compatible. It must include
		"fsl,interlaken-lac-hv". This node represents the protected
		LAC register space and is required except inside a partition
		where access to the hypervisor node is to be denied.

  - fsl,non-hv-node
	Usage: required in "fsl,interlaken-lac-hv"
	Value type: <phandle>
	Definition: Points to the non-protected LAC CCSR mapped register space
		node.

  - reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property. The first resource represents the
		Interlaken LAC configuration registers.

  - interrupts:
	Usage: required in non-hv node only
	Value type: <prop-encoded-array>
	Definition: Interrupt mapping for Interlaken LAC error IRQ.

EXAMPLE
	lac: lac@229000 {
		compatible = "fsl,interlaken-lac"
		reg = <0x229000 0x1000>;
		interrupts = <16 2 1 18>;
	};

	lac-hv@228000 {
		compatible = "fsl,interlaken-lac-hv"
		reg = <0x228000 0x1000>;
		fsl,non-hv-node = <&lac>;
	};

===============================================================================
Interlaken Look-Aside Controller (LAC) Software Portal Container Node

DESCRIPTION
The Interlaken Look-Aside Controller (LAC) utilizes Software Portals to accept
Interlaken Look-Aside (ILA) commands. The Interlaken LAC software portal
memory map occupies 128KB of memory space. The software portal memory space is
intended to be cache-enabled. WIMG for each software space is required to be
0010 if stashing is enabled; otherwise, WIMG can be 0000 or 0010.

PROPERTIES

  - #address-cells
	Usage: required
	Value type: <u32>
	Definition: A standard property. Must have a value of 1.

  - #size-cells
	Usage: required
	Value type: <u32>
	Definition: A standard property. Must have a value of 1.

  - compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,interlaken-lac-portals"

  - ranges
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property. Specifies the address and length
		of the LAC portal memory space.

===============================================================================
Interlaken Look-Aside Controller (LAC) Software Portals Child Nodes

DESCRIPTION
There are up to 24 available software portals with each software portal
requiring 4KB of consecutive memory within the software portal memory mapped
space.

PROPERTIES

  - compatible
	Usage: required
	Value type: <string>
	Definition: Must include "fsl,interlaken-lac-portal-vX.Y" where X is
		the Major version (IP_MJ) found in the LAC IP Block Revision
		Register (IPBRR0), at offset 0x0BF8, and Y is the Minor version
		(IP_MN).

		Table of correspondences between version values and example chips:
		    Value	Device
		    ------	-------
		      1.0	T4240

  - reg
	Usage: required
	Value type: <prop-encoded-array>
	Definition: A standard property.  The first resource represents the
		Interlaken LAC software portal registers.

  - fsl,liodn
	Value type: <u32>
	Definition: The logical I/O device number (LIODN) for this device.  The
		LIODN is a number expressed by this device and used to perform
		look-ups in the IOMMU (PAMU) address table when performing
		DMAs. This property is automatically added by u-boot.

===============================================================================
EXAMPLE

lac-portals {
	#address-cells = <0x1>;
	#size-cells = <0x1>;
	compatible = "fsl,interlaken-lac-portals";
	ranges = <0x0 0xf 0xf4400000 0x20000>;

	lportal0: lac-portal@0 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x204>;
		reg = <0x0 0x1000>;
	};

	lportal1: lac-portal@1000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x205>;
		reg = <0x1000 0x1000>;
	};

	lportal2: lac-portal@2000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x206>;
		reg = <0x2000 0x1000>;
	};

	lportal3: lac-portal@3000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x207>;
		reg = <0x3000 0x1000>;
	};

	lportal4: lac-portal@4000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x208>;
		reg = <0x4000 0x1000>;
	};

	lportal5: lac-portal@5000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x209>;
		reg = <0x5000 0x1000>;
	};

	lportal6: lac-portal@6000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x20A>;
		reg = <0x6000 0x1000>;
	};

	lportal7: lac-portal@7000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x20B>;
		reg = <0x7000 0x1000>;
	};

	lportal8: lac-portal@8000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x20C>;
		reg = <0x8000 0x1000>;
	};

	lportal9: lac-portal@9000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x20D>;
		reg = <0x9000 0x1000>;
	};

	lportal10: lac-portal@a000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x20E>;
		reg = <0xA000 0x1000>;
	};

	lportal11: lac-portal@b000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x20F>;
		reg = <0xB000 0x1000>;
	};

	lportal12: lac-portal@c000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x210>;
		reg = <0xC000 0x1000>;
	};

	lportal13: lac-portal@d000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x211>;
		reg = <0xD000 0x1000>;
	};

	lportal14: lac-portal@e000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x212>;
		reg = <0xE000 0x1000>;
	};

	lportal15: lac-portal@f000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x213>;
		reg = <0xF000 0x1000>;
	};

	lportal16: lac-portal@10000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x214>;
		reg = <0x10000 0x1000>;
	};

	lportal17: lac-portal@11000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x215>;
		reg = <0x11000 0x1000>;
	};

	lportal8: lac-portal@1200 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x216>;
		reg = <0x12000 0x1000>;
	};

	lportal19: lac-portal@13000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x217>;
		reg = <0x13000 0x1000>;
	};

	lportal20: lac-portal@14000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x218>;
		reg = <0x14000 0x1000>;
	};

	lportal21: lac-portal@15000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x219>;
		reg = <0x15000 0x1000>;
	};

	lportal22: lac-portal@16000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x21A>;
		reg = <0x16000 0x1000>;
	};

	lportal23: lac-portal@17000 {
		compatible = "fsl,interlaken-lac-portal-v1.0";
		fsl,liodn = <0x21B>;
		reg = <0x17000 0x1000>;
	};
};


code:
Freescale L2 Cache Controller

L2 cache is present in Freescale's QorIQ and QorIQ Qonverge platforms.
The cache bindings explained below are Devicetree Specification compliant

Required Properties:

- compatible	: Should include one of the following:
		  "fsl,b4420-l2-cache-controller"
		  "fsl,b4860-l2-cache-controller"
		  "fsl,bsc9131-l2-cache-controller"
		  "fsl,bsc9132-l2-cache-controller"
		  "fsl,c293-l2-cache-controller"
		  "fsl,mpc8536-l2-cache-controller"
		  "fsl,mpc8540-l2-cache-controller"
		  "fsl,mpc8541-l2-cache-controller"
		  "fsl,mpc8544-l2-cache-controller"
		  "fsl,mpc8548-l2-cache-controller"
		  "fsl,mpc8555-l2-cache-controller"
		  "fsl,mpc8560-l2-cache-controller"
		  "fsl,mpc8568-l2-cache-controller"
		  "fsl,mpc8569-l2-cache-controller"
		  "fsl,mpc8572-l2-cache-controller"
		  "fsl,p1010-l2-cache-controller"
		  "fsl,p1011-l2-cache-controller"
		  "fsl,p1012-l2-cache-controller"
		  "fsl,p1013-l2-cache-controller"
		  "fsl,p1014-l2-cache-controller"
		  "fsl,p1015-l2-cache-controller"
		  "fsl,p1016-l2-cache-controller"
		  "fsl,p1020-l2-cache-controller"
		  "fsl,p1021-l2-cache-controller"
		  "fsl,p1022-l2-cache-controller"
		  "fsl,p1023-l2-cache-controller"
		  "fsl,p1024-l2-cache-controller"
		  "fsl,p1025-l2-cache-controller"
		  "fsl,p2010-l2-cache-controller"
		  "fsl,p2020-l2-cache-controller"
		  "fsl,t2080-l2-cache-controller"
		  "fsl,t4240-l2-cache-controller"
		  and "cache".
- reg		: Address and size of L2 cache controller registers
- cache-size	: Size of the entire L2 cache
- interrupts	: Error interrupt of L2 controller
- cache-line-size : Size of L2 cache lines

Example:

	L2: l2-cache-controller@20000 {
		compatible = "fsl,bsc9132-l2-cache-controller", "cache";
		reg = <0x20000 0x1000>;
		cache-line-size = <32>; // 32 bytes
		cache-size = <0x40000>; // L2,256K
		interrupts = <16 2 1 0>;
	};


code:
* Chipselect/Local Bus

Properties:
- name : Should be localbus
- #address-cells : Should be either two or three.  The first cell is the
                   chipselect number, and the remaining cells are the
                   offset into the chipselect.
- #size-cells : Either one or two, depending on how large each chipselect
                can be.
- ranges : Each range corresponds to a single chipselect, and cover
           the entire access window as configured.

Example:
	localbus@f0010100 {
		compatible = "fsl,mpc8272-localbus",
			   "fsl,pq2-localbus";
		#address-cells = <2>;
		#size-cells = <1>;
		reg = <0xf0010100 0x40>;

		ranges = <0x0 0x0 0xfe000000 0x02000000
			  0x1 0x0 0xf4500000 0x00008000
			  0x2 0x0 0xfd810000 0x00010000>;

		flash@0,0 {
			compatible = "jedec-flash";
			reg = <0x0 0x0 0x2000000>;
			bank-width = <4>;
			device-width = <1>;
		};

		board-control@1,0 {
			reg = <0x1 0x0 0x20>;
			compatible = "fsl,mpc8272ads-bcsr";
		};

		simple-periph@2,0 {
			compatible = "fsl,elbc-gpcm-uio";
			reg = <0x2 0x0 0x10000>;
			elbc-gpcm-br = <0xfd810800>;
			elbc-gpcm-or = <0xffff09f7>;
		};
	};


code:
=====================================================================
MPX LAW & Coherency Module Device Tree Binding
Copyright (C) 2009 Freescale Semiconductor Inc.
=====================================================================

Local Access Window (LAW) Node

The LAW node represents the region of CCSR space where local access
windows are configured.  For MCM based devices this is the first 4k
of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some
number of local access windows as specified by fsl,num-laws.

PROPERTIES

  - compatible
      Usage: required
      Value type: <string>
      Definition: Must include "fsl,mcm-law"

  - reg
      Usage: required
      Value type: <prop-encoded-array>
      Definition: A standard property.  The value specifies the
          physical address offset and length of the CCSR space
          registers.

  - fsl,num-laws
      Usage: required
      Value type: <u32>
      Definition: The value specifies the number of local access
          windows for this device.

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

MPX Coherency Module Node

The MPX LAW node represents the region of CCSR space where MCM config
and error reporting registers exist, this is the second 4k (0x1000)
of CCSR space.

PROPERTIES

  - compatible
      Usage: required
      Value type: <string>
      Definition: Must include "fsl,CHIP-mcm", "fsl,mcm" where
      CHIP is the processor (mpc8641, mpc8610, etc.)

  - reg
      Usage: required
      Value type: <prop-encoded-array>
      Definition: A standard property.  The value specifies the
          physical address offset and length of the CCSR space
          registers.

   - interrupts
      Usage: required
      Value type: <prop-encoded-array>

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


code:
Freescale MPC8349E-mITX-compatible Power Management Micro Controller Unit (MCU)

Required properties:
- compatible : "fsl,<mcu-chip>-<board>", "fsl,mcu-mpc8349emitx".
- reg : should specify I2C address (0x0a).
- #gpio-cells : should be 2.
- gpio-controller : should be present.

Example:

mcu@a {
	#gpio-cells = <2>;
	compatible = "fsl,mc9s08qg8-mpc8349emitx",
		     "fsl,mcu-mpc8349emitx";
	reg = <0x0a>;
	gpio-controller;
};


code:
MPC5121 PSC Device Tree Bindings

PSC in UART mode
----------------

For PSC in UART mode the needed PSC serial devices
are specified by fsl,mpc5121-psc-uart nodes in the
fsl,mpc5121-immr SoC node. Additionally the PSC FIFO
Controller node fsl,mpc5121-psc-fifo is required there:

fsl,mpc512x-psc-uart nodes
--------------------------

Required properties :
 - compatible : Should contain "fsl,<soc>-psc-uart" and "fsl,<soc>-psc"
   Supported <soc>s: mpc5121, mpc5125
 - reg : Offset and length of the register set for the PSC device
 - interrupts : <a b> where a is the interrupt number of the
   PSC FIFO Controller and b is a field that represents an
   encoding of the sense and level information for the interrupt.

Recommended properties :
 - fsl,rx-fifo-size : the size of the RX fifo slice (a multiple of 4)
 - fsl,tx-fifo-size : the size of the TX fifo slice (a multiple of 4)

PSC in SPI mode
---------------

Similar to the UART mode a PSC can be operated in SPI mode. The compatible used
for that is fsl,mpc5121-psc-spi. It requires a fsl,mpc5121-psc-fifo as well.
The required and recommended properties are identical to the
fsl,mpc5121-psc-uart nodes, just use spi instead of uart in the compatible
string.

fsl,mpc512x-psc-fifo node
-------------------------

Required properties :
 - compatible : Should be "fsl,<soc>-psc-fifo"
   Supported <soc>s: mpc5121, mpc5125
 - reg : Offset and length of the register set for the PSC
         FIFO Controller
 - interrupts : <a b> where a is the interrupt number of the
   PSC FIFO Controller and b is a field that represents an
   encoding of the sense and level information for the interrupt.

Recommended properties :
 - clocks : specifies the clock needed to operate the fifo controller
 - clock-names : name(s) for the clock(s) listed in clocks

Example for a board using PSC0 and PSC1 devices in serial mode:

serial@11000 {
	compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
	cell-index = <0>;
	reg = <0x11000 0x100>;
	interrupts = <40 0x8>;
	interrupt-parent = < &ipic >;
	fsl,rx-fifo-size = <16>;
	fsl,tx-fifo-size = <16>;
};

serial@11100 {
	compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
	cell-index = <1>;
	reg = <0x11100 0x100>;
	interrupts = <40 0x8>;
	interrupt-parent = < &ipic >;
	fsl,rx-fifo-size = <16>;
	fsl,tx-fifo-size = <16>;
};

pscfifo@11f00 {
	compatible = "fsl,mpc5121-psc-fifo";
	reg = <0x11f00 0x100>;
	interrupts = <40 0x8>;
	interrupt-parent = < &ipic >;
};


code:
Freescale MPC512x LocalPlus Bus FIFO (called SCLPC in the Reference Manual)

Required properties:
- compatible: should be "fsl,mpc512x-lpbfifo";
- reg: should contain the offset and length of SCLPC register set;
- interrupts: should contain the interrupt specifier for SCLPC; syntax of an
    interrupt client node is described in interrupt-controller/interrupts.txt;
- dmas: should contain the DMA specifier for SCLPC as described at
    dma/dma.txt and dma/mpc512x-dma.txt;
- dma-names: should be "rx-tx";

Example:

	sclpc@10100 {
		compatible = "fsl,mpc512x-lpbfifo";
		reg = <0x10100 0x50>;
		interrupts = <7 0x8>;
		dmas = <&dma0 26>;
		dma-names = "rx-tx";
	};


code:
MPC5200 Device Tree Bindings
----------------------------

(c) 2006-2009 Secret Lab Technologies Ltd
Grant Likely <grant.likely@secretlab.ca>

Naming conventions
------------------
For mpc5200 on-chip devices, the format for each compatible value is
<chip>-<device>[-<mode>].  The OS should be able to match a device driver
to the device based solely on the compatible value.  If two drivers
match on the compatible list; the 'most compatible' driver should be
selected.

The split between the MPC5200 and the MPC5200B leaves a bit of a
conundrum.  How should the compatible property be set up to provide
maximum compatibility information; but still accurately describe the
chip?  For the MPC5200; the answer is easy.  Most of the SoC devices
originally appeared on the MPC5200.  Since they didn't exist anywhere
else; the 5200 compatible properties will contain only one item;
"fsl,mpc5200-<device>".

The 5200B is almost the same as the 5200, but not quite.  It fixes
silicon bugs and it adds a small number of enhancements.  Most of the
devices either provide exactly the same interface as on the 5200.  A few
devices have extra functions but still have a backwards compatible mode.
To express this information as completely as possible, 5200B device trees
should have two items in the compatible list:
	compatible = "fsl,mpc5200b-<device>","fsl,mpc5200-<device>";

It is *strongly* recommended that 5200B device trees follow this convention
(instead of only listing the base mpc5200 item).

ie. ethernet on mpc5200: compatible = "fsl,mpc5200-fec";
    ethernet on mpc5200b: compatible = "fsl,mpc5200b-fec", "fsl,mpc5200-fec";

Modal devices, like PSCs, also append the configured function to the
end of the compatible field.  ie. A PSC in i2s mode would specify
"fsl,mpc5200-psc-i2s", not "fsl,mpc5200-i2s".  This convention is chosen to
avoid naming conflicts with non-psc devices providing the same
function.  For example, "fsl,mpc5200-spi" and "fsl,mpc5200-psc-spi" describe
the mpc5200 simple spi device and a PSC spi mode respectively.

At the time of writing, exact chip may be either 'fsl,mpc5200' or
'fsl,mpc5200b'.

The soc node
------------
This node describes the on chip SOC peripherals.  Every mpc5200 based
board will have this node, and as such there is a common naming
convention for SOC devices.

Required properties:
name			description
----			-----------
ranges			Memory range of the internal memory mapped registers.
			Should be <0 [baseaddr] 0xc000>
reg			Should be <[baseaddr] 0x100>
compatible		mpc5200: "fsl,mpc5200-immr"
			mpc5200b: "fsl,mpc5200b-immr"
system-frequency	'fsystem' frequency in Hz; XLB, IPB, USB and PCI
			clocks are derived from the fsystem clock.
bus-frequency		IPB bus frequency in Hz.  Clock rate
			used by most of the soc devices.

soc child nodes
---------------
Any on chip SOC devices available to Linux must appear as soc5200 child nodes.

Note: The tables below show the value for the mpc5200.  A mpc5200b device
tree should use the "fsl,mpc5200b-<device>","fsl,mpc5200-<device>" form.

Required soc5200 child nodes:
name				compatible		Description
----				----------		-----------
cdm@<addr>			fsl,mpc5200-cdm		Clock Distribution
interrupt-controller@<addr>	fsl,mpc5200-pic		need an interrupt
							controller to boot
bestcomm@<addr>			fsl,mpc5200-bestcomm	Bestcomm DMA controller

Recommended soc5200 child nodes; populate as needed for your board
name		compatible		Description
----		----------		-----------
timer@<addr>	fsl,mpc5200-gpt		 General purpose timers
gpio@<addr>	fsl,mpc5200-gpio	 MPC5200 simple gpio controller
gpio@<addr>	fsl,mpc5200-gpio-wkup	 MPC5200 wakeup gpio controller
rtc@<addr>	fsl,mpc5200-rtc		 Real time clock
mscan@<addr>	fsl,mpc5200-mscan	 CAN bus controller
pci@<addr>	fsl,mpc5200-pci		 PCI bridge
serial@<addr>	fsl,mpc5200-psc-uart	 PSC in serial mode
i2s@<addr>	fsl,mpc5200-psc-i2s	 PSC in i2s mode
ac97@<addr>	fsl,mpc5200-psc-ac97	 PSC in ac97 mode
spi@<addr>	fsl,mpc5200-psc-spi	 PSC in spi mode
irda@<addr>	fsl,mpc5200-psc-irda	 PSC in IrDA mode
spi@<addr>	fsl,mpc5200-spi		 MPC5200 spi device
ethernet@<addr>	fsl,mpc5200-fec		 MPC5200 ethernet device
ata@<addr>	fsl,mpc5200-ata		 IDE ATA interface
i2c@<addr>	fsl,mpc5200-i2c		 I2C controller
usb@<addr>	fsl,mpc5200-ohci,ohci-be USB controller
xlb@<addr>	fsl,mpc5200-xlb		 XLB arbitrator

fsl,mpc5200-gpt nodes
---------------------
On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the board
design supports the internal wdt, then the device node for GPT0 should
include the empty property 'fsl,has-wdt'.  Note that this does not activate
the watchdog.  The timer will function as a GPT if the timer api is used, and
it will function as watchdog if the watchdog device is used.  The watchdog
mode has priority over the gpt mode, i.e. if the watchdog is activated, any
gpt api call to this timer will fail with -EBUSY.

If you add the property
	fsl,wdt-on-boot = <n>;
GPT0 will be marked as in-use watchdog, i.e. blocking every gpt access to it.
If n>0, the watchdog is started with a timeout of n seconds.  If n=0, the
configuration of the watchdog is not touched.  This is useful in two cases:
- just mark GPT0 as watchdog, blocking gpt accesses, and configure it later;
- do not touch a configuration assigned by the boot loader which supervises
  the boot process itself.

The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option.

An mpc5200-gpt can be used as a single line GPIO controller.  To do so,
add the following properties to the gpt node:
	gpio-controller;
	#gpio-cells = <2>;
When referencing the GPIO line from another node, the first cell must always
be zero and the second cell represents the gpio flags and described in the
gpio device tree binding.

An mpc5200-gpt can be used as a single line edge sensitive interrupt
controller.  To do so, add the following properties to the gpt node:
	interrupt-controller;
	#interrupt-cells = <1>;
When referencing the IRQ line from another node, the cell represents the
sense mode; 1 for edge rising, 2 for edge falling.

fsl,mpc5200-psc nodes
---------------------
The PSCs should include a cell-index which is the index of the PSC in
hardware.  cell-index is used to determine which shared SoC registers to
use when setting up PSC clocking.  cell-index number starts at '0'.  ie:
	PSC1 has 'cell-index = <0>'
	PSC4 has 'cell-index = <3>'

PSC in i2s mode:  The mpc5200 and mpc5200b PSCs are not compatible when in
i2s mode.  An 'mpc5200b-psc-i2s' node cannot include 'mpc5200-psc-i2s' in the
compatible field.

fsl,mpc5200-gpio and fsl,mpc5200-gpio-wkup nodes
------------------------------------------------
Each GPIO controller node should have the empty property gpio-controller and
#gpio-cells set to 2. First cell is the GPIO number which is interpreted
according to the bit numbers in the GPIO control registers. The second cell
is for flags which is currently unused.

fsl,mpc5200-fec nodes
---------------------
The FEC node can specify one of the following properties to configure
the MII link:
- fsl,7-wire-mode - An empty property that specifies the link uses 7-wire
                    mode instead of MII
- current-speed   - Specifies that the MII should be configured for a fixed
                    speed.  This property should contain two cells.  The
                    first cell specifies the speed in Mbps and the second
                    should be '0' for half duplex and '1' for full duplex
- phy-handle      - Contains a phandle to an Ethernet PHY.

Interrupt controller (fsl,mpc5200-pic) node
-------------------------------------------
The mpc5200 pic binding splits hardware IRQ numbers into two levels.  The
split reflects the layout of the PIC hardware itself, which groups
interrupts into one of three groups; CRIT, MAIN or PERP.  Also, the
Bestcomm dma engine has its own set of interrupt sources which are
cascaded off of peripheral interrupt 0, which the driver interprets as a
fourth group, SDMA.

The interrupts property for device nodes using the mpc5200 pic consists
of three cells; <L1 L2 level>

    L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
    L2 := interrupt number; directly mapped from the value in the
          "ICTL PerStat, MainStat, CritStat Encoded Register"
    level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]

For external IRQs, use the following interrupt property values (how to
specify external interrupts is a frequently asked question):
External interrupts:
	external irq0:	interrupts = <0 0 n>;
	external irq1:	interrupts = <1 1 n>;
	external irq2:	interrupts = <1 2 n>;
	external irq3:	interrupts = <1 3 n>;
'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low)

fsl,mpc5200-mscan nodes
-----------------------
See file Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt


code:
* FSL MPIC Message Registers

This binding specifies what properties must be available in the device tree
representation of the message register blocks found in some FSL MPIC
implementations.

Required properties:

    - compatible: Specifies the compatibility list for the message register
      block.  The type shall be <string-list> and the value shall be of the form
      "fsl,mpic-v<version>-msgr", where <version> is the version number of
      the MPIC containing the message registers.

    - reg: Specifies the base physical address(s) and size(s) of the
      message register block's addressable register space.  The type shall be
      <prop-encoded-array>.

    - interrupts: Specifies a list of interrupt-specifiers which are available
      for receiving interrupts. Interrupt-specifier consists of two cells: first
      cell is interrupt-number and second cell is level-sense. The type shall be
      <prop-encoded-array>.

Optional properties:

    - mpic-msgr-receive-mask: Specifies what registers in the containing block
      are allowed to receive interrupts. The value is a bit mask where a set
      bit at bit 'n' indicates that message register 'n' can receive interrupts.
      Note that "bit 'n'" is numbered from LSB for PPC hardware. The type shall
      be <u32>. If not present, then all of the message registers in the block
      are available.

Aliases:

    An alias should be created for every message register block.  They are not
    required, though.  However, a particular implementation of this binding
    may require aliases to be present.  Aliases are of the form
    'mpic-msgr-block<n>', where <n> is an integer specifying the block's number.
    Numbers shall start at 0.

Example:

	aliases {
		mpic-msgr-block0 = &mpic_msgr_block0;
		mpic-msgr-block1 = &mpic_msgr_block1;
	};

	mpic_msgr_block0: mpic-msgr-block@41400 {
		compatible = "fsl,mpic-v3.1-msgr";
		reg = <0x41400 0x200>;
		// Message registers 0 and 2 in this block can receive interrupts on
		// sources 0xb0 and 0xb2, respectively.
		interrupts = <0xb0 2 0xb2 2>;
		mpic-msgr-receive-mask = <0x5>;
	};

	mpic_msgr_block1: mpic-msgr-block@42400 {
		compatible = "fsl,mpic-v3.1-msgr";
		reg = <0x42400 0x200>;
		// Message registers 0 and 2 in this block can receive interrupts on
		// sources 0xb4 and 0xb6, respectively.
		interrupts = <0xb4 2 0xb6 2>;
		mpic-msgr-receive-mask = <0x5>;
	};


code:
* Freescale MPIC timers

Required properties:
- compatible: "fsl,mpic-global-timer"

- reg : Contains two regions.  The first is the main timer register bank
  (GTCCRxx, GTBCRxx, GTVPRxx, GTDRxx).  The second is the timer control
  register (TCRx) for the group.

- fsl,available-ranges: use <start count> style section to define which
  timer interrupts can be used.  This property is optional; without this,
  all timers within the group can be used.

- interrupts: one interrupt per timer in the group, in order, starting
  with timer zero.  If timer-available-ranges is present, only the
  interrupts that correspond to available timers shall be present.

Example:
	/* Note that this requires #interrupt-cells to be 4 */
	timer0: timer@41100 {
		compatible = "fsl,mpic-global-timer";
		reg = <0x41100 0x100 0x41300 4>;

		/* Another AMP partition is using timers 0 and 1 */
		fsl,available-ranges = <2 2>;

		interrupts = <2 0 3 0
		              3 0 3 0>;
	};

	timer1: timer@42100 {
		compatible = "fsl,mpic-global-timer";
		reg = <0x42100 0x100 0x42300 4>;
		interrupts = <4 0 3 0
		              5 0 3 0
		              6 0 3 0
		              7 0 3 0>;
	};


code:
=====================================================================
Freescale MPIC Interrupt Controller Node
Copyright (C) 2010,2011 Freescale Semiconductor Inc.
=====================================================================

The Freescale MPIC interrupt controller is found on all PowerQUICC
and QorIQ processors and is compatible with the Open PIC.  The
notable difference from Open PIC binding is the addition of 2
additional cells in the interrupt specifier defining interrupt type
information.

PROPERTIES

  - compatible
      Usage: required
      Value type: <string>
      Definition: Shall include "fsl,mpic".  Freescale MPIC
          controllers compatible with this binding have Block
          Revision Registers BRR1 and BRR2 at offset 0x0 and
          0x10 in the MPIC.

  - reg
      Usage: required
      Value type: <prop-encoded-array>
      Definition: A standard property.  Specifies the physical
          offset and length of the device's registers within the
          CCSR address space.

  - interrupt-controller
      Usage: required
      Value type: <empty>
      Definition: Specifies that this node is an interrupt
          controller

  - #interrupt-cells
      Usage: required
      Value type: <u32>
      Definition: Shall be 2 or 4.  A value of 2 means that interrupt
          specifiers do not contain the interrupt-type or type-specific
          information cells.

  - #address-cells
      Usage: required
      Value type: <u32>
      Definition: Shall be 0.

  - pic-no-reset
      Usage: optional
      Value type: <empty>
      Definition: The presence of this property specifies that the
          MPIC must not be reset by the client program, and that
          the boot program has initialized all interrupt source
          configuration registers to a sane state-- masked or
          directed at other cores.  This ensures that the client
          program will not receive interrupts for sources not belonging
          to the client.  The presence of this property also mandates
          that any initialization related to interrupt sources shall
          be limited to sources explicitly referenced in the device tree.

  - big-endian
      Usage: optional
      Value type: <empty>
          If present the MPIC will be assumed to be big-endian.  Some
          device-trees omit this property on MPIC nodes even when the MPIC is
          in fact big-endian, so certain boards override this property.

  - single-cpu-affinity
      Usage: optional
      Value type: <empty>
          If present the MPIC will be assumed to only be able to route
          non-IPI interrupts to a single CPU at a time (EG: Freescale MPIC).

  - last-interrupt-source
      Usage: optional
      Value type: <u32>
          Some MPICs do not correctly report the number of hardware sources
          in the global feature registers.  If specified, this field will
          override the value read from MPIC_GREG_FEATURE_LAST_SRC.

INTERRUPT SPECIFIER DEFINITION

  Interrupt specifiers consists of 4 cells encoded as
  follows:

   <1st-cell>   interrupt-number

                Identifies the interrupt source.  The meaning
                depends on the type of interrupt.

                Note: If the interrupt-type cell is undefined
                (i.e. #interrupt-cells = 2), this cell
                should be interpreted the same as for
                interrupt-type 0-- i.e. an external or
                normal SoC device interrupt.

   <2nd-cell>   level-sense information, encoded as follows:
                    0 = low-to-high edge triggered
                    1 = active low level-sensitive
                    2 = active high level-sensitive
                    3 = high-to-low edge triggered

   <3rd-cell>   interrupt-type

                The following types are supported:

                  0 = external or normal SoC device interrupt

                      The interrupt-number cell contains
                      the SoC device interrupt number.  The
                      type-specific cell is undefined.  The
                      interrupt-number is derived from the
                      MPIC a block of registers referred to as
                      the "Interrupt Source Configuration Registers".
                      Each source has 32-bytes of registers
                      (vector/priority and destination) in this
                      region.   So interrupt 0 is at offset 0x0,
                      interrupt 1 is at offset 0x20, and so on.

                  1 = error interrupt

                      The interrupt-number cell contains
                      the SoC device interrupt number for
                      the error interrupt.  The type-specific
                      cell identifies the specific error
                      interrupt number.

                  2 = MPIC inter-processor interrupt (IPI)

                      The interrupt-number cell identifies
                      the MPIC IPI number.  The type-specific
                      cell is undefined.

                  3 = MPIC timer interrupt

                      The interrupt-number cell identifies
                      the MPIC timer number.  The type-specific
                      cell is undefined.

   <4th-cell>   type-specific information

                The type-specific cell is encoded as follows:

                 - For interrupt-type 1 (error interrupt),
                   the type-specific cell contains the
                   bit number of the error interrupt in the
                   Error Interrupt Summary Register.

EXAMPLE 1
	/*
	 * mpic interrupt controller with 4 cells per specifier
	 */
	mpic: pic@40000 {
		compatible = "fsl,mpic";
		interrupt-controller;
		#interrupt-cells = <4>;
		#address-cells = <0>;
		reg = <0x40000 0x40000>;
	};

EXAMPLE 2
	/*
	 * The MPC8544 I2C controller node has an internal
	 * interrupt number of 27.  As per the reference manual
	 * this corresponds to interrupt source configuration
	 * registers at 0x5_0560.
	 *
	 * The interrupt source configuration registers begin
	 * at 0x5_0000.
	 *
	 * To compute the interrupt specifier interrupt number
         *
	 *       0x560 >> 5 = 43
	 *
	 * The interrupt source configuration registers begin
	 * at 0x5_0000, and so the i2c vector/priority registers
	 * are at 0x5_0560.
	 */
	i2c@3000 {
		#address-cells = <1>;
		#size-cells = <0>;
		cell-index = <0>;
		compatible = "fsl-i2c";
		reg = <0x3000 0x100>;
		interrupts = <43 2>;
		interrupt-parent = <&mpic>;
		dfsrr;
	};

EXAMPLE 3
	/*
	 *  Definition of a node defining the 4
	 *  MPIC IPI interrupts.  Note the interrupt
	 *  type of 2.
	 */
	ipi@410a0 {
		compatible = "fsl,mpic-ipi";
		reg = <0x40040 0x10>;
		interrupts = <0 0 2 0
		              1 0 2 0
		              2 0 2 0
		              3 0 2 0>;
	};

EXAMPLE 4
	/*
	 *  Definition of a node defining the MPIC
	 *  global timers.  Note the interrupt
	 *  type of 3.
	 */
	timer0: timer@41100 {
		compatible = "fsl,mpic-global-timer";
		reg = <0x41100 0x100 0x41300 4>;
		interrupts = <0 0 3 0
		              1 0 3 0
		              2 0 3 0
		              3 0 3 0>;
	};

EXAMPLE 5
	/*
	 * Definition of an error interrupt (interrupt type 1).
	 * SoC interrupt number is 16 and the specific error
         * interrupt bit in the error interrupt summary register
	 * is 23.
	 */
	memory-controller@8000 {
		compatible = "fsl,p4080-memory-controller";
		reg = <0x8000 0x1000>;
		interrupts = <16 2 1 23>;
	};


code:
* Freescale MSI interrupt controller

Required properties:
- compatible : compatible list, may contain one or two entries
  The first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
  etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" or
  "fsl,mpic-msi-v4.3" depending on the parent type and version. If mpic
  version is 4.3, the number of MSI registers is increased to 16, MSIIR1 is
  provided to access these 16 registers, and compatible "fsl,mpic-msi-v4.3"
  should be used. The first entry is optional; the second entry is
  required.

- reg : It may contain one or two regions. The first region should contain
  the address and the length of the shared message interrupt register set.
  The second region should contain the address of aliased MSIIR or MSIIR1
  register for platforms that have such an alias, if using MSIIR1, the second
  region must be added because different MSI group has different MSIIR1 offset.

- interrupts : each one of the interrupts here is one entry per 32 MSIs,
  and routed to the host interrupt controller. the interrupts should
  be set as edge sensitive.  If msi-available-ranges is present, only
  the interrupts that correspond to available ranges shall be present.

Optional properties:
- msi-available-ranges: use <start count> style section to define which
  msi interrupt can be used in the 256 msi interrupts. This property is
  optional, without this, all the MSI interrupts can be used.
  Each available range must begin and end on a multiple of 32 (i.e.
  no splitting an individual MSI register or the associated PIC interrupt).
  MPIC v4.3 does not support this property because the 32 interrupts of an
  individual register are not continuous when using MSIIR1.

- msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register
  is used for MSI messaging.  The address of MSIIR in PCI address space is
  the MSI message address.

  This property may be used in virtualized environments where the hypervisor
  has created an alternate mapping for the MSIR block.  See below for an
  explanation.

Example:
	msi@41600 {
		compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
		reg = <0x41600 0x80>;
		msi-available-ranges = <0 0x100>;
		interrupts = <
			0xe0 0
			0xe1 0
			0xe2 0
			0xe3 0
			0xe4 0
			0xe5 0
			0xe6 0
			0xe7 0>;
		interrupt-parent = <&mpic>;
	};

	msi@41600 {
		compatible = "fsl,mpic-msi-v4.3";
		reg = <0x41600 0x200 0x44148 4>;
		interrupts = <
			0xe0 0 0 0
			0xe1 0 0 0
			0xe2 0 0 0
			0xe3 0 0 0
			0xe4 0 0 0
			0xe5 0 0 0
			0xe6 0 0 0
			0xe7 0 0 0
			0x100 0 0 0
			0x101 0 0 0
			0x102 0 0 0
			0x103 0 0 0
			0x104 0 0 0
			0x105 0 0 0
			0x106 0 0 0
			0x107 0 0 0>;
	};

The Freescale hypervisor and msi-address-64
-------------------------------------------
Normally, PCI devices have access to all of CCSR via an ATMU mapping.  The
Freescale MSI driver calculates the address of MSIIR (in the MSI register
block) and sets that address as the MSI message address.

In a virtualized environment, the hypervisor may need to create an IOMMU
mapping for MSIIR.  The Freescale ePAPR hypervisor has this requirement
because of hardware limitations of the Peripheral Access Management Unit
(PAMU), which is currently the only IOMMU that the hypervisor supports.
The ATMU is programmed with the guest physical address, and the PAMU
intercepts transactions and reroutes them to the true physical address.

In the PAMU, each PCI controller is given only one primary window.  The
PAMU restricts DMA operations so that they can only occur within a window.
Because PCI devices must be able to DMA to memory, the primary window must
be used to cover all of the guest's memory space.

PAMU primary windows can be divided into 256 subwindows, and each
subwindow can have its own address mapping ("guest physical" to "true
physical").  However, each subwindow has to have the same alignment, which
means they cannot be located at just any address.  Because of these
restrictions, it is usually impossible to create a 4KB subwindow that
covers MSIIR where it's normally located.

Therefore, the hypervisor has to create a subwindow inside the same
primary window used for memory, but mapped to the MSIR block (where MSIIR
lives).  The first subwindow after the end of guest memory is used for
this.  The address specified in the msi-address-64 property is the PCI
address of MSIIR.  The hypervisor configures the PAMU to map that address to
the true physical address of MSIIR.


code:
Freescale Peripheral Management Access Unit (PAMU) Device Tree Binding

DESCRIPTION

The PAMU is an I/O MMU that provides device-to-memory access control and
address translation capabilities.

Required properties:

- compatible	: <string>
		  First entry is a version-specific string, such as
		  "fsl,pamu-v1.0".  The second is "fsl,pamu".
- ranges	: <prop-encoded-array>
		  A standard property. Utilized to describe the memory mapped
		  I/O space utilized by the controller.  The size should
		  be set to the total size of the register space of all
		  physically present PAMU controllers.  For example, for
		  PAMU v1.0, on an SOC that has five PAMU devices, the size
		  is 0x5000.
- interrupts	: <prop-encoded-array>
		  Interrupt mappings.  The first tuple is the normal PAMU
		  interrupt, used for reporting access violations.  The second
		  is for PAMU hardware errors, such as PAMU operation errors
		  and ECC errors.
- #address-cells: <u32>
		  A standard property.
- #size-cells	: <u32>
		  A standard property.

Optional properties:
- reg		: <prop-encoded-array>
		  A standard property.   It represents the CCSR registers of
		  all child PAMUs combined.  Include it to provide support
		  for legacy drivers.
- fsl,portid-mapping : <u32>
		  The Coherency Subdomain ID Port Mapping Registers and
		  Snoop ID Port Mapping registers, which are part of the
		  CoreNet Coherency fabric (CCF), provide a CoreNet
		  Coherency Subdomain ID/CoreNet Snoop ID to pamu mapping
		  functions.  Certain bits from these registers should be
		  set if PAMUs should be snooped.  This property defines
		  a bitmask which selects the bits that should be set if
		  PAMUs should be snooped.

Child nodes:

Each child node represents one PAMU controller.  Each SOC device that is
connected to a specific PAMU device should have a "fsl,pamu-phandle" property
that links to the corresponding specific child PAMU controller.

- reg		: <prop-encoded-array>
		  A standard property.  Specifies the physical address and
		  length (relative to the parent 'ranges' property) of this
		  PAMU controller's configuration registers.  The size should
		  be set to the size of this PAMU controllers's register space.
		  For PAMU v1.0, this size is 0x1000.
- fsl,primary-cache-geometry
		: <prop-encoded-array>
		  Two cells that specify the geometry of the primary PAMU
		  cache.  The first is the number of cache lines, and the
		  second is the number of "ways".  For direct-mapped caches,
		  specify a value of 1.
- fsl,secondary-cache-geometry
		: <prop-encoded-array>
		  Two cells that specify the geometry of the secondary PAMU
		  cache.  The first is the number of cache lines, and the
		  second is the number of "ways".  For direct-mapped caches,
		  specify a value of 1.

Device nodes:

Devices that have LIODNs need to specify links to the parent PAMU controller
(the actual PAMU controller that this device is connected to) and a pointer to
the LIODN register, if applicable.

- fsl,iommu-parent
		: <phandle>
		Phandle to the single, specific PAMU controller node to which
		this device is connect.  The PAMU topology is represented in
		the device tree to assist code that dynamically determines the
		best LIODN values to minimize PAMU cache thrashing.

- fsl,liodn-reg : <prop-encoded-array>
		  Two cells that specify the location of the LIODN register
		  for this device.  Required for devices that have a single
		  LIODN.  The first cell is a phandle to a node that contains
		  the registers where the LIODN is to be set.  The second is
		  the offset from the first "reg" resource of the node where
		  the specific LIODN register is located.

Example:

	iommu@20000 {
		compatible = "fsl,pamu-v1.0", "fsl,pamu";
		reg = <0x20000 0x5000>;
		ranges = <0 0x20000 0x5000>;
		fsl,portid-mapping = <0xf80000>;
		#address-cells = <1>;
		#size-cells = <1>;
		interrupts = <
			24 2 0 0
			16 2 1 30>;

		pamu0: pamu@0 {
			reg = <0 0x1000>;
			fsl,primary-cache-geometry = <32 1>;
			fsl,secondary-cache-geometry = <128 2>;
		};

		pamu1: pamu@1000 {
			reg = <0x1000 0x1000>;
			fsl,primary-cache-geometry = <32 1>;
			fsl,secondary-cache-geometry = <128 2>;
		};

		pamu2: pamu@2000 {
			reg = <0x2000 0x1000>;
			fsl,primary-cache-geometry = <32 1>;
			fsl,secondary-cache-geometry = <128 2>;
		};

		pamu3: pamu@3000 {
			reg = <0x3000 0x1000>;
			fsl,primary-cache-geometry = <32 1>;
			fsl,secondary-cache-geometry = <128 2>;
		};

		pamu4: pamu@4000 {
			reg = <0x4000 0x1000>;
			fsl,primary-cache-geometry = <32 1>;
			fsl,secondary-cache-geometry = <128 2>;
		};
	};

	guts: global-utilities@e0000 {
		compatible = "fsl,qoriq-device-config-1.0";
		reg = <0xe0000 0xe00>;
		fsl,has-rstcr;
		#sleep-cells = <1>;
		fsl,liodn-bits = <12>;
	};

/include/ "qoriq-dma-0.dtsi"
	dma@100300 {
		fsl,iommu-parent = <&pamu0>;
		fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
	};


code:
* Power Management Controller

Properties:
- compatible: "fsl,<chip>-pmc".

  "fsl,mpc8349-pmc" should be listed for any chip whose PMC is
  compatible.  "fsl,mpc8313-pmc" should also be listed for any chip
  whose PMC is compatible, and implies deep-sleep capability.

  "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
  compatible.  "fsl,mpc8536-pmc" should also be listed for any chip
  whose PMC is compatible, and implies deep-sleep capability.

  "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is
  compatible; all statements below that apply to "fsl,mpc8548-pmc" also
  apply to "fsl,mpc8641d-pmc".

  Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these
  bit assignments are indicated via the sleep specifier in each device's
  sleep property.

- reg: For devices compatible with "fsl,mpc8349-pmc", the first resource
  is the PMC block, and the second resource is the Clock Configuration
  block.

  For devices compatible with "fsl,mpc8548-pmc", the first resource
  is a 32-byte block beginning with DEVDISR.

- interrupts: For "fsl,mpc8349-pmc"-compatible devices, the first
  resource is the PMC block interrupt.

- fsl,mpc8313-wakeup-timer: For "fsl,mpc8313-pmc"-compatible devices,
  this is a phandle to an "fsl,gtm" node on which timer 4 can be used as
  a wakeup source from deep sleep.

Sleep specifiers:

  fsl,mpc8349-pmc: Sleep specifiers consist of one cell.  For each bit
  that is set in the cell, the corresponding bit in SCCR will be saved
  and cleared on suspend, and restored on resume.  This sleep controller
  supports disabling and resuming devices at any time.

  fsl,mpc8536-pmc: Sleep specifiers consist of three cells, the third of
  which will be ORed into PMCDR upon suspend, and cleared from PMCDR
  upon resume.  The first two cells are as described for fsl,mpc8578-pmc.
  This sleep controller only supports disabling devices during system
  sleep, or permanently.

  fsl,mpc8548-pmc: Sleep specifiers consist of one or two cells, the
  first of which will be ORed into DEVDISR (and the second into
  DEVDISR2, if present -- this cell should be zero or absent if the
  hardware does not have DEVDISR2) upon a request for permanent device
  disabling.  This sleep controller does not support configuring devices
  to disable during system sleep (unless supported by another compatible
  match), or dynamically.

Example:

	power@b00 {
		compatible = "fsl,mpc8313-pmc", "fsl,mpc8349-pmc";
		reg = <0xb00 0x100 0xa00 0x100>;
		interrupts = <80 8>;
	};


code:
* Freescale 85xx RAID Engine nodes

RAID Engine nodes are defined to describe on-chip RAID accelerators.  Each RAID
Engine should have a separate node.

Supported chips:
P5020, P5040

Required properties:

- compatible:	Should contain "fsl,raideng-v1.0" as the value
		This identifies RAID Engine block. 1 in 1.0 represents
		major number whereas 0 represents minor number. The
		version matches the hardware IP version.
- reg:		offset and length of the register set for the device
- ranges:	standard ranges property specifying the translation
		between child address space and parent address space

Example:
	/* P5020 */
	raideng: raideng@320000 {
		compatible = "fsl,raideng-v1.0";
		#address-cells = <1>;
		#size-cells = <1>;
		reg	= <0x320000 0x10000>;
		ranges	= <0 0x320000 0x10000>;
	};

There must be a sub-node for each job queue present in RAID Engine
This node must be a sub-node of the main RAID Engine node

- compatible:	Should contain "fsl,raideng-v1.0-job-queue" as the value
		This identifies the job queue interface
- reg:		offset and length of the register set for job queue
- ranges:	standard ranges property specifying the translation
		between child address space and parent address space

Example:
	/* P5020 */
	raideng_jq0@1000 {
		compatible = "fsl,raideng-v1.0-job-queue";
		reg	   = <0x1000 0x1000>;
		ranges	   = <0x0 0x1000 0x1000>;
	};

There must be a sub-node for each job ring present in RAID Engine
This node must be a sub-node of job queue node

- compatible:	Must contain "fsl,raideng-v1.0-job-ring" as the value
		This identifies job ring. Should contain either
		"fsl,raideng-v1.0-hp-ring" or "fsl,raideng-v1.0-lp-ring"
		depending upon whether ring has high or low priority
- reg:		offset and length of the register set for job ring
- interrupts:	interrupt mapping for job ring IRQ

Optional property:

- fsl,liodn:	Specifies the LIODN to be used for Job Ring. This
		property is normally set by firmware. Value
		is of 12-bits which is the LIODN number for this JR.
		This property is used by the IOMMU (PAMU) to distinquish
		transactions from this JR and than be able to do address
		translation & protection accordingly.

Example:
	/* P5020 */
	raideng_jq0@1000 {
		compatible = "fsl,raideng-v1.0-job-queue";
		reg	   = <0x1000 0x1000>;
		ranges	   = <0x0 0x1000 0x1000>;

		raideng_jr0: jr@0 {
			compatible = "fsl,raideng-v1.0-job-ring", "fsl,raideng-v1.0-hp-ring";
			reg	   = <0x0 0x400>;
			interrupts = <139 2 0 0>;
			interrupt-parent = <&mpic>;
			fsl,liodn = <0x41>;
		};
	};


code:
Freescale Supplement configuration unit (SCFG)

SCFG is the supplemental configuration unit, that provides SoC specific
configuration and status registers for the chip. Such as getting PEX port
status.

Required properties:

- compatible: should be "fsl,<chip>-scfg"
- reg: should contain base address and length of SCFG memory-mapped
registers

Example:

	scfg: global-utilities@fc000 {
		compatible = "fsl,t1040-scfg";
		reg = <0xfc000 0x1000>;
	};