Skip to content
Snippets Groups Projects
Commit a70bb580 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux 

Pull devicetree updates from Rob Herring:

 - Refine reserved memory nomap handling

 - Merge some PCI and non-PCI address handling implementations

 - Simplify of_address.h header ifdefs

 - Improve printk handling of some 64-bit types

 - Convert adi,adv7511, Arm ccree, Arm SCMI, Arm SCU, Arm TWD timer, Arm
   VIC, arm,sbsa-gwdt, Arm/Amlogic SCPI, Aspeed I2C, Broadcom iProc PWM,
   linaro,optee-tz, MDIO GPIO, Mediatek RNG, MTD physmap, NXP
   pcf8563/pcf85263/pcf85363, Renesas TPU, renesas,emev2-smu,
   renesas,r9a06g032-sysctrl, sysc-rmobile, Tegra20 EMC, TI AM56 PCI, TI
   OMAP mailbox, TI SCI bindings, virtio-mmio, Zynq FPGA, and ZynqMP RTC
   to DT schema

 - Convert mux and mux controller bindings to schema. This includes MDIO
   IIO, and I2C muxes.

 - Add Arm PL031 RTC binding schema

 - Add vendor prefixes for StarFive Technology Co. Ltd. and Insignal Ltd

 - Fix some stale doc references

 - Remove stale property-units.txt. Superseded by schema in dt-schema
   repo.

 - Fixes for 'unevaluatedProperties' handling (enabled with experimental
   json-schema support)

 - Drop redundant usage of minItems and maxItems across the tree

 - Update some examples to use bindings with a schema

* tag 'devicetree-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (83 commits)
  dt-bindings: Fix 'unevaluatedProperties' errors in DT graph users
  dt-bindings: display: renesas,du: Fix 'ports' reference
  dt-bindings: media: adv7180: Add missing video-interfaces.yaml reference
  dt-bindings: crypto: ccree: Convert to json-schema
  dt-bindings: fpga: zynq: convert bindings to YAML
  dt-bindings: rtc: zynqmp: convert bindings to YAML
  dt-bindings: interrupt-controller: Convert ARM VIC to json-schema
  of: of_reserved_mem: mark nomap memory instead of removing
  of: of_reserved_mem: only call memblock_free for normal reserved memory
  dt-bindings: Drop redundant minItems/maxItems
  dt-bindings: spmi: Correct 'reg' schema
  of: reserved-memory: Add stub for RESERVEDMEM_OF_DECLARE()
  dt-bindings: clk: vc5: Fix example
  dt-bindings: timer: renesas,tmu: add r8a779a0 TMU support
  dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
  dt-bindings: PCI: ti,am65: Convert PCIe host/endpoint mode dt-bindings to YAML
  of: Remove superfluous casts when printing u64 values
  of: Fix truncation of memory sizes on 32-bit platforms
  dt-bindings: rtc: nxp,pcf8563: Absorb pcf85263/pcf85363 bindings
  dt-bindings: pwm: Use examples with documented/matching schema
  ...
parents 4b820e16 6a9a930d
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 252 additions and 767 deletions
Documentation/devicetree/bindings/arm/amlogic,scpi.txt deleted 100644 → 0
+ 0
− 27
View file @ 4b820e16
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
----------------------------------------------------------
Required properties
- compatible : should be "amlogic,meson-gxbb-scpi"
AMLOGIC SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "amlogic,meson-gxbb-sram"
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
memory on Amlogic GXBB SoC.
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "amlogic,meson-gxbb-scpi-sensors".
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
Documentation/devicetree/bindings/arm/arm,scmi.txt deleted 100644 → 0
+ 0
− 239
View file @ 4b820e16
System Control and Management Interface (SCMI) Message Protocol
----------------------------------------------------------
The SCMI is intended to allow agents such as OSPM to manage various functions
that are provided by the hardware platform it is running on, including power
and performance functions.
This binding is intended to define the interface the firmware implementing
the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control
and Management Interface Platform Design Document")[0] provide for OSPM in
the device tree.
Required properties:
The scmi node with the following properties shall be under the /firmware/ node.
- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports
- mboxes: List of phandle and mailbox channel specifiers. It should contain
exactly one or two mailboxes, one for transmitting messages("tx")
and another optional for receiving the notifications("rx") if
supported.
- shmem : List of phandle pointing to the shared memory(SHM) area as per
generic mailbox client binding.
- #address-cells : should be '1' if the device has sub-nodes, maps to
protocol identifier for a given sub-node.
- #size-cells : should be '0' as 'reg' property doesn't have any size
associated with it.
- arm,smc-id : SMC id required when using smc or hvc transports
Optional properties:
- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
- interrupts : when using smc or hvc transports, this optional
property indicates that msg completion by the platform is indicated
by an interrupt rather than by the return of the smc call. This
should not be used except when the platform requires such behavior.
- interrupt-names : if "interrupts" is present, interrupt-names must also
be present and have the value "a2p".
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
about the generic mailbox controller and client driver bindings.
The mailbox is the only permitted method of calling the SCMI firmware.
Mailbox doorbell is used as a mechanism to alert the presence of a
messages and/or notification.
Each protocol supported shall have a sub-node with corresponding compatible
as described in the following sections. If the platform supports dedicated
communication channel for a particular protocol, the 3 properties namely:
mboxes, mbox-names and shmem shall be present in the sub-node corresponding
to that protocol.
Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Required properties:
- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
Power domain bindings for the power domains based on SCMI Message Protocol
------------------------------------------------------------
This binding for the SCMI power domain providers uses the generic power
domain binding[2].
Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCMI commands.
Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
------------------------------------------------------------
An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
and should be always positioned as a root regulator.
It does not support any current operation.
SCMI Regulators are grouped under a 'regulators' node which in turn is a child
of the SCMI Voltage protocol node inside the desired SCMI instance node.
This binding uses the common regulator binding[6].
Required properties:
- reg : shall identify an existent SCMI Voltage Domain.
Sensor bindings for the sensors based on SCMI Message Protocol
--------------------------------------------------------------
SCMI provides an API to access the various sensors on the SoC.
Required properties:
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[3].
Valid cell values are raw identifiers (Sensor ID)
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Reset signal bindings for the reset domains based on SCMI Message Protocol
------------------------------------------------------------
This binding for the SCMI reset domain providers uses the generic reset
signal binding[5].
Required properties:
- #reset-cells : Should be 1. Contains the reset domain ID value used
by SCMI commands.
SRAM and Shared Memory for SCMI
-------------------------------
A small area of SRAM is reserved for SCMI communication between application
processors and SCP.
The properties should follow the generic mmio-sram description found in [4]
Each sub-node represents the reserved area for SCMI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
shared memory
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/power/power-domain.yaml
[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
[4] Documentation/devicetree/bindings/sram/sram.yaml
[5] Documentation/devicetree/bindings/reset/reset.txt
[6] Documentation/devicetree/bindings/regulator/regulator.yaml
Example:
sram@50000000 {
compatible = "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,scmi-shmem";
reg = <0x200 0x200>;
};
};
mailbox@40000000 {
....
#mbox-cells = <1>;
reg = <0x0 0x40000000 0x0 0x10000>;
};
firmware {
...
scmi {
compatible = "arm,scmi";
mboxes = <&mailbox 0 &mailbox 1>;
mbox-names = "tx", "rx";
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_dvfs: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
};
scmi_clk: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
};
scmi_sensors0: protocol@15 {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
scmi_reset: protocol@16 {
reg = <0x16>;
#reset-cells = <1>;
};
scmi_voltage: protocol@17 {
reg = <0x17>;
regulators {
regulator_devX: regulator@0 {
reg = <0x0>;
regulator-max-microvolt = <3300000>;
};
regulator_devY: regulator@9 {
reg = <0x9>;
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <4200000>;
};
...
};
};
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scmi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scmi_clk 4>;
power-domains = <&scmi_devpd 1>;
resets = <&scmi_reset 10>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scmi_sensors0 3>;
...
};
};
Documentation/devicetree/bindings/arm/arm,scpi.txt deleted 100644 → 0
+ 0
− 219
View file @ 4b820e16
System Control and Power Interface (SCPI) Message Protocol
----------------------------------------------------------
Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
by Linux to initiate various system control and power operations.
Required properties:
- compatible : should be
* "arm,scpi" : For implementations complying to SCPI v1.0 or above
* "arm,scpi-pre-1.0" : For implementations complying to all
unversioned releases prior to SCPI v1.0
- mboxes: List of phandle and mailbox channel specifiers
All the channels reserved by remote SCP firmware for use by
SCPI message protocol should be specified in any order
- shmem : List of phandle pointing to the shared memory(SHM) area between the
processors using these mailboxes for IPC, one for each mailbox
SHM can be any memory reserved for the purpose of this communication
between the processors.
See Documentation/devicetree/bindings/mailbox/mailbox.txt
for more details about the generic mailbox controller and
client driver bindings.
Clock bindings for the clocks based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Container Node
==============
Required properties:
- compatible : should be "arm,scpi-clocks"
All the clocks provided by SCP firmware via SCPI message
protocol much be listed as sub-nodes under this node.
Sub-nodes
=========
Required properties:
- compatible : shall include one of the following
"arm,scpi-dvfs-clocks" - all the clocks that are variable and index based.
These clocks don't provide an entire range of values between the
limits but only discrete points within the range. The firmware
provides the mapping for each such operating frequency and the
index associated with it. The firmware also manages the
voltage scaling appropriately with the clock scaling.
"arm,scpi-variable-clocks" - all the clocks that are variable and provide full
range within the specified range. The firmware provides the
range of values within a specified range.
Other required properties for all clocks(all from common clock binding):
- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands.
- clock-output-names : shall be the corresponding names of the outputs.
- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
node. It can be non linear and hence provide the mapping of identifiers
into the clock-output-names array.
SRAM and Shared Memory for SCPI
-------------------------------
A small area of SRAM is reserved for SCPI communication between application
processors and SCP.
The properties should follow the generic mmio-sram description found in [3]
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
shared memory
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[2].
Valid cell values are raw identifiers (Sensor ID)
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Power domain bindings for the power domains based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the generic power domain binding[4].
PM domain providers
===================
Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCPI commands.
- num-domains: Total number of power domains provided by SCPI. This is
needed as the SCPI message protocol lacks a mechanism to
query this information at runtime.
PM domain consumers
===================
Required properties:
- power-domains : A phandle and PM domain specifier as defined by bindings of
the power controller specified by phandle.
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal*.yaml
[3] Documentation/devicetree/bindings/sram/sram.yaml
[4] Documentation/devicetree/bindings/power/power-domain.yaml
Example:
sram: sram@50000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,juno-scp-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,juno-scp-shmem";
reg = <0x200 0x200>;
};
};
mailbox: mailbox0@40000000 {
....
#mbox-cells = <1>;
};
scpi_protocol: scpi@2e000000 {
compatible = "arm,scpi";
mboxes = <&mailbox 0 &mailbox 1>;
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
clocks {
compatible = "arm,scpi-clocks";
scpi_dvfs: scpi_clocks@0 {
compatible = "arm,scpi-dvfs-clocks";
#clock-cells = <1>;
clock-indices = <0>, <1>, <2>;
clock-output-names = "atlclk", "aplclk","gpuclk";
};
scpi_clk: scpi_clocks@3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
clock-indices = <3>, <4>;
clock-output-names = "pxlclk0", "pxlclk1";
};
};
scpi_sensors0: sensors {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
scpi_devpd: scpi-power-domains {
compatible = "arm,scpi-power-domains";
num-domains = <2>;
#power-domain-cells = <1>;
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scpi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scpi_clk 4>;
power-domains = <&scpi_devpd 1>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scpi_sensors0 3>;
...
};
};
In the above example, the #clock-cells is set to 1 as required.
scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
and pxlclk1 with 3 and 4 as clock-indices.
The first consumer in the example is cpu@0 and it has '0' as the clock
specifier which points to the first entry in the output clocks of
scpi_dvfs i.e. "atlclk".
Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input
clock. '4' in the clock specifier here points to the second entry
in the output clocks of scpi_clocks i.e. "pxlclk1"
The thermal-sensors property in the soc_thermal node uses the
temperature sensor provided by SCP firmware to setup a thermal
zone. The ID "3" is the sensor identifier for the temperature sensor
as used by the firmware.
The num-domains property in scpi-power-domains domain specifies that
SCPI provides 2 power domains. The hdlcd node uses the power domain with
domain ID 1.
Documentation/devicetree/bindings/arm/arm,scu.yaml 0 → 100644
+ 46
− 0
View file @ a70bb580
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,scu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Snoop Control Unit (SCU)
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided
with a Snoop Control Unit. The register range is usually 256 (0x100)
bytes.
References:
- Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual
Revision r2p0
- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual
Revision r0p1
- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference
Manial Revision r2p0
properties:
compatible:
enum:
- arm,cortex-a9-scu
- arm,cortex-a5-scu
- arm,arm11mp-scu
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
scu@a0410000 {
compatible = "arm,cortex-a9-scu";
reg = <0xa0410000 0x100>;
};
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt deleted 100644 → 0
+ 0
− 31
View file @ 4b820e16
OP-TEE Device Tree Bindings
OP-TEE is a piece of software using hardware features to provide a Trusted
Execution Environment. The security can be provided with ARM TrustZone, but
also by virtualization or a separate chip.
We're using "linaro" as the first part of the compatible property for
the reference implementation maintained by Linaro.
* OP-TEE based on ARM TrustZone required properties:
- compatible : should contain "linaro,optee-tz"
- method : The method of calling the OP-TEE Trusted OS. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
"hvc" : HVC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
Example:
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml 0 → 100644
+ 58
− 0
View file @ a70bb580
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OP-TEE Device Tree Bindings
maintainers:
- Jens Wiklander <jens.wiklander@linaro.org>
description: |
OP-TEE is a piece of software using hardware features to provide a Trusted
Execution Environment. The security can be provided with ARM TrustZone, but
also by virtualization or a separate chip.
We're using "linaro" as the first part of the compatible property for
the reference implementation maintained by Linaro.
properties:
$nodename:
const: optee
compatible:
const: linaro,optee-tz
method:
enum: [smc, hvc]
description: |
The method of calling the OP-TEE Trusted OS depending on smc or hvc
instruction usage.
SMC #0, register assignments
or
HVC #0, register assignments
register assignments are specified in drivers/tee/optee/optee_smc.h
required:
- compatible
- method
additionalProperties: false
examples:
- |
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
- |
firmware {
optee {
compatible = "linaro,optee-tz";
method = "hvc";
};
};
Documentation/devicetree/bindings/arm/intel,keembay.yaml
+ 2
− 0
View file @ a70bb580
......@@ -11,6 +11,8 @@ maintainers:
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
......
Documentation/devicetree/bindings/arm/juno,scpi.txt deleted 100644 → 0
+ 0
− 26
View file @ 4b820e16
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
Juno SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1.
For Juno R0 and Juno R1 refer to [1] for the
sensor identifiers
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt deleted 100644 → 0
+ 0
− 86
View file @ 4b820e16
Texas Instruments System Control Interface (TI-SCI) Message Protocol
--------------------------------------------------------------------
Texas Instrument's processors including those belonging to Keystone generation
of processors have separate hardware entity which is now responsible for the
management of the System on Chip (SoC) system. These include various system
level functions as well.
An example of such an SoC is K2G, which contains the system control hardware
block called Power Management Micro Controller (PMMC). This hardware block is
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
TI-SCI controller Device Node:
=============================
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.
Required properties:
-------------------
- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC
should be "ti,am654-sci" for for TI AM654 SoC
- mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
property should contain a phandle to the mailbox controller device
node and an args specifier that will be the phandle to the intended
sub-mailbox child node to be used for communication.
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
about the generic mailbox controller and client driver bindings. Also see
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
controller that is used to communicate with this System controllers.
Optional Properties:
-------------------
- reg-names:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
for identification of host processing entities such as virtual
machines
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
ti,host-id = <2>;
mbox-names = "rx", "tx";
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
<&msgmgr &msgmgr_proxy_pmmc_tx>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
TI-SCI Client Device Node:
=========================
Client nodes are maintained as children of the relevant TI-SCI device node.
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
...
my_clk_node: clk_node {
...
...
};
my_pd_node: pd_node {
...
...
};
};
Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml 0 → 100644
+ 129
− 0
View file @ a70bb580
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI-SCI controller device node bindings
maintainers:
- Nishanth Menon <nm@ti.com>
description: |
Texas Instrument's processors including those belonging to Keystone generation
of processors have separate hardware entity which is now responsible for the
management of the System on Chip (SoC) system. These include various system
level functions as well.
An example of such an SoC is K2G, which contains the system control hardware
block called Power Management Micro Controller (PMMC). This hardware block is
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.
properties:
$nodename:
pattern: "^system-controller@[0-9a-f]+$"
compatible:
oneOf:
- description: System controller on TI 66AK2G SoC and other K3 SoCs
items:
- const: ti,k2g-sci
- description: System controller on TI AM654 SoC
items:
- const: ti,am654-sci
reg-names:
description: |
Specifies the debug messages memory mapped region that is optionally
made available from TI-SCI controller.
const: debug_messages
reg:
minItems: 1
mbox-names:
description: |
Specifies the mailboxes used to communicate with TI-SCI Controller
made available from TI-SCI controller.
items:
- const: rx
- const: tx
mboxes:
minItems: 2
ti,system-reboot-controller:
description: Determines If system reboot can be triggered by SoC reboot
type: boolean
ti,host-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Value corresponding to the host ID assigned by Firmware
for identification of host processing entities such as virtual machines.
power-controller:
type: object
$ref: /schemas/soc/ti/sci-pm-domain.yaml#
clock-controller:
type: object
$ref: /schemas/clock/ti,sci-clk.yaml#
reset-controller:
type: object
$ref: /schemas/reset/ti,sci-reset.yaml#
required:
- compatible
- mbox-names
- mboxes
additionalProperties: false
examples:
- |
pmmc: system-controller@2921800 {
compatible = "ti,k2g-sci";
ti,system-reboot-controller;
mbox-names = "rx", "tx";
mboxes= <&msgmgr 5 2>,
<&msgmgr 0 0>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
- |
dmsc: system-controller@44083000 {
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
mboxes= <&secure_proxy_main 11>,
<&secure_proxy_main 13>;
reg-names = "debug_messages";
reg = <0x44083000 0x1000>;
k3_pds: power-controller {
compatible = "ti,sci-pm-domain";
#power-domain-cells = <2>;
};
k3_clks: clock-controller {
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
k3_reset: reset-controller {
compatible = "ti,sci-reset";
#reset-cells = <2>;
};
};
Documentation/devicetree/bindings/arm/scu.txt deleted 100644 → 0
+ 0
− 28
View file @ 4b820e16
* ARM Snoop Control Unit (SCU)
As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided
with a Snoop Control Unit. The register range is usually 256 (0x100)
bytes.
References:
- Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual
Revision r2p0
- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual
Revision r0p1
- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference
Manial Revision r2p0
- compatible : Should be:
"arm,cortex-a9-scu"
"arm,cortex-a5-scu"
"arm,arm11mp-scu"
- reg : Specify the base address and the size of the SCU register window.
Example:
scu@a0410000 {
compatible = "arm,cortex-a9-scu";
reg = <0xa0410000 0x100>;
};
Documentation/devicetree/bindings/arm/ux500/boards.txt
+ 2
− 2
View file @ a70bb580
......@@ -20,13 +20,13 @@ during retention, system won't boot without this):
compatible = "ste,dbx500-backupram"
scu:
see binding for arm/scu.txt
see binding for arm/arm,scu.yaml
interrupt-controller:
see binding for interrupt-controller/arm,gic.txt
timer:
see binding for timer/arm,twd.txt
see binding for timer/arm,twd-timer.yaml
clocks:
see binding for clocks/ux500.txt
......
Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml
+ 0
− 1
View file @ a70bb580
......@@ -20,7 +20,6 @@ properties:
reg:
minItems: 2
maxItems: 3
items:
- description: AHCI registers
- description: SATA configuration and IPFS registers
......
Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
+ 11
− 0
View file @ a70bb580
......@@ -53,6 +53,17 @@ required:
- reg
- interrupts
- clocks
- power-domains
if:
not:
properties:
compatible:
contains:
const: renesas,sata-r8a7779
then:
required:
- resets
additionalProperties: false
......
Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
+ 0
− 2
View file @ a70bb580
......@@ -51,7 +51,6 @@ properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: High Frequency Oscillator (usually at 24MHz)
- description: Low Frequency Oscillator (usually at 32kHz)
......@@ -60,7 +59,6 @@ properties:
clock-names:
minItems: 2
maxItems: 4
items:
- const: hosc
- const: losc
......
Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
+ 4
− 3
View file @ a70bb580
......@@ -84,6 +84,7 @@ patternProperties:
idt,slew-percent:
description: The Slew rate control for CMOS single-ended.
enum: [ 80, 85, 90, 100 ]
additionalProperties: false
required:
- compatible
......@@ -139,13 +140,13 @@ examples:
clock-names = "xin";
OUT1 {
idt,drive-mode = <VC5_CMOSD>;
idt,voltage-microvolts = <1800000>;
idt,mode = <VC5_CMOSD>;
idt,voltage-microvolt = <1800000>;
idt,slew-percent = <80>;
};
OUT4 {
idt,drive-mode = <VC5_LVDS>;
idt,mode = <VC5_LVDS>;
};
};
};
......
Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
+ 0
− 1
View file @ a70bb580
......@@ -46,7 +46,6 @@ properties:
nvmem-cell-names:
minItems: 1
maxItems: 2
items:
- const: calib
- const: calib_backup
......
Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
+ 0
− 2
View file @ a70bb580
......@@ -27,7 +27,6 @@ properties:
- description: Sleep clock source
- description: PLL test clock source (Optional clock)
minItems: 2
maxItems: 3
clock-names:
items:
......@@ -35,7 +34,6 @@ properties:
- const: sleep_clk
- const: core_bi_pll_test_se # Optional clock
minItems: 2
maxItems: 3
'#clock-cells':
const: 1
......
Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
+ 0
− 2
View file @ a70bb580
......@@ -36,7 +36,6 @@ properties:
- description: USB3 phy wrapper pipe clock source (Optional clock)
- description: USB3 phy sec pipe clock source (Optional clock)
minItems: 2
maxItems: 13
clock-names:
items:
......@@ -54,7 +53,6 @@ properties:
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock
- const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock
minItems: 2
maxItems: 13
'#clock-cells':
const: 1
......
Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt deleted 100644 → 0
+ 0
− 98
View file @ 4b820e16
Device tree Clock bindings for Renesas EMMA Mobile EV2
This binding uses the common clock binding.
* SMU
System Management Unit described in user's manual R19UH0037EJ1000_SMU.
This is not a clock provider, but clocks under SMU depend on it.
Required properties:
- compatible: Should be "renesas,emev2-smu"
- reg: Address and Size of SMU registers
* SMU_CLKDIV
Function block with an input mux and a divider, which corresponds to
"Serial clock generator" in fig."Clock System Overview" of the manual,
and "xxx frequency division setting register" (XXXCLKDIV) registers.
This makes internal (neither input nor output) clock that is provided
to input of xxxGCLK block.
Required properties:
- compatible: Should be "renesas,emev2-smu-clkdiv"
- reg: Byte offset from SMU base and Bit position in the register
- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
- #clock-cells: Should be <0>
* SMU_GCLK
Clock gating node shown as "Clock stop processing block" in the
fig."Clock System Overview" of the manual.
Registers are "xxx clock gate control register" (XXXGCLKCTRL).
Required properties:
- compatible: Should be "renesas,emev2-smu-gclk"
- reg: Byte offset from SMU base and Bit position in the register
- clocks: Input clock as described in clock-bindings.txt
- #clock-cells: Should be <0>
Example of provider:
usia_u0_sclkdiv: usia_u0_sclkdiv {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
Example of consumer:
serial@e1020000 {
compatible = "renesas,em-uart";
reg = <0xe1020000 0x38>;
interrupts = <0 8 0>;
clocks = <&usia_u0_sclk>;
clock-names = "sclk";
};
Example of clock-tree description:
This describes a clock path in the clock tree
c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
smu@e0110000 {
compatible = "renesas,emev2-smu";
reg = <0xe0110000 0x10000>;
#address-cells = <2>;
#size-cells = <0>;
c32ki: c32ki {
compatible = "fixed-clock";
clock-frequency = <32768>;
#clock-cells = <0>;
};
pll3_fo: pll3_fo {
compatible = "fixed-factor-clock";
clocks = <&c32ki>;
clock-div = <1>;
clock-mult = <7000>;
#clock-cells = <0>;
};
usia_u0_sclkdiv: usia_u0_sclkdiv {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
};
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