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

432
bindings/firmware/arm,scmi.yaml Normal file
View File

@@ -0,0 +1,432 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2021 ARM Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: System Control and Management Interface (SCMI) Message Protocol bindings
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
description: |
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 0056 ("ARM System Control
and Management Interface Platform Design Document")[0] provide for OSPM in
the device tree.
[0] https://developer.arm.com/documentation/den0056/latest
properties:
$nodename:
const: scmi
compatible:
oneOf:
- description: SCMI compliant firmware with mailbox transport
items:
- const: arm,scmi
- description: SCMI compliant firmware with ARM SMC/HVC transport
items:
- const: arm,scmi-smc
- description: SCMI compliant firmware with SCMI Virtio transport.
The virtio transport only supports a single device.
items:
- const: arm,scmi-virtio
- description: SCMI compliant firmware with OP-TEE transport
items:
- const: linaro,scmi-optee
interrupts:
description:
The interrupt that indicates message completion by the platform
rather than by the return of the smc call. This should not be used
except when the platform requires such behavior.
maxItems: 1
interrupt-names:
const: a2p
mbox-names:
description:
Specifies the mailboxes used to communicate with SCMI compliant
firmware.
items:
- const: tx
- const: rx
mboxes:
description:
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.
minItems: 1
maxItems: 2
shmem:
description:
List of phandle pointing to the shared memory(SHM) area, for each
transport channel specified.
minItems: 1
maxItems: 2
'#address-cells':
const: 1
'#size-cells':
const: 0
atomic-threshold-us:
description:
An optional time value, expressed in microseconds, representing, on this
platform, the threshold above which any SCMI command, advertised to have
an higher-than-threshold execution latency, should not be considered for
atomic mode of operation, even if requested.
default: 0
arm,smc-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
SMC id required when using smc or hvc transports
linaro,optee-channel-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Channel specifier required when using OP-TEE transport.
protocol@11:
type: object
properties:
reg:
const: 0x11
'#power-domain-cells':
const: 1
required:
- '#power-domain-cells'
protocol@13:
type: object
properties:
reg:
const: 0x13
'#clock-cells':
const: 1
required:
- '#clock-cells'
protocol@14:
type: object
properties:
reg:
const: 0x14
'#clock-cells':
const: 1
required:
- '#clock-cells'
protocol@15:
type: object
properties:
reg:
const: 0x15
'#thermal-sensor-cells':
const: 1
required:
- '#thermal-sensor-cells'
protocol@16:
type: object
properties:
reg:
const: 0x16
'#reset-cells':
const: 1
required:
- '#reset-cells'
protocol@17:
type: object
properties:
reg:
const: 0x17
regulators:
type: object
description:
The list of all regulators provided by this SCMI controller.
patternProperties:
'^regulators@[0-9a-f]+$':
type: object
$ref: "../regulator/regulator.yaml#"
properties:
reg:
maxItems: 1
description: Identifier for the voltage regulator.
required:
- reg
protocol@18:
type: object
properties:
reg:
const: 0x18
additionalProperties: false
patternProperties:
'^protocol@[0-9a-f]+$':
type: object
description:
Each sub-node represents a protocol supported. If the platform
supports a dedicated communication channel for a particular protocol,
then the corresponding transport properties must be present.
The virtio transport does not support a dedicated communication channel.
properties:
reg:
maxItems: 1
mbox-names:
items:
- const: tx
- const: rx
mboxes:
minItems: 1
maxItems: 2
shmem:
minItems: 1
maxItems: 2
linaro,optee-channel-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Channel specifier required when using OP-TEE transport and
protocol has a dedicated communication channel.
required:
- reg
required:
- compatible
if:
properties:
compatible:
contains:
const: arm,scmi
then:
properties:
interrupts: false
interrupt-names: false
required:
- mboxes
- shmem
else:
if:
properties:
compatible:
contains:
const: arm,scmi-smc
then:
required:
- arm,smc-id
- shmem
else:
if:
properties:
compatible:
contains:
const: linaro,scmi-optee
then:
required:
- linaro,optee-channel-id
examples:
- |
firmware {
scmi {
compatible = "arm,scmi";
mboxes = <&mhuB 0 0>,
<&mhuB 0 1>;
mbox-names = "tx", "rx";
shmem = <&cpu_scp_lpri0>,
<&cpu_scp_lpri1>;
#address-cells = <1>;
#size-cells = <0>;
atomic-threshold-us = <10000>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_dvfs: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
mboxes = <&mhuB 1 0>,
<&mhuB 1 1>;
mbox-names = "tx", "rx";
shmem = <&cpu_scp_hpri0>,
<&cpu_scp_hpri1>;
};
scmi_clk: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
};
scmi_sensors: protocol@15 {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
scmi_reset: protocol@16 {
reg = <0x16>;
#reset-cells = <1>;
};
scmi_voltage: protocol@17 {
reg = <0x17>;
regulators {
#address-cells = <1>;
#size-cells = <0>;
regulator_devX: regulator@0 {
reg = <0x0>;
regulator-max-microvolt = <3300000>;
};
regulator_devY: regulator@9 {
reg = <0x9>;
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <4200000>;
};
};
};
scmi_powercap: protocol@18 {
reg = <0x18>;
};
};
};
soc {
#address-cells = <2>;
#size-cells = <2>;
sram@50000000 {
compatible = "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri0: scp-sram-section@0 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x80>;
};
cpu_scp_lpri1: scp-sram-section@80 {
compatible = "arm,scmi-shmem";
reg = <0x80 0x80>;
};
cpu_scp_hpri0: scp-sram-section@100 {
compatible = "arm,scmi-shmem";
reg = <0x100 0x80>;
};
cpu_scp_hpri2: scp-sram-section@180 {
compatible = "arm,scmi-shmem";
reg = <0x180 0x80>;
};
};
};
- |
firmware {
scmi {
compatible = "arm,scmi-smc";
shmem = <&cpu_scp_lpri0>, <&cpu_scp_lpri1>;
arm,smc-id = <0xc3000001>;
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd1: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
};
};
- |
firmware {
scmi {
compatible = "linaro,scmi-optee";
linaro,optee-channel-id = <0>;
#address-cells = <1>;
#size-cells = <0>;
scmi_dvfs1: protocol@13 {
reg = <0x13>;
linaro,optee-channel-id = <1>;
shmem = <&cpu_optee_lpri0>;
#clock-cells = <1>;
};
scmi_clk0: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
};
};
};
soc {
#address-cells = <2>;
#size-cells = <2>;
sram@51000000 {
compatible = "mmio-sram";
reg = <0x0 0x51000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x51000000 0x10000>;
cpu_optee_lpri0: optee-sram-section@0 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x80>;
};
};
};
...

249
bindings/firmware/arm,scpi.yaml Normal file
View File

@@ -0,0 +1,249 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2021 ARM Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: System Control and Power Interface (SCPI) Message Protocol bindings
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
description: |
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.
This binding is intended to define the interface the firmware implementing
the SCPI provide for OSPM in the device tree.
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
properties:
$nodename:
const: scpi
compatible:
description:
SCPI compliant firmware complying to SCPI v1.0 and above OR
SCPI compliant firmware complying to all unversioned releases
prior to SCPI v1.0
oneOf:
- const: arm,scpi # SCPI v1.0 and above
- const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0
- items:
- enum:
- amlogic,meson-gxbb-scpi
- const: arm,scpi-pre-1.0
mboxes:
description:
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.
minItems: 1
maxItems: 4
shmem:
description:
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.
minItems: 1
maxItems: 4
power-controller:
type: object
description:
This sub-node represents SCPI power domain controller.
properties:
compatible:
const: arm,scpi-power-domains
'#power-domain-cells':
const: 1
num-domains:
$ref: /schemas/types.yaml#/definitions/uint32
description:
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.
required:
- compatible
- '#power-domain-cells'
- num-domains
additionalProperties: false
sensors:
type: object
description: |
This sub-node represents SCPI sensors controller.
properties:
compatible:
oneOf:
- const: arm,scpi-sensors
- items:
- enum:
- amlogic,meson-gxbb-scpi-sensors
- const: arm,scpi-sensors
'#thermal-sensor-cells':
const: 1
required:
- compatible
- '#thermal-sensor-cells'
additionalProperties: false
clocks:
type: object
description:
This is the container node. Each sub-node represents one of the types
of clock controller - indexed or full range.
properties:
compatible:
const: arm,scpi-clocks
patternProperties:
"^clocks-[0-9a-f]+$":
type: object
description: |
This sub-node represents one of the types of clock controller
- indexed or full range.
"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.
properties:
compatible:
enum:
- arm,scpi-dvfs-clocks
- arm,scpi-variable-clocks
'#clock-cells':
const: 1
clock-output-names: true
clock-indices:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
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.
required:
- compatible
- '#clock-cells'
- clock-output-names
- clock-indices
additionalProperties: false
required:
- compatible
additionalProperties: false
additionalProperties: false
required:
- compatible
- mboxes
- shmem
examples:
- |
firmware {
scpi {
compatible = "arm,scpi";
mboxes = <&mhuA 1>;
shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
scpi_devpd: power-controller {
compatible = "arm,scpi-power-domains";
num-domains = <2>;
#power-domain-cells = <1>;
};
clocks {
compatible = "arm,scpi-clocks";
scpi_dvfs: clocks-0 {
compatible = "arm,scpi-dvfs-clocks";
#clock-cells = <1>;
clock-indices = <0>, <1>, <2>;
clock-output-names = "atlclk", "aplclk","gpuclk";
};
scpi_clk: clocks-1 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
clock-indices = <3>, <4>;
clock-output-names = "pxlclk0", "pxlclk1";
};
};
scpi_sensors: sensors {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
};
};
soc {
#address-cells = <2>;
#size-cells = <2>;
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-sram-section@0 {
compatible = "arm,scp-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-sram-section@200 {
compatible = "arm,scp-shmem";
reg = <0x200 0x200>;
};
};
};
- |
firmware {
scpi {
compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0";
mboxes = <&mailbox 1>, <&mailbox 2>;
shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>;
scpi_sensors1: sensors {
compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
};
};
...

33
bindings/firmware/coreboot.txt Normal file
View File

@@ -0,0 +1,33 @@
COREBOOT firmware information
The device tree node to communicate the location of coreboot's memory-resident
bookkeeping structures to the kernel. Since coreboot itself cannot boot a
device-tree-based kernel (yet), this node needs to be inserted by a
second-stage bootloader (a coreboot "payload").
Required properties:
- compatible: Should be "coreboot"
- reg: Address and length of the following two memory regions, in order:
1.) The coreboot table. This is a list of variable-sized descriptors
that contain various compile- and run-time generated firmware
parameters. It is identified by the magic string "LBIO" in its first
four bytes.
See coreboot's src/commonlib/include/commonlib/coreboot_tables.h for
details.
2.) The CBMEM area. This is a downward-growing memory region used by
coreboot to dynamically allocate data structures that remain resident.
It may or may not include the coreboot table as one of its members. It
is identified by a root node descriptor with the magic number
0xc0389481 that resides in the topmost 8 bytes of the area.
See coreboot's src/include/imd.h for details.
Example:
firmware {
ranges;
coreboot {
compatible = "coreboot";
reg = <0xfdfea000 0x264>,
<0xfdfea000 0x16000>;
}
};

19
bindings/firmware/cznic,turris-mox-rwtm.txt Normal file
View File

@@ -0,0 +1,19 @@
Turris Mox rWTM firmware driver
Required properties:
- compatible : Should be "cznic,turris-mox-rwtm"
- mboxes : Must contain a reference to associated mailbox
This device tree node should be used on Turris Mox, or potentially another A3700
compatible device running the Mox's rWTM firmware in the secure processor (for
example it is possible to flash this firmware into EspressoBin).
Example:
firmware {
turris-mox-rwtm {
compatible = "cznic,turris-mox-rwtm";
mboxes = <&rwtm 0>;
status = "okay";
};
};

215
bindings/firmware/fsl,scu.yaml Normal file
View File

@@ -0,0 +1,215 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/fsl,scu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX System Controller Firmware (SCFW)
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
description:
The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).
The AP communicates with the SC using a multi-ported MU module found
in the LSIO subsystem. The current definition of this MU module provides
5 remote AP connections to the SC to support up to 5 execution environments
(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
with the LSIO DSC IP bus. The SC firmware will communicate with this MU
using the MSI bus.
properties:
compatible:
const: fsl,imx-scu
clock-controller:
description:
Clock controller node that provides the clocks controlled by the SCU
$ref: /schemas/clock/fsl,scu-clk.yaml
gpio:
description:
Control the GPIO PINs on SCU domain over the firmware APIs
$ref: /schemas/gpio/fsl,imx8qxp-sc-gpio.yaml
ocotp:
description:
OCOTP controller node provided by the SCU
$ref: /schemas/nvmem/fsl,scu-ocotp.yaml
keys:
description:
Keys provided by the SCU
$ref: /schemas/input/fsl,scu-key.yaml
mboxes:
description:
A list of phandles of TX MU channels followed by a list of phandles of
RX MU channels. The list may include at the end one more optional MU
channel for general interrupt. The number of expected tx and rx
channels is 1 TX and 1 RX channels if MU instance is "fsl,imx8-mu-scu"
compatible, 4 TX and 4 RX channels otherwise. All MU channels must be
within the same MU instance. Cross instances are not allowed. The MU
instance can only be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users
need to ensure that one is used that does not conflict with other
execution environments such as ATF.
oneOf:
- items:
- description: TX0 MU channel
- description: RX0 MU channel
- items:
- description: TX0 MU channel
- description: RX0 MU channel
- description: optional MU channel for general interrupt
- items:
- description: TX0 MU channel
- description: TX1 MU channel
- description: TX2 MU channel
- description: TX3 MU channel
- description: RX0 MU channel
- description: RX1 MU channel
- description: RX2 MU channel
- description: RX3 MU channel
- items:
- description: TX0 MU channel
- description: TX1 MU channel
- description: TX2 MU channel
- description: TX3 MU channel
- description: RX0 MU channel
- description: RX1 MU channel
- description: RX2 MU channel
- description: RX3 MU channel
- description: optional MU channel for general interrupt
mbox-names:
oneOf:
- items:
- const: tx0
- const: rx0
- items:
- const: tx0
- const: rx0
- const: gip3
- items:
- const: tx0
- const: tx1
- const: tx2
- const: tx3
- const: rx0
- const: rx1
- const: rx2
- const: rx3
- items:
- const: tx0
- const: tx1
- const: tx2
- const: tx3
- const: rx0
- const: rx1
- const: rx2
- const: rx3
- const: gip3
pinctrl:
description:
Pin controller provided by the SCU
$ref: /schemas/pinctrl/fsl,scu-pinctrl.yaml
power-controller:
description:
Power domains controller node that provides the power domains
controlled by the SCU
$ref: /schemas/power/fsl,scu-pd.yaml
rtc:
description:
RTC controller provided by the SCU
$ref: /schemas/rtc/fsl,scu-rtc.yaml
thermal-sensor:
description:
Thermal sensor provided by the SCU
$ref: /schemas/thermal/fsl,scu-thermal.yaml
watchdog:
description:
Watchdog controller provided by the SCU
$ref: /schemas/watchdog/fsl,scu-wdt.yaml
required:
- compatible
- mbox-names
- mboxes
additionalProperties: false
examples:
- |
#include <dt-bindings/firmware/imx/rsrc.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/pinctrl/pads-imx8qxp.h>
firmware {
system-controller {
compatible = "fsl,imx-scu";
mbox-names = "tx0", "tx1", "tx2", "tx3",
"rx0", "rx1", "rx2", "rx3",
"gip3";
mboxes = <&lsio_mu1 0 0 &lsio_mu1 0 1 &lsio_mu1 0 2 &lsio_mu1 0 3
&lsio_mu1 1 0 &lsio_mu1 1 1 &lsio_mu1 1 2 &lsio_mu1 1 3
&lsio_mu1 3 3>;
clock-controller {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
#clock-cells = <2>;
};
pinctrl {
compatible = "fsl,imx8qxp-iomuxc";
pinctrl_lpuart0: lpuart0grp {
fsl,pins = <
IMX8QXP_UART0_RX_ADMA_UART0_RX 0x06000020
IMX8QXP_UART0_TX_ADMA_UART0_TX 0x06000020
>;
};
};
ocotp {
compatible = "fsl,imx8qxp-scu-ocotp";
#address-cells = <1>;
#size-cells = <1>;
fec_mac0: mac@2c4 {
reg = <0x2c4 6>;
};
};
power-controller {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
};
rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
keys {
compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
linux,keycodes = <KEY_POWER>;
};
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
thermal-sensor {
compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal";
#thermal-sensor-cells = <1>;
};
};
};

94
bindings/firmware/intel,ixp4xx-network-processing-engine.yaml Normal file
View File

@@ -0,0 +1,94 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
$id: "http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Intel IXP4xx Network Processing Engine
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
On the IXP4xx SoCs, the Network Processing Engine (NPE) is a small
processor that can load a firmware to perform offloading of networking
and crypto tasks. It also manages the MDIO bus to the ethernet PHYs
on the IXP4xx platform. All IXP4xx platforms have three NPEs at
consecutive memory locations. They are all included in the same
device node since they are not independent of each other.
properties:
compatible:
oneOf:
- items:
- const: intel,ixp4xx-network-processing-engine
reg:
items:
- description: NPE0 (NPE-A) register range
- description: NPE1 (NPE-B) register range
- description: NPE2 (NPE-C) register range
crypto:
$ref: /schemas/crypto/intel,ixp4xx-crypto.yaml#
type: object
description: Optional node for the embedded crypto engine, the node
should be named with the instance number of the NPE engine used for
the crypto engine.
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
hss@[0-9]+$:
$ref: /schemas/net/intel,ixp4xx-hss.yaml#
type: object
description: Optional node for the High Speed Serial link (HSS), the
node should be named with the instance number of the NPE engine
used for the HSS.
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
npe: npe@c8006000 {
compatible = "intel,ixp4xx-network-processing-engine";
reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
hss@0 {
compatible = "intel,ixp4xx-hss";
reg = <0>;
intel,npe-handle = <&npe 0>;
intel,queue-chl-rxtrig = <&qmgr 12>;
intel,queue-chl-txready = <&qmgr 34>;
intel,queue-pkt-rx = <&qmgr 13>;
intel,queue-pkt-tx = <&qmgr 14>, <&qmgr 15>, <&qmgr 16>, <&qmgr 17>;
intel,queue-pkt-rxfree = <&qmgr 18>, <&qmgr 19>, <&qmgr 20>, <&qmgr 21>;
intel,queue-pkt-txdone = <&qmgr 22>;
cts-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
rts-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
dcd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
dtr-gpios = <&gpio_74 2 GPIO_ACTIVE_LOW>;
clk-internal-gpios = <&gpio_74 0 GPIO_ACTIVE_HIGH>;
};
crypto {
compatible = "intel,ixp4xx-crypto";
intel,npe-handle = <&npe 2>;
queue-rx = <&qmgr 30>;
queue-txready = <&qmgr 29>;
};
};
...

57
bindings/firmware/intel,stratix10-svc.txt Normal file
View File

@@ -0,0 +1,57 @@
Intel Service Layer Driver for Stratix10 SoC
============================================
Intel Stratix10 SoC is composed of a 64 bit quad-core ARM Cortex A53 hard
processor system (HPS) and Secure Device Manager (SDM). When the FPGA is
configured from HPS, there needs to be a way for HPS to notify SDM the
location and size of the configuration data. Then SDM will get the
configuration data from that location and perform the FPGA configuration.
To meet the whole system security needs and support virtual machine requesting
communication with SDM, only the secure world of software (EL3, Exception
Layer 3) can interface with SDM. All software entities running on other
exception layers must channel through the EL3 software whenever it needs
service from SDM.
Intel Stratix10 service layer driver, running at privileged exception level
(EL1, Exception Layer 1), interfaces with the service providers and provides
the services for FPGA configuration, QSPI, Crypto and warm reset. Service layer
driver also manages secure monitor call (SMC) to communicate with secure monitor
code running in EL3.
Required properties:
-------------------
The svc node has the following mandatory properties, must be located under
the firmware node.
- compatible: "intel,stratix10-svc" or "intel,agilex-svc"
- method: smc or hvc
smc - Secure Monitor Call
hvc - Hypervisor Call
- memory-region:
phandle to the reserved memory node. See
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
for details
Example:
-------
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
service_reserved: svcbuffer@0 {
compatible = "shared-dma-pool";
reg = <0x0 0x0 0x0 0x1000000>;
alignment = <0x1000>;
no-map;
};
};
firmware {
svc {
compatible = "intel,stratix10-svc";
method = "smc";
memory-region = <&service_reserved>;
};
};

15
bindings/firmware/meson/meson_sm.txt Normal file
View File

@@ -0,0 +1,15 @@
* Amlogic Secure Monitor
In the Amlogic SoCs the Secure Monitor code is used to provide access to the
NVMEM, enable JTAG, set USB boot, etc...
Required properties for the secure monitor node:
- compatible: Should be "amlogic,meson-gxbb-sm"
Example:
firmware {
sm: secure-monitor {
compatible = "amlogic,meson-gxbb-sm";
};
};

186
bindings/firmware/nvidia,tegra186-bpmp.yaml Normal file
View File

@@ -0,0 +1,186 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/nvidia,tegra186-bpmp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra Boot and Power Management Processor (BPMP)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
description: |
The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management, clock
management, and reset control tasks from the CPU. The binding document
defines the resources that would be used by the BPMP firmware driver,
which can create the interprocessor communication (IPC) between the
CPU and BPMP.
This node is a mailbox consumer. See the following files for details
of the mailbox subsystem, and the specifiers implemented by the
relevant provider(s):
- .../mailbox/mailbox.txt
- .../mailbox/nvidia,tegra186-hsp.yaml
This node is a clock, power domain, and reset provider. See the
following files for general documentation of those features, and the
specifiers implemented by this node:
- .../clock/clock-bindings.txt
- <dt-bindings/clock/tegra186-clock.h>
- ../power/power-domain.yaml
- <dt-bindings/power/tegra186-powergate.h>
- .../reset/reset.txt
- <dt-bindings/reset/tegra186-reset.h>
The BPMP implements some services which must be represented by
separate nodes. For example, it can provide access to certain I2C
controllers, and the I2C bindings represent each I2C controller as a
device tree node. Such nodes should be nested directly inside the main
BPMP node.
Software can determine whether a child node of the BPMP node
represents a device by checking for a compatible property. Any node
with a compatible property represents a device that can be
instantiated. Nodes without a compatible property may be used to
provide configuration information regarding the BPMP itself, although
no such configuration nodes are currently defined by this binding.
The BPMP firmware defines no single global name-/numbering-space for
such services. Put another way, the numbering scheme for I2C buses is
distinct from the numbering scheme for any other service the BPMP may
provide (e.g. a future hypothetical SPI bus service). As such, child
device nodes will have no reg property, and the BPMP node will have no
"#address-cells" or "#size-cells" property.
The shared memory area for the IPC TX and RX between CPU and BPMP are
predefined and work on top of sysram, which is an SRAM inside the
chip. See ".../sram/sram.yaml" for the bindings.
properties:
compatible:
oneOf:
- items:
- enum:
- nvidia,tegra194-bpmp
- nvidia,tegra234-bpmp
- const: nvidia,tegra186-bpmp
- const: nvidia,tegra186-bpmp
mboxes:
description: A phandle and channel specifier for the mailbox used to
communicate with the BPMP.
maxItems: 1
shmem:
description: List of the phandle to the TX and RX shared memory area
that the IPC between CPU and BPMP is based on.
minItems: 2
maxItems: 2
"#clock-cells":
const: 1
"#power-domain-cells":
const: 1
"#reset-cells":
const: 1
interconnects:
items:
- description: memory read client
- description: memory write client
- description: DMA read client
- description: DMA write client
interconnect-names:
items:
- const: read
- const: write
- const: dma-mem # dma-read
- const: dma-write
iommus:
maxItems: 1
i2c:
type: object
thermal:
type: object
additionalProperties: false
required:
- compatible
- mboxes
- shmem
- "#clock-cells"
- "#power-domain-cells"
- "#reset-cells"
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mailbox/tegra186-hsp.h>
#include <dt-bindings/memory/tegra186-mc.h>
hsp_top0: hsp@3c00000 {
compatible = "nvidia,tegra186-hsp";
reg = <0x03c00000 0xa0000>;
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "doorbell";
#mbox-cells = <2>;
};
sram@30000000 {
compatible = "nvidia,tegra186-sysram", "mmio-sram";
reg = <0x30000000 0x50000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x30000000 0x50000>;
cpu_bpmp_tx: sram@4e000 {
reg = <0x4e000 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
cpu_bpmp_rx: sram@4f000 {
reg = <0x4f000 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
};
bpmp {
compatible = "nvidia,tegra186-bpmp";
interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &emc>,
<&mc TEGRA186_MEMORY_CLIENT_BPMPW &emc>,
<&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &emc>,
<&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>;
interconnect-names = "read", "write", "dma-mem", "dma-write";
iommus = <&smmu TEGRA186_SID_BPMP>;
mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB
TEGRA_HSP_DB_MASTER_BPMP>;
shmem = <&cpu_bpmp_tx>, <&cpu_bpmp_rx>;
#clock-cells = <1>;
#power-domain-cells = <1>;
#reset-cells = <1>;
i2c {
compatible = "nvidia,tegra186-bpmp-i2c";
nvidia,bpmp-bus-id = <5>;
#address-cells = <1>;
#size-cells = <0>;
};
thermal {
compatible = "nvidia,tegra186-bpmp-thermal";
#thermal-sensor-cells = <1>;
};
};

35
bindings/firmware/nvidia,tegra210-bpmp.txt Normal file
View File

@@ -0,0 +1,35 @@
NVIDIA Tegra210 Boot and Power Management Processor (BPMP)
The Boot and Power Management Processor (BPMP) is a co-processor found
in Tegra210 SoC. It is designed to handle the early stages of the boot
process as well as to assisting in entering deep low power state
(suspend to ram), and also offloading DRAM memory clock scaling on
some platforms. The binding document defines the resources that would
be used by the BPMP T210 firmware driver, which can create the
interprocessor communication (IPC) between the CPU and BPMP.
Required properties:
- compatible
Array of strings
One of:
- "nvidia,tegra210-bpmp"
- reg: physical base address and length for HW synchornization primitives
1) base address and length to Tegra 'atomics' hardware
2) base address and length to Tegra 'semaphore' hardware
- interrupts: specifies the interrupt number for receiving messages ("rx")
and for triggering messages ("tx")
Optional properties:
- #clock-cells : Should be 1 for platforms where DRAM clock control is
offloaded to bpmp.
Example:
bpmp@70016000 {
compatible = "nvidia,tegra210-bpmp";
reg = <0x0 0x70016000 0x0 0x2000
0x0 0x60001000 0x0 0x1000>;
interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 4 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "tx", "rx";
};

151
bindings/firmware/qcom,scm.yaml Normal file
View File

@@ -0,0 +1,151 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/qcom,scm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: QCOM Secure Channel Manager (SCM)
description: |
Qualcomm processors include an interface to communicate to the secure firmware.
This interface allows for clients to request different types of actions.
These can include CPU power up/down, HDCP requests, loading of firmware,
and other assorted actions.
maintainers:
- Bjorn Andersson <bjorn.andersson@linaro.org>
- Robert Marko <robimarko@gmail.com>
- Guru Das Srinagesh <quic_gurus@quicinc.com>
properties:
compatible:
items:
- enum:
- qcom,scm-apq8064
- qcom,scm-apq8084
- qcom,scm-ipq4019
- qcom,scm-ipq6018
- qcom,scm-ipq806x
- qcom,scm-ipq8074
- qcom,scm-mdm9607
- qcom,scm-msm8226
- qcom,scm-msm8660
- qcom,scm-msm8916
- qcom,scm-msm8953
- qcom,scm-msm8960
- qcom,scm-msm8974
- qcom,scm-msm8976
- qcom,scm-msm8994
- qcom,scm-msm8996
- qcom,scm-msm8998
- qcom,scm-sc7180
- qcom,scm-sc7280
- qcom,scm-sc8280xp
- qcom,scm-sdm670
- qcom,scm-sdm845
- qcom,scm-sdx55
- qcom,scm-sdx65
- qcom,scm-sm6115
- qcom,scm-sm6125
- qcom,scm-sm6350
- qcom,scm-sm6375
- qcom,scm-sm8150
- qcom,scm-sm8250
- qcom,scm-sm8350
- qcom,scm-sm8450
- qcom,scm-qcs404
- const: qcom,scm
clocks:
minItems: 1
maxItems: 3
clock-names:
minItems: 1
maxItems: 3
interconnects:
maxItems: 1
interconnect-names:
maxItems: 1
'#reset-cells':
const: 1
qcom,dload-mode:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to TCSR hardware block
- description: offset of the download mode control register
description: TCSR hardware block
allOf:
- if:
properties:
compatible:
contains:
enum:
- qcom,scm-apq8064
- qcom,scm-msm8660
- qcom,scm-msm8960
- qcom,scm-sm6375
then:
properties:
clock-names:
items:
- const: core
clocks:
maxItems: 1
required:
- clocks
- clock-names
- if:
properties:
compatible:
contains:
enum:
- qcom,scm-apq8084
- qcom,scm-mdm9607
- qcom,scm-msm8916
- qcom,scm-msm8953
- qcom,scm-msm8974
- qcom,scm-msm8976
then:
properties:
clock-names:
items:
- const: core
- const: bus
- const: iface
clocks:
minItems: 3
maxItems: 3
required:
- clocks
- clock-names
required:
- compatible
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
firmware {
scm {
compatible = "qcom,scm-msm8916", "qcom,scm";
clocks = <&gcc GCC_CRYPTO_CLK>,
<&gcc GCC_CRYPTO_AXI_CLK>,
<&gcc GCC_CRYPTO_AHB_CLK>;
clock-names = "core", "bus", "iface";
};
};

54
bindings/firmware/qemu,fw-cfg-mmio.yaml Normal file
View File

@@ -0,0 +1,54 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/qemu,fw-cfg-mmio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: QEMU Firmware Configuration bindings
maintainers:
- Rob Herring <robh@kernel.org>
description: |
Various QEMU emulation / virtualization targets provide the following
Firmware Configuration interface on the "virt" machine type:
- A write-only, 16-bit wide selector (or control) register,
- a read-write, 64-bit wide data register.
QEMU exposes the control and data register to guests as memory mapped
registers; their location is communicated to the guest's UEFI firmware in the
DTB that QEMU places at the bottom of the guest's DRAM.
The authoritative guest-side hardware interface documentation to the fw_cfg
device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree.
properties:
compatible:
const: qemu,fw-cfg-mmio
reg:
maxItems: 1
description: |
* Bytes 0x0 to 0x7 cover the data register.
* Bytes 0x8 to 0x9 cover the selector register.
* Further registers may be appended to the region in case of future interface
revisions / feature bits.
dma-coherent: true
required:
- compatible
- reg
additionalProperties: false
examples:
- |
fw-cfg@9020000 {
compatible = "qemu,fw-cfg-mmio";
reg = <0x9020000 0xa>;
};
...

89
bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml Normal file
View File

@@ -0,0 +1,89 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx firmware driver
maintainers:
- Nava kishore Manne <nava.manne@xilinx.com>
description: The zynqmp-firmware node describes the interface to platform
firmware. ZynqMP has an interface to communicate with secure firmware.
Firmware driver provides an interface to firmware APIs. Interface APIs
can be used by any driver to communicate to PMUFW(Platform Management Unit).
These requests include clock management, pin control, device control,
power management service, FPGA service and other platform management
services.
properties:
compatible:
oneOf:
- description: For implementations complying for Zynq Ultrascale+ MPSoC.
const: xlnx,zynqmp-firmware
- description: For implementations complying for Versal.
const: xlnx,versal-firmware
method:
description: |
The method of calling the PM-API firmware layer.
Permitted values are.
- "smc" : SMC #0, following the SMCCC
- "hvc" : HVC #0, following the SMCCC
$ref: /schemas/types.yaml#/definitions/string-array
enum:
- smc
- hvc
versal_fpga:
$ref: /schemas/fpga/xlnx,versal-fpga.yaml#
description: Compatible of the FPGA device.
type: object
zynqmp-aes:
$ref: /schemas/crypto/xlnx,zynqmp-aes.yaml#
description: The ZynqMP AES-GCM hardened cryptographic accelerator is
used to encrypt or decrypt the data with provided key and initialization
vector.
type: object
clock-controller:
$ref: /schemas/clock/xlnx,versal-clk.yaml#
description: The clock controller is a hardware block of Xilinx versal
clock tree. It reads required input clock frequencies from the devicetree
and acts as clock provider for all clock consumers of PS clocks.list of
clock specifiers which are external input clocks to the given clock
controller.
type: object
required:
- compatible
additionalProperties: false
examples:
- |
versal-firmware {
compatible = "xlnx,versal-firmware";
method = "smc";
versal_fpga: versal_fpga {
compatible = "xlnx,versal-fpga";
};
xlnx_aes: zynqmp-aes {
compatible = "xlnx,zynqmp-aes";
};
versal_clk: clock-controller {
#clock-cells = <1>;
compatible = "xlnx,versal-clk";
clocks = <&ref>, <&alt_ref>, <&pl_alt_ref>;
clock-names = "ref", "alt_ref", "pl_alt_ref";
};
};
...