samsung_sm8750/android_kernel_samsung_sm8750-devicetrees
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

dt-bindings: Add devicetree bindings

Browse Source 
Add snapshot of device tree bindings from keystone common kernel, branch
"android-mainline-keystone-qcom-release" at c4c12103f9c0 ("Snap for 9228065
from e32903b9a63bb558df8b803b076619c53c16baad to
android-mainline-keystone-qcom-release").

Change-Id: I7682079615cbd9f29340a5c1f2a1d84ec441a1f1
Signed-off-by: Melody Olvera <quic_molvera@quicinc.com>
This commit is contained in:
Melody Olvera
2023-04-03 14:38:11 -07:00
parent c334acf377
commit 6f18ce8026
4878 changed files with 424312 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
bindings/powerpc/4xx/akebono.txt Normal file
View File

@@ -0,0 +1,52 @@
IBM Akebono board device tree
=============================
The IBM Akebono board is a development board for the PPC476GTR SoC.
0) The root node
Required properties:
- model : "ibm,akebono".
- compatible : "ibm,akebono" , "ibm,476gtr".
1.a) The Secure Digital Host Controller Interface (SDHCI) node
Represent the Secure Digital Host Controller Interfaces.
Required properties:
- compatible : should be "ibm,476gtr-sdhci","generic-sdhci".
- reg : should contain the SDHCI registers location and length.
- interrupts : should contain the SDHCI interrupt.
1.b) The Advanced Host Controller Interface (AHCI) SATA node
Represents the advanced host controller SATA interface.
Required properties:
- compatible : should be "ibm,476gtr-ahci".
- reg : should contain the AHCI registers location and length.
- interrupts : should contain the AHCI interrupt.
1.c) The FPGA node
The Akebono board stores some board information such as the revision
number in an FPGA which is represented by this node.
Required properties:
- compatible : should be "ibm,akebono-fpga".
- reg : should contain the FPGA registers location and length.
1.d) The AVR node
The Akebono board has an Atmel AVR microprocessor attached to the I2C
bus as a power controller for the board.
Required properties:
- compatible : should be "ibm,akebono-avr".
- reg : should contain the I2C bus address for the AVR.

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

18
bindings/powerpc/4xx/hsta.txt Normal file
View File

@@ -0,0 +1,18 @@
ppc476gtr High Speed Serial Assist (HSTA) node
==============================================
The 476gtr SoC contains a high speed serial assist module attached
between the plb4 and plb6 system buses to provide high speed data
transfer between memory and system peripherals as well as support for
PCI message signalled interrupts.
Currently only the MSI support is used by Linux using the following
device tree entries:
Require properties:
- compatible : "ibm,476gtr-hsta-msi", "ibm,hsta-msi"
- reg : register mapping for the HSTA MSI space
- interrupts : ordered interrupt mapping for each MSI in the register
space. The first interrupt should be associated with a
register offset of 0x00, the second to 0x10, etc.

91
bindings/powerpc/4xx/ppc440spe-adma.txt Normal file
View File

@@ -0,0 +1,91 @@
PPC440SPe DMA/XOR (DMA Controller and XOR Accelerator)
Device nodes needed for operation of the ppc440spe-adma driver
are specified hereby. These are I2O/DMA, DMA and XOR nodes
for DMA engines and Memory Queue Module node. The latter is used
by ADMA driver for configuration of RAID-6 H/W capabilities of
the PPC440SPe. In addition to the nodes and properties described
below, the ranges property of PLB node must specify ranges for
DMA devices.
i) The I2O node
Required properties:
- compatible : "ibm,i2o-440spe";
- reg : <registers mapping>
- dcr-reg : <DCR registers range>
Example:
I2O: i2o@400100000 {
compatible = "ibm,i2o-440spe";
reg = <0x00000004 0x00100000 0x100>;
dcr-reg = <0x060 0x020>;
};
ii) The DMA node
Required properties:
- compatible : "ibm,dma-440spe";
- cell-index : 1 cell, hardware index of the DMA engine
(typically 0x0 and 0x1 for DMA0 and DMA1)
- reg : <registers mapping>
- dcr-reg : <DCR registers range>
- interrupts : <interrupt mapping for DMA0/1 interrupts sources:
2 sources: DMAx CS FIFO Needs Service IRQ (on UIC0)
and DMA Error IRQ (on UIC1). The latter is common
for both DMA engines>.
Example:
DMA0: dma0@400100100 {
compatible = "ibm,dma-440spe";
cell-index = <0>;
reg = <0x00000004 0x00100100 0x100>;
dcr-reg = <0x060 0x020>;
interrupt-parent = <&DMA0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = <
0 &UIC0 0x14 4
1 &UIC1 0x16 4>;
};
iii) XOR Accelerator node
Required properties:
- compatible : "amcc,xor-accelerator";
- reg : <registers mapping>
- interrupts : <interrupt mapping for XOR interrupt source>
Example:
xor-accel@400200000 {
compatible = "amcc,xor-accelerator";
reg = <0x00000004 0x00200000 0x400>;
interrupt-parent = <&UIC1>;
interrupts = <0x1f 4>;
};
iv) Memory Queue Module node
Required properties:
- compatible : "ibm,mq-440spe";
- dcr-reg : <DCR registers range>
Example:
MQ0: mq {
compatible = "ibm,mq-440spe";
dcr-reg = <0x040 0x020>;
};

18
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 overridden. Here the possible values of
"reset_type":
1 - PPC4xx core reset
2 - PPC4xx chip reset
3 - PPC4xx system reset (default)
Example:
cpu@0 {
device_type = "cpu";
model = "PowerPC,440SPe";
...
reset-type = <2>; /* Use chip-reset */
};

46
bindings/powerpc/fsl/ccf.txt Normal file
View File

@@ -0,0 +1,46 @@
Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding
DESCRIPTION
The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure
that enables the implementation of coherent, multicore systems.
Required properties:
- compatible: <string list>
fsl,corenet1-cf - CoreNet coherency fabric version 1.
Example chips: T4240, B4860
fsl,corenet2-cf - CoreNet coherency fabric version 2.
Example chips: P5040, P5020, P4080, P3041, P2041
fsl,corenet-cf - Used to represent the common registers
between CCF version 1 and CCF version 2. This compatible
is retained for compatibility reasons, as it was already
used for both CCF version 1 chips and CCF version 2
chips. It should be specified after either
"fsl,corenet1-cf" or "fsl,corenet2-cf".
- reg: <prop-encoded-array>
A standard property. Represents the CCF registers.
- interrupts: <prop-encoded-array>
Interrupt mapping for CCF error interrupt.
- fsl,ccf-num-csdids: <u32>
Specifies the number of Coherency Subdomain ID Port Mapping
Registers that are supported by the CCF.
- fsl,ccf-num-snoopids: <u32>
Specifies the number of Snoop ID Port Mapping Registers that
are supported by CCF.
Example:
corenet-cf@18000 {
compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
reg = <0x18000 0x1000>;
interrupts = <16 2 1 31>;
fsl,ccf-num-csdids = <32>;
fsl,ccf-num-snoopids = <32>;
};

33
bindings/powerpc/fsl/cpus.txt Normal file
View File

@@ -0,0 +1,33 @@
===================================================================
Power Architecture CPU Binding
Copyright 2013 Freescale Semiconductor Inc.
Power Architecture CPUs in Freescale SOCs are represented in device trees as
per the definition in the Devicetree Specification.
In addition to the Devicetree Specification definitions, the properties
defined below may be present on CPU nodes.
PROPERTIES
- fsl,eref-*
Usage: optional
Value type: <empty>
Definition: The EREF (EREF: A Programmer.s Reference Manual for
Freescale Power Architecture) defines the architecture for Freescale
Power CPUs. The EREF defines some architecture categories not defined
by the Power ISA. For these EREF-specific categories, the existence of
a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
name with all uppercase letters converted to lowercase, indicates that
the category is supported by the implementation.
- fsl,portid-mapping
Usage: optional
Value type: <u32>
Definition: The Coherency Subdomain ID Port Mapping Registers and
Snoop ID Port Mapping registers, which are part of the CoreNet
Coherency fabric (CCF), provide a CoreNet Coherency Subdomain
ID/CoreNet Snoop ID to cpu mapping functions. Certain bits from
these registers should be set if the coresponding CPU should be
snooped. This property defines a bitmask which selects the bit
that should be set if this cpu should be snooped.

388
bindings/powerpc/fsl/dcsr.txt Normal file
View File

@@ -0,0 +1,388 @@
===================================================================
Debug Control and Status Register (DCSR) Binding
Copyright 2011 Freescale Semiconductor Inc.
NOTE: The bindings described in this document are preliminary and subject
to change. Some of the compatible strings that contain only generic names
may turn out to be inappropriate, or need additional properties to describe
the integration of the block with the rest of the chip.
=====================================================================
Debug Control and Status Register Memory Map
Description
This node defines the base address and range for the
defined DCSR Memory Map. Child nodes will describe the individual
debug blocks defined within this memory space.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,dcsr" and "simple-bus".
The DCSR space exists in the memory-mapped bus.
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
or representing physical addresses in child nodes.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
or representing the size of physical addresses in
child nodes.
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
range of the DCSR space.
EXAMPLE
dcsr: dcsr@f00000000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,dcsr", "simple-bus";
ranges = <0x00000000 0xf 0x00000000 0x01008000>;
};
=====================================================================
Event Processing Unit
This node represents the region of DCSR space allocated to the EPU
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,dcsr-epu"
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by the EPU.
The value of the interrupts property consists of three
interrupt specifiers. The format of the specifier is defined
by the binding document describing the node's interrupt parent.
The EPU counters can be configured to assert the performance
monitor interrupt signal based on either counter overflow or value
match. Which counter asserted the interrupt is captured in an EPU
Counter Interrupt Status Register (EPCPUISR).
The EPU unit can also be configured to assert either or both of
two interrupt signals based on debug event sources within the SoC.
The interrupt signals are epu_xt_int0 and epu_xt_int1.
Which event source asserted the interrupt is captured in an EPU
Interrupt Status Register (EPISR0,EPISR1).
Interrupt numbers are listed in order (perfmon, event0, event1).
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-epu@0 {
compatible = "fsl,dcsr-epu";
interrupts = <52 2 0 0
84 2 0 0
85 2 0 0>;
interrupt-parent = <&mpic>;
reg = <0x0 0x1000>;
};
=======================================================================
Nexus Port Controller
This node represents the region of DCSR space allocated to the NPC
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,dcsr-npc"
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
The Nexus Port controller occupies two regions in the DCSR space
with distinct functionality.
The first register range describes the Nexus Port Controller
control and status registers.
The second register range describes the Nexus Port Controller
internal trace buffer. The NPC trace buffer is a small memory buffer
which stages the nexus trace data for transmission via the Aurora port
or to a DDR based trace buffer. In some configurations the NPC trace
buffer can be the only trace buffer used.
EXAMPLE
dcsr-npc {
compatible = "fsl,dcsr-npc";
reg = <0x1000 0x1000 0x1000000 0x8000>;
};
=======================================================================
Nexus Concentrator
This node represents the region of DCSR space allocated to the NXC
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,dcsr-nxc"
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-nxc@2000 {
compatible = "fsl,dcsr-nxc";
reg = <0x2000 0x1000>;
};
=======================================================================
CoreNet Debug Controller
This node represents the region of DCSR space allocated to
the CoreNet Debug controller.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,dcsr-corenet"
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
The CoreNet Debug controller occupies two regions in the DCSR space
with distinct functionality.
The first register range describes the CoreNet Debug Controller
functionalty to perform transaction and transaction attribute matches.
The second register range describes the CoreNet Debug Controller
functionalty to trigger event notifications and debug traces.
EXAMPLE
dcsr-corenet {
compatible = "fsl,dcsr-corenet";
reg = <0x8000 0x1000 0xB0000 0x1000>;
};
=======================================================================
Data Path Debug controller
This node represents the region of DCSR space allocated to
the DPAA Debug Controller. This controller controls debug configuration
for the QMAN and FMAN blocks.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include both an identifier specific to the SoC
or Debug IP of the form "fsl,<soc>-dcsr-dpaa" in addition to the
generic compatible string "fsl,dcsr-dpaa".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-dpaa@9000 {
compatible = "fsl,p4080-dcsr-dpaa", "fsl,dcsr-dpaa";
reg = <0x9000 0x1000>;
};
=======================================================================
OCeaN Debug controller
This node represents the region of DCSR space allocated to
the OCN Debug Controller.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include both an identifier specific to the SoC
or Debug IP of the form "fsl,<soc>-dcsr-ocn" in addition to the
generic compatible string "fsl,dcsr-ocn".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-ocn@11000 {
compatible = "fsl,p4080-dcsr-ocn", "fsl,dcsr-ocn";
reg = <0x11000 0x1000>;
};
=======================================================================
DDR Controller Debug controller
This node represents the region of DCSR space allocated to
the OCN Debug Controller.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,dcsr-ddr"
- dev-handle
Usage: required
Definition: A phandle to associate this debug node with its
component controller.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-ddr@12000 {
compatible = "fsl,dcsr-ddr";
dev-handle = <&ddr1>;
reg = <0x12000 0x1000>;
};
=======================================================================
Nexus Aurora Link Controller
This node represents the region of DCSR space allocated to
the NAL Controller.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include both an identifier specific to the SoC
or Debug IP of the form "fsl,<soc>-dcsr-nal" in addition to the
generic compatible string "fsl,dcsr-nal".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-nal@18000 {
compatible = "fsl,p4080-dcsr-nal", "fsl,dcsr-nal";
reg = <0x18000 0x1000>;
};
=======================================================================
Run Control and Power Management
This node represents the region of DCSR space allocated to
the RCPM Debug Controller. This functionlity is limited to the
control the debug operations of the SoC and cores.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include both an identifier specific to the SoC
or Debug IP of the form "fsl,<soc>-dcsr-rcpm" in addition to the
generic compatible string "fsl,dcsr-rcpm".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-rcpm@22000 {
compatible = "fsl,p4080-dcsr-rcpm", "fsl,dcsr-rcpm";
reg = <0x22000 0x1000>;
};
=======================================================================
Core Service Bridge Proxy
This node represents the region of DCSR space allocated to
the Core Service Bridge Proxies.
There is one Core Service Bridge Proxy device for each CPU in the system.
This functionlity provides access to the debug operations of the CPU.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include both an identifier specific to the cpu
of the form "fsl,dcsr-<cpu>-sb-proxy" in addition to the
generic compatible string "fsl,dcsr-cpu-sb-proxy".
- cpu-handle
Usage: required
Definition: A phandle to associate this debug node with its cpu.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
offset and length of the DCSR space registers of the device
configuration block.
EXAMPLE
dcsr-cpu-sb-proxy@40000 {
compatible = "fsl,dcsr-e500mc-sb-proxy",
"fsl,dcsr-cpu-sb-proxy";
cpu-handle = <&cpu0>;
reg = <0x40000 0x1000>;
};
dcsr-cpu-sb-proxy@41000 {
compatible = "fsl,dcsr-e500mc-sb-proxy",
"fsl,dcsr-cpu-sb-proxy";
cpu-handle = <&cpu1>;
reg = <0x41000 0x1000>;
};
=======================================================================

32
bindings/powerpc/fsl/diu.txt Normal file
View File

@@ -0,0 +1,32 @@
* Freescale Display Interface Unit
The Freescale DIU is a LCD controller, with proper hardware, it can also
drive DVI monitors.
Required properties:
- compatible : should be "fsl,diu" or "fsl,mpc5121-diu".
- reg : should contain at least address and length of the DIU register
set.
- interrupts : one DIU interrupt should be described here.
Optional properties:
- edid : verbatim EDID data block describing attached display.
Data from the detailed timing descriptor will be used to
program the display controller.
Example (MPC8610HPCD):
display@2c000 {
compatible = "fsl,diu";
reg = <0x2c000 100>;
interrupts = <72 2>;
interrupt-parent = <&mpic>;
};
Example for MPC5121:
display@2100 {
compatible = "fsl,mpc5121-diu";
reg = <0x2100 0x100>;
interrupts = <64 0x8>;
interrupt-parent = <&ipic>;
edid = [edid-data];
};

204
bindings/powerpc/fsl/dma.txt Normal file
View File

@@ -0,0 +1,204 @@
* Freescale DMA Controllers
** Freescale Elo DMA Controller
This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx
series chips such as mpc8315, mpc8349, mpc8379 etc.
Required properties:
- compatible : must include "fsl,elo-dma"
- reg : DMA General Status Register, i.e. DGSR which contains
status for all the 4 DMA channels
- ranges : describes the mapping between the address space of the
DMA channels and the address space of the DMA controller
- cell-index : controller index. 0 for controller @ 0x8100
- interrupts : interrupt specifier for DMA IRQ
- DMA channel nodes:
- compatible : must include "fsl,elo-dma-channel"
However, see note below.
- reg : DMA channel specific registers
- cell-index : DMA channel index starts at 0.
Optional properties:
- interrupts : interrupt specifier for DMA channel IRQ
(on 83xx this is expected to be identical to
the interrupts property of the parent node)
Example:
dma@82a8 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8349-dma", "fsl,elo-dma";
reg = <0x82a8 4>;
ranges = <0 0x8100 0x1a4>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
cell-index = <0>;
reg = <0 0x80>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@80 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
cell-index = <1>;
reg = <0x80 0x80>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@100 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
cell-index = <2>;
reg = <0x100 0x80>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
dma-channel@180 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
cell-index = <3>;
reg = <0x180 0x80>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
};
** Freescale EloPlus DMA Controller
This is a 4-channel DMA controller with extended addresses and chaining,
mainly used in Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as
mpc8540, mpc8641 p4080, bsc9131 etc.
Required properties:
- compatible : must include "fsl,eloplus-dma"
- reg : DMA General Status Register, i.e. DGSR which contains
status for all the 4 DMA channels
- cell-index : controller index. 0 for controller @ 0x21000,
1 for controller @ 0xc000
- ranges : describes the mapping between the address space of the
DMA channels and the address space of the DMA controller
- DMA channel nodes:
- compatible : must include "fsl,eloplus-dma-channel"
However, see note below.
- cell-index : DMA channel index starts at 0.
- reg : DMA channel specific registers
- interrupts : interrupt specifier for DMA channel IRQ
Example:
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
reg = <0x21300 4>;
ranges = <0 0x21100 0x200>;
cell-index = <0>;
dma-channel@0 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <0 0x80>;
cell-index = <0>;
interrupt-parent = <&mpic>;
interrupts = <20 2>;
};
dma-channel@80 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
cell-index = <1>;
interrupt-parent = <&mpic>;
interrupts = <21 2>;
};
dma-channel@100 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
cell-index = <2>;
interrupt-parent = <&mpic>;
interrupts = <22 2>;
};
dma-channel@180 {
compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
cell-index = <3>;
interrupt-parent = <&mpic>;
interrupts = <23 2>;
};
};
** Freescale Elo3 DMA Controller
DMA controller which has same function as EloPlus except that Elo3 has 8
channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
series chips, such as t1040, t4240, b4860.
Required properties:
- compatible : must include "fsl,elo3-dma"
- reg : contains two entries for DMA General Status Registers,
i.e. DGSR0 which includes status for channel 1~4, and
DGSR1 for channel 5~8
- ranges : describes the mapping between the address space of the
DMA channels and the address space of the DMA controller
- DMA channel nodes:
- compatible : must include "fsl,eloplus-dma-channel"
- reg : DMA channel specific registers
- interrupts : interrupt specifier for DMA channel IRQ
Example:
dma@100300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,elo3-dma";
reg = <0x100300 0x4>,
<0x100600 0x4>;
ranges = <0x0 0x100100 0x500>;
dma-channel@0 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x0 0x80>;
interrupts = <28 2 0 0>;
};
dma-channel@80 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x80 0x80>;
interrupts = <29 2 0 0>;
};
dma-channel@100 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x100 0x80>;
interrupts = <30 2 0 0>;
};
dma-channel@180 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x180 0x80>;
interrupts = <31 2 0 0>;
};
dma-channel@300 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x300 0x80>;
interrupts = <76 2 0 0>;
};
dma-channel@380 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x380 0x80>;
interrupts = <77 2 0 0>;
};
dma-channel@400 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x400 0x80>;
interrupts = <78 2 0 0>;
};
dma-channel@480 {
compatible = "fsl,eloplus-dma-channel";
reg = <0x480 0x80>;
interrupts = <79 2 0 0>;
};
};
Note on DMA channel compatible properties: The compatible property must say
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
DMA driver, such as the SSI sound drivers for the MPC8610. Therefore, any DMA
channel that should be used for another driver should not use
"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel". For the SSI drivers, for
example, the compatible property should be "fsl,ssi-dma-channel". See ssi.txt
for more information.

60
bindings/powerpc/fsl/ecm.txt Normal file
View File

@@ -0,0 +1,60 @@
=====================================================================
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>
=====================================================================

309
bindings/powerpc/fsl/interlaken-lac.txt Normal file
View File

@@ -0,0 +1,309 @@
===============================================================================
Freescale Interlaken Look-Aside Controller Device Bindings
Copyright 2012 Freescale Semiconductor Inc.
CONTENTS
- Interlaken Look-Aside Controller (LAC) Node
- Example LAC Node
- Interlaken Look-Aside Controller (LAC) Software Portal Node
- Interlaken Look-Aside Controller (LAC) Software Portal Child Nodes
- Example LAC SWP Node with Child Nodes
==============================================================================
Interlaken Look-Aside Controller (LAC) Node
DESCRIPTION
The Interlaken is a narrow, high speed channelized chip-to-chip interface. To
facilitate interoperability between a data path device and a look-aside
co-processor, the Interlaken Look-Aside protocol is defined for short
transaction-related transfers. Although based on the Interlaken protocol,
Interlaken Look-Aside is not directly compatible with Interlaken and can be
considered a different operation mode.
The Interlaken LA controller connects internal platform to Interlaken serial
interface. It accepts LA command through software portals, which are system
memory mapped 4KB spaces. The LA commands are then translated into the
Interlaken control words and data words, which are sent on TX side to TCAM
through SerDes lanes.
There are two 4KiB spaces defined within the LAC global register memory map.
There is a full register set at 0x0000-0x0FFF (also known as the "hypervisor"
version), and a subset at 0x1000-0x1FFF. The former is a superset of the
latter, and includes certain registers that should not be accessible to
partitioned software. Separate nodes are used for each region, with a phandle
linking the hypervisor node to the normal operating node.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,interlaken-lac". This represents only
those LAC CCSR registers not protected in partitioned
software. The version of the device is determined by the LAC
IP Block Revision Register (IPBRR0) at offset 0x0BF8.
Table of correspondences between IPBRR0 values and example
chips:
Value Device
----------- -------
0x02000100 T4240
The Hypervisor node has a different compatible. It must include
"fsl,interlaken-lac-hv". This node represents the protected
LAC register space and is required except inside a partition
where access to the hypervisor node is to be denied.
- fsl,non-hv-node
Usage: required in "fsl,interlaken-lac-hv"
Value type: <phandle>
Definition: Points to the non-protected LAC CCSR mapped register space
node.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The first resource represents the
Interlaken LAC configuration registers.
- interrupts:
Usage: required in non-hv node only
Value type: <prop-encoded-array>
Definition: Interrupt mapping for Interlaken LAC error IRQ.
EXAMPLE
lac: lac@229000 {
compatible = "fsl,interlaken-lac"
reg = <0x229000 0x1000>;
interrupts = <16 2 1 18>;
};
lac-hv@228000 {
compatible = "fsl,interlaken-lac-hv"
reg = <0x228000 0x1000>;
fsl,non-hv-node = <&lac>;
};
===============================================================================
Interlaken Look-Aside Controller (LAC) Software Portal Container Node
DESCRIPTION
The Interlaken Look-Aside Controller (LAC) utilizes Software Portals to accept
Interlaken Look-Aside (ILA) commands. The Interlaken LAC software portal
memory map occupies 128KB of memory space. The software portal memory space is
intended to be cache-enabled. WIMG for each software space is required to be
0010 if stashing is enabled; otherwise, WIMG can be 0000 or 0010.
PROPERTIES
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Must have a value of 1.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Must have a value of 1.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,interlaken-lac-portals"
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the address and length
of the LAC portal memory space.
===============================================================================
Interlaken Look-Aside Controller (LAC) Software Portals Child Nodes
DESCRIPTION
There are up to 24 available software portals with each software portal
requiring 4KB of consecutive memory within the software portal memory mapped
space.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,interlaken-lac-portal-vX.Y" where X is
the Major version (IP_MJ) found in the LAC IP Block Revision
Register (IPBRR0), at offset 0x0BF8, and Y is the Minor version
(IP_MN).
Table of correspondences between version values and example chips:
Value Device
------ -------
1.0 T4240
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The first resource represents the
Interlaken LAC software portal registers.
- fsl,liodn
Value type: <u32>
Definition: The logical I/O device number (LIODN) for this device. The
LIODN is a number expressed by this device and used to perform
look-ups in the IOMMU (PAMU) address table when performing
DMAs. This property is automatically added by u-boot.
===============================================================================
EXAMPLE
lac-portals {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,interlaken-lac-portals";
ranges = <0x0 0xf 0xf4400000 0x20000>;
lportal0: lac-portal@0 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x204>;
reg = <0x0 0x1000>;
};
lportal1: lac-portal@1000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x205>;
reg = <0x1000 0x1000>;
};
lportal2: lac-portal@2000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x206>;
reg = <0x2000 0x1000>;
};
lportal3: lac-portal@3000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x207>;
reg = <0x3000 0x1000>;
};
lportal4: lac-portal@4000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x208>;
reg = <0x4000 0x1000>;
};
lportal5: lac-portal@5000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x209>;
reg = <0x5000 0x1000>;
};
lportal6: lac-portal@6000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20A>;
reg = <0x6000 0x1000>;
};
lportal7: lac-portal@7000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20B>;
reg = <0x7000 0x1000>;
};
lportal8: lac-portal@8000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20C>;
reg = <0x8000 0x1000>;
};
lportal9: lac-portal@9000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20D>;
reg = <0x9000 0x1000>;
};
lportal10: lac-portal@a000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20E>;
reg = <0xA000 0x1000>;
};
lportal11: lac-portal@b000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20F>;
reg = <0xB000 0x1000>;
};
lportal12: lac-portal@c000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x210>;
reg = <0xC000 0x1000>;
};
lportal13: lac-portal@d000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x211>;
reg = <0xD000 0x1000>;
};
lportal14: lac-portal@e000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x212>;
reg = <0xE000 0x1000>;
};
lportal15: lac-portal@f000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x213>;
reg = <0xF000 0x1000>;
};
lportal16: lac-portal@10000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x214>;
reg = <0x10000 0x1000>;
};
lportal17: lac-portal@11000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x215>;
reg = <0x11000 0x1000>;
};
lportal8: lac-portal@1200 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x216>;
reg = <0x12000 0x1000>;
};
lportal19: lac-portal@13000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x217>;
reg = <0x13000 0x1000>;
};
lportal20: lac-portal@14000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x218>;
reg = <0x14000 0x1000>;
};
lportal21: lac-portal@15000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x219>;
reg = <0x15000 0x1000>;
};
lportal22: lac-portal@16000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x21A>;
reg = <0x16000 0x1000>;
};
lportal23: lac-portal@17000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x21B>;
reg = <0x17000 0x1000>;
};
};

55
bindings/powerpc/fsl/l2cache.txt Normal file
View File

@@ -0,0 +1,55 @@
Freescale L2 Cache Controller
L2 cache is present in Freescale's QorIQ and QorIQ Qonverge platforms.
The cache bindings explained below are Devicetree Specification compliant
Required Properties:
- compatible : Should include one of the following:
"fsl,b4420-l2-cache-controller"
"fsl,b4860-l2-cache-controller"
"fsl,bsc9131-l2-cache-controller"
"fsl,bsc9132-l2-cache-controller"
"fsl,c293-l2-cache-controller"
"fsl,mpc8536-l2-cache-controller"
"fsl,mpc8540-l2-cache-controller"
"fsl,mpc8541-l2-cache-controller"
"fsl,mpc8544-l2-cache-controller"
"fsl,mpc8548-l2-cache-controller"
"fsl,mpc8555-l2-cache-controller"
"fsl,mpc8560-l2-cache-controller"
"fsl,mpc8568-l2-cache-controller"
"fsl,mpc8569-l2-cache-controller"
"fsl,mpc8572-l2-cache-controller"
"fsl,p1010-l2-cache-controller"
"fsl,p1011-l2-cache-controller"
"fsl,p1012-l2-cache-controller"
"fsl,p1013-l2-cache-controller"
"fsl,p1014-l2-cache-controller"
"fsl,p1015-l2-cache-controller"
"fsl,p1016-l2-cache-controller"
"fsl,p1020-l2-cache-controller"
"fsl,p1021-l2-cache-controller"
"fsl,p1022-l2-cache-controller"
"fsl,p1023-l2-cache-controller"
"fsl,p1024-l2-cache-controller"
"fsl,p1025-l2-cache-controller"
"fsl,p2010-l2-cache-controller"
"fsl,p2020-l2-cache-controller"
"fsl,t2080-l2-cache-controller"
"fsl,t4240-l2-cache-controller"
and "cache".
- reg : Address and size of L2 cache controller registers
- cache-size : Size of the entire L2 cache
- interrupts : Error interrupt of L2 controller
- cache-line-size : Size of L2 cache lines
Example:
L2: l2-cache-controller@20000 {
compatible = "fsl,bsc9132-l2-cache-controller", "cache";
reg = <0x20000 0x1000>;
cache-line-size = <32>; // 32 bytes
cache-size = <0x40000>; // L2,256K
interrupts = <16 2 1 0>;
};

43
bindings/powerpc/fsl/lbc.txt Normal file
View File

@@ -0,0 +1,43 @@
* Chipselect/Local Bus
Properties:
- name : Should be localbus
- #address-cells : Should be either two or three. The first cell is the
chipselect number, and the remaining cells are the
offset into the chipselect.
- #size-cells : Either one or two, depending on how large each chipselect
can be.
- ranges : Each range corresponds to a single chipselect, and cover
the entire access window as configured.
Example:
localbus@f0010100 {
compatible = "fsl,mpc8272-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0010100 0x40>;
ranges = <0x0 0x0 0xfe000000 0x02000000
0x1 0x0 0xf4500000 0x00008000
0x2 0x0 0xfd810000 0x00010000>;
flash@0,0 {
compatible = "jedec-flash";
reg = <0x0 0x0 0x2000000>;
bank-width = <4>;
device-width = <1>;
};
board-control@1,0 {
reg = <0x1 0x0 0x20>;
compatible = "fsl,mpc8272ads-bcsr";
};
simple-periph@2,0 {
compatible = "fsl,elbc-gpcm-uio";
reg = <0x2 0x0 0x10000>;
elbc-gpcm-br = <0xfd810800>;
elbc-gpcm-or = <0xffff09f7>;
};
};

60
bindings/powerpc/fsl/mcm.txt Normal file
View File

@@ -0,0 +1,60 @@
=====================================================================
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>
=====================================================================

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

78
bindings/powerpc/fsl/mpc5121-psc.txt Normal file
View File

@@ -0,0 +1,78 @@
MPC5121 PSC Device Tree Bindings
PSC in UART mode
----------------
For PSC in UART mode the needed PSC serial devices
are specified by fsl,mpc5121-psc-uart nodes in the
fsl,mpc5121-immr SoC node. Additionally the PSC FIFO
Controller node fsl,mpc5121-psc-fifo is required there:
fsl,mpc512x-psc-uart nodes
--------------------------
Required properties :
- compatible : Should contain "fsl,<soc>-psc-uart" and "fsl,<soc>-psc"
Supported <soc>s: mpc5121, mpc5125
- reg : Offset and length of the register set for the PSC device
- interrupts : <a b> where a is the interrupt number of the
PSC FIFO Controller and b is a field that represents an
encoding of the sense and level information for the interrupt.
Recommended properties :
- fsl,rx-fifo-size : the size of the RX fifo slice (a multiple of 4)
- fsl,tx-fifo-size : the size of the TX fifo slice (a multiple of 4)
PSC in SPI mode
---------------
Similar to the UART mode a PSC can be operated in SPI mode. The compatible used
for that is fsl,mpc5121-psc-spi. It requires a fsl,mpc5121-psc-fifo as well.
The required and recommended properties are identical to the
fsl,mpc5121-psc-uart nodes, just use spi instead of uart in the compatible
string.
fsl,mpc512x-psc-fifo node
-------------------------
Required properties :
- compatible : Should be "fsl,<soc>-psc-fifo"
Supported <soc>s: mpc5121, mpc5125
- reg : Offset and length of the register set for the PSC
FIFO Controller
- interrupts : <a b> where a is the interrupt number of the
PSC FIFO Controller and b is a field that represents an
encoding of the sense and level information for the interrupt.
Recommended properties :
- clocks : specifies the clock needed to operate the fifo controller
- clock-names : name(s) for the clock(s) listed in clocks
Example for a board using PSC0 and PSC1 devices in serial mode:
serial@11000 {
compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
cell-index = <0>;
reg = <0x11000 0x100>;
interrupts = <40 0x8>;
interrupt-parent = < &ipic >;
fsl,rx-fifo-size = <16>;
fsl,tx-fifo-size = <16>;
};
serial@11100 {
compatible = "fsl,mpc5121-psc-uart", "fsl,mpc5121-psc";
cell-index = <1>;
reg = <0x11100 0x100>;
interrupts = <40 0x8>;
interrupt-parent = < &ipic >;
fsl,rx-fifo-size = <16>;
fsl,tx-fifo-size = <16>;
};
pscfifo@11f00 {
compatible = "fsl,mpc5121-psc-fifo";
reg = <0x11f00 0x100>;
interrupts = <40 0x8>;
interrupt-parent = < &ipic >;
};

21
bindings/powerpc/fsl/mpc512x_lpbfifo.txt Normal file
View File

@@ -0,0 +1,21 @@
Freescale MPC512x LocalPlus Bus FIFO (called SCLPC in the Reference Manual)
Required properties:
- compatible: should be "fsl,mpc512x-lpbfifo";
- reg: should contain the offset and length of SCLPC register set;
- interrupts: should contain the interrupt specifier for SCLPC; syntax of an
interrupt client node is described in interrupt-controller/interrupts.txt;
- dmas: should contain the DMA specifier for SCLPC as described at
dma/dma.txt and dma/mpc512x-dma.txt;
- dma-names: should be "rx-tx";
Example:
sclpc@10100 {
compatible = "fsl,mpc512x-lpbfifo";
reg = <0x10100 0x50>;
interrupts = <7 0x8>;
dmas = <&dma0 26>;
dma-names = "rx-tx";
};

198
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 its own set of interrupt sources which are
cascaded off of peripheral interrupt 0, which the driver interprets as a
fourth group, SDMA.
The interrupts property for device nodes using the mpc5200 pic consists
of three cells; <L1 L2 level>
L1 := [CRIT=0, MAIN=1, PERP=2, SDMA=3]
L2 := interrupt number; directly mapped from the value in the
"ICTL PerStat, MainStat, CritStat Encoded Register"
level := [LEVEL_HIGH=0, EDGE_RISING=1, EDGE_FALLING=2, LEVEL_LOW=3]
For external IRQs, use the following interrupt property values (how to
specify external interrupts is a frequently asked question):
External interrupts:
external irq0: interrupts = <0 0 n>;
external irq1: interrupts = <1 1 n>;
external irq2: interrupts = <1 2 n>;
external irq3: interrupts = <1 3 n>;
'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low)
fsl,mpc5200-mscan nodes
-----------------------
See file Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt

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

111
bindings/powerpc/fsl/msi-pic.txt Normal file
View File

@@ -0,0 +1,111 @@
* Freescale MSI interrupt controller
Required properties:
- compatible : compatible list, may contain one or two entries
The first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" or
"fsl,mpic-msi-v4.3" depending on the parent type and version. If mpic
version is 4.3, the number of MSI registers is increased to 16, MSIIR1 is
provided to access these 16 registers, and compatible "fsl,mpic-msi-v4.3"
should be used. The first entry is optional; the second entry is
required.
- reg : It may contain one or two regions. The first region should contain
the address and the length of the shared message interrupt register set.
The second region should contain the address of aliased MSIIR or MSIIR1
register for platforms that have such an alias, if using MSIIR1, the second
region must be added because different MSI group has different MSIIR1 offset.
- interrupts : each one of the interrupts here is one entry per 32 MSIs,
and routed to the host interrupt controller. the interrupts should
be set as edge sensitive. If msi-available-ranges is present, only
the interrupts that correspond to available ranges shall be present.
Optional properties:
- msi-available-ranges: use <start count> style section to define which
msi interrupt can be used in the 256 msi interrupts. This property is
optional, without this, all the MSI interrupts can be used.
Each available range must begin and end on a multiple of 32 (i.e.
no splitting an individual MSI register or the associated PIC interrupt).
MPIC v4.3 does not support this property because the 32 interrupts of an
individual register are not continuous when using MSIIR1.
- msi-address-64: 64-bit PCI address of the MSIIR register. The MSIIR register
is used for MSI messaging. The address of MSIIR in PCI address space is
the MSI message address.
This property may be used in virtualized environments where the hypervisor
has created an alternate mapping for the MSIR block. See below for an
explanation.
Example:
msi@41600 {
compatible = "fsl,mpc8610-msi", "fsl,mpic-msi";
reg = <0x41600 0x80>;
msi-available-ranges = <0 0x100>;
interrupts = <
0xe0 0
0xe1 0
0xe2 0
0xe3 0
0xe4 0
0xe5 0
0xe6 0
0xe7 0>;
interrupt-parent = <&mpic>;
};
msi@41600 {
compatible = "fsl,mpic-msi-v4.3";
reg = <0x41600 0x200 0x44148 4>;
interrupts = <
0xe0 0 0 0
0xe1 0 0 0
0xe2 0 0 0
0xe3 0 0 0
0xe4 0 0 0
0xe5 0 0 0
0xe6 0 0 0
0xe7 0 0 0
0x100 0 0 0
0x101 0 0 0
0x102 0 0 0
0x103 0 0 0
0x104 0 0 0
0x105 0 0 0
0x106 0 0 0
0x107 0 0 0>;
};
The Freescale hypervisor and msi-address-64
-------------------------------------------
Normally, PCI devices have access to all of CCSR via an ATMU mapping. The
Freescale MSI driver calculates the address of MSIIR (in the MSI register
block) and sets that address as the MSI message address.
In a virtualized environment, the hypervisor may need to create an IOMMU
mapping for MSIIR. The Freescale ePAPR hypervisor has this requirement
because of hardware limitations of the Peripheral Access Management Unit
(PAMU), which is currently the only IOMMU that the hypervisor supports.
The ATMU is programmed with the guest physical address, and the PAMU
intercepts transactions and reroutes them to the true physical address.
In the PAMU, each PCI controller is given only one primary window. The
PAMU restricts DMA operations so that they can only occur within a window.
Because PCI devices must be able to DMA to memory, the primary window must
be used to cover all of the guest's memory space.
PAMU primary windows can be divided into 256 subwindows, and each
subwindow can have its own address mapping ("guest physical" to "true
physical"). However, each subwindow has to have the same alignment, which
means they cannot be located at just any address. Because of these
restrictions, it is usually impossible to create a 4KB subwindow that
covers MSIIR where it's normally located.
Therefore, the hypervisor has to create a subwindow inside the same
primary window used for memory, but mapped to the MSIR block (where MSIIR
lives). The first subwindow after the end of guest memory is used for
this. The address specified in the msi-address-64 property is the PCI
address of MSIIR. The hypervisor configures the PAMU to map that address to
the true physical address of MSIIR.

148
bindings/powerpc/fsl/pamu.txt Normal file
View File

@@ -0,0 +1,148 @@
Freescale Peripheral Management Access Unit (PAMU) Device Tree Binding
DESCRIPTION
The PAMU is an I/O MMU that provides device-to-memory access control and
address translation capabilities.
Required properties:
- compatible : <string>
First entry is a version-specific string, such as
"fsl,pamu-v1.0". The second is "fsl,pamu".
- ranges : <prop-encoded-array>
A standard property. Utilized to describe the memory mapped
I/O space utilized by the controller. The size should
be set to the total size of the register space of all
physically present PAMU controllers. For example, for
PAMU v1.0, on an SOC that has five PAMU devices, the size
is 0x5000.
- interrupts : <prop-encoded-array>
Interrupt mappings. The first tuple is the normal PAMU
interrupt, used for reporting access violations. The second
is for PAMU hardware errors, such as PAMU operation errors
and ECC errors.
- #address-cells: <u32>
A standard property.
- #size-cells : <u32>
A standard property.
Optional properties:
- reg : <prop-encoded-array>
A standard property. It represents the CCSR registers of
all child PAMUs combined. Include it to provide support
for legacy drivers.
- fsl,portid-mapping : <u32>
The Coherency Subdomain ID Port Mapping Registers and
Snoop ID Port Mapping registers, which are part of the
CoreNet Coherency fabric (CCF), provide a CoreNet
Coherency Subdomain ID/CoreNet Snoop ID to pamu mapping
functions. Certain bits from these registers should be
set if PAMUs should be snooped. This property defines
a bitmask which selects the bits that should be set if
PAMUs should be snooped.
Child nodes:
Each child node represents one PAMU controller. Each SOC device that is
connected to a specific PAMU device should have a "fsl,pamu-phandle" property
that links to the corresponding specific child PAMU controller.
- reg : <prop-encoded-array>
A standard property. Specifies the physical address and
length (relative to the parent 'ranges' property) of this
PAMU controller's configuration registers. The size should
be set to the size of this PAMU controllers's register space.
For PAMU v1.0, this size is 0x1000.
- fsl,primary-cache-geometry
: <prop-encoded-array>
Two cells that specify the geometry of the primary PAMU
cache. The first is the number of cache lines, and the
second is the number of "ways". For direct-mapped caches,
specify a value of 1.
- fsl,secondary-cache-geometry
: <prop-encoded-array>
Two cells that specify the geometry of the secondary PAMU
cache. The first is the number of cache lines, and the
second is the number of "ways". For direct-mapped caches,
specify a value of 1.
Device nodes:
Devices that have LIODNs need to specify links to the parent PAMU controller
(the actual PAMU controller that this device is connected to) and a pointer to
the LIODN register, if applicable.
- fsl,iommu-parent
: <phandle>
Phandle to the single, specific PAMU controller node to which
this device is connect. The PAMU topology is represented in
the device tree to assist code that dynamically determines the
best LIODN values to minimize PAMU cache thrashing.
- fsl,liodn-reg : <prop-encoded-array>
Two cells that specify the location of the LIODN register
for this device. Required for devices that have a single
LIODN. The first cell is a phandle to a node that contains
the registers where the LIODN is to be set. The second is
the offset from the first "reg" resource of the node where
the specific LIODN register is located.
Example:
iommu@20000 {
compatible = "fsl,pamu-v1.0", "fsl,pamu";
reg = <0x20000 0x5000>;
ranges = <0 0x20000 0x5000>;
fsl,portid-mapping = <0xf80000>;
#address-cells = <1>;
#size-cells = <1>;
interrupts = <
24 2 0 0
16 2 1 30>;
pamu0: pamu@0 {
reg = <0 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu1: pamu@1000 {
reg = <0x1000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu2: pamu@2000 {
reg = <0x2000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu3: pamu@3000 {
reg = <0x3000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
pamu4: pamu@4000 {
reg = <0x4000 0x1000>;
fsl,primary-cache-geometry = <32 1>;
fsl,secondary-cache-geometry = <128 2>;
};
};
guts: global-utilities@e0000 {
compatible = "fsl,qoriq-device-config-1.0";
reg = <0xe0000 0xe00>;
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
};
/include/ "qoriq-dma-0.dtsi"
dma@100300 {
fsl,iommu-parent = <&pamu0>;
fsl,liodn-reg = <&guts 0x584>; /* DMA2LIODNR */
};

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

18
bindings/powerpc/fsl/scfg.txt Normal file
View File

@@ -0,0 +1,18 @@
Freescale Supplement configuration unit (SCFG)
SCFG is the supplemental configuration unit, that provides SoC specific
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- compatible: should be "fsl,<chip>-scfg"
- reg: should contain base address and length of SCFG memory-mapped
registers
Example:
scfg: global-utilities@fc000 {
compatible = "fsl,t1040-scfg";
reg = <0xfc000 0x1000>;
};

163
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 Devicetree Specification)
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>;
};
};

104
bindings/powerpc/fsl/srio.txt Normal file
View File

@@ -0,0 +1,104 @@
* 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 the Devicetree Specification)
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>;
};
};

248
bindings/powerpc/ibm,powerpc-cpu-features.txt Normal file
View File

@@ -0,0 +1,248 @@
*** NOTE ***
This document is copied from OPAL firmware
(skiboot/doc/device-tree/ibm,powerpc-cpu-features/binding.txt)
There is more complete overview and documentation of features in that
source tree. All patches and modifications should go there.
************
ibm,powerpc-cpu-features binding
================================
This device tree binding describes CPU features available to software, with
enablement, privilege, and compatibility metadata.
More general description of design and implementation of this binding is
found in design.txt, which also points to documentation of specific features.
/cpus/ibm,powerpc-cpu-features node binding
-------------------------------------------
Node: ibm,powerpc-cpu-features
Description: Container of CPU feature nodes.
The node name must be "ibm,powerpc-cpu-features".
It is implemented as a child of the node "/cpus", but this must not be
assumed by parsers.
The node is optional but should be provided by new OPAL firmware.
Properties:
- compatible
Usage: required
Value type: string
Definition: "ibm,powerpc-cpu-features"
This compatibility refers to backwards compatibility of the overall
design with parsers that behave according to these guidelines. This can
be extended in a backward compatible manner which would not warrant a
revision of the compatible property.
- isa
Usage: required
Value type: <u32>
Definition:
isa that the CPU is currently running in. This provides instruction set
compatibility, less the individual feature nodes. For example, an ISA v3.0
implementation that lacks the "transactional-memory" cpufeature node
should not use transactional memory facilities.
Value corresponds to the "Power ISA Version" multiplied by 1000.
For example, <3000> corresponds to Version 3.0, <2070> to Version 2.07.
The minor digit is available for revisions.
- display-name
Usage: optional
Value type: string
Definition:
A human readable name for the CPU.
/cpus/ibm,powerpc-cpu-features/example-feature node bindings
----------------------------------------------------------------
Each child node of cpu-features represents a CPU feature / capability.
Node: A string describing an architected CPU feature, e.g., "floating-point".
Description: A feature or capability supported by the CPUs.
The name of the node is a human readable string that forms the interface
used to describe features to software. Features are currently documented
in the code where they are implemented in skiboot/core/cpufeatures.c
Presence of the node indicates the feature is available.
Properties:
- isa
Usage: required
Value type: <u32>
Definition:
First level of the Power ISA that the feature appears in.
Software should filter out features when constraining the
environment to a particular ISA version.
Value is defined similarly to /cpus/features/isa
- usable-privilege
Usage: required
Value type: <u32> bit mask
Definition:
Bit numbers are LSB0
bit 0 - PR (problem state / user mode)
bit 1 - OS (privileged state)
bit 2 - HV (hypervisor state)
All other bits reserved and should be zero.
This property describes the privilege levels and/or software components
that can use the feature.
If bit 0 is set, then the hwcap-bit-nr property will exist.
- hv-support
Usage: optional
Value type: <u32> bit mask
Definition:
Bit numbers are LSB0
bit 0 - HFSCR
All other bits reserved and should be zero.
This property describes the HV privilege support required to enable the
feature to lesser privilege levels. If the property does not exist then no
support is required.
If no bits are set, the hypervisor must have explicit/custom support for
this feature.
If the HFSCR bit is set, then the hfscr-bit-nr property will exist and
the feature may be enabled by setting this bit in the HFSCR register.
- os-support
Usage: optional
Value type: <u32> bit mask
Definition:
Bit numbers are LSB0
bit 0 - FSCR
All other bits reserved and should be zero.
This property describes the OS privilege support required to enable the
feature to lesser privilege levels. If the property does not exist then no
support is required.
If no bits are set, the operating system must have explicit/custom support
for this feature.
If the FSCR bit is set, then the fscr-bit-nr property will exist and
the feature may be enabled by setting this bit in the FSCR register.
- hfscr-bit-nr
Usage: optional
Value type: <u32>
Definition: HFSCR bit position (LSB0)
This property exists when the hv-support property HFSCR bit is set. This
property describes the bit number in the HFSCR register that the
hypervisor must set in order to enable this feature.
This property also exists if an HFSCR bit corresponds with this feature.
This makes CPU feature parsing slightly simpler.
- fscr-bit-nr
Usage: optional
Value type: <u32>
Definition: FSCR bit position (LSB0)
This property exists when the os-support property FSCR bit is set. This
property describes the bit number in the FSCR register that the
operating system must set in order to enable this feature.
This property also exists if an FSCR bit corresponds with this feature.
This makes CPU feature parsing slightly simpler.
- hwcap-bit-nr
Usage: optional
Value type: <u32>
Definition: Linux ELF AUX vector bit position (LSB0)
This property may exist when the usable-privilege property value has PR bit set.
This property describes the bit number that should be set in the ELF AUX
hardware capability vectors in order to advertise this feature to userspace.
Bits 0-31 correspond to bits 0-31 in AT_HWCAP vector. Bits 32-63 correspond
to 0-31 in AT_HWCAP2 vector, and so on. Missing AT_HWCAPx vectors implies
that the feature is not enabled or can not be advertised. Operating systems
may provide a number of unassigned hardware capability bits to allow for new
features to be advertised.
Some properties representing features created before this binding are
advertised to userspace without a one-to-one hwcap bit number may not specify
this bit. Operating system will handle those bits specifically. All new
features usable by userspace will have a hwcap-bit-nr property.
- dependencies
Usage: optional
Value type: <prop-encoded-array>
Definition:
If this property exists then it is a list of phandles to cpu feature
nodes that must be enabled for this feature to be enabled.
Example
-------
/cpus/ibm,powerpc-cpu-features {
compatible = "ibm,powerpc-cpu-features";
isa = <3020>;
darn {
isa = <3000>;
usable-privilege = <1 | 2 | 4>;
hwcap-bit-nr = <xx>;
};
scv {
isa = <3000>;
usable-privilege = <1 | 2>;
os-support = <0>;
hwcap-bit-nr = <xx>;
};
stop {
isa = <3000>;
usable-privilege = <2 | 4>;
hv-support = <0>;
os-support = <0>;
};
vsx2 (hypothetical) {
isa = <3010>;
usable-privilege = <1 | 2 | 4>;
hv-support = <0>;
os-support = <0>;
hwcap-bit-nr = <xx>;
};
vsx2-newinsns {
isa = <3020>;
usable-privilege = <1 | 2 | 4>;
os-support = <1>;
fscr-bit-nr = <xx>;
hwcap-bit-nr = <xx>;
dependencies = <&vsx2>;
};
};

22
bindings/powerpc/ibm,vas.txt Normal file
View File

@@ -0,0 +1,22 @@
* IBM Powerpc Virtual Accelerator Switchboard (VAS)
VAS is a hardware mechanism that allows kernel subsystems and user processes
to directly submit compression and other requests to Nest accelerators (NX)
or other coprocessors functions.
Required properties:
- compatible : should be "ibm,vas".
- ibm,vas-id : A unique identifier for each instance of VAS in the system
- reg : Should contain 4 pairs of 64-bit fields specifying the Hypervisor
window context start and length, OS/User window context start and length,
"Paste address" start and length, "Paste window id" start bit and number
of bits)
Example:
vas@6019100000000 {
compatible = "ibm,vas", "ibm,power9-vas";
reg = <0x6019100000000 0x2000000 0x6019000000000 0x100000000 0x8000000000000 0x100000000 0x20 0x10>;
name = "vas";
ibm,vas-id = <0x1>;
};

109
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

176
bindings/powerpc/nintendo/wii.txt Normal file
View File

@@ -0,0 +1,176 @@
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
1.l) The General Purpose I/O (GPIO) controller node
see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
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

14
bindings/powerpc/opal/oppanel-opal.txt Normal file
View File

@@ -0,0 +1,14 @@
IBM OPAL Operator Panel Binding
-------------------------------
Required properties:
- compatible : Should be "ibm,opal-oppanel".
- #lines : Number of lines on the operator panel e.g. <0x2>.
- #length : Number of characters per line of the operator panel e.g. <0x10>.
Example:
oppanel {
compatible = "ibm,opal-oppanel";
#lines = <0x2>;
#length = <0x10>;
};

118
bindings/powerpc/opal/power-mgt.txt Normal file
View File

@@ -0,0 +1,118 @@
IBM Power-Management Bindings
=============================
Linux running on baremetal POWER machines has access to the processor
idle states. The description of these idle states is exposed via the
node @power-mgt in the device-tree by the firmware.
Definitions:
----------------
Typically each idle state has the following associated properties:
- name: The name of the idle state as defined by the firmware.
- flags: indicating some aspects of this idle states such as the
extent of state-loss, whether timebase is stopped on this
idle states and so on. The flag bits are as follows:
- exit-latency: The latency involved in transitioning the state of the
CPU from idle to running.
- target-residency: The minimum time that the CPU needs to reside in
this idle state in order to accrue power-savings
benefit.
Properties
----------------
The following properties provide details about the idle states. These
properties are exposed as arrays. Each entry in the property array
provides the value of that property for the idle state associated with
the array index of that entry.
If idle-states are defined, then the properties
"ibm,cpu-idle-state-names" and "ibm,cpu-idle-state-flags" are
required. The other properties are required unless mentioned
otherwise. The length of all the property arrays must be the same.
- ibm,cpu-idle-state-names:
Array of strings containing the names of the idle states.
- ibm,cpu-idle-state-flags:
Array of unsigned 32-bit values containing the values of the
flags associated with the aforementioned idle-states. The
flag bits are as follows:
0x00000001 /* Decrementer would stop */
0x00000002 /* Needs timebase restore */
0x00001000 /* Restore GPRs like nap */
0x00002000 /* Restore hypervisor resource from PACA pointer */
0x00004000 /* Program PORE to restore PACA pointer */
0x00010000 /* This is a nap state (POWER7,POWER8) */
0x00020000 /* This is a fast-sleep state (POWER8)*/
0x00040000 /* This is a winkle state (POWER8) */
0x00080000 /* This is a fast-sleep state which requires a */
/* software workaround for restoring the */
/* timebase (POWER8) */
0x00800000 /* This state uses SPR PMICR instruction */
/* (POWER8)*/
0x00100000 /* This is a fast stop state (POWER9) */
0x00200000 /* This is a deep-stop state (POWER9) */
- ibm,cpu-idle-state-latencies-ns:
Array of unsigned 32-bit values containing the values of the
exit-latencies (in ns) for the idle states in
ibm,cpu-idle-state-names.
- ibm,cpu-idle-state-residency-ns:
Array of unsigned 32-bit values containing the values of the
target-residency (in ns) for the idle states in
ibm,cpu-idle-state-names. On POWER8 this is an optional
property. If the property is absent, the target residency for
the "Nap", "FastSleep" are defined to 10000 and 300000000
respectively by the kernel. On POWER9 this property is required.
- ibm,cpu-idle-state-psscr:
Array of unsigned 64-bit values containing the values for the
PSSCR for each of the idle states in ibm,cpu-idle-state-names.
This property is required on POWER9 and absent on POWER8.
- ibm,cpu-idle-state-psscr-mask:
Array of unsigned 64-bit values containing the masks
indicating which psscr fields are set in the corresponding
entries of ibm,cpu-idle-state-psscr. This property is
required on POWER9 and absent on POWER8.
Whenever the firmware sets an entry in
ibm,cpu-idle-state-psscr-mask value to 0xf, it implies that
only the Requested Level (RL) field of the corresponding entry
in ibm,cpu-idle-state-psscr should be considered by the
kernel. For such idle states, the kernel would set the
remaining fields of the psscr to the following sane-default
values.
- ESL and EC bits are to 1. So wakeup from any stop
state will be at vector 0x100.
- MTL and PSLL are set to the maximum allowed value as
per the ISA, i.e. 15.
- The Transition Rate, TR is set to the Maximum value
3.
For all the other values of the entry in
ibm,cpu-idle-state-psscr-mask, the kernel expects all the
psscr fields of the corresponding entry in
ibm,cpu-idle-state-psscr to be correctly set by the firmware.
- ibm,cpu-idle-state-pmicr:
Array of unsigned 64-bit values containing the pmicr values
for the idle states in ibm,cpu-idle-state-names. This 64-bit
register value is to be set in pmicr for the corresponding
state if the flag indicates that pmicr SPR should be set. This
is an optional property on POWER8 and is absent on
POWER9.
- ibm,cpu-idle-state-pmicr-mask:
Array of unsigned 64-bit values containing the mask indicating
which of the fields of the PMICR are set in the corresponding
entries in ibm,cpu-idle-state-pmicr. This is an optional
property on POWER8 and is absent on POWER9.

27
bindings/powerpc/opal/sensor-groups.txt Normal file
View File

@@ -0,0 +1,27 @@
IBM OPAL Sensor Groups Binding
-------------------------------
Node: /ibm,opal/sensor-groups
Description: Contains sensor groups available in the Powernv P9
servers. Each child node indicates a sensor group.
- compatible : Should be "ibm,opal-sensor-group"
Each child node contains below properties:
- type : String to indicate the type of sensor-group
- sensor-group-id: Abstract unique identifier provided by firmware of
type <u32> which is used for sensor-group
operations like clearing the min/max history of all
sensors belonging to the group.
- ibm,chip-id : Chip ID
- sensors : Phandle array of child nodes of /ibm,opal/sensor/
belonging to this group
- ops : Array of opal-call numbers indicating available operations on
sensor groups like clearing min/max, enabling/disabling sensor
group.

47
bindings/powerpc/sleep.yaml Normal file
View File

@@ -0,0 +1,47 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/powerpc/sleep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: PowerPC sleep property
maintainers:
- Rob Herring <robh@kernel.org>
description: |
Devices on SOCs often have mechanisms for placing devices into low-power
states that are decoupled from the devices' own register blocks. Sometimes,
this information is more complicated than a cell-index property can
reasonably describe. Thus, each device controlled in such a manner
may contain a "sleep" property which describes these connections.
The sleep property consists of one or more sleep resources, each of
which consists of a phandle to a sleep controller, followed by a
controller-specific sleep specifier of zero or more cells.
The semantics of what type of low power modes are possible are defined
by the sleep controller. Some examples of the types of low power modes
that may be supported are:
- Dynamic: The device may be disabled or enabled at any time.
- System Suspend: The device may request to be disabled or remain
awake during system suspend, but will not be disabled until then.
- Permanent: The device is disabled permanently (until the next hard
reset).
Some devices may share a clock domain with each other, such that they should
only be suspended when none of the devices are in use. Where reasonable,
such nodes should be placed on a virtual bus, where the bus has the sleep
property. If the clock domain is shared among devices that cannot be
reasonably grouped in this manner, then create a virtual sleep controller
(similar to an interrupt nexus, except that defining a standardized
sleep-map should wait until its necessity is demonstrated).
select: true
properties:
sleep:
$ref: /schemas/types.yaml#/definitions/phandle-array
additionalProperties: true