Commit 076fb0c4 authored by Frank Rowand's avatar Frank Rowand Committed by Rob Herring

of: update ePAPR references to point to Devicetree Specification

The Devicetree Specification has superseded the ePAPR as the
base specification for bindings.  Update files in Documentation
to reference the new document.

First reference to ePAPR in Documentation/devicetree/bindings/arm/cci.txt
is generic, remove it.

Some files are not updated because there is no hypervisor chapter
in the Devicetree Specification:
   Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
   Documenation/virtual/kvm/api.txt
   Documenation/virtual/kvm/ppc-pv.txt
Signed-off-by: default avatarFrank Rowand <frank.rowand@sony.com>
Signed-off-by: default avatarRob Herring <robh@kernel.org>
parent 7782b144
...@@ -11,13 +11,6 @@ clusters, through memory mapped interface, with a global control register ...@@ -11,13 +11,6 @@ clusters, through memory mapped interface, with a global control register
space and multiple sets of interface control registers, one per slave space and multiple sets of interface control registers, one per slave
interface. interface.
Bindings for the CCI node follow the ePAPR standard, available from:
www.power.org/documentation/epapr-version-1-1/
with the addition of the bindings described in this document which are
specific to ARM.
* CCI interconnect node * CCI interconnect node
Description: Describes a CCI cache coherent Interconnect component Description: Describes a CCI cache coherent Interconnect component
...@@ -50,10 +43,10 @@ specific to ARM. ...@@ -50,10 +43,10 @@ specific to ARM.
as a tuple of cells, containing child address, as a tuple of cells, containing child address,
parent address and the size of the region in the parent address and the size of the region in the
child address space. child address space.
Definition: A standard property. Follow rules in the ePAPR for Definition: A standard property. Follow rules in the Devicetree
hierarchical bus addressing. CCI interfaces Specification for hierarchical bus addressing. CCI
addresses refer to the parent node addressing interfaces addresses refer to the parent node
scheme to declare their register bases. addressing scheme to declare their register bases.
CCI interconnect node can define the following child nodes: CCI interconnect node can define the following child nodes:
......
...@@ -6,9 +6,9 @@ The device tree allows to describe the layout of CPUs in a system through ...@@ -6,9 +6,9 @@ The device tree allows to describe the layout of CPUs in a system through
the "cpus" node, which in turn contains a number of subnodes (ie "cpu") the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
defining properties for every cpu. defining properties for every cpu.
Bindings for CPU nodes follow the ePAPR v1.1 standard, available from: Bindings for CPU nodes follow the Devicetree Specification, available from:
https://www.power.org/documentation/epapr-version-1-1/ https://www.devicetree.org/specifications/
with updates for 32-bit and 64-bit ARM systems provided in this document. with updates for 32-bit and 64-bit ARM systems provided in this document.
...@@ -16,8 +16,8 @@ with updates for 32-bit and 64-bit ARM systems provided in this document. ...@@ -16,8 +16,8 @@ with updates for 32-bit and 64-bit ARM systems provided in this document.
Convention used in this document Convention used in this document
================================ ================================
This document follows the conventions described in the ePAPR v1.1, with This document follows the conventions described in the Devicetree
the addition: Specification, with the addition:
- square brackets define bitfields, eg reg[7:0] value of the bitfield in - square brackets define bitfields, eg reg[7:0] value of the bitfield in
the reg property contained in bits 7 down to 0 the reg property contained in bits 7 down to 0
...@@ -26,8 +26,9 @@ the addition: ...@@ -26,8 +26,9 @@ the addition:
cpus and cpu node bindings definition cpus and cpu node bindings definition
===================================== =====================================
The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu The ARM architecture, in accordance with the Devicetree Specification,
nodes to be present and contain the properties described below. requires the cpus and cpu nodes to be present and contain the properties
described below.
- cpus node - cpus node
......
...@@ -695,5 +695,5 @@ cpus { ...@@ -695,5 +695,5 @@ cpus {
[4] ARM Architecture Reference Manuals [4] ARM Architecture Reference Manuals
http://infocenter.arm.com/help/index.jsp http://infocenter.arm.com/help/index.jsp
[5] ePAPR standard [5] Devicetree Specification
https://www.power.org/documentation/epapr-version-1-1/ https://www.devicetree.org/specifications/
...@@ -4,8 +4,8 @@ ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/ ...@@ -4,8 +4,8 @@ ARM cores often have a separate L2C210/L2C220/L2C310 (also known as PL210/PL220/
PL310 and variants) based level 2 cache controller. All these various implementations PL310 and variants) based level 2 cache controller. All these various implementations
of the L2 cache controller have compatible programming models (Note 1). of the L2 cache controller have compatible programming models (Note 1).
Some of the properties that are just prefixed "cache-*" are taken from section Some of the properties that are just prefixed "cache-*" are taken from section
3.7.3 of the ePAPR v1.1 specification which can be found at: 3.7.3 of the Devicetree Specification which can be found at:
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf https://www.devicetree.org/specifications/
The ARM L2 cache representation in the device tree should be done as follows: The ARM L2 cache representation in the device tree should be done as follows:
......
...@@ -29,9 +29,9 @@ corresponding to the system hierarchy; syntactically they are defined as device ...@@ -29,9 +29,9 @@ corresponding to the system hierarchy; syntactically they are defined as device
tree nodes. tree nodes.
The remainder of this document provides the topology bindings for ARM, based The remainder of this document provides the topology bindings for ARM, based
on the ePAPR standard, available from: on the Devicetree Specification, available from:
http://www.power.org/documentation/epapr-version-1-1/ https://www.devicetree.org/specifications/
If not stated otherwise, whenever a reference to a cpu node phandle is made its If not stated otherwise, whenever a reference to a cpu node phandle is made its
value must point to a cpu node compliant with the cpu node bindings as value must point to a cpu node compliant with the cpu node bindings as
......
...@@ -10,7 +10,7 @@ enabled for child devices connected to the bus (either on-SoC or externally) ...@@ -10,7 +10,7 @@ enabled for child devices connected to the bus (either on-SoC or externally)
to function. to function.
While "simple-pm-bus" follows the "simple-bus" set of properties, as specified While "simple-pm-bus" follows the "simple-bus" set of properties, as specified
in ePAPR, it is not an extension of "simple-bus". in the Devicetree Specification, it is not an extension of "simple-bus".
Required properties: Required properties:
......
...@@ -10,7 +10,8 @@ stdout-path property ...@@ -10,7 +10,8 @@ stdout-path property
-------------------- --------------------
Device trees may specify the device to be used for boot console output Device trees may specify the device to be used for boot console output
with a stdout-path property under /chosen, as described in ePAPR, e.g. with a stdout-path property under /chosen, as described in the Devicetree
Specification, e.g.
/ { / {
chosen { chosen {
......
Common properties Common properties
The ePAPR specification does not define any properties related to hardware The Devicetree Specification does not define any properties related to hardware
byteswapping, but endianness issues show up frequently in porting Linux to byteswapping, but endianness issues show up frequently in porting Linux to
different machine types. This document attempts to provide a consistent different machine types. This document attempts to provide a consistent
way of handling byteswapping across drivers. way of handling byteswapping across drivers.
......
...@@ -118,8 +118,8 @@ PROPERTIES ...@@ -118,8 +118,8 @@ PROPERTIES
Definition: A list of clock name strings in the same order as the Definition: A list of clock name strings in the same order as the
clocks property. clocks property.
Note: All other standard properties (see the ePAPR) are allowed Note: All other standard properties (see the Devicetree Specification)
but are optional. are allowed but are optional.
EXAMPLE EXAMPLE
......
...@@ -55,8 +55,8 @@ PROPERTIES ...@@ -55,8 +55,8 @@ PROPERTIES
triplet that includes the child address, parent address, & triplet that includes the child address, parent address, &
length. length.
Note: All other standard properties (see the ePAPR) are allowed Note: All other standard properties (see the Devicetree Specification)
but are optional. are allowed but are optional.
EXAMPLE EXAMPLE
crypto@a0000 { crypto@a0000 {
......
...@@ -92,7 +92,6 @@ Example 2: ...@@ -92,7 +92,6 @@ Example 2:
* References * References
[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform [1] Devicetree Specification
Requirements (ePAPR), Version 1.0, July 2008. (https://www.devicetree.org/specifications/)
(http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf)
...@@ -8,7 +8,8 @@ The following properties are common to the Ethernet controllers: ...@@ -8,7 +8,8 @@ The following properties are common to the Ethernet controllers:
property; property;
- max-speed: number, specifies maximum speed in Mbit/s supported by the device; - max-speed: number, specifies maximum speed in Mbit/s supported by the device;
- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
the maximum frame size (there's contradiction in ePAPR). the maximum frame size (there's contradiction in the Devicetree
Specification).
- phy-mode: string, operation mode of the PHY interface. This is now a de-facto - phy-mode: string, operation mode of the PHY interface. This is now a de-facto
standard property; supported values are: standard property; supported values are:
* "mii" * "mii"
...@@ -32,9 +33,11 @@ The following properties are common to the Ethernet controllers: ...@@ -32,9 +33,11 @@ The following properties are common to the Ethernet controllers:
* "2000base-x", * "2000base-x",
* "2500base-x", * "2500base-x",
* "rxaui" * "rxaui"
- phy-connection-type: the same as "phy-mode" property but described in ePAPR; - phy-connection-type: the same as "phy-mode" property but described in the
Devicetree Specification;
- phy-handle: phandle, specifies a reference to a node representing a PHY - phy-handle: phandle, specifies a reference to a node representing a PHY
device; this property is described in ePAPR and so preferred; device; this property is described in the Devicetree Specification and so
preferred;
- phy: the same as "phy-handle" property, not recommended for new bindings. - phy: the same as "phy-handle" property, not recommended for new bindings.
- phy-device: the same as "phy-handle" property, not recommended for new - phy-device: the same as "phy-handle" property, not recommended for new
bindings. bindings.
......
...@@ -3,10 +3,10 @@ Power Architecture CPU Binding ...@@ -3,10 +3,10 @@ Power Architecture CPU Binding
Copyright 2013 Freescale Semiconductor Inc. Copyright 2013 Freescale Semiconductor Inc.
Power Architecture CPUs in Freescale SOCs are represented in device trees as Power Architecture CPUs in Freescale SOCs are represented in device trees as
per the definition in ePAPR. per the definition in the Devicetree Specification.
In addition to the ePAPR definitions, the properties defined below may be In addition to the the Devicetree Specification definitions, the properties
present on CPU nodes. defined below may be present on CPU nodes.
PROPERTIES PROPERTIES
......
Freescale L2 Cache Controller Freescale L2 Cache Controller
L2 cache is present in Freescale's QorIQ and QorIQ Qonverge platforms. L2 cache is present in Freescale's QorIQ and QorIQ Qonverge platforms.
The cache bindings explained below are ePAPR compliant The cache bindings explained below are Devicetree Specification compliant
Required Properties: Required Properties:
......
...@@ -124,8 +124,8 @@ Port-Write Unit: ...@@ -124,8 +124,8 @@ Port-Write Unit:
A single IRQ that handles port-write conditions is A single IRQ that handles port-write conditions is
specified by this property. (Typically shared with error). specified by this property. (Typically shared with error).
Note: All other standard properties (see the ePAPR) are allowed Note: All other standard properties (see the Devicetree Specification)
but are optional. are allowed but are optional.
Example: Example:
rmu: rmu@d3000 { rmu: rmu@d3000 {
......
...@@ -72,7 +72,8 @@ the following properties: ...@@ -72,7 +72,8 @@ the following properties:
represents the LIODN associated with maintenance transactions represents the LIODN associated with maintenance transactions
for the port. for the port.
Note: All other standard properties (see ePAPR) are allowed but are optional. Note: All other standard properties (see the Devicetree Specification)
are allowed but are optional.
Example: Example:
......
...@@ -1413,7 +1413,7 @@ Optional property: ...@@ -1413,7 +1413,7 @@ Optional property:
from DMA operations originating from the bus. It provides a means of from DMA operations originating from the bus. It provides a means of
defining a mapping or translation between the physical address space of defining a mapping or translation between the physical address space of
the bus and the physical address space of the parent of the bus. the bus and the physical address space of the parent of the bus.
(for more information see ePAPR specification) (for more information see the Devicetree Specification)
* DMA Bus child * DMA Bus child
Optional property: Optional property:
......
...@@ -387,7 +387,7 @@ static void __init harmony_init_machine(void) ...@@ -387,7 +387,7 @@ static void __init harmony_init_machine(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
} }
"simple-bus" is defined in the ePAPR 1.0 specification as a property "simple-bus" is defined in the Devicetree Specification as a property
meaning a simple memory mapped bus, so the of_platform_populate() code meaning a simple memory mapped bus, so the of_platform_populate() code
could be written to just assume simple-bus compatible nodes will could be written to just assume simple-bus compatible nodes will
always be traversed. However, we pass it in as an argument so that always be traversed. However, we pass it in as an argument so that
......
...@@ -41,9 +41,9 @@ The scheme below assumes that the kernel is loaded below 0x40000000. ...@@ -41,9 +41,9 @@ The scheme below assumes that the kernel is loaded below 0x40000000.
00..1F -> 00 -> 00 -> 00 00..1F -> 00 -> 00 -> 00
The default location of IO peripherals is above 0xf0000000. This may be changed The default location of IO peripherals is above 0xf0000000. This may be changed
using a "ranges" property in a device tree simple-bus node. See ePAPR 1.1, §6.5 using a "ranges" property in a device tree simple-bus node. See the Devicetree
for details on the syntax and semantic of simple-bus nodes. The following Specification, section 4.5 for details on the syntax and semantics of
limitations apply: simple-bus nodes. The following limitations apply:
1. Only top level simple-bus nodes are considered 1. Only top level simple-bus nodes are considered
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment