summaryrefslogtreecommitdiff
path: root/Documentation/devicetree/bindings/arm
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2019-09-19 23:48:37 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2019-09-19 23:48:37 +0300
commite3a008ac1213d99f5f1210adc9d2a1f60da10c3b (patch)
tree4d4d13f81cb06eb278de0bf601346b73f38534be /Documentation/devicetree/bindings/arm
parent671df189537883f36cf9c7d4f9495bfac0f86627 (diff)
parent59e9fcf8772bd97b6d681706fb8c9a972500c524 (diff)
downloadlinux-e3a008ac1213d99f5f1210adc9d2a1f60da10c3b.tar.xz
Merge tag 'devicetree-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux
Pull Devicetree updates from Rob Herring: - a bunch of DT binding conversions to DT schema format - clean-ups of the Arm idle-states binding - support a default number of cells in of_for_each_phandle() when the cells name is missing - expose dtbs_check and dt_binding_check in the make help - convert writting-schema.md to ReST - HiSilicon reset controller binding updates - add documentation for MT8516 RNG * tag 'devicetree-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (46 commits) of: restore old handling of cells_name=NULL in of_*_phandle_with_args() bus: qcom: fix spelling mistake "ambigous" -> "ambiguous" of: Let of_for_each_phandle fallback to non-negative cell_count iommu: pass cell_count = -1 to of_for_each_phandle with cells_name dt-bindings: arm: Convert Realtek board/soc bindings to json-schema dt-bindings: arm: Convert Actions Semi bindings to jsonschema dt-bindings: Correct spelling in example schema dt-bindings: cpu: Add a support cpu type for cortex-a55 dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible dt-bindings: arm: idle-states: Move exit-latency-us explanation dt-bindings: arm: idle-states: Add punctuation to improve readability dt-bindings: arm: idle-states: Correct "constraint guarantees" dt-bindings: arm: idle-states: Correct references to wake-up delay dt-bindings: arm: idle-states: Use "e.g." and "i.e." consistently pinctrl-mcp23s08: Fix property-name in dt-example dt-bindings: Clarify interrupts-extended usage dt-bindings: Convert Arm Mali Utgard GPU to DT schema dt-bindings: Convert Arm Mali Bifrost GPU to DT schema dt-bindings: Convert Arm Mali Midgard GPU to DT schema dt-bindings: irq: Convert Allwinner NMI Controller to a schema ...
Diffstat (limited to 'Documentation/devicetree/bindings/arm')
-rw-r--r--Documentation/devicetree/bindings/arm/actions.txt56
-rw-r--r--Documentation/devicetree/bindings/arm/actions.yaml38
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt28
-rw-r--r--Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml52
-rw-r--r--Documentation/devicetree/bindings/arm/arm-boards2
-rw-r--r--Documentation/devicetree/bindings/arm/cpus.yaml2
-rw-r--r--Documentation/devicetree/bindings/arm/idle-states.txt32
-rw-r--r--Documentation/devicetree/bindings/arm/realtek.txt22
-rw-r--r--Documentation/devicetree/bindings/arm/realtek.yaml23
9 files changed, 132 insertions, 123 deletions
diff --git a/Documentation/devicetree/bindings/arm/actions.txt b/Documentation/devicetree/bindings/arm/actions.txt
deleted file mode 100644
index d54f33c4e0da..000000000000
--- a/Documentation/devicetree/bindings/arm/actions.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Actions Semi platforms device tree bindings
--------------------------------------------
-
-
-S500 SoC
-========
-
-Required root node properties:
-
- - compatible : must contain "actions,s500"
-
-
-Modules:
-
-Root node property compatible must contain, depending on module:
-
- - LeMaker Guitar: "lemaker,guitar"
-
-
-Boards:
-
-Root node property compatible must contain, depending on board:
-
- - Allo.com Sparky: "allo,sparky"
- - Cubietech CubieBoard6: "cubietech,cubieboard6"
- - LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
-
-
-S700 SoC
-========
-
-Required root node properties:
-
-- compatible : must contain "actions,s700"
-
-
-Boards:
-
-Root node property compatible must contain, depending on board:
-
- - Cubietech CubieBoard7: "cubietech,cubieboard7"
-
-
-S900 SoC
-========
-
-Required root node properties:
-
-- compatible : must contain "actions,s900"
-
-
-Boards:
-
-Root node property compatible must contain, depending on board:
-
- - uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96"
diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml
new file mode 100644
index 000000000000..ace3fdaa8396
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/actions.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/actions.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi platforms device tree bindings
+
+maintainers:
+ - Andreas Färber <afaerber@suse.de>
+ - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ # The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC.
+ - items:
+ - enum:
+ - allo,sparky # Allo.com Sparky
+ - cubietech,cubieboard6 # Cubietech CubieBoard6
+ - const: actions,s500
+ - items:
+ - enum:
+ - lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B
+ - const: lemaker,guitar
+ - const: actions,s500
+
+ # The Actions Semi S700 is a quad-core ARM Cortex-A53 SoC.
+ - items:
+ - enum:
+ - cubietech,cubieboard7 # Cubietech CubieBoard7
+ - const: actions,s700
+
+ # The Actions Semi S900 is a quad-core ARM Cortex-A53 SoC.
+ - items:
+ - enum:
+ - ucrobotics,bubblegum-96 # uCRobotics Bubblegum-96
+ - const: actions,s900
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
deleted file mode 100644
index c67d9f48fb91..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Amlogic Meson Firmware registers Interface
-------------------------------------------
-
-The Meson SoCs have a register bank with status and data shared with the
-secure firmware.
-
-Required properties:
- - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon"
-
-Properties should indentify components of this register interface :
-
-Meson GX SoC Information
-------------------------
-A firmware register encodes the SoC type, package and revision information on
-the Meson GX SoCs.
-If present, the following property should be added :
-
-Optional properties:
- - amlogic,has-chip-id: If present, the interface gives the current SoC version.
-
-Example
--------
-
-ao-secure@140 {
- compatible = "amlogic,meson-gx-ao-secure", "syscon";
- reg = <0x0 0x140 0x0 0x140>;
- amlogic,has-chip-id;
-};
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
new file mode 100644
index 000000000000..853d7d2b56f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Firmware registers Interface
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Meson SoCs have a register bank with status and data shared with the
+ secure firmware.
+
+# We need a select here so we don't match all nodes with 'syscon'
+select:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,meson-gx-ao-secure
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: amlogic,meson-gx-ao-secure
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ amlogic,has-chip-id:
+ description: |
+ A firmware register encodes the SoC type, package and revision
+ information on the Meson GX SoCs. If present, the interface gives
+ the current SoC version.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ ao-secure@140 {
+ compatible = "amlogic,meson-gx-ao-secure", "syscon";
+ reg = <0x140 0x140>;
+ amlogic,has-chip-id;
+ };
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index 6758ece324b1..b2a9f9f8430b 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -199,7 +199,7 @@ The description for the board must include:
A detailed description of the bindings used for "psci" nodes is present
in the psci.yaml file.
- a "cpus" node describing the available cores and their associated
- "enable-method"s. For more details see cpus.txt file.
+ "enable-method"s. For more details see cpus.yaml file.
Example:
diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 727e0ffc702b..cb30895e3b67 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -124,6 +124,7 @@ properties:
- arm,cortex-a15
- arm,cortex-a17
- arm,cortex-a53
+ - arm,cortex-a55
- arm,cortex-a57
- arm,cortex-a72
- arm,cortex-a73
@@ -155,6 +156,7 @@ properties:
- qcom,krait
- qcom,kryo
- qcom,kryo385
+ - qcom,kryo485
- qcom,scorpion
enable-method:
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index 2d325bed37e5..771f5d20ae18 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -28,7 +28,7 @@ PM implementation to put the processor in different idle states (which include
states listed above; "off" state is not an idle state since it does not have
wake-up capabilities, hence it is not considered in this document).
-Idle state parameters (eg entry latency) are platform specific and need to be
+Idle state parameters (e.g. entry latency) are platform specific and need to be
characterized with bindings that provide the required information to OS PM
code so that it can build the required tables and use them at runtime.
@@ -90,24 +90,24 @@ These timing parameters can be used by an OS in different circumstances.
An idle CPU requires the expected min-residency time to select the most
appropriate idle state based on the expected expiry time of the next IRQ
-(ie wake-up) that causes the CPU to return to the EXEC phase.
+(i.e. wake-up) that causes the CPU to return to the EXEC phase.
An operating system scheduler may need to compute the shortest wake-up delay
for CPUs in the system by detecting how long will it take to get a CPU out
-of an idle state, eg:
+of an idle state, e.g.:
wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
In other words, the scheduler can make its scheduling decision by selecting
-(eg waking-up) the CPU with the shortest wake-up latency.
-The wake-up latency must take into account the entry latency if that period
+(e.g. waking-up) the CPU with the shortest wake-up delay.
+The wake-up delay must take into account the entry latency if that period
has not expired. The abortable nature of the PREP period can be ignored
if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
-the worst case since it depends on the CPU operating conditions, ie caches
+the worst case since it depends on the CPU operating conditions, i.e. caches
state).
An OS has to reliably probe the wakeup-latency since some devices can enforce
-latency constraints guarantees to work properly, so the OS has to detect the
+latency constraint guarantees to work properly, so the OS has to detect the
worst case wake-up latency it can incur if a CPU is allowed to enter an
idle state, and possibly to prevent that to guarantee reliable device
functioning.
@@ -183,15 +183,15 @@ and IDLE2:
Graph 2: idle states min-residency example
In graph 2 above, that takes into account idle states entry/exit energy
-costs, it is clear that if the idle state residency time (ie time till next
+costs, it is clear that if the idle state residency time (i.e. time till next
wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
choice energywise.
This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
than IDLE2.
-However, the lower power consumption (ie shallower energy curve slope) of idle
-state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
+However, the lower power consumption (i.e. shallower energy curve slope) of
+idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
efficient.
The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
@@ -214,8 +214,8 @@ processor idle states, defined as device tree nodes, are listed.
Usage: Optional - On ARM systems, it is a container of processor idle
states nodes. If the system does not provide CPU
- power management capabilities or the processor just
- supports idle_standby an idle-states node is not
+ power management capabilities, or the processor just
+ supports idle_standby, an idle-states node is not
required.
Description: idle-states node is a container node, where its
@@ -287,14 +287,14 @@ follows:
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency in
microseconds required to enter the idle state.
- The exit-latency-us duration may be guaranteed
- only after entry-latency-us has passed.
- exit-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency
in microseconds required to exit the idle state.
+ The exit-latency-us duration may be guaranteed
+ only after entry-latency-us has passed.
- min-residency-us
Usage: Required
@@ -342,8 +342,8 @@ follows:
state.
In addition to the properties listed above, a state node may require
- additional properties specifics to the entry-method defined in the
- idle-states node, please refer to the entry-method bindings
+ additional properties specific to the entry-method defined in the
+ idle-states node. Please refer to the entry-method bindings
documentation for properties definitions.
===========================================
diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt
deleted file mode 100644
index 95839e19ae92..000000000000
--- a/Documentation/devicetree/bindings/arm/realtek.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Realtek platforms device tree bindings
---------------------------------------
-
-
-RTD1295 SoC
-===========
-
-Required root node properties:
-
- - compatible : must contain "realtek,rtd1295"
-
-
-Root node property compatible must contain, depending on board:
-
- - MeLE V9: "mele,v9"
- - ProBox2 AVA: "probox2,ava"
- - Zidoo X9S: "zidoo,x9s"
-
-
-Example:
-
- compatible = "zidoo,x9s", "realtek,rtd1295";
diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml
new file mode 100644
index 000000000000..3528b61963b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/realtek.yaml
@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/realtek.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek platforms device tree bindings
+
+maintainers:
+ - Andreas Färber <afaerber@suse.de>
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ # RTD1295 SoC based boards
+ items:
+ - enum:
+ - mele,v9
+ - probox2,ava
+ - zidoo,x9s
+ - const: realtek,rtd1295
+...