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
space and multiple sets of interface control registers, one per slave
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
Description: Describes a CCI cache coherent Interconnect component
......@@ -50,10 +43,10 @@ specific to ARM.
as a tuple of cells, containing child address,
parent address and the size of the region in the
child address space.
Definition: A standard property. Follow rules in the ePAPR for
hierarchical bus addressing. CCI interfaces
addresses refer to the parent node addressing
scheme to declare their register bases.
Definition: A standard property. Follow rules in the Devicetree
Specification for hierarchical bus addressing. CCI
interfaces addresses refer to the parent node
addressing scheme to declare their register bases.
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
the "cpus" node, which in turn contains a number of subnodes (ie "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.
......@@ -16,8 +16,8 @@ with updates for 32-bit and 64-bit ARM systems provided in this document.
Convention used in this document
================================
This document follows the conventions described in the ePAPR v1.1, with
the addition:
This document follows the conventions described in the Devicetree
Specification, with the addition:
- square brackets define bitfields, eg reg[7:0] value of the bitfield in
the reg property contained in bits 7 down to 0
......@@ -26,8 +26,9 @@ the addition:
cpus and cpu node bindings definition
=====================================
The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
nodes to be present and contain the properties described below.
The ARM architecture, in accordance with the Devicetree Specification,
requires the cpus and cpu nodes to be present and contain the properties
described below.
- cpus node
......
......@@ -695,5 +695,5 @@ cpus {
[4] ARM Architecture Reference Manuals
http://infocenter.arm.com/help/index.jsp
[5] ePAPR standard
https://www.power.org/documentation/epapr-version-1-1/
[5] Devicetree Specification
https://www.devicetree.org/specifications/
......@@ -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
of the L2 cache controller have compatible programming models (Note 1).
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:
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
3.7.3 of the Devicetree Specification which can be found at:
https://www.devicetree.org/specifications/
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
tree nodes.
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
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)
to function.
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:
......
......@@ -10,7 +10,8 @@ stdout-path property
--------------------
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 {
......
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
different machine types. This document attempts to provide a consistent
way of handling byteswapping across drivers.
......
......@@ -118,8 +118,8 @@ PROPERTIES
Definition: A list of clock name strings in the same order as the
clocks property.
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
Note: All other standard properties (see the Devicetree Specification)
are allowed but are optional.
EXAMPLE
......
......@@ -55,8 +55,8 @@ PROPERTIES
triplet that includes the child address, parent address, &
length.
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
Note: All other standard properties (see the Devicetree Specification)
are allowed but are optional.
EXAMPLE
crypto@a0000 {
......
......@@ -92,7 +92,6 @@ Example 2:
* References
[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform
Requirements (ePAPR), Version 1.0, July 2008.
(http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf)
[1] Devicetree Specification
(https://www.devicetree.org/specifications/)
......@@ -8,7 +8,8 @@ The following properties are common to the Ethernet controllers:
property;
- 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
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
standard property; supported values are:
* "mii"
......@@ -32,9 +33,11 @@ The following properties are common to the Ethernet controllers:
* "2000base-x",
* "2500base-x",
* "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
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-device: the same as "phy-handle" property, not recommended for new
bindings.
......
......@@ -3,10 +3,10 @@ Power Architecture CPU Binding
Copyright 2013 Freescale Semiconductor Inc.
Power Architecture CPUs in Freescale SOCs are represented in device trees as
per the definition in ePAPR.
per the definition in the Devicetree Specification.
In addition to the ePAPR definitions, the properties defined below may be
present on CPU nodes.
In addition to the the Devicetree Specification definitions, the properties
defined below may be present on CPU nodes.
PROPERTIES
......
Freescale L2 Cache Controller
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:
......
......@@ -124,8 +124,8 @@ Port-Write Unit:
A single IRQ that handles port-write conditions is
specified by this property. (Typically shared with error).
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
Note: All other standard properties (see the Devicetree Specification)
are allowed but are optional.
Example:
rmu: rmu@d3000 {
......
......@@ -72,7 +72,8 @@ the following properties:
represents the LIODN associated with maintenance transactions
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:
......
......@@ -1413,7 +1413,7 @@ Optional property:
from DMA operations originating from the bus. It provides a means 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.
(for more information see ePAPR specification)
(for more information see the Devicetree Specification)
* DMA Bus child
Optional property:
......
......@@ -387,7 +387,7 @@ static void __init harmony_init_machine(void)
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
could be written to just assume simple-bus compatible nodes will
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.
00..1F -> 00 -> 00 -> 00
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
for details on the syntax and semantic of simple-bus nodes. The following
limitations apply:
using a "ranges" property in a device tree simple-bus node. See the Devicetree
Specification, section 4.5 for details on the syntax and semantics of
simple-bus nodes. The following limitations apply:
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