pandory500/oleavr-rgl-a500-mini-linux-3.10
2
0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Initial commit

Browse source
This commit is contained in:
Ole André Vadla Ravnås 2022-05-07 01:01:45 +02:00
commit 169c65d57e
51358 changed files with 23120455 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

52
Documentation/devicetree/bindings/powerpc/4xx/cpm.txt Normal file
View file

@ -0,0 +1,52 @@
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>;
};

148
Documentation/devicetree/bindings/powerpc/4xx/emac.txt Normal file
View file

@ -0,0 +1,148 @@
4xx/Axon EMAC ethernet nodes
The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
the Axon bridge. To operate this needs to interact with a ths
special McMAL DMA controller, and sometimes an RGMII or ZMII
interface. In addition to the nodes and properties described
below, the node for the OPB bus on which the EMAC sits must have a
correct clock-frequency property.
i) The EMAC node itself
Required properties:
- device_type : "network"
- compatible : compatible list, contains 2 entries, first is
"ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
405gp, Axon) and second is either "ibm,emac" or
"ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
"ibm,emac4"
- interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
- interrupt-parent : optional, if needed for interrupt mapping
- reg : <registers mapping>
- local-mac-address : 6 bytes, MAC address
- mal-device : phandle of the associated McMAL node
- mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
with this EMAC
- mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
with this EMAC
- cell-index : 1 cell, hardware index of the EMAC cell on a given
ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
each Axon chip)
- max-frame-size : 1 cell, maximum frame size supported in bytes
- rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
operations.
For Axon, 2048
- tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
operations.
For Axon, 2048.
- fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
thresholds).
For Axon, 0x00000010
- mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
in bytes.
For Axon, 0x00000100 (I think ...)
- phy-mode : string, mode of operations of the PHY interface.
Supported values are: "mii", "rmii", "smii", "rgmii",
"tbi", "gmii", rtbi", "sgmii".
For Axon on CAB, it is "rgmii"
- mdio-device : 1 cell, required iff using shared MDIO registers
(440EP). phandle of the EMAC to use to drive the
MDIO lines for the PHY used by this EMAC.
- zmii-device : 1 cell, required iff connected to a ZMII. phandle of
the ZMII device node
- zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
channel or 0xffffffff if ZMII is only used for MDIO.
- rgmii-device : 1 cell, required iff connected to an RGMII. phandle
of the RGMII device node.
For Axon: phandle of plb5/plb4/opb/rgmii
- rgmii-channel : 1 cell, required iff connected to an RGMII. Which
RGMII channel is used by this EMAC.
Fox Axon: present, whatever value is appropriate for each
EMAC, that is the content of the current (bogus) "phy-port"
property.
Optional properties:
- phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
a search is performed.
- phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
for, used if phy-address is absent. bit 0x00000001 is
MDIO address 0.
For Axon it can be absent, though my current driver
doesn't handle phy-address yet so for now, keep
0x00ffffff in it.
- rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
operations (if absent the value is the same as
rx-fifo-size). For Axon, either absent or 2048.
- tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
operations (if absent the value is the same as
tx-fifo-size). For Axon, either absent or 2048.
- tah-device : 1 cell, optional. If connected to a TAH engine for
offload, phandle of the TAH device node.
- tah-channel : 1 cell, optional. If appropriate, channel used on the
TAH engine.
Example:
EMAC0: ethernet@40000800 {
device_type = "network";
compatible = "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
interrupts = <1c 4 1d 4>;
reg = <40000800 70>;
local-mac-address = [00 04 AC E3 1B 1E];
mal-device = <&MAL0>;
mal-tx-channel = <0 1>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rmii";
phy-map = <00000001>;
zmii-device = <&ZMII0>;
zmii-channel = <0>;
};
ii) McMAL node
Required properties:
- device_type : "dma-controller"
- compatible : compatible list, containing 2 entries, first is
"ibm,mcmal-CHIP" where CHIP is the host ASIC (like
emac) and the second is either "ibm,mcmal" or
"ibm,mcmal2".
For Axon, "ibm,mcmal-axon","ibm,mcmal2"
- interrupts : <interrupt mapping for the MAL interrupts sources:
5 sources: tx_eob, rx_eob, serr, txde, rxde>.
For Axon: This is _different_ from the current
firmware. We use the "delayed" interrupts for txeob
and rxeob. Thus we end up with mapping those 5 MPIC
interrupts, all level positive sensitive: 10, 11, 32,
33, 34 (in decimal)
- dcr-reg : < DCR registers range >
- dcr-parent : if needed for dcr-reg
- num-tx-chans : 1 cell, number of Tx channels
- num-rx-chans : 1 cell, number of Rx channels
iii) ZMII node
Required properties:
- compatible : compatible list, containing 2 entries, first is
"ibm,zmii-CHIP" where CHIP is the host ASIC (like
EMAC) and the second is "ibm,zmii".
For Axon, there is no ZMII node.
- reg : <registers mapping>
iv) RGMII node
Required properties:
- compatible : compatible list, containing 2 entries, first is
"ibm,rgmii-CHIP" where CHIP is the host ASIC (like
EMAC) and the second is "ibm,rgmii".
For Axon, "ibm,rgmii-axon","ibm,rgmii"
- reg : <registers mapping>
- revision : as provided by the RGMII new version register if
available.
For Axon: 0x0000012a

39
Documentation/devicetree/bindings/powerpc/4xx/ndfc.txt Normal file
View file

@ -0,0 +1,39 @@
AMCC NDFC (NanD Flash Controller)
Required properties:
- compatible : "ibm,ndfc".
- reg : should specify chip select and size used for the chip (0x2000).
Optional properties:
- ccr : NDFC config and control register value (default 0).
- bank-settings : NDFC bank configuration register value (default 0).
Notes:
- partition(s) - follows the OF MTD standard for partitions
Example:
ndfc@1,0 {
compatible = "ibm,ndfc";
reg = <0x00000001 0x00000000 0x00002000>;
ccr = <0x00001000>;
bank-settings = <0x80002222>;
#address-cells = <1>;
#size-cells = <1>;
nand {
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "kernel";
reg = <0x00000000 0x00200000>;
};
partition@200000 {
label = "root";
reg = <0x00200000 0x03E00000>;
};
};
};

93
Documentation/devicetree/bindings/powerpc/4xx/ppc440spe-adma.txt Normal file
View file

@ -0,0 +1,93 @@
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>.
- interrupt-parent : needed for interrupt mapping
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>
- interrupt-parent : for interrupt mapping
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>;
};

18
Documentation/devicetree/bindings/powerpc/4xx/reboot.txt Normal file
View file

@ -0,0 +1,18 @@
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 overidden. 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 */
};

69
Documentation/devicetree/bindings/powerpc/fsl/board.txt Normal file
View file

@ -0,0 +1,69 @@
Freescale Reference Board Bindings
This document describes device tree bindings for various devices that
exist on some Freescale reference boards.
* Board Control and Status (BCSR)
Required properties:
- compatible : Should be "fsl,<board>-bcsr"
- reg : Offset and length of the register set for the device
Example:
bcsr@f8000000 {
compatible = "fsl,mpc8360mds-bcsr";
reg = <f8000000 8000>;
};
* Freescale on-board FPGA
This is the memory-mapped registers for on board FPGA.
Required properities:
- compatible: should be a board-specific string followed by a string
indicating the type of FPGA. Example:
"fsl,<board>-fpga", "fsl,fpga-pixis"
- reg: should contain the address and the length of the FPGA register set.
- interrupt-parent: should specify phandle for the interrupt controller.
- interrupts: should specify event (wakeup) IRQ.
Example (P1022DS):
board-control@3,0 {
compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
reg = <3 0 0x30>;
interrupt-parent = <&mpic>;
interrupts = <8 8 0 0>;
};
* Freescale BCSR GPIO banks
Some BCSR registers act as simple GPIO controllers, each such
register can be represented by the gpio-controller node.
Required properities:
- compatible : Should be "fsl,<board>-bcsr-gpio".
- reg : Should contain the address and the length of the GPIO bank
register.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the port as GPIO controller.
Example:
bcsr@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8360mds-bcsr";
reg = <1 0 0x8000>;
ranges = <0 1 0 0x8000>;
bcsr13: gpio-controller@d {
#gpio-cells = <2>;
compatible = "fsl,mpc8360mds-bcsr-gpio";
reg = <0xd 1>;
gpio-controller;
};
};

20
Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt Normal file
View file

@ -0,0 +1,20 @@
* Freescale PQ3 and QorIQ based Cache SRAM
Freescale's mpc85xx and some QorIQ platforms provide an
option of configuring a part of (or full) cache memory
as SRAM. This cache SRAM representation in the device
tree should be done as under:-
Required properties:
- compatible : should be "fsl,p2020-cache-sram"
- fsl,cache-sram-ctlr-handle : points to the L2 controller
- reg : offset and length of the cache-sram.
Example:
cache-sram@fff00000 {
fsl,cache-sram-ctlr-handle = <&L2>;
reg = <0 0xfff00000 0 0x10000>;
compatible = "fsl,p2020-cache-sram";
};

67
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm.txt Normal file
View file

@ -0,0 +1,67 @@
* Freescale Communications Processor Module
NOTE: This is an interim binding, and will likely change slightly,
as more devices are supported. The QE bindings especially are
incomplete.
* Root CPM node
Properties:
- compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe".
- reg : A 48-byte region beginning with CPCR.
Example:
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <119c0 30>;
}
* Properties common to multiple CPM/QE devices
- fsl,cpm-command : This value is ORed with the opcode and command flag
to specify the device on which a CPM command operates.
- fsl,cpm-brg : Indicates which baud rate generator the device
is associated with. If absent, an unused BRG
should be dynamically allocated. If zero, the
device uses an external clock rather than a BRG.
- reg : Unless otherwise specified, the first resource represents the
scc/fcc/ucc registers, and the second represents the device's
parameter RAM region (if it has one).
* Multi-User RAM (MURAM)
The multi-user/dual-ported RAM is expressed as a bus under the CPM node.
Ranges must be set up subject to the following restrictions:
- Children's reg nodes must be offsets from the start of all muram, even
if the user-data area does not begin at zero.
- If multiple range entries are used, the difference between the parent
address and the child address must be the same in all, so that a single
mapping can cover them all while maintaining the ability to determine
CPM-side offsets with pointer subtraction. It is recommended that
multiple range entries not be used.
- A child address of zero must be translatable, even if no reg resources
contain it.
A child "data" node must exist, compatible with "fsl,cpm-muram-data", to
indicate the portion of muram that is usable by the OS for arbitrary
purposes. The data node may have an arbitrary number of reg resources,
all of which contribute to the allocatable muram pool.
Example, based on mpc8272:
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0 2000 9800 800>;
};
};

21
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/brg.txt Normal file
View file

@ -0,0 +1,21 @@
* Baud Rate Generators
Currently defined compatibles:
fsl,cpm-brg
fsl,cpm1-brg
fsl,cpm2-brg
Properties:
- reg : There may be an arbitrary number of reg resources; BRG
numbers are assigned to these in order.
- clock-frequency : Specifies the base frequency driving
the BRG.
Example:
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
clock-frequency = <d#25000000>;
};

41
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/i2c.txt Normal file
View file

@ -0,0 +1,41 @@
* I2C
The I2C controller is expressed as a bus under the CPM node.
Properties:
- compatible : "fsl,cpm1-i2c", "fsl,cpm2-i2c"
- reg : On CPM2 devices, the second resource doesn't specify the I2C
Parameter RAM itself, but the I2C_BASE field of the CPM2 Parameter RAM
(typically 0x8afc 0x2).
- #address-cells : Should be one. The cell is the i2c device address with
the r/w bit set to zero.
- #size-cells : Should be zero.
- clock-frequency : Can be used to set the i2c clock frequency. If
unspecified, a default frequency of 60kHz is being used.
The following two properties are deprecated. They are only used by legacy
i2c drivers to find the bus to probe:
- linux,i2c-index : Can be used to hard code an i2c bus number. By default,
the bus number is dynamically assigned by the i2c core.
- linux,i2c-class : Can be used to override the i2c class. The class is used
by legacy i2c device drivers to find a bus in a specific context like
system management, video or sound. By default, I2C_CLASS_HWMON (1) is
being used. The definition of the classes can be found in
include/i2c/i2c.h
Example, based on mpc823:
i2c@860 {
compatible = "fsl,mpc823-i2c",
"fsl,cpm1-i2c";
reg = <0x860 0x20 0x3c80 0x30>;
interrupts = <16>;
interrupt-parent = <&CPM_PIC>;
fsl,cpm-command = <0x10>;
#address-cells = <1>;
#size-cells = <0>;
rtc@68 {
compatible = "dallas,ds1307";
reg = <0x68>;
};
};

18
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/pic.txt Normal file
View file

@ -0,0 +1,18 @@
* Interrupt Controllers
Currently defined compatibles:
- fsl,cpm1-pic
- only one interrupt cell
- fsl,pq1-pic
- fsl,cpm2-pic
- second interrupt cell is level/sense:
- 2 is falling edge
- 8 is active low
Example:
interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <10c00 80>;
compatible = "mpc8272-pic", "fsl,cpm2-pic";
};

15
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/usb.txt Normal file
View file

@ -0,0 +1,15 @@
* USB (Universal Serial Bus Controller)
Properties:
- compatible : "fsl,cpm1-usb", "fsl,cpm2-usb", "fsl,qe-usb"
Example:
usb@11bc0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,cpm2-usb";
reg = <11b60 18 8b00 100>;
interrupts = <b 8>;
interrupt-parent = <&PIC>;
fsl,cpm-command = <2e600000>;
};

38
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/gpio.txt Normal file
View file

@ -0,0 +1,38 @@
Every GPIO controller node must have #gpio-cells property defined,
this information will be used to translate gpio-specifiers.
On CPM1 devices, all ports are using slightly different register layouts.
Ports A, C and D are 16bit ports and Ports B and E are 32bit ports.
On CPM2 devices, all ports are 32bit ports and use a common register layout.
Required properties:
- compatible : "fsl,cpm1-pario-bank-a", "fsl,cpm1-pario-bank-b",
"fsl,cpm1-pario-bank-c", "fsl,cpm1-pario-bank-d",
"fsl,cpm1-pario-bank-e", "fsl,cpm2-pario-bank"
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the port as GPIO controller.
Example of three SOC GPIO banks defined as gpio-controller nodes:
CPM1_PIO_A: gpio-controller@950 {
#gpio-cells = <2>;
compatible = "fsl,cpm1-pario-bank-a";
reg = <0x950 0x10>;
gpio-controller;
};
CPM1_PIO_B: gpio-controller@ab8 {
#gpio-cells = <2>;
compatible = "fsl,cpm1-pario-bank-b";
reg = <0xab8 0x10>;
gpio-controller;
};
CPM1_PIO_E: gpio-controller@ac8 {
#gpio-cells = <2>;
compatible = "fsl,cpm1-pario-bank-e";
reg = <0xac8 0x18>;
gpio-controller;
};

45
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt Normal file
View file

@ -0,0 +1,45 @@
* Network
Currently defined compatibles:
- fsl,cpm1-scc-enet
- fsl,cpm2-scc-enet
- fsl,cpm1-fec-enet
- fsl,cpm2-fcc-enet (third resource is GFEMR)
- fsl,qe-enet
Example:
ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <11300 20 8400 100 11390 1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
fsl,cpm-command = <12000300>;
};
* MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
fsl,mdio-pin : pin of port C controlling mdio data
fsl,mdc-pin : pin of port C controlling mdio clock
Example:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
};

115
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt Normal file
View file

@ -0,0 +1,115 @@
* Freescale QUICC Engine module (QE)
This represents qe module that is installed on PowerQUICC II Pro.
NOTE: This is an interim binding; it should be updated to fit
in with the CPM binding later in this document.
Basically, it is a bus of devices, that could act more or less
as a complete entity (UCC, USB etc ). All of them should be siblings on
the "root" qe node, using the common properties from there.
The description below applies to the qe of MPC8360 and
more nodes and properties would be extended in the future.
i) Root QE device
Required properties:
- compatible : should be "fsl,qe";
- model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
- reg : offset and length of the device registers.
- bus-frequency : the clock frequency for QUICC Engine.
- fsl,qe-num-riscs: define how many RISC engines the QE has.
- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
threads.
Optional properties:
- fsl,firmware-phandle:
Usage: required only if there is no fsl,qe-firmware child node
Value type: <phandle>
Definition: Points to a firmware node (see "QE Firmware Node" below)
that contains the firmware that should be uploaded for this QE.
The compatible property for the firmware node should say,
"fsl,qe-firmware".
Recommended properties
- brg-frequency : the internal clock source frequency for baud-rate
generators in Hz.
Example:
qe@e0100000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,qe";
ranges = <0 e0100000 00100000>;
reg = <e0100000 480>;
brg-frequency = <0>;
bus-frequency = <179A7B00>;
}
* Multi-User RAM (MURAM)
Required properties:
- compatible : should be "fsl,qe-muram", "fsl,cpm-muram".
- mode : the could be "host" or "slave".
- ranges : Should be defined as specified in 1) to describe the
translation of MURAM addresses.
- data-only : sub-node which defines the address area under MURAM
bus that can be allocated as data/parameter
Example:
muram@10000 {
compatible = "fsl,qe-muram", "fsl,cpm-muram";
ranges = <0 00010000 0000c000>;
data-only@0{
compatible = "fsl,qe-muram-data",
"fsl,cpm-muram-data";
reg = <0 c000>;
};
};
* QE Firmware Node
This node defines a firmware binary that is embedded in the device tree, for
the purpose of passing the firmware from bootloader to the kernel, or from
the hypervisor to the guest.
The firmware node itself contains the firmware binary contents, a compatible
property, and any firmware-specific properties. The node should be placed
inside a QE node that needs it. Doing so eliminates the need for a
fsl,firmware-phandle property. Other QE nodes that need the same firmware
should define an fsl,firmware-phandle property that points to the firmware node
in the first QE node.
The fsl,firmware property can be specified in the DTS (possibly using incbin)
or can be inserted by the boot loader at boot time.
Required properties:
- compatible
Usage: required
Value type: <string>
Definition: A standard property. Specify a string that indicates what
kind of firmware it is. For QE, this should be "fsl,qe-firmware".
- fsl,firmware
Usage: required
Value type: <prop-encoded-array>, encoded as an array of bytes
Definition: A standard property. This property contains the firmware
binary "blob".
Example:
qe1@e0080000 {
compatible = "fsl,qe";
qe_firmware:qe-firmware {
compatible = "fsl,qe-firmware";
fsl,firmware = [0x70 0xcd 0x00 0x00 0x01 0x46 0x45 ...];
};
...
};
qe2@e0090000 {
compatible = "fsl,qe";
fsl,firmware-phandle = <&qe_firmware>;
...
};

24
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/firmware.txt Normal file
View file

@ -0,0 +1,24 @@
* Uploaded QE firmware
If a new firmware has been uploaded to the QE (usually by the
boot loader), then a 'firmware' child node should be added to the QE
node. This node provides information on the uploaded firmware that
device drivers may need.
Required properties:
- id: The string name of the firmware. This is taken from the 'id'
member of the qe_firmware structure of the uploaded firmware.
Device drivers can search this string to determine if the
firmware they want is already present.
- extended-modes: The Extended Modes bitfield, taken from the
firmware binary. It is a 64-bit number represented
as an array of two 32-bit numbers.
- virtual-traps: The virtual traps, taken from the firmware binary.
It is an array of 8 32-bit numbers.
Example:
firmware {
id = "Soft-UART";
extended-modes = <0 0>;
virtual-traps = <0 0 0 0 0 0 0 0>;
};

51
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/par_io.txt Normal file
View file

@ -0,0 +1,51 @@
* Parallel I/O Ports
This node configures Parallel I/O ports for CPUs with QE support.
The node should reside in the "soc" node of the tree. For each
device that using parallel I/O ports, a child node should be created.
See the definition of the Pin configuration nodes below for more
information.
Required properties:
- device_type : should be "par_io".
- reg : offset to the register set and its length.
- num-ports : number of Parallel I/O ports
Example:
par_io@1400 {
reg = <1400 100>;
#address-cells = <1>;
#size-cells = <0>;
device_type = "par_io";
num-ports = <7>;
ucc_pin@01 {
......
};
Note that "par_io" nodes are obsolete, and should not be used for
the new device trees. Instead, each Par I/O bank should be represented
via its own gpio-controller node:
Required properties:
- #gpio-cells : should be "2".
- compatible : should be "fsl,<chip>-qe-pario-bank",
"fsl,mpc8323-qe-pario-bank".
- reg : offset to the register set and its length.
- gpio-controller : node to identify gpio controllers.
Example:
qe_pio_a: gpio-controller@1400 {
#gpio-cells = <2>;
compatible = "fsl,mpc8360-qe-pario-bank",
"fsl,mpc8323-qe-pario-bank";
reg = <0x1400 0x18>;
gpio-controller;
};
qe_pio_e: gpio-controller@1460 {
#gpio-cells = <2>;
compatible = "fsl,mpc8360-qe-pario-bank",
"fsl,mpc8323-qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
};

60
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt Normal file
View file

@ -0,0 +1,60 @@
* Pin configuration nodes
Required properties:
- linux,phandle : phandle of this node; likely referenced by a QE
device.
- pio-map : array of pin configurations. Each pin is defined by 6
integers. The six numbers are respectively: port, pin, dir,
open_drain, assignment, has_irq.
- port : port number of the pin; 0-6 represent port A-G in UM.
- pin : pin number in the port.
- dir : direction of the pin, should encode as follows:
0 = The pin is disabled
1 = The pin is an output
2 = The pin is an input
3 = The pin is I/O
- open_drain : indicates the pin is normal or wired-OR:
0 = The pin is actively driven as an output
1 = The pin is an open-drain driver. As an output, the pin is
driven active-low, otherwise it is three-stated.
- assignment : function number of the pin according to the Pin Assignment
tables in User Manual. Each pin can have up to 4 possible functions in
QE and two options for CPM.
- has_irq : indicates if the pin is used as source of external
interrupts.
Example:
ucc_pin@01 {
linux,phandle = <140001>;
pio-map = <
/* port pin dir open_drain assignment has_irq */
0 3 1 0 1 0 /* TxD0 */
0 4 1 0 1 0 /* TxD1 */
0 5 1 0 1 0 /* TxD2 */
0 6 1 0 1 0 /* TxD3 */
1 6 1 0 3 0 /* TxD4 */
1 7 1 0 1 0 /* TxD5 */
1 9 1 0 2 0 /* TxD6 */
1 a 1 0 2 0 /* TxD7 */
0 9 2 0 1 0 /* RxD0 */
0 a 2 0 1 0 /* RxD1 */
0 b 2 0 1 0 /* RxD2 */
0 c 2 0 1 0 /* RxD3 */
0 d 2 0 1 0 /* RxD4 */
1 1 2 0 2 0 /* RxD5 */
1 0 2 0 2 0 /* RxD6 */
1 4 2 0 2 0 /* RxD7 */
0 7 1 0 1 0 /* TX_EN */
0 8 1 0 1 0 /* TX_ER */
0 f 2 0 1 0 /* RX_DV */
0 10 2 0 1 0 /* RX_ER */
0 0 2 0 1 0 /* RX_CLK */
2 9 1 0 3 0 /* GTX_CLK - CLK10 */
2 8 2 0 1 0>; /* GTX125 - CLK9 */
};

70
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/ucc.txt Normal file
View file

@ -0,0 +1,70 @@
* UCC (Unified Communications Controllers)
Required properties:
- device_type : should be "network", "hldc", "uart", "transparent"
"bisync", "atm", or "serial".
- compatible : could be "ucc_geth" or "fsl_atm" and so on.
- cell-index : the ucc number(1-8), corresponding to UCCx in UM.
- reg : Offset and length of the register set for the device
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
information for the interrupt. This should be encoded based on
the information in section 2) depending on the type of interrupt
controller you have.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- pio-handle : The phandle for the Parallel I/O port configuration.
- port-number : for UART drivers, the port number to use, between 0 and 3.
This usually corresponds to the /dev/ttyQE device, e.g. <0> = /dev/ttyQE0.
The port number is added to the minor number of the device. Unlike the
CPM UART driver, the port-number is required for the QE UART driver.
- soft-uart : for UART drivers, if specified this means the QE UART device
driver should use "Soft-UART" mode, which is needed on some SOCs that have
broken UART hardware. Soft-UART is provided via a microcode upload.
- rx-clock-name: the UCC receive clock source
"none": clock source is disabled
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
"clk1" through "clk24": clock source is CLK1-CLK24, respectively
- tx-clock-name: the UCC transmit clock source
"none": clock source is disabled
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
"clk1" through "clk24": clock source is CLK1-CLK24, respectively
The following two properties are deprecated. rx-clock has been replaced
with rx-clock-name, and tx-clock has been replaced with tx-clock-name.
Drivers that currently use the deprecated properties should continue to
do so, in order to support older device trees, but they should be updated
to check for the new properties first.
- rx-clock : represents the UCC receive clock source.
0x00 : clock source is disabled;
0x1~0x10 : clock source is BRG1~BRG16 respectively;
0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
- tx-clock: represents the UCC transmit clock source;
0x00 : clock source is disabled;
0x1~0x10 : clock source is BRG1~BRG16 respectively;
0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
Required properties for network device_type:
- mac-address : list of bytes representing the ethernet address.
- phy-handle : The phandle for the PHY connected to this controller.
Recommended properties:
- phy-connection-type : a string naming the controller/PHY interface type,
i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
"tbi", or "rtbi".
Example:
ucc@2000 {
device_type = "network";
compatible = "ucc_geth";
cell-index = <1>;
reg = <2000 200>;
interrupts = <a0 0>;
interrupt-parent = <700>;
mac-address = [ 00 04 9f 00 23 23 ];
rx-clock = "none";
tx-clock = "clk9";
phy-handle = <212000>;
phy-connection-type = "gmii";
pio-handle = <140001>;
};

37
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/usb.txt Normal file
View file

@ -0,0 +1,37 @@
Freescale QUICC Engine USB Controller
Required properties:
- compatible : should be "fsl,<chip>-qe-usb", "fsl,mpc8323-qe-usb".
- reg : the first two cells should contain usb registers location and
length, the next two two cells should contain PRAM location and
length.
- interrupts : should contain USB interrupt.
- interrupt-parent : interrupt source phandle.
- fsl,fullspeed-clock : specifies the full speed USB clock source:
"none": clock source is disabled
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
"clk1" through "clk24": clock source is CLK1-CLK24, respectively
- fsl,lowspeed-clock : specifies the low speed USB clock source:
"none": clock source is disabled
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
"clk1" through "clk24": clock source is CLK1-CLK24, respectively
- hub-power-budget : USB power budget for the root hub, in mA.
- gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN, USBRP,
USBRN, SPEED (optional), and POWER (optional).
Example:
usb@6c0 {
compatible = "fsl,mpc8360-qe-usb", "fsl,mpc8323-qe-usb";
reg = <0x6c0 0x40 0x8b00 0x100>;
interrupts = <11>;
interrupt-parent = <&qeic>;
fsl,fullspeed-clock = "clk21";
gpios = <&qe_pio_b 2 0 /* USBOE */
&qe_pio_b 3 0 /* USBTP */
&qe_pio_b 8 0 /* USBTN */
&qe_pio_b 9 0 /* USBRP */
&qe_pio_b 11 0 /* USBRN */
&qe_pio_e 20 0 /* SPEED */
&qe_pio_e 21 0 /* POWER */>;
};

32
Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/serial.txt Normal file
View file

@ -0,0 +1,32 @@
* Serial
Currently defined compatibles:
- fsl,cpm1-smc-uart
- fsl,cpm2-smc-uart
- fsl,cpm1-scc-uart
- fsl,cpm2-scc-uart
- fsl,qe-uart
Modem control lines connected to GPIO controllers are listed in the gpios
property as described in booting-without-of.txt, section IX.1 in the following
order:
CTS, RTS, DCD, DSR, DTR, and RI.
The gpios property is optional and can be left out when control lines are
not used.
Example:
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
gpios = <&gpio_c 15 0
&gpio_d 29 0>;
};

22
Documentation/devicetree/bindings/powerpc/fsl/cpus.txt Normal file
View file

@ -0,0 +1,22 @@
===================================================================
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 ePAPR.
In addition to the ePAPR 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.

395
Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt Normal file
View file

@ -0,0 +1,395 @@
===================================================================
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 lised in order (perfmon, event0, event1).
- interrupt-parent
Usage: required
Value type: <phandle>
Definition: A single <phandle> value that points
to the interrupt parent to which the child domain
is being mapped. Value must be "&mpic"
- 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>;
};
=======================================================================

34
Documentation/devicetree/bindings/powerpc/fsl/diu.txt Normal file
View file

@ -0,0 +1,34 @@
* 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.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
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];
};

144
Documentation/devicetree/bindings/powerpc/fsl/dma.txt Normal file
View file

@ -0,0 +1,144 @@
* Freescale 83xx DMA Controller
Freescale PowerPC 83xx have on chip general purpose DMA controllers.
Required properties:
- compatible : compatible list, contains 2 entries, first is
"fsl,CHIP-dma", where CHIP is the processor
(mpc8349, mpc8360, etc.) and the second is
"fsl,elo-dma"
- reg : <registers mapping for DMA general status reg>
- ranges : Should be defined as specified in 1) to describe the
DMA controller channels.
- cell-index : controller index. 0 for controller @ 0x8100
- interrupts : <interrupt mapping for DMA IRQ>
- interrupt-parent : optional, if needed for interrupt mapping
- DMA channel nodes:
- compatible : compatible list, contains 2 entries, first is
"fsl,CHIP-dma-channel", where CHIP is the processor
(mpc8349, mpc8350, etc.) and the second is
"fsl,elo-dma-channel". However, see note below.
- reg : <registers mapping for channel>
- cell-index : dma channel index starts at 0.
Optional properties:
- interrupts : <interrupt mapping for DMA channel IRQ>
(on 83xx this is expected to be identical to
the interrupts property of the parent node)
- interrupt-parent : optional, if needed for interrupt mapping
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 85xx/86xx DMA Controller
Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers.
Required properties:
- compatible : compatible list, contains 2 entries, first is
"fsl,CHIP-dma", where CHIP is the processor
(mpc8540, mpc8540, etc.) and the second is
"fsl,eloplus-dma"
- reg : <registers mapping for DMA general status reg>
- cell-index : controller index. 0 for controller @ 0x21000,
1 for controller @ 0xc000
- ranges : Should be defined as specified in 1) to describe the
DMA controller channels.
- DMA channel nodes:
- compatible : compatible list, contains 2 entries, first is
"fsl,CHIP-dma-channel", where CHIP is the processor
(mpc8540, mpc8560, etc.) and the second is
"fsl,eloplus-dma-channel". However, see note below.
- cell-index : dma channel index starts at 0.
- reg : <registers mapping for channel>
- interrupts : <interrupt mapping for DMA channel IRQ>
- interrupt-parent : optional, if needed for interrupt mapping
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>;
};
};
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.

64
Documentation/devicetree/bindings/powerpc/fsl/ecm.txt Normal file
View file

@ -0,0 +1,64 @@
=====================================================================
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>
- interrupt-parent
Usage: required
Value type: <phandle>
=====================================================================

31
Documentation/devicetree/bindings/powerpc/fsl/gtm.txt Normal file
View file

@ -0,0 +1,31 @@
* Freescale General-purpose Timers Module
Required properties:
- compatible : should be
"fsl,<chip>-gtm", "fsl,gtm" for SOC GTMs
"fsl,<chip>-qe-gtm", "fsl,qe-gtm", "fsl,gtm" for QE GTMs
"fsl,<chip>-cpm2-gtm", "fsl,cpm2-gtm", "fsl,gtm" for CPM2 GTMs
- reg : should contain gtm registers location and length (0x40).
- interrupts : should contain four interrupts.
- interrupt-parent : interrupt source phandle.
- clock-frequency : specifies the frequency driving the timer.
Example:
timer@500 {
compatible = "fsl,mpc8360-gtm", "fsl,gtm";
reg = <0x500 0x40>;
interrupts = <90 8 78 8 84 8 72 8>;
interrupt-parent = <&ipic>;
/* filled by u-boot */
clock-frequency = <0>;
};
timer@440 {
compatible = "fsl,mpc8360-qe-gtm", "fsl,qe-gtm", "fsl,gtm";
reg = <0x440 0x40>;
interrupts = <12 13 14 15>;
interrupt-parent = <&qeic>;
/* filled by u-boot */
clock-frequency = <0>;
};

36
Documentation/devicetree/bindings/powerpc/fsl/guts.txt Normal file
View file

@ -0,0 +1,36 @@
* Global Utilities Block
The global utilities block controls power management, I/O device
enabling, power-on-reset configuration monitoring, general-purpose
I/O signal configuration, alternate function selection for multiplexed
signals, and clock control.
Required properties:
- compatible : Should define the compatible device type for
global-utilities.
- reg : Offset and length of the register set for the device.
Recommended properties:
- fsl,has-rstcr : Indicates that the global utilities register set
contains a functioning "reset control register" (i.e. the board
is wired to reset upon setting the HRESET_REQ bit in this register).
- fsl,liodn-bits : Indicates the number of defined bits in the LIODN
registers, for those SOCs that have a PAMU device.
Examples:
global-utilities@e0000 { /* global utilities block */
compatible = "fsl,mpc8548-guts";
reg = <e0000 1000>;
fsl,has-rstcr;
};
guts: global-utilities@e0000 {
compatible = "fsl,qoriq-device-config-1.0";
reg = <0xe0000 0xe00>;
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
};

79
Documentation/devicetree/bindings/powerpc/fsl/ifc.txt Normal file
View file

@ -0,0 +1,79 @@
Integrated Flash Controller
Properties:
- name : Should be ifc
- compatible : should contain "fsl,ifc". The version of the integrated
flash controller can be found in the IFC_REV register at
offset zero.
- #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.
- reg : Offset and length of the register set for the device
- interrupts: IFC may have one or two interrupts. If two interrupt
specifiers are present, the first is the "common"
interrupt (CM_EVTER_STAT), and the second is the NAND
interrupt (NAND_EVTER_STAT). If there is only one,
that interrupt reports both types of event.
- ranges : Each range corresponds to a single chipselect, and covers
the entire access window as configured.
Child device nodes describe the devices connected to IFC such as NOR (e.g.
cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices
like FPGAs, CPLDs, etc.
Example:
ifc@ffe1e000 {
compatible = "fsl,ifc", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x0 0xffe1e000 0 0x2000>;
interrupts = <16 2 19 2>;
/* NOR, NAND Flashes and CPLD on board */
ranges = <0x0 0x0 0x0 0xee000000 0x02000000
0x1 0x0 0x0 0xffa00000 0x00010000
0x3 0x0 0x0 0xffb00000 0x00020000>;
flash@0,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x2000000>;
bank-width = <2>;
device-width = <1>;
partition@0 {
/* 32MB for user data */
reg = <0x0 0x02000000>;
label = "NOR Data";
};
};
flash@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,ifc-nand";
reg = <0x1 0x0 0x10000>;
partition@0 {
/* This location must not be altered */
/* 1MB for u-boot Bootloader Image */
reg = <0x0 0x00100000>;
label = "NAND U-Boot Image";
read-only;
};
};
cpld@3,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p1010rdb-cpld";
reg = <0x3 0x0 0x000001f>;
};
};

35
Documentation/devicetree/bindings/powerpc/fsl/lbc.txt Normal file
View file

@ -0,0 +1,35 @@
* 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 = <f0010100 40>;
ranges = <0 0 fe000000 02000000
1 0 f4500000 00008000>;
flash@0,0 {
compatible = "jedec-flash";
reg = <0 0 2000000>;
bank-width = <4>;
device-width = <1>;
};
board-control@1,0 {
reg = <1 0 20>;
compatible = "fsl,mpc8272ads-bcsr";
};
};

64
Documentation/devicetree/bindings/powerpc/fsl/mcm.txt Normal file
View file

@ -0,0 +1,64 @@
=====================================================================
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>
- interrupt-parent
Usage: required
Value type: <phandle>
=====================================================================

17
Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt Normal file
View file

@ -0,0 +1,17 @@
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@0a {
#gpio-cells = <2>;
compatible = "fsl,mc9s08qg8-mpc8349emitx",
"fsl,mcu-mpc8349emitx";
reg = <0x0a>;
gpio-controller;
};

70
Documentation/devicetree/bindings/powerpc/fsl/mpc5121-psc.txt Normal file
View file

@ -0,0 +1,70 @@
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 requered there:
fsl,mpc5121-psc-uart nodes
--------------------------
Required properties :
- compatible : Should contain "fsl,mpc5121-psc-uart" and "fsl,mpc5121-psc"
- cell-index : Index of the PSC in hardware
- 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.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
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)
fsl,mpc5121-psc-fifo node
-------------------------
Required properties :
- compatible : Should be "fsl,mpc5121-psc-fifo"
- 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.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
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 >;
};

198
Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt Normal file
View file

@ -0,0 +1,198 @@
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 it's 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 can.txt in this directory.

63
Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt Normal file
View file

@ -0,0 +1,63 @@
* 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>;
};

38
Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt Normal file
View file

@ -0,0 +1,38 @@
* 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>;
};

231
Documentation/devicetree/bindings/powerpc/fsl/mpic.txt Normal file
View file

@ -0,0 +1,231 @@
=====================================================================
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>;
};

87
Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt Normal file
View file

@ -0,0 +1,87 @@
* Freescale MSI interrupt controller
Required properties:
- compatible : compatible list, contains 2 entries,
first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
the parent type.
- 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 register for
platforms that have such an alias.
- 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 256 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).
- 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.
- interrupt-parent: the phandle for the interrupt controller
that services interrupts for this device. for 83xx cpu, the interrupts
are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed
to MPIC.
Optional properties:
- 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>;
};
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.

140
Documentation/devicetree/bindings/powerpc/fsl/pamu.txt Normal file
View file

@ -0,0 +1,140 @@
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.
- interrupt-parent : <phandle>
Phandle to interrupt controller
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>;
#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 */
};

63
Documentation/devicetree/bindings/powerpc/fsl/pmc.txt Normal file
View file

@ -0,0 +1,63 @@
* 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>;
};

81
Documentation/devicetree/bindings/powerpc/fsl/raideng.txt Normal file
View file

@ -0,0 +1,81 @@
* 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>;
};
};

163
Documentation/devicetree/bindings/powerpc/fsl/srio-rmu.txt Normal file
View file

@ -0,0 +1,163 @@
Message unit node:
For SRIO controllers that implement the message unit as part of the controller
this node is required. For devices with RMAN this node should NOT exist. The
node is composed of three types of sub-nodes ("fsl-srio-msg-unit",
"fsl-srio-dbell-unit" and "fsl-srio-port-write-unit").
See srio.txt for more details about generic SRIO controller details.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio-rmu-vX.Y", "fsl,srio-rmu".
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- fsl,liodn
Usage: optional-but-recommended (for devices with PAMU)
Value type: <prop-encoded-array>
Definition: The logical I/O device number for the PAMU (IOMMU) to be
correctly configured for SRIO accesses. The property should
not exist on devices that do not support PAMU.
The LIODN value is associated with all RMU transactions
(msg-unit, doorbell, port-write).
Sub-Nodes for RMU: The RMU node is composed of multiple sub-nodes that
correspond to the actual sub-controllers in the RMU. The manual for a given
SoC will detail which and how many of these sub-controllers are implemented.
Message Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio-msg-unit-vX.Y", "fsl,srio-msg-unit".
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A pair of IRQs are specified in this property. The first
element is associated with the transmit (TX) interrupt and the
second element is associated with the receive (RX) interrupt.
Doorbell Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include:
"fsl,srio-dbell-unit-vX.Y", "fsl,srio-dbell-unit"
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A pair of IRQs are specified in this property. The first
element is associated with the transmit (TX) interrupt and the
second element is associated with the receive (RX) interrupt.
Port-Write Unit:
- compatible
Usage: required
Value type: <string>
Definition: Must include:
"fsl,srio-port-write-unit-vX.Y", "fsl,srio-port-write-unit"
The version X.Y should match the general SRIO controller's IP Block
revision register's Major(X) and Minor (Y) value.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers for message units
and doorbell units.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A single IRQ that handles port-write conditions is
specified by this property. (Typically shared with error).
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
Example:
rmu: rmu@d3000 {
compatible = "fsl,srio-rmu";
reg = <0xd3000 0x400>;
ranges = <0x0 0xd3000 0x400>;
fsl,liodn = <0xc8>;
message-unit@0 {
compatible = "fsl,srio-msg-unit";
reg = <0x0 0x100>;
interrupts = <
60 2 0 0 /* msg1_tx_irq */
61 2 0 0>;/* msg1_rx_irq */
};
message-unit@100 {
compatible = "fsl,srio-msg-unit";
reg = <0x100 0x100>;
interrupts = <
62 2 0 0 /* msg2_tx_irq */
63 2 0 0>;/* msg2_rx_irq */
};
doorbell-unit@400 {
compatible = "fsl,srio-dbell-unit";
reg = <0x400 0x80>;
interrupts = <
56 2 0 0 /* bell_outb_irq */
57 2 0 0>;/* bell_inb_irq */
};
port-write-unit@4e0 {
compatible = "fsl,srio-port-write-unit";
reg = <0x4e0 0x20>;
interrupts = <16 2 1 11>;
};
};

103
Documentation/devicetree/bindings/powerpc/fsl/srio.txt Normal file
View file

@ -0,0 +1,103 @@
* Freescale Serial RapidIO (SRIO) Controller
RapidIO port node:
Properties:
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,srio" for IP blocks with IP Block
Revision Register (SRIO IPBRR1) Major ID equal to 0x01c0.
Optionally, a compatible string of "fsl,srio-vX.Y" where X is Major
version in IP Block Revision Register and Y is Minor version. If this
compatible is provided it should be ordered before "fsl,srio".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address and
length of the SRIO configuration registers. The size should
be set to 0x11000.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this device. The
value of the interrupts property consists of one interrupt
specifier. The format of the specifier is defined by the
binding document describing the node's interrupt parent.
A single IRQ that handles error conditions is specified by this
property. (Typically shared with port-write).
- fsl,srio-rmu-handle:
Usage: required if rmu node is defined
Value type: <phandle>
Definition: A single <phandle> value that points to the RMU.
(See srio-rmu.txt for more details on RMU node binding)
Port Child Nodes: There should a port child node for each port that exists in
the controller. The ports are numbered starting at one (1) and should have
the following properties:
- cell-index
Usage: required
Value type: <u32>
Definition: A standard property. Matches the port id.
- ranges
Usage: required if local access windows preset
Value type: <prop-encoded-array>
Definition: A standard property. Utilized to describe the memory mapped
IO space utilized by the controller. This corresponds to the
setting of the local access windows that are targeted to this
SRIO port.
- fsl,liodn
Usage: optional-but-recommended (for devices with PAMU)
Value type: <prop-encoded-array>
Definition: The logical I/O device number for the PAMU (IOMMU) to be
correctly configured for SRIO accesses. The property should
not exist on devices that do not support PAMU.
For HW (ie, the P4080) that only supports a LIODN for both
memory and maintenance transactions then a single LIODN is
represented in the property for both transactions.
For HW (ie, the P304x/P5020, etc) that supports an LIODN for
memory transactions and a unique LIODN for maintenance
transactions then a pair of LIODNs are represented in the
property. Within the pair, the first element represents the
LIODN associated with memory transactions and the second element
represents the LIODN associated with maintenance transactions
for the port.
Note: All other standard properties (see ePAPR) are allowed but are optional.
Example:
rapidio: rapidio@ffe0c0000 {
#address-cells = <2>;
#size-cells = <2>;
reg = <0xf 0xfe0c0000 0 0x11000>;
compatible = "fsl,srio";
interrupts = <16 2 1 11>; /* err_irq */
fsl,srio-rmu-handle = <&rmu>;
ranges;
port1 {
cell-index = <1>;
#address-cells = <2>;
#size-cells = <2>;
fsl,liodn = <34>;
ranges = <0 0 0xc 0x20000000 0 0x10000000>;
};
port2 {
cell-index = <2>;
#address-cells = <2>;
#size-cells = <2>;
fsl,liodn = <48>;
ranges = <0 0 0xc 0x30000000 0 0x10000000>;
};
};

73
Documentation/devicetree/bindings/powerpc/fsl/ssi.txt Normal file
View file

@ -0,0 +1,73 @@
Freescale Synchronous Serial Interface
The SSI is a serial device that communicates with audio codecs. It can
be programmed in AC97, I2S, left-justified, or right-justified modes.
Required properties:
- compatible: Compatible list, contains "fsl,ssi".
- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on.
- reg: Offset and length of the register set for the device.
- interrupts: <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and
level information for the interrupt. This should be
encoded based on the information in section 2)
depending on the type of interrupt controller you
have.
- interrupt-parent: The phandle for the interrupt controller that
services interrupts for this device.
- fsl,mode: The operating mode for the SSI interface.
"i2s-slave" - I2S mode, SSI is clock slave
"i2s-master" - I2S mode, SSI is clock master
"lj-slave" - left-justified mode, SSI is clock slave
"lj-master" - l.j. mode, SSI is clock master
"rj-slave" - right-justified mode, SSI is clock slave
"rj-master" - r.j., SSI is clock master
"ac97-slave" - AC97 mode, SSI is clock slave
"ac97-master" - AC97 mode, SSI is clock master
- fsl,playback-dma: Phandle to a node for the DMA channel to use for
playback of audio. This is typically dictated by SOC
design. See the notes below.
- fsl,capture-dma: Phandle to a node for the DMA channel to use for
capture (recording) of audio. This is typically dictated
by SOC design. See the notes below.
- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs.
This number is the maximum allowed value for SFCSR[TFWM0].
- fsl,ssi-asynchronous:
If specified, the SSI is to be programmed in asynchronous
mode. In this mode, pins SRCK, STCK, SRFS, and STFS must
all be connected to valid signals. In synchronous mode,
SRCK and SRFS are ignored. Asynchronous mode allows
playback and capture to use different sample sizes and
sample rates. Some drivers may require that SRCK and STCK
be connected together, and SRFS and STFS be connected
together. This would still allow different sample sizes,
but not different sample rates.
Optional properties:
- codec-handle: Phandle to a 'codec' node that defines an audio
codec connected to this SSI. This node is typically
a child of an I2C or other control node.
Child 'codec' node required properties:
- compatible: Compatible list, contains the name of the codec
Child 'codec' node optional properties:
- clock-frequency: The frequency of the input clock, which typically comes
from an on-board dedicated oscillator.
Notes on fsl,playback-dma and fsl,capture-dma:
On SOCs that have an SSI, specific DMA channels are hard-wired for playback
and capture. On the MPC8610, for example, SSI1 must use DMA channel 0 for
playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for
playback and DMA channel 3 for capture. The developer can choose which
DMA controller to use, but the channels themselves are hard-wired. The
purpose of these two properties is to represent this hardware design.
The device tree nodes for the DMA channels that are referenced by
"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with
"fsl,ssi-dma-channel". The SOC-specific compatible string (e.g.
"fsl,mpc8610-dma-channel") can remain. If these nodes are left as
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA
drivers (fsldma) will attempt to use them, and it will conflict with the
sound drivers.

109
Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt Normal file
View file

@ -0,0 +1,109 @@
Nintendo GameCube device tree
=============================
1) The "flipper" node
This node represents the multi-function "Flipper" chip, which packages
many of the devices found in the Nintendo GameCube.
Required properties:
- compatible : Should be "nintendo,flipper"
1.a) The Video Interface (VI) node
Represents the interface between the graphics processor and a external
video encoder.
Required properties:
- compatible : should be "nintendo,flipper-vi"
- reg : should contain the VI registers location and length
- interrupts : should contain the VI interrupt
1.b) The Processor Interface (PI) node
Represents the data and control interface between the main processor
and graphics and audio processor.
Required properties:
- compatible : should be "nintendo,flipper-pi"
- reg : should contain the PI registers location and length
1.b.i) The "Flipper" interrupt controller node
Represents the interrupt controller within the "Flipper" chip.
The node for the "Flipper" interrupt controller must be placed under
the PI node.
Required properties:
- compatible : should be "nintendo,flipper-pic"
1.c) The Digital Signal Procesor (DSP) node
Represents the digital signal processor interface, designed to offload
audio related tasks.
Required properties:
- compatible : should be "nintendo,flipper-dsp"
- reg : should contain the DSP registers location and length
- interrupts : should contain the DSP interrupt
1.c.i) The Auxiliary RAM (ARAM) node
Represents the non cpu-addressable ram designed mainly to store audio
related information.
The ARAM node must be placed under the DSP node.
Required properties:
- compatible : should be "nintendo,flipper-aram"
- reg : should contain the ARAM start (zero-based) and length
1.d) The Disk Interface (DI) node
Represents the interface used to communicate with mass storage devices.
Required properties:
- compatible : should be "nintendo,flipper-di"
- reg : should contain the DI registers location and length
- interrupts : should contain the DI interrupt
1.e) The Audio Interface (AI) node
Represents the interface to the external 16-bit stereo digital-to-analog
converter.
Required properties:
- compatible : should be "nintendo,flipper-ai"
- reg : should contain the AI registers location and length
- interrupts : should contain the AI interrupt
1.f) The Serial Interface (SI) node
Represents the interface to the four single bit serial interfaces.
The SI is a proprietary serial interface used normally to control gamepads.
It's NOT a RS232-type interface.
Required properties:
- compatible : should be "nintendo,flipper-si"
- reg : should contain the SI registers location and length
- interrupts : should contain the SI interrupt
1.g) The External Interface (EXI) node
Represents the multi-channel SPI-like interface.
Required properties:
- compatible : should be "nintendo,flipper-exi"
- reg : should contain the EXI registers location and length
- interrupts : should contain the EXI interrupt

184
Documentation/devicetree/bindings/powerpc/nintendo/wii.txt Normal file
View file

@ -0,0 +1,184 @@
Nintendo Wii device tree
========================
0) The root node
This node represents the Nintendo Wii video game console.
Required properties:
- model : Should be "nintendo,wii"
- compatible : Should be "nintendo,wii"
1) The "hollywood" node
This node represents the multi-function "Hollywood" chip, which packages
many of the devices found in the Nintendo Wii.
Required properties:
- compatible : Should be "nintendo,hollywood"
1.a) The Video Interface (VI) node
Represents the interface between the graphics processor and a external
video encoder.
Required properties:
- compatible : should be "nintendo,hollywood-vi","nintendo,flipper-vi"
- reg : should contain the VI registers location and length
- interrupts : should contain the VI interrupt
1.b) The Processor Interface (PI) node
Represents the data and control interface between the main processor
and graphics and audio processor.
Required properties:
- compatible : should be "nintendo,hollywood-pi","nintendo,flipper-pi"
- reg : should contain the PI registers location and length
1.b.i) The "Flipper" interrupt controller node
Represents the "Flipper" interrupt controller within the "Hollywood" chip.
The node for the "Flipper" interrupt controller must be placed under
the PI node.
Required properties:
- #interrupt-cells : <1>
- compatible : should be "nintendo,flipper-pic"
- interrupt-controller
1.c) The Digital Signal Procesor (DSP) node
Represents the digital signal processor interface, designed to offload
audio related tasks.
Required properties:
- compatible : should be "nintendo,hollywood-dsp","nintendo,flipper-dsp"
- reg : should contain the DSP registers location and length
- interrupts : should contain the DSP interrupt
1.d) The Serial Interface (SI) node
Represents the interface to the four single bit serial interfaces.
The SI is a proprietary serial interface used normally to control gamepads.
It's NOT a RS232-type interface.
Required properties:
- compatible : should be "nintendo,hollywood-si","nintendo,flipper-si"
- reg : should contain the SI registers location and length
- interrupts : should contain the SI interrupt
1.e) The Audio Interface (AI) node
Represents the interface to the external 16-bit stereo digital-to-analog
converter.
Required properties:
- compatible : should be "nintendo,hollywood-ai","nintendo,flipper-ai"
- reg : should contain the AI registers location and length
- interrupts : should contain the AI interrupt
1.f) The External Interface (EXI) node
Represents the multi-channel SPI-like interface.
Required properties:
- compatible : should be "nintendo,hollywood-exi","nintendo,flipper-exi"
- reg : should contain the EXI registers location and length
- interrupts : should contain the EXI interrupt
1.g) The Open Host Controller Interface (OHCI) nodes
Represent the USB 1.x Open Host Controller Interfaces.
Required properties:
- compatible : should be "nintendo,hollywood-usb-ohci","usb-ohci"
- reg : should contain the OHCI registers location and length
- interrupts : should contain the OHCI interrupt
1.h) The Enhanced Host Controller Interface (EHCI) node
Represents the USB 2.0 Enhanced Host Controller Interface.
Required properties:
- compatible : should be "nintendo,hollywood-usb-ehci","usb-ehci"
- reg : should contain the EHCI registers location and length
- interrupts : should contain the EHCI interrupt
1.i) The Secure Digital Host Controller Interface (SDHCI) nodes
Represent the Secure Digital Host Controller Interfaces.
Required properties:
- compatible : should be "nintendo,hollywood-sdhci","sdhci"
- reg : should contain the SDHCI registers location and length
- interrupts : should contain the SDHCI interrupt
1.j) The Inter-Processor Communication (IPC) node
Represent the Inter-Processor Communication interface. This interface
enables communications between the Broadway and the Starlet processors.
- compatible : should be "nintendo,hollywood-ipc"
- reg : should contain the IPC registers location and length
- interrupts : should contain the IPC interrupt
1.k) The "Hollywood" interrupt controller node
Represents the "Hollywood" interrupt controller within the
"Hollywood" chip.
Required properties:
- #interrupt-cells : <1>
- compatible : should be "nintendo,hollywood-pic"
- reg : should contain the controller registers location and length
- interrupt-controller
- interrupts : should contain the cascade interrupt of the "flipper" pic
- interrupt-parent: should contain the phandle of the "flipper" pic
1.l) The General Purpose I/O (GPIO) controller node
Represents the dual access 32 GPIO controller interface.
Required properties:
- #gpio-cells : <2>
- compatible : should be "nintendo,hollywood-gpio"
- reg : should contain the IPC registers location and length
- gpio-controller
1.m) The control node
Represents the control interface used to setup several miscellaneous
settings of the "Hollywood" chip like boot memory mappings, resets,
disk interface mode, etc.
Required properties:
- compatible : should be "nintendo,hollywood-control"
- reg : should contain the control registers location and length
1.n) The Disk Interface (DI) node
Represents the interface used to communicate with mass storage devices.
Required properties:
- compatible : should be "nintendo,hollywood-di"
- reg : should contain the DI registers location and length
- interrupts : should contain the DI interrupt