renegade-project/linux-snapdragon
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Devicetree updates for v5.14:

Browse Source 
- 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 Arm ccree, Zynq FPGA, ZynqMP RTC, Arm VIC, adi,adv7511, TI
   AM56 PCI, Aspeed I2C, arm,sbsa-gwdt, MTD physmap, virtio-mmio, Arm
   SCMI, Arm/Amlogic SCPI, TI OMAP mailbox, NXP pcf8563/pcf85263/pcf85363,
   Mediatek RNG, Arm SCU, Arm TWD timer, Broadcom iProc PWM, Renesas TPU,
   Tegra20 EMC, MDIO GPIO, renesas,r9a06g032-sysctrl, renesas,emev2-smu,
   sysc-rmobile, linaro,optee-tz, and TI SCI bindings 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
 -----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCgAuFiEEktVUI4SxYhzZyEuo+vtdtY28YcMFAmDfNTsQHHJvYmhAa2Vy
 bmVsLm9yZwAKCRD6+121jbxhwx/jD/0TG5A5clgwEA/0wKTLUK0OmRhTS4T9AjD2
 NIgs+74YztwP1c49u6SXmSCD1wfyHl1dznmvXUn/gD9838gwYjHH4eZgG5weOwOy
 hQgEhUqZ3AJF24wEDAfkQX7KCh9rxO1Vifx+2ER+DXCc65kBxbwdBSUSgWSkN/fj
 UHRENdW37ORw4WLXELGYDRegvLktzCbPqwPWUBJy8+9or1/r2ZFN5Or6gG1J7HR5
 jGiiKyB5O5E1GBtiCQaFoGl+uQG5/X2aSb7AMYbMnOTP+fr9YiTbcTjKwoMMurJW
 T56YUse0QZ7yK5umUMV17A2urrOg9Nnk7kj5Sf63UkOwVY5Xjx/TqIwBPZGXUTlK
 RdSIZXzzdv491pem1sHty6TjX3NFIe81aR9p7CZIigOa9AXj5PMcVHflq3SUDSuQ
 nCg2qf7E73307w5PNLSbkEFkR/g341pqwvwMmRDb9a68ZBwhylKKVdV0GzAdea8P
 ez1R0hJMJ/y5DqdC1KXOjLOR6zX+a3daLTPLsPKXeeKMsI/U4BXF3s5aoxBavkzU
 SLiZynost28oTlVX7K2fl4r7WocyMj4htywqerfeJVry+FVopFVNcwb/zowRSOpd
 o9xqpSXMXzBDB5eSQR331mOrUU5SxKhISmofH3U+MvF9D2/yNB1qMhMSAN9DBzOl
 mofZZWSIzg==
 =MDNZ
 -----END PGP SIGNATURE-----

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
  ...
This commit is contained in:
Linus Torvalds 2021-07-03 10:54:08 -07:00
commit a70bb580bf
250 changed files with 5047 additions and 3772 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
Documentation/devicetree/bindings/arm/amlogic,scpi.txt
View File

@ -1,27 +0,0 @@
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

239
Documentation/devicetree/bindings/arm/arm,scmi.txt
View File

@ -1,239 +0,0 @@
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>;
...
};
};

219
Documentation/devicetree/bindings/arm/arm,scpi.txt
View File

@ -1,219 +0,0 @@
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.

46
Documentation/devicetree/bindings/arm/arm,scu.yaml Normal file
View File

@ -0,0 +1,46 @@
# 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>;
};

31
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
View File

@ -1,31 +0,0 @@
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";
};
};

58
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml Normal file
View File

@ -0,0 +1,58 @@
# 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";
};
};

2
Documentation/devicetree/bindings/arm/intel,keembay.yaml
View File

@ -11,6 +11,8 @@ maintainers:
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:

26
Documentation/devicetree/bindings/arm/juno,scpi.txt
View File

@ -1,26 +0,0 @@
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

86
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
View File

@ -1,86 +0,0 @@
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 {
...
...
};
};

129
Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml Normal file
View File

@ -0,0 +1,129 @@
# 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>;
};
};

28
Documentation/devicetree/bindings/arm/scu.txt
View File

@ -1,28 +0,0 @@
* 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>;
};

4
Documentation/devicetree/bindings/arm/ux500/boards.txt
View File

@ -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

1
Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml
View File

@ -20,7 +20,6 @@ properties:
reg:
minItems: 2
maxItems: 3
items:
- description: AHCI registers
- description: SATA configuration and IPFS registers

11
Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
View File

@ -53,6 +53,17 @@ required:
- reg
- interrupts
- clocks
- power-domains
if:
not:
properties:
compatible:
contains:
const: renesas,sata-r8a7779
then:
required:
- resets
additionalProperties: false

2
Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
View File

@ -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

7
Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
View File

@ -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>;
};
};
};

1
Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
View File

@ -46,7 +46,6 @@ properties:
nvmem-cell-names:
minItems: 1
maxItems: 2
items:
- const: calib
- const: calib_backup

2
Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
View File

@ -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

2
Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
View File

@ -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

98
Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt
View File

@ -1,98 +0,0 @@
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>;
};
};

140
Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml Normal file
View File

@ -0,0 +1,140 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/renesas,emev2-smu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas EMMA Mobile EV2 System Management Unit
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
- Magnus Damm <magnus.damm@gmail.com>
description: |
The System Management Unit is described in user's manual R19UH0037EJ1000_SMU.
This is not a clock provider, but clocks under SMU depend on it.
properties:
compatible:
const: renesas,emev2-smu
reg:
maxItems: 1
'#address-cells':
const: 2
'#size-cells':
const: 0
required:
- compatible
- reg
- '#address-cells'
- '#size-cells'
patternProperties:
".*sclkdiv@.*":
type: object
description: |
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.
properties:
compatible:
const: renesas,emev2-smu-clkdiv
reg:
maxItems: 1
description:
Byte offset from SMU base and Bit position in the register.
clocks:
minItems: 1
maxItems: 4
'#clock-cells':
const: 0
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
".*sclk@.*":
type: object
description: |
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).
properties:
compatible:
const: renesas,emev2-smu-gclk
reg:
maxItems: 1
description:
Byte offset from SMU base and Bit position in the register.
clocks:
maxItems: 1
'#clock-cells':
const: 0
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
additionalProperties: true
examples:
- |
// Example of clock-tree description:
//
// This describes a clock path in the clock tree
// c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
clocks@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@610,0 {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk@4a0,1 {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
};

46
Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt
View File

@ -1,46 +0,0 @@
* Renesas R9A06G032 SYSCTRL
Required Properties:
- compatible: Must be:
- "renesas,r9a06g032-sysctrl"
- reg: Base address and length of the SYSCTRL IO block.
- #clock-cells: Must be 1
- clocks: References to the parent clocks:
- external 40mhz crystal.
- external (optional) 32.768khz
- external (optional) jtag input
- external (optional) RGMII_REFCLK
- clock-names: Must be:
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
- #power-domain-cells: Must be 0
Examples
--------
- SYSCTRL node:
sysctrl: system-controller@4000c000 {
compatible = "renesas,r9a06g032-sysctrl";
reg = <0x4000c000 0x1000>;
#clock-cells = <1>;
clocks = <&ext_mclk>, <&ext_rtc_clk>,
<&ext_jtag_clk>, <&ext_rgmii_ref>;
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
#power-domain-cells = <0>;
};
- Other nodes can use the clocks provided by SYSCTRL as in:
#include <dt-bindings/clock/r9a06g032-sysctrl.h>
uart0: serial@40060000 {
compatible = "snps,dw-apb-uart";
reg = <0x40060000 0x400>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&sysctrl R9A06G032_CLK_UART0>, <&sysctrl R9A06G032_HCLK_UART0>;
clock-names = "baudclk", "apb_pclk";
power-domains = <&sysctrl>;
};

62
Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml Normal file
View File

@ -0,0 +1,62 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/renesas,r9a06g032-sysctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1D (R9A06G032) System Controller
maintainers:
- Gareth Williams <gareth.williams.jx@renesas.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:
compatible:
const: renesas,r9a06g032-sysctrl
reg:
maxItems: 1
clocks:
minItems: 1
items:
- description: External 40 MHz crystal
- description: Optional external 32.768 kHz crystal
- description: Optional external JTAG input
- description: Optional external RGMII_REFCLK
clock-names:
minItems: 1
items:
- const: mclk
- const: rtc
- const: jtag
- const: rgmii_ref_ext
'#clock-cells':
const: 1
'#power-domain-cells':
const: 0
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
sysctrl: system-controller@4000c000 {
compatible = "renesas,r9a06g032-sysctrl";
reg = <0x4000c000 0x1000>;
clocks = <&ext_mclk>, <&ext_rtc_clk>, <&ext_jtag_clk>,
<&ext_rgmii_ref>;
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
#clock-cells = <1>;
#power-domain-cells = <0>;
};

1
Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
View File

@ -40,7 +40,6 @@ properties:
clock-names:
minItems: 1
maxItems: 4
items:
- const: ext-26m
- const: ext-32k

36
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
View File

@ -1,36 +0,0 @@
Texas Instruments TI-SCI Clocks
===============================
All clocks on Texas Instruments' SoCs that contain a System Controller,
are only controlled by this entity. Communication between a host processor
running an OS and the System Controller happens through a protocol known
as TI-SCI[1]. This clock implementation plugs into the common clock
framework and makes use of the TI-SCI protocol on clock API requests.
[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
Required properties:
-------------------
- compatible: Must be "ti,k2g-sci-clk"
- #clock-cells: Shall be 2.
In clock consumers, this cell represents the device ID and clock ID
exposed by the PM firmware. The list of valid values for the device IDs
and clocks IDs for 66AK2G SoC are documented at
http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
Examples:
--------
pmmc: pmmc {
compatible = "ti,k2g-sci";
k2g_clks: clocks {
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
};
uart0: serial@2530c00 {
compatible = "ns16550a";
clocks = <&k2g_clks 0x2c 0>;
};

49
Documentation/devicetree/bindings/clock/ti,sci-clk.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI-SCI clock controller node bindings
maintainers:
- Nishanth Menon <nm@ti.com>
description: |
Some TI SoCs contain a system controller (like the Power Management Micro
Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
the state of the various hardware modules present on the SoC. Communication
between the host processor running an OS and the system controller happens
through a protocol called TI System Control Interface (TI-SCI protocol).
This clock controller node uses the TI SCI protocol to perform various clock
management of various hardware modules (devices) present on the SoC. This
node must be a child node of the associated TI-SCI system controller node.
properties:
$nodename:
pattern: "^clock-controller$"
compatible:
const: ti,k2g-sci-clk
"#clock-cells":
const: 2
description:
The two cells represent values that the TI-SCI controller defines.
The first cell should contain the device ID.
The second cell should contain the clock ID.
Please see http://processors.wiki.ti.com/index.php/TISCI for
protocol documentation for the values to be used for different devices.
additionalProperties: false
examples:
- |
k3_clks: clock-controller {
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};

2
Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
View File

@ -30,7 +30,6 @@ properties:
- description: Module clock
- description: MBus clock
minItems: 2
maxItems: 3
clock-names:
items:
@ -38,7 +37,6 @@ properties:
- const: mod
- const: ram
minItems: 2
maxItems: 3
resets:
maxItems: 1

53
Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml Normal file
View File

@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/arm,cryptocell.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm TrustZone CryptoCell cryptographic engine
maintainers:
- Gilad Ben-Yossef <gilad@benyossef.com>
properties:
compatible:
enum:
- arm,cryptocell-713-ree
- arm,cryptocell-703-ree
- arm,cryptocell-712-ree
- arm,cryptocell-710-ree
- arm,cryptocell-630p-ree
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
dma-coherent: true
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
arm_cc712: crypto@80000000 {
compatible = "arm,cryptocell-712-ree";
reg = <0x80000000 0x10000>;
interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
};

25
Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
View File

@ -1,25 +0,0 @@
Arm TrustZone CryptoCell cryptographic engine
Required properties:
- compatible: Should be one of -
"arm,cryptocell-713-ree"
"arm,cryptocell-703-ree"
"arm,cryptocell-712-ree"
"arm,cryptocell-710-ree"
"arm,cryptocell-630p-ree"
- reg: Base physical address of the engine and length of memory mapped region.
- interrupts: Interrupt number for the device.
Optional properties:
- clocks: Reference to the crypto engine clock.
- dma-coherent: Present if dma operations are coherent.
Examples:
arm_cc712: crypto@80000000 {
compatible = "arm,cryptocell-712-ree";
interrupt-parent = <&intc>;
interrupts = < 0 30 4 >;
reg = < 0x80000000 0x10000 >;
};

1
Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
View File

@ -27,7 +27,6 @@ properties:
- description: MXS DCP DCP interrupt
- description: MXS DCP secure interrupt
minItems: 2
maxItems: 3
clocks:
maxItems: 1

6
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
View File

@ -26,14 +26,12 @@ properties:
reg:
minItems: 1
maxItems: 2
items:
- description: Display Backend registers
- description: SAT registers
reg-names:
minItems: 1
maxItems: 2
items:
- const: be
- const: sat
@ -43,7 +41,6 @@ properties:
clocks:
minItems: 3
maxItems: 4
items:
- description: The backend interface clock
- description: The backend module clock
@ -52,7 +49,6 @@ properties:
clock-names:
minItems: 3
maxItems: 4
items:
- const: ahb
- const: mod
@ -61,14 +57,12 @@ properties:
resets:
minItems: 1
maxItems: 2
items:
- description: The Backend reset line
- description: The SAT reset line
reset-names:
minItems: 1
maxItems: 2
items:
- const: be
- const: sat

1
Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
View File

@ -24,7 +24,6 @@ properties:
clocks:
minItems: 1
maxItems: 2
items:
- description: Bus Clock
- description: Module Clock

4
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
View File

@ -46,7 +46,6 @@ properties:
clocks:
minItems: 3
maxItems: 6
items:
- description: Bus Clock
- description: Register Clock
@ -57,7 +56,6 @@ properties:
clock-names:
minItems: 3
maxItems: 6
items:
- const: iahb
- const: isfr
@ -68,14 +66,12 @@ properties:
resets:
minItems: 1
maxItems: 2
items:
- description: HDMI Controller Reset
- description: HDCP Reset
reset-names:
minItems: 1
maxItems: 2
items:
- const: ctrl
- const: hdcp

2
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
View File

@ -27,7 +27,6 @@ properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: Bus Clock
- description: Module Clock
@ -36,7 +35,6 @@ properties:
clock-names:
minItems: 2
maxItems: 4
items:
- const: bus
- const: mod

2
Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
View File

@ -48,7 +48,6 @@ properties:
clocks:
minItems: 2
maxItems: 6
items:
- description: The TCON TOP interface clock
- description: The TCON TOP TV0 clock
@ -59,7 +58,6 @@ properties:
clock-names:
minItems: 2
maxItems: 6
items:
- const: bus
- const: tcon-tv0

143
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
View File

@ -1,143 +0,0 @@
Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
------------------------------------------------
The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
pixels, while the others support RGB interface.
Required properties:
- compatible: Should be one of:
"adi,adv7511"
"adi,adv7511w"
"adi,adv7513"
"adi,adv7533"
"adi,adv7535"
- reg: I2C slave addresses
The ADV7511 internal registers are split into four pages exposed through
different I2C addresses, creating four register maps. Each map has it own
I2C address and acts as a standard slave device on the I2C bus. The main
address is mandatory, others are optional and revert to defaults if not
specified.
The ADV7511 supports a large number of input data formats that differ by their
color depth, color format, clock mode, bit justification and random
arrangement of components on the data bus. The combination of the following
properties describe the input and map directly to the video input tables of the
ADV7511 datasheet that document all the supported combinations.
- adi,input-depth: Number of bits per color component at the input (8, 10 or
12).
- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
"yuv444".
- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
data driven on both edges).
The following input format properties are required except in "rgb 1x" and
"yuv444 1x" modes, in which case they must not be specified.
- adi,input-style: The input components arrangement variant (1, 2 or 3), as
listed in the input format tables in the datasheet.
- adi,input-justification: The input bit justification ("left", "evenly",
"right").
- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
on the chip.
- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
needed only for ADV7511.
The following properties are required for ADV7533 and ADV7535:
- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
be one of 1, 2, 3 or 4.
- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
Optional properties:
- interrupts: Specifier for the ADV7511 interrupt
- pd-gpios: Specifier for the GPIO connected to the power down signal
- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
(-1200 ps .. 1600 ps). Defaults to no delay.
- adi,embedded-sync: The input uses synchronization signals embedded in the
data stream (similar to BT.656). Defaults to separate H/V synchronization
signals.
- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
internal timing generator. The chip will rely on the sync signals in the
DSI data lanes, rather than generate its own timings for HDMI output.
- clocks: from common clock binding: reference to the CEC clock.
- clock-names: from common clock binding: must be "cec".
- reg-names : Names of maps with programmable addresses.
It can contain any map needing a non-default address.
Possible maps names are : "main", "edid", "cec", "packet"
Required nodes:
The ADV7511 has two video ports. Their connections are modelled using the OF
graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
remote endpoint phandle should be a reference to a valid mipi_dsi_host device
node.
- Video port 1 for the HDMI output
- Audio port 2 for the HDMI audio input
Example
-------
adv7511w: hdmi@39 {
compatible = "adi,adv7511w";
/*
* The EDID page will be accessible on address 0x66 on the I2C
* bus. All other maps continue to use their default addresses.
*/
reg = <0x39>, <0x66>;
reg-names = "main", "edid";
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <&cec_clock>;
clock-names = "cec";
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
adi,input-style = <1>;
adi,input-justification = "evenly";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7511w_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
port@2 {
reg = <2>;
codec_endpoint: endpoint {
remote-endpoint = <&i2s0_cpu_endpoint>;
};
};
};
};

240
Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml Normal file
View File

@ -0,0 +1,240 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADV7511/11W/13 HDMI Encoders
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description: |
The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
space conversion, S/PDIF, CEC and HDCP. The transmitter input is
parallel RGB or YUV data.
properties:
compatible:
enum:
- adi,adv7511
- adi,adv7511w
- adi,adv7513
reg:
description: |
I2C slave addresses.
The ADV7511/11W/13 internal registers are split into four pages
exposed through different I2C addresses, creating four register
maps. Each map has it own I2C address and acts as a standard slave
device on the I2C bus. The main address is mandatory, others are
optional and revert to defaults if not specified.
minItems: 1
maxItems: 4
reg-names:
description:
Names of maps with programmable addresses. It can contain any map
needing a non-default address.
minItems: 1
items:
- const: main
- const: edid
- const: cec
- const: packet
clocks:
description: Reference to the CEC clock.
maxItems: 1
clock-names:
const: cec
interrupts:
maxItems: 1
pd-gpios:
description: GPIO connected to the power down signal.
maxItems: 1
avdd-supply:
description: A 1.8V supply that powers up the AVDD pin.
dvdd-supply:
description: A 1.8V supply that powers up the DVDD pin.
pvdd-supply:
description: A 1.8V supply that powers up the PVDD pin.
dvdd-3v-supply:
description: A 3.3V supply that powers up the DVDD_3V pin.
bgvdd-supply:
description: A 1.8V supply that powers up the BGVDD pin.
adi,input-depth:
description: Number of bits per color component at the input.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 8, 10, 12 ]
adi,input-colorspace:
description: Input color space.
enum: [ rgb, yuv422, yuv444 ]
adi,input-clock:
description: |
Input clock type.
"1x": one clock cycle per pixel
"2x": two clock cycles per pixel
"dd": one clock cycle per pixel, data driven on both edges
enum: [ 1x, 2x, dd ]
adi,clock-delay:
description:
Video data clock delay relative to the pixel clock, in ps
(-1200ps .. 1600 ps).
$ref: /schemas/types.yaml#/definitions/uint32
default: 0
adi,embedded-sync:
description:
If defined, the input uses synchronization signals embedded in the
data stream (similar to BT.656).
type: boolean
adi,input-style:
description:
Input components arrangement variant as listed in the input
format tables in the datasheet.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 2, 3 ]
adi,input-justification:
description: Input bit justification.
enum: [ left, evenly, right ]
ports:
description:
The ADV7511(W)/13 has two video ports and one audio port. This node
models their connections as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
Documentation/devicetree/bindings/graph.txt
type: object
properties:
port@0:
description: Video port for the RGB or YUV input.
type: object
port@1:
description: Video port for the HDMI output.
type: object
port@2:
description: Audio port for the HDMI output.
type: object
# adi,input-colorspace and adi,input-clock are required except in
# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
# specified.
if:
not:
properties:
adi,input-colorspace:
contains:
enum: [ rgb, yuv444 ]
adi,input-clock:
contains:
const: 1x
then:
required:
- adi,input-style
- adi,input-justification
else:
properties:
adi,input-style: false
adi,input-justification: false
required:
- compatible
- reg
- ports
- adi,input-depth
- adi,input-colorspace
- adi,input-clock
- avdd-supply
- dvdd-supply
- pvdd-supply
- dvdd-3v-supply
- bgvdd-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c@e6500000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0xe6500000>;
adv7511w: hdmi@39 {
compatible = "adi,adv7511w";
/*
* The EDID page will be accessible on address 0x66 on the I2C
* bus. All other maps continue to use their default addresses.
*/
reg = <0x39>, <0x66>;
reg-names = "main", "edid";
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <&cec_clock>;
clock-names = "cec";
avdd-supply = <&v1v8>;
dvdd-supply = <&v1v8>;
pvdd-supply = <&v1v8>;
dvdd-3v-supply = <&v3v3>;
bgvdd-supply = <&v1v8>;
adi,input-depth = <8>;
adi,input-colorspace = "yuv422";
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "right";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7511w_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
port@2 {
reg = <2>;
codec_endpoint: endpoint {
remote-endpoint = <&i2s0_cpu_endpoint>;
};
};
};
};
};
...

184
Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml Normal file
View File

@ -0,0 +1,184 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADV7533/35 HDMI Encoders
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description: |
The ADV7533 and ADV7535 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They support color space
conversion, S/PDIF, CEC and HDCP. The transmitter input is MIPI DSI.
properties:
compatible:
enum:
- adi,adv7533
- adi,adv7535
reg:
description: |
I2C slave addresses.
The ADV7533/35 internal registers are split into four pages
exposed through different I2C addresses, creating four register
maps. Each map has it own I2C address and acts as a standard slave
device on the I2C bus. The main address is mandatory, others are
optional and revert to defaults if not specified.
minItems: 1
maxItems: 4
reg-names:
description:
Names of maps with programmable addresses. It can contain any map
needing a non-default address.
minItems: 1
items:
- const: main
- const: edid
- const: cec
- const: packet
clocks:
description: Reference to the CEC clock.
maxItems: 1
clock-names:
const: cec
interrupts:
maxItems: 1
pd-gpios:
description: GPIO connected to the power down signal.
maxItems: 1
avdd-supply:
description: A 1.8V supply that powers up the AVDD pin.
dvdd-supply:
description: A 1.8V supply that powers up the DVDD pin.
pvdd-supply:
description: A 1.8V supply that powers up the PVDD pin.
a2vdd-supply:
description: A 1.8V supply that powers up the A2VDD pin.
v3p3-supply:
description: A 3.3V supply that powers up the V3P3 pin.
v1p2-supply:
description:
A supply that powers up the V1P2 pin. It can be either 1.2V
or 1.8V for ADV7533 but only 1.8V for ADV7535.
adi,disable-timing-generator:
description:
Disables the internal timing generator. The chip will rely on the
sync signals in the DSI data lanes, rather than generating its own
timings for HDMI output.
type: boolean
adi,dsi-lanes:
description: Number of DSI data lanes connected to the DSI host.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 2, 3, 4 ]
ports:
description:
The ADV7533/35 has two video ports and one audio port. This node
models their connections as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
Documentation/devicetree/bindings/graph.txt
type: object
properties:
port@0:
description:
Video port for the DSI input. The remote endpoint phandle
should be a reference to a valid mipi_dsi_host_device.
type: object
port@1:
description: Video port for the HDMI output.
type: object
port@2:
description: Audio port for the HDMI output.
type: object
required:
- compatible
- reg
- ports
- adi,dsi-lanes
- avdd-supply
- dvdd-supply
- pvdd-supply
- a2vdd-supply
- v3p3-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c@e6500000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0xe6500000>;
adv7533: hdmi@39 {
compatible = "adi,adv7533";
/*
* The EDID page will be accessible on address 0x66 on the I2C
* bus. All other maps continue to use their default addresses.
*/
reg = <0x39>, <0x66>;
reg-names = "main", "edid";
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <&cec_clock>;
clock-names = "cec";
adi,dsi-lanes = <4>;
avdd-supply = <&v1v8>;
dvdd-supply = <&v1v8>;
pvdd-supply = <&v1v8>;
a2vdd-supply = <&v1v8>;
v3p3-supply = <&v3v3>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7533_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
port@1 {
reg = <1>;
adv7533_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
port@2 {
reg = <2>;
codec_endpoint: endpoint {
remote-endpoint = <&i2s0_cpu_endpoint>;
};
};
};
};
};
...

2
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
View File

@ -18,7 +18,6 @@ properties:
reg:
minItems: 1
maxItems: 3
items:
- description:
Register block of mhdptx apb registers up to PHY mapped area (AUX_CONFIG_P).
@ -31,7 +30,6 @@ properties:
reg-names:
minItems: 1
maxItems: 3
items:
- const: mhdptx
- const: j721e-intg

3
Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
View File

@ -29,7 +29,8 @@ properties:
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Primary MIPI port for MIPI input

46
Documentation/devicetree/bindings/display/panel/lvds.yaml
View File

@ -51,37 +51,37 @@ properties:
- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
[VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
specifications. Data are transferred as follows on 4 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
Data are transferred as follows on 4 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
Control signals are mapped as follows.

2
Documentation/devicetree/bindings/display/renesas,du.yaml
View File

@ -55,7 +55,7 @@ properties:
maxItems: 1
ports:
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/properties/ports
description: |
The connections to the DU output video ports are modeled using the OF
graph bindings specified in Documentation/devicetree/bindings/graph.txt.

2
Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
View File

@ -29,7 +29,6 @@ properties:
clocks:
minItems: 2
maxItems: 5
items:
- {}
- {}
@ -41,7 +40,6 @@ properties:
clock-names:
minItems: 2
maxItems: 5
items:
- {}
- {}

2
Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
View File

@ -29,7 +29,6 @@ properties:
- description: DSI bus clock
- description: Pixel clock
minItems: 2
maxItems: 3
clock-names:
items:
@ -37,7 +36,6 @@ properties:
- const: ref
- const: px_clk
minItems: 2
maxItems: 3
resets:
maxItems: 1

1
Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
View File

@ -22,7 +22,6 @@ properties:
- description: events interrupt line.
- description: errors interrupt line.
minItems: 1
maxItems: 2
clocks:
maxItems: 1

4
Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml
View File

@ -65,7 +65,6 @@ properties:
The APB clock and at least one video clock are mandatory, the audio clock
is optional.
minItems: 2
maxItems: 4
items:
- description: dp_apb_clk is the APB clock
- description: dp_aud_clk is the Audio clock
@ -78,13 +77,11 @@ properties:
clock-names:
oneOf:
- minItems: 2
maxItems: 3
items:
- const: dp_apb_clk
- enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
- enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
- minItems: 3
maxItems: 4
items:
- const: dp_apb_clk
- const: dp_aud_clk
@ -116,7 +113,6 @@ properties:
maxItems: 2
phy-names:
minItems: 1
maxItems: 2
items:
- const: dp-phy0
- const: dp-phy1

1
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
View File

@ -52,7 +52,6 @@ properties:
interrupt-names:
minItems: 9
maxItems: 17
items:
- const: error
- pattern: "^ch([0-9]|1[0-5])$"

4
Documentation/devicetree/bindings/dma/ti-edma.txt
View File

@ -33,7 +33,7 @@ The following are mandatory properties for 66AK2G SoCs only:
- power-domains:Should contain a phandle to a PM domain provider node
and an args specifier containing the device id
value. This property is as per the binding,
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
Optional properties:
-------------------
@ -70,7 +70,7 @@ The following are mandatory properties for 66AK2G SoCs only:
- power-domains:Should contain a phandle to a PM domain provider node
and an args specifier containing the device id
value. This property is as per the binding,
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
Optional properties:
-------------------

2
Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml
View File

@ -30,14 +30,12 @@ properties:
interrupts:
minItems: 1
maxItems: 2
items:
- description: uncorrectable error interrupt
- description: correctable error interrupt
interrupt-names:
minItems: 1
maxItems: 2
items:
- const: ue
- const: ce

1
Documentation/devicetree/bindings/eeprom/at24.yaml
View File

@ -32,7 +32,6 @@ properties:
oneOf:
- allOf:
- minItems: 1
maxItems: 2
items:
- pattern: "^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|lc|mac)[0-9]+|spd)$"
- pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$"

2
Documentation/devicetree/bindings/example-schema.yaml
View File

@ -91,7 +91,6 @@ properties:
interrupts:
# Either 1 or 2 interrupts can be present
minItems: 1
maxItems: 2
items:
- description: tx or combined interrupt
- description: rx interrupt
@ -105,7 +104,6 @@ properties:
interrupt-names:
# minItems must be specified here because the default would be 2
minItems: 1
maxItems: 2
items:
- const: tx irq
- const: rx irq

341
Documentation/devicetree/bindings/firmware/arm,scmi.yaml Normal file
View File

@ -0,0 +1,341 @@
# 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
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
arm,smc-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
SMC id required when using smc or hvc transports
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
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.
properties:
reg:
maxItems: 1
mbox-names:
items:
- const: tx
- const: rx
mboxes:
minItems: 1
maxItems: 2
shmem:
minItems: 1
maxItems: 2
required:
- reg
required:
- compatible
- shmem
if:
properties:
compatible:
contains:
const: arm,scmi
then:
properties:
interrupts: false
interrupt-names: false
required:
- mboxes
else:
if:
properties:
compatible:
contains:
const: arm,scmi-smc
then:
required:
- arm,smc-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>;
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>;
};
};
};
};
};
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>;
};
};
};
...

247
Documentation/devicetree/bindings/firmware/arm,scpi.yaml Normal file
View File

@ -0,0 +1,247 @@
# 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
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
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:
oneOf:
- const: arm,scpi-dvfs-clocks
- const: 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>;
};
};
};
...

19
Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
View File

@ -1,19 +0,0 @@
Xilinx Zynq FPGA Manager
Required properties:
- compatible: should contain "xlnx,zynq-devcfg-1.0"
- reg: base address and size for memory mapped io
- interrupts: interrupt for the FPGA manager device
- clocks: phandle for clocks required operation
- clock-names: name for the clock, should be "ref_clk"
- syscon: phandle for access to SLCR registers
Example:
devcfg: devcfg@f8007000 {
compatible = "xlnx,zynq-devcfg-1.0";
reg = <0xf8007000 0x100>;
interrupts = <0 8 4>;
clocks = <&clkc 12>;
clock-names = "ref_clk";
syscon = <&slcr>;
};

52
Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml Normal file
View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/fpga/xilinx-zynq-fpga-mgr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx Zynq FPGA Manager Device Tree Bindings
maintainers:
- Michal Simek <michal.simek@xilinx.com>
properties:
compatible:
const: xlnx,zynq-devcfg-1.0
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
items:
- const: ref_clk
syscon:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to syscon block which provide access to SLCR registers
required:
- compatible
- reg
- clocks
- clock-names
- syscon
additionalProperties: false
examples:
- |
devcfg: devcfg@f8007000 {
compatible = "xlnx,zynq-devcfg-1.0";
reg = <0xf8007000 0x100>;
interrupts = <0 8 4>;
clocks = <&clkc 12>;
clock-names = "ref_clk";
syscon = <&slcr>;
};

2
Documentation/devicetree/bindings/gpio/gpio-davinci.txt
View File

@ -32,7 +32,7 @@ Required Properties:
Documentation/devicetree/bindings/clock/keystone-gate.txt
for 66AK2HK/66AK2L/66AK2E SoCs or,
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
for 66AK2G SoCs
- clock-names: Name should be "gpio";

1
Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
View File

@ -34,7 +34,6 @@ properties:
- enum: [ bridge, gca ]
- enum: [ bridge, gca ]
minItems: 2
maxItems: 4
interrupts:
items:

1
Documentation/devicetree/bindings/gpu/vivante,gc.yaml
View File

@ -36,7 +36,6 @@ properties:
- description: AHB/slave interface clock (only required if GPU can gate
slave interface independently)
minItems: 1
maxItems: 4
clock-names:
items:

74
Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml Normal file
View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/aspeed,i2c.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ASPEED I2C on the AST24XX, AST25XX, and AST26XX SoCs Device Tree Bindings
maintainers:
- Rayn Chen <rayn_chen@aspeedtech.com>
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
enum:
- aspeed,ast2400-i2c-bus
- aspeed,ast2500-i2c-bus
- aspeed,ast2600-i2c-bus
reg:
minItems: 1
items:
- description: address offset and range of bus
- description: address offset and range of bus buffer
interrupts:
maxItems: 1
clocks:
maxItems: 1
description:
root clock of bus, should reference the APB
clock in the second cell
resets:
maxItems: 1
bus-frequency:
minimum: 500
maximum: 4000000
default: 100000
description: frequency of the bus clock in Hz defaults to 100 kHz when not
specified
multi-master:
type: boolean
description:
states that there is another master active on this bus
required:
- reg
- compatible
- clocks
- resets
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/aspeed-clock.h>
i2c0: i2c-bus@40 {
#address-cells = <1>;
#size-cells = <0>;
#interrupt-cells = <1>;
compatible = "aspeed,ast2500-i2c-bus";
reg = <0x40 0x40>;
clocks = <&syscon ASPEED_CLK_APB>;
resets = <&syscon ASPEED_RESET_I2C>;
bus-frequency = <100000>;
interrupts = <0>;
interrupt-parent = <&i2c_ic>;
};

1
Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml
View File

@ -21,7 +21,6 @@ properties:
reg:
minItems: 1
maxItems: 2
items:
- description: BSC register range
- description: Auto-I2C register range

49
Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
View File

@ -1,49 +0,0 @@
Device tree configuration for the I2C busses on the AST24XX, AST25XX, and AST26XX SoCs.
Required Properties:
- #address-cells : should be 1
- #size-cells : should be 0
- reg : address offset and range of bus
- compatible : should be "aspeed,ast2400-i2c-bus"
or "aspeed,ast2500-i2c-bus"
or "aspeed,ast2600-i2c-bus"
- clocks : root clock of bus, should reference the APB
clock in the second cell
- resets : phandle to reset controller with the reset number in
the second cell
- interrupts : interrupt number
Optional Properties:
- bus-frequency : frequency of the bus clock in Hz defaults to 100 kHz when not
specified
- multi-master : states that there is another master active on this bus.
Example:
i2c {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1e78a000 0x1000>;
i2c_ic: interrupt-controller@0 {
#interrupt-cells = <1>;
compatible = "aspeed,ast2400-i2c-ic";
reg = <0x0 0x40>;
interrupts = <12>;
interrupt-controller;
};
i2c0: i2c-bus@40 {
#address-cells = <1>;
#size-cells = <0>;
#interrupt-cells = <1>;
reg = <0x40 0x40>;
compatible = "aspeed,ast2400-i2c-bus";
clocks = <&syscon ASPEED_CLK_APB>;
resets = <&syscon ASPEED_RESET_I2C>;
bus-frequency = <100000>;
interrupts = <0>;
interrupt-parent = <&i2c_ic>;
};
};

4
Documentation/devicetree/bindings/i2c/i2c-davinci.txt
View File

@ -8,7 +8,7 @@ Required properties:
- reg : Offset and length of the register set for the device
- clocks: I2C functional clock phandle.
For 66AK2G this property should be set per binding,
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
SoC-specific Required Properties:
@ -17,7 +17,7 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only:
- power-domains: Should contain a phandle to a PM domain provider node
and an args specifier containing the I2C device id
value. This property is as per the binding,
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
Recommended properties :
- interrupts : standard interrupt property.

2
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
View File

@ -27,7 +27,7 @@ Required properties:
- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
parents.
Furthermore, I2C mux properties and child nodes. See i2c-mux.txt in this
Furthermore, I2C mux properties and child nodes. See i2c-mux.yaml in this
directory.
Example:

4
Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
View File

@ -22,8 +22,8 @@ Required properties:
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
- mux-gpios: list of gpios used to control the muxer
* Standard I2C mux properties. See i2c-mux.txt in this directory.
* I2C child bus nodes. See i2c-mux.txt in this directory.
* Standard I2C mux properties. See i2c-mux.yaml in this directory.
* I2C child bus nodes. See i2c-mux.yaml in this directory.
Optional properties:
- idle-state: value to set the muxer to when idle. When no value is

99
Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
View File

@ -1,99 +0,0 @@
General Purpose I2C Bus Mux
This binding describes an I2C bus multiplexer that uses a mux controller
from the mux subsystem to route the I2C signals.
.-----. .-----.
| dev | | dev |
.------------. '-----' '-----'
| SoC | | |
| | .--------+--------'
| .------. | .------+ child bus A, on MUX value set to 0
| | I2C |-|--| Mux |
| '------' | '--+---+ child bus B, on MUX value set to 1
| .------. | | '----------+--------+--------.
| | MUX- | | | | | |
| | Ctrl |-|-----+ .-----. .-----. .-----.
| '------' | | dev | | dev | | dev |
'------------' '-----' '-----' '-----'
Required properties:
- compatible: i2c-mux
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
- mux-controls: The phandle of the mux controller to use for operating the
mux.
* Standard I2C mux properties. See i2c-mux.txt in this directory.
* I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number
is also the mux-controller state described in ../mux/mux-controller.txt
Optional properties:
- mux-locked: If present, explicitly allow unrelated I2C transactions on the
parent I2C adapter at these times:
+ during setup of the multiplexer
+ between setup of the multiplexer and the child bus I2C transaction
+ between the child bus I2C transaction and releasing of the multiplexer
+ during releasing of the multiplexer
However, I2C transactions to devices behind all I2C multiplexers connected
to the same parent adapter that this multiplexer is connected to are blocked
for the full duration of the complete multiplexed I2C transaction (i.e.
including the times covered by the above list).
If mux-locked is not present, the multiplexer is assumed to be parent-locked.
This means that no unrelated I2C transactions are allowed on the parent I2C
adapter for the complete multiplexed I2C transaction.
The properties of mux-locked and parent-locked multiplexers are discussed
in more detail in Documentation/i2c/i2c-topology.rst.
For each i2c child node, an I2C child bus will be created. They will
be numbered based on their order in the device tree.
Whenever an access is made to a device on a child bus, the value set
in the relevant node's reg property will be set as the state in the
mux controller.
Example:
mux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>;
};
i2c-mux {
compatible = "i2c-mux";
mux-locked;
i2c-parent = <&i2c1>;
mux-controls = <&mux>;
#address-cells = <1>;
#size-cells = <0>;
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
ssd1307: oled@3c {
compatible = "solomon,ssd1307fb-i2c";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7 1>;
reset-active-low;
};
};
i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
pca9555: pca9555@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
};

124
Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml Normal file
View File

@ -0,0 +1,124 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mux-gpmux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: General Purpose I2C Bus Mux
maintainers:
- Peter Rosin <peda@axentia.se>
description: |+
This binding describes an I2C bus multiplexer that uses a mux controller
from the mux subsystem to route the I2C signals.
.-----. .-----.
| dev | | dev |
.------------. '-----' '-----'
| SoC | | |
| | .--------+--------'
| .------. | .------+ child bus A, on MUX value set to 0
| | I2C |-|--| Mux |
| '------' | '--+---+ child bus B, on MUX value set to 1
| .------. | | '----------+--------+--------.
| | MUX- | | | | | |
| | Ctrl |-|-----+ .-----. .-----. .-----.
| '------' | | dev | | dev | | dev |
'------------' '-----' '-----' '-----'
allOf:
- $ref: /schemas/i2c/i2c-mux.yaml#
properties:
compatible:
const: i2c-mux
i2c-parent:
$ref: /schemas/types.yaml#/definitions/phandle
description:
The phandle of the I2C bus that this multiplexer's master-side port is
connected to.
mux-controls:
maxItems: 1
description:
The mux-controller states are the I2C sub-bus numbers.
mux-locked:
type: boolean
description: |
Explicitly allow unrelated I2C transactions on the parent I2C adapter at
these times:
- during setup of the multiplexer
- between setup of the multiplexer and the child bus I2C transaction
- between the child bus I2C transaction and releasing of the multiplexer
- during releasing of the multiplexer
However, I2C transactions to devices behind all I2C multiplexers connected
to the same parent adapter that this multiplexer is connected to are blocked
for the full duration of the complete multiplexed I2C transaction (i.e.
including the times covered by the above list).
If mux-locked is not present, the multiplexer is assumed to be parent-locked.
This means that no unrelated I2C transactions are allowed on the parent I2C
adapter for the complete multiplexed I2C transaction.
The properties of mux-locked and parent-locked multiplexers are discussed
in more detail in Documentation/i2c/i2c-topology.rst.
required:
- compatible
- i2c-parent
- mux-controls
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
mux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>;
};
i2c-mux {
compatible = "i2c-mux";
mux-locked;
i2c-parent = <&i2c1>;
mux-controls = <&mux>;
#address-cells = <1>;
#size-cells = <0>;
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
gpio@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
gpio@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
};
...

4
Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
View File

@ -8,8 +8,8 @@ Required Properties:
The following required properties are defined externally:
- Standard I2C mux properties. See i2c-mux.txt in this directory.
- I2C child bus nodes. See i2c-mux.txt in this directory.
- Standard I2C mux properties. See i2c-mux.yaml in this directory.
- I2C child bus nodes. See i2c-mux.yaml in this directory.
Optional Properties:

74
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
View File

@ -1,74 +0,0 @@
* NXP PCA954x I2C bus switch
The driver supports NXP PCA954x and PCA984x I2C mux/switch devices.
Required Properties:
- compatible: Must contain one of the following.
"nxp,pca9540",
"nxp,pca9542",
"nxp,pca9543",
"nxp,pca9544",
"nxp,pca9545",
"nxp,pca9546", "nxp,pca9846",
"nxp,pca9547", "nxp,pca9847",
"nxp,pca9548", "nxp,pca9848",
"nxp,pca9849"
- reg: The I2C address of the device.
The following required properties are defined externally:
- Standard I2C mux properties. See i2c-mux.txt in this directory.
- I2C child bus nodes. See i2c-mux.txt in this directory.
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the reset input.
- idle-state: if present, overrides i2c-mux-idle-disconnect,
Please refer to Documentation/devicetree/bindings/mux/mux-controller.txt
- i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
children in idle state. This is necessary for example, if there are several
multiplexers on the bus and the devices behind them use same I2C addresses.
- interrupts: Interrupt mapping for IRQ.
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be two.
- first cell is the pin number
- second cell is used to specify flags.
See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Example:
i2c-switch@74 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <2>;
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
eeprom@54 {
compatible = "atmel,24c08";
reg = <0x54>;
};
};
i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
};
};
};

110
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml Normal file
View File

@ -0,0 +1,110 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP PCA954x I2C bus switch
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description:
The binding supports NXP PCA954x and PCA984x I2C mux/switch devices.
allOf:
- $ref: /schemas/i2c/i2c-mux.yaml#
properties:
compatible:
oneOf:
- enum:
- nxp,pca9540
- nxp,pca9542
- nxp,pca9543
- nxp,pca9544
- nxp,pca9545
- nxp,pca9546
- nxp,pca9547
- nxp,pca9548
- nxp,pca9846
- nxp,pca9847
- nxp,pca9848
- nxp,pca9849
- items:
- const: nxp,pca9646
- const: nxp,pca9546
reg:
maxItems: 1
interrupts:
maxItems: 1
"#interrupt-cells":
const: 2
interrupt-controller: true
reset-gpios:
maxItems: 1
i2c-mux-idle-disconnect:
type: boolean
description: Forces mux to disconnect all children in idle state. This is
necessary for example, if there are several multiplexers on the bus and
the devices behind them use same I2C addresses.
idle-state:
description: if present, overrides i2c-mux-idle-disconnect
$ref: /schemas/mux/mux-controller.yaml#/properties/idle-state
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
i2c-mux@74 {
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
interrupt-parent = <&ipic>;
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <2>;
i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
eeprom@54 {
compatible = "atmel,24c08";
reg = <0x54>;
};
};
i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
};
};
};
};
...

4
Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt
View File

@ -28,9 +28,9 @@ Also required are:
* Standard pinctrl properties that specify the pin mux state for each child
bus. See ../pinctrl/pinctrl-bindings.txt.
* Standard I2C mux properties. See i2c-mux.txt in this directory.
* Standard I2C mux properties. See i2c-mux.yaml in this directory.
* I2C child bus nodes. See i2c-mux.txt in this directory.
* I2C child bus nodes. See i2c-mux.yaml in this directory.
For each named state defined in the pinctrl-names property, an I2C child bus
will be created. I2C child bus numbers are assigned based on the index into

4
Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt
View File

@ -7,8 +7,8 @@ Required properties:
- compatible: i2c-mux-reg
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
* Standard I2C mux properties. See i2c-mux.txt in this directory.
* I2C child bus nodes. See i2c-mux.txt in this directory.
* Standard I2C mux properties. See i2c-mux.yaml in this directory.
* I2C child bus nodes. See i2c-mux.yaml in this directory.
Optional properties:
- reg: this pair of <offset size> specifies the register to control the mux.

73
Documentation/devicetree/bindings/i2c/i2c-mux.txt
View File

@ -1,73 +0,0 @@
Common i2c bus multiplexer/switch properties.
An i2c bus multiplexer/switch will have several child busses that are
numbered uniquely in a device dependent manner. The nodes for an i2c bus
multiplexer/switch will have one child node for each child bus.
Optional properties:
- #address-cells = <1>;
This property is required if the i2c-mux child node does not exist.
- #size-cells = <0>;
This property is required if the i2c-mux child node does not exist.
- i2c-mux
For i2c multiplexers/switches that have child nodes that are a mixture
of both i2c child busses and other child nodes, the 'i2c-mux' subnode
can be used for populating the i2c child busses. If an 'i2c-mux'
subnode is present, only subnodes of this will be considered as i2c
child busses.
Required properties for the i2c-mux child node:
- #address-cells = <1>;
- #size-cells = <0>;
Required properties for i2c child bus nodes:
- #address-cells = <1>;
- #size-cells = <0>;
- reg : The sub-bus number.
Optional properties for i2c child bus nodes:
- Other properties specific to the multiplexer/switch hardware.
- Child nodes conforming to i2c bus binding
Example :
/*
An NXP pca9548 8 channel I2C multiplexer at address 0x70
with two NXP pca8574 GPIO expanders attached, one each to
ports 3 and 4.
*/
mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
#address-cells = <1>;
#size-cells = <0>;
i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
gpio1: gpio@38 {
compatible = "nxp,pca8574";
reg = <0x38>;
#gpio-cells = <2>;
gpio-controller;
};
};
i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
gpio2: gpio@38 {
compatible = "nxp,pca8574";
reg = <0x38>;
#gpio-cells = <2>;
gpio-controller;
};
};
};

87
Documentation/devicetree/bindings/i2c/i2c-mux.yaml Normal file
View File

@ -0,0 +1,87 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/i2c/i2c-mux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common i2c bus multiplexer/switch properties.
maintainers:
- Peter Rosin <peda@axentia.se>
description: |+
An i2c bus multiplexer/switch will have several child busses that are numbered
uniquely in a device dependent manner. The nodes for an i2c bus
multiplexer/switch will have one child node for each child bus.
For i2c multiplexers/switches that have child nodes that are a mixture of both
i2c child busses and other child nodes, the 'i2c-mux' subnode can be used for
populating the i2c child busses. If an 'i2c-mux' subnode is present, only
subnodes of this will be considered as i2c child busses.
properties:
$nodename:
pattern: '^(i2c-?)?mux'
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
'^i2c@[0-9a-f]+$':
$ref: /schemas/i2c/i2c-controller.yaml
unevaluatedProperties: false
properties:
reg:
description: The mux selector sub-bus number for the child I2C bus.
maxItems: 1
additionalProperties: true
examples:
- |
/*
* An NXP pca9548 8 channel I2C multiplexer at address 0x70
* with two NXP pca8574 GPIO expanders attached, one each to
* ports 3 and 4.
*/
i2c {
#address-cells = <1>;
#size-cells = <0>;
i2c-mux@70 {
compatible = "nxp,pca9548";
reg = <0x70>;
#address-cells = <1>;
#size-cells = <0>;
i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
gpio@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
gpio@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
};
};
...

2
Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
View File

@ -43,14 +43,12 @@ properties:
clocks:
minItems: 1
maxItems: 2
items:
- description: Reference clock for the I2C bus
- description: Bus clock (Only for Armada 7K/8K)
clock-names:
minItems: 1
maxItems: 2
items:
- const: core
- const: reg

1
Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml
View File

@ -20,7 +20,6 @@ properties:
reg:
minItems: 3
maxItems: 4
items:
- description: Smbus block registers
- description: Cause master registers

1
Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml
View File

@ -41,7 +41,6 @@ properties:
clock-names:
minItems: 2
maxItems: 4
items:
- const: clkin
- const: core

2
Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
View File

@ -38,14 +38,12 @@ properties:
dfsdm clock can also feed CLKOUT, when CLKOUT is used.
- description: audio clock can be used as an alternate to feed CLKOUT.
minItems: 1
maxItems: 2
clock-names:
items:
- const: dfsdm
- const: audio
minItems: 1
maxItems: 2
"#address-cells":
const: 1

39
Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
View File

@ -1,39 +0,0 @@
I/O channel multiplexer bindings
If a multiplexer is used to select which hardware signal is fed to
e.g. an ADC channel, these bindings describe that situation.
Required properties:
- compatible : "io-channel-mux"
- io-channels : Channel node of the parent channel that has multiplexed
input.
- io-channel-names : Should be "parent".
- #address-cells = <1>;
- #size-cells = <0>;
- mux-controls : Mux controller node to use for operating the mux
- channels : List of strings, labeling the mux controller states.
For each non-empty string in the channels property, an io-channel will
be created. The number of this io-channel is the same as the index into
the list of strings in the channels property, and also matches the mux
controller state. The mux controller state is described in
../mux/mux-controller.txt
Example:
mux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>;
};
adc-mux {
compatible = "io-channel-mux";
io-channels = <&adc 0>;
io-channel-names = "parent";
mux-controls = <&mux>;
channels = "sync", "in", "system-regulator";
};

70
Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml Normal file
View File

@ -0,0 +1,70 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/multiplexer/io-channel-mux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: I/O channel multiplexer bindings
maintainers:
- Peter Rosin <peda@axentia.se>
description: |
If a multiplexer is used to select which hardware signal is fed to
e.g. an ADC channel, these bindings describe that situation.
For each non-empty string in the channels property, an io-channel will be
created. The number of this io-channel is the same as the index into the list
of strings in the channels property, and also matches the mux controller
state. The mux controller state is described in
Documentation/devicetree/bindings/mux/mux-controller.yaml
properties:
compatible:
const: io-channel-mux
io-channels:
maxItems: 1
description: Channel node of the parent channel that has multiplexed input.
io-channel-names:
const: parent
mux-controls: true
mux-control-names: true
channels:
$ref: /schemas/types.yaml#/definitions/string-array
description:
List of strings, labeling the mux controller states.
required:
- compatible
- io-channels
- io-channel-names
- mux-controls
- channels
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
mux: mux-controller {
compatible = "gpio-mux";
#mux-control-cells = <0>;
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>;
};
adc-mux {
compatible = "io-channel-mux";
io-channels = <&adc 0>;
io-channel-names = "parent";
mux-controls = <&mux>;
channels = "sync", "in", "system-regulator";
};
...

41
Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt
View File

@ -1,41 +0,0 @@
* ARM Vectored Interrupt Controller
One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM
system for interrupt routing. For multiple controllers they can either be
nested or have the outputs wire-OR'd together.
Required properties:
- compatible : should be one of
"arm,pl190-vic"
"arm,pl192-vic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as
the VIC has no configuration options for interrupt sources. The cell is a u32
and defines the interrupt number.
- reg : The register bank for the VIC.
Optional properties:
- interrupts : Interrupt source for parent controllers if the VIC is nested.
- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit
represents single interrupt source, starting from source 0 at LSb and ending
at source 31 at MSb. A bit that is set means that the source is wired and
clear means otherwise. If unspecified, defaults to all valid.
- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be
configured as wake up source for the system. Order of bits is the same as for
valid-mask property. A set bit means that this interrupt source can be
configured as a wake up source for the system. If unspecied, defaults to all
interrupt sources configurable as wake up sources.
Example:
vic0: interrupt-controller@60000 {
compatible = "arm,pl192-vic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x60000 0x1000>;
valid-mask = <0xffffff7f>;
valid-wakeup-mask = <0x0000ff7f>;
};

81
Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml Normal file
View File

@ -0,0 +1,81 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/arm,vic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Vectored Interrupt Controller
maintainers:
- Rob Herring <robh@kernel.org>
description: |+
One or more Vectored Interrupt Controllers (VIC's) can be connected in an
ARM system for interrupt routing. For multiple controllers they can either
be nested or have the outputs wire-OR'd together.
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
enum:
- arm,pl190-vic
- arm,pl192-vic
- arm,versatile-vic
interrupt-controller: true
"#interrupt-cells":
const: 1
description:
The number of cells to define the interrupts. It must be 1 as the
VIC has no configuration options for interrupt sources. The single
cell defines the interrupt number.
reg:
maxItems: 1
interrupts:
maxItems: 1
valid-mask:
description:
A one cell big bit mask of valid interrupt sources. Each bit
represents single interrupt source, starting from source 0 at
LSb and ending at source 31 at MSb. A bit that is set means
that the source is wired and clear means otherwise. If unspecified,
defaults to all valid.
$ref: /schemas/types.yaml#/definitions/uint32
valid-wakeup-mask:
description:
A one cell big bit mask of interrupt sources that can be configured
as wake up source for the system. Order of bits is the same as for
valid-mask property. A set bit means that this interrupt source
can be configured as a wake up source for the system. If unspecied,
defaults to all interrupt sources configurable as wake up sources.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible
- reg
- interrupt-controller
- "#interrupt-cells"
additionalProperties: false
examples:
- |
// PL192 VIC
vic0: interrupt-controller@60000 {
compatible = "arm,pl192-vic";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x60000 0x1000>;
valid-mask = <0xffffff7f>;
valid-wakeup-mask = <0x0000ff7f>;
};
...

1
Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
View File

@ -35,7 +35,6 @@ properties:
- description: output interrupt 6
- description: output interrupt 7
minItems: 1
maxItems: 8
clocks:
maxItems: 1

1
Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
View File

@ -50,7 +50,6 @@ properties:
- const: int2
- const: int3
minItems: 1
maxItems: 4
'#interrupt-cells':
const: 2

2
Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml
View File

@ -134,7 +134,7 @@ examples:
/* AM4376 PRU-ICSS */
#include <dt-bindings/interrupt-controller/arm-gic.h>
pruss@0 {
compatible = "ti,am4376-pruss";
compatible = "ti,am4376-pruss1";
reg = <0x0 0x40000>;
#address-cells = <1>;
#size-cells = <1>;

1
Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
View File

@ -38,7 +38,6 @@ properties:
If provided, then the combined interrupt will be used in preference to
any others.
- minItems: 2
maxItems: 4
items:
- const: eventq # Event Queue not empty
- const: gerror # Global Error activated

1
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml
View File

@ -49,7 +49,6 @@ properties:
interrupts:
minItems: 1
maxItems: 2
description:
Specifiers for the MMU fault interrupts. Not required for cache IPMMUs.
items:

48
Documentation/devicetree/bindings/mailbox/arm,mhu.yaml
View File

@ -101,11 +101,19 @@ examples:
clocks = <&clock 0 2 1>;
clock-names = "apb_pclk";
};
};
mhu_client_scb: scb@2e000000 {
compatible = "fujitsu,mb86s70-scb-1.0";
reg = <0 0x2e000000 0 0x4000>;
firmware {
scpi {
compatible = "arm,scpi";
mboxes = <&mhuA 1>; /* HP-NonSecure */
shmem = <&cpu_scp_hpri>; /* HP-NonSecure */
scpi_devpd: power-controller {
compatible = "arm,scpi-power-domains";
num-domains = <2>;
#power-domain-cells = <1>;
};
};
};
@ -125,10 +133,36 @@ examples:
clocks = <&clock 0 2 1>;
clock-names = "apb_pclk";
};
};
mhu_client_scpi: scpi@2f000000 {
compatible = "arm,scpi";
reg = <0 0x2f000000 0 0x200>;
mboxes = <&mhuB 1 4>; /* HP-NonSecure, 5th doorbell */
firmware {
scmi {
compatible = "arm,scmi";
mboxes = <&mhuB 0 0>, /* LP-NonSecure, 1st doorbell */
<&mhuB 0 1>; /* LP-NonSecure, 2nd doorbell */
mbox-names = "tx", "rx";
shmem = <&cpu_scp_lpri0>,
<&cpu_scp_lpri1>;
#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>;
mboxes = <&mhuB 1 2>, /* HP-NonSecure, 3rd doorbell */
<&mhuB 1 3>; /* HP-NonSecure, 4th doorbell */
mbox-names = "tx", "rx";
shmem = <&cpu_scp_hpri0>,
<&cpu_scp_hpri1>;
};
};
};
...

25
Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
View File

@ -192,18 +192,17 @@ examples:
arm,mhuv2-protocols = <1 1>, <1 7>, <0 2>;
};
mhu_client: scb@2e000000 {
compatible = "fujitsu,mb86s70-scb-1.0";
reg = <0 0x2e000000 0 0x4000>;
mboxes =
//data-transfer protocol with 5 windows, mhu-tx
<&mhu_tx 2 0>,
//data-transfer protocol with 7 windows, mhu-tx
<&mhu_tx 3 0>,
//doorbell protocol channel 4, doorbell 27, mhu-tx
<&mhu_tx 4 27>,
//data-transfer protocol with 1 window, mhu-rx
<&mhu_rx 0 0>;
mhu_client: dsp@596e8000 {
compatible = "fsl,imx8qxp-dsp";
reg = <0 0x596e8000 0 0x88000>;
clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>;
clock-names = "ipg", "ocram", "core";
power-domains = <&pd 0>, <&pd 1>, <&pd 2>, <&pd 3>;
mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx
<&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx
<&mhu_rx 2 27>, //doorbell protocol channel 2, doorbell 27, mhu-rx
<&mhu_rx 0 0>; //data-transfer protocol with 1 window, mhu-rx
memory-region = <&dsp_reserved>;
};
};

184
Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
View File

@ -1,184 +0,0 @@
OMAP2+ and K3 Mailbox
=====================
The OMAP mailbox hardware facilitates communication between different processors
using a queued mailbox interrupt mechanism. The IP block is external to the
various processor subsystems and is connected on an interconnect bus. The
communication is achieved through a set of registers for message storage and
interrupt configuration registers.
Each mailbox IP block/cluster has a certain number of h/w fifo queues and output
interrupt lines. An output interrupt line is routed to an interrupt controller
within a processor subsystem, and there can be more than one line going to a
specific processor's interrupt controller. The interrupt line connections are
fixed for an instance and are dictated by the IP integration into the SoC
(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is
programmable through a set of interrupt configuration registers, and have a rx
and tx interrupt source per h/w fifo. Communication between different processors
is achieved through the appropriate programming of the rx and tx interrupt
sources on the appropriate interrupt lines.
The number of h/w fifo queues and interrupt lines dictate the usable registers.
All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP
instance. DRA7xx has multiple instances with different number of h/w fifo queues
and interrupt lines between different instances. The interrupt lines can also be
routed to different processor sub-systems on DRA7xx as they are routed through
the Crossbar, a kind of interrupt router/multiplexer. The K3 AM65x and J721E
SoCs has each of these instances form a cluster and combine multiple clusters
into a single IP block present within the Main NavSS. The interrupt lines from
all these clusters are multiplexed and routed to different processor subsystems
over a limited number of common interrupt output lines of an Interrupt Router.
The AM64x SoCS also uses a single IP block comprising of multiple clusters,
but the number of clusters are smaller, and the interrupt output lines are
connected directly to various processors.
Mailbox Device Node:
====================
A Mailbox device node is used to represent a Mailbox IP instance/cluster within
a SoC. The sub-mailboxes are represented as child nodes of this parent node.
Required properties:
--------------------
- compatible: Should be one of the following,
"ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs
"ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs
"ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx,
AM43xx and DRA7xx SoCs
"ti,am654-mailbox" for K3 AM65x and J721E SoCs
"ti,am64-mailbox" for K3 AM64x SoCs
- reg: Contains the mailbox register address range (base
address and length)
- interrupts: Contains the interrupt information for the mailbox
device. The format is dependent on which interrupt
controller the Mailbox device uses
- #mbox-cells: Common mailbox binding property to identify the number
of cells required for the mailbox specifier. Should be
1
- ti,mbox-num-users: Number of targets (processor devices) that the mailbox
device can interrupt
- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block
SoC-specific Required properties:
---------------------------------
The following are mandatory properties for the OMAP architecture based SoCs
only:
- ti,hwmods: Name of the hwmod associated with the mailbox. This
should be defined in the mailbox node only if the node
is not defined as a child node of a corresponding sysc
interconnect node.
The following are mandatory properties for the K3 AM65x and J721E SoCs only:
- interrupt-parent: Should contain a phandle to the TI-SCI interrupt
controller node that is used to dynamically program
the interrupt routes between the IP and the main GIC
controllers. See the following binding for additional
details,
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
Child Nodes:
============
A child node is used for representing the actual sub-mailbox device that is
used for the communication between the host processor and a remote processor.
Each child node should have a unique node name across all the different
mailbox device nodes.
Required properties:
--------------------
- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo
- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo
Sub-mailbox Descriptor Data
---------------------------
Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of
data that represent the following:
Cell #1 (fifo_id) - mailbox fifo id used either for transmitting
(ti,mbox-tx) or for receiving (ti,mbox-rx)
Cell #2 (irq_id) - irq identifier index number to use from the parent's
interrupts data. Should be 0 for most of the cases, a
positive index value is seen only on mailboxes that have
multiple interrupt lines connected to the MPU processor.
Cell #3 (usr_id) - mailbox user id for identifying the interrupt line
associated with generating a tx/rx fifo interrupt.
Optional Properties:
--------------------
- ti,mbox-send-noirq: Quirk flag to allow the client user of this sub-mailbox
to send messages without triggering a Tx ready interrupt,
and to control the Tx ticker. Should be used only on
sub-mailboxes used to communicate with WkupM3 remote
processor on AM33xx/AM43xx SoCs.
Mailbox Users:
==============
A device needing to communicate with a target processor device should specify
them using the common mailbox binding properties, "mboxes" and the optional
"mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt
for details). 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. The equivalent
"mbox-names" property value can be used to give a name to the communication channel
to be used by the client user.
Example:
--------
1. /* OMAP4 */
mailbox: mailbox@4a0f4000 {
compatible = "ti,omap4-mailbox";
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "mailbox";
#mbox-cells = <1>;
ti,mbox-num-users = <3>;
ti,mbox-num-fifos = <8>;
mbox_ipu: mbox_ipu {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
};
mbox_dsp: mbox_dsp {
ti,mbox-tx = <3 0 0>;
ti,mbox-rx = <2 0 0>;
};
};
dsp {
...
mboxes = <&mailbox &mbox_dsp>;
...
};
2. /* AM33xx */
mailbox: mailbox@480c8000 {
compatible = "ti,omap4-mailbox";
reg = <0x480C8000 0x200>;
interrupts = <77>;
ti,hwmods = "mailbox";
#mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <8>;
mbox_wkupm3: wkup_m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
};
};
3. /* AM65x */
&cbass_main {
cbass_main_navss: interconnect0 {
mailbox0_cluster0: mailbox@31f80000 {
compatible = "ti,am654-mailbox";
reg = <0x00 0x31f80000 0x00 0x200>;
#mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <16>;
interrupt-parent = <&intr_main_navss>;
interrupts = <164 0>;
mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 {
ti,mbox-tx = <1 0 0>;
ti,mbox-rx = <0 0 0>;
};
};
};
};

2
Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml
View File

@ -32,7 +32,6 @@ properties:
- description: tx channel free
- description: wakeup source
minItems: 2
maxItems: 3
interrupt-names:
items:
@ -40,7 +39,6 @@ properties:
- const: tx
- const: wakeup
minItems: 2
maxItems: 3
wakeup-source: true

308
Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml Normal file
View File

@ -0,0 +1,308 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI OMAP2+ and K3 Mailbox devices
maintainers:
- Suman Anna <s-anna@ti.com>
description: |
The OMAP Mailbox hardware facilitates communication between different
processors using a queued mailbox interrupt mechanism. The IP block is
external to the various processor subsystems and is connected on an
interconnect bus. The communication is achieved through a set of registers
for message storage and interrupt configuration registers.
Each mailbox IP block/cluster has a certain number of h/w fifo queues and
output interrupt lines. An output interrupt line is routed to an interrupt
controller within a processor subsystem, and there can be more than one line
going to a specific processor's interrupt controller. The interrupt line
connections are fixed for an instance and are dictated by the IP integration
into the SoC (excluding the SoCs that have an Interrupt Crossbar or an
Interrupt Router IP). Each interrupt line is programmable through a set of
interrupt configuration registers, and have a rx and tx interrupt source per
h/w fifo. Communication between different processors is achieved through the
appropriate programming of the rx and tx interrupt sources on the appropriate
interrupt lines.
The number of h/w fifo queues and interrupt lines dictate the usable
registers. All the current OMAP SoCs except for the newest DRA7xx SoC has a
single IP instance. DRA7xx has multiple instances with different number of
h/w fifo queues and interrupt lines between different instances. The interrupt
lines can also be routed to different processor sub-systems on DRA7xx as they
are routed through the Crossbar, a kind of interrupt router/multiplexer. The
K3 AM65x, J721E and J7200 SoCs has each of these instances form a cluster and
combine multiple clusters into a single IP block present within the Main
NavSS. The interrupt lines from all these clusters are multiplexed and routed
to different processor subsystems over a limited number of common interrupt
output lines of an Interrupt Router. The AM64x SoCS also uses a single IP
block comprising of multiple clusters, but the number of clusters are
smaller, and the interrupt output lines are connected directly to various
processors.
Mailbox Controller Nodes
=========================
A Mailbox device node is used to represent a Mailbox IP instance/cluster
within a SoC. The sub-mailboxes (actual communication channels) are
represented as child nodes of this parent node.
Mailbox Users
==============
A device needing to communicate with a target processor device should specify
them using the common mailbox binding properties, "mboxes" and the optional
"mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt
for details). 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.
The equivalent "mbox-names" property value can be used to give a name to the
communication channel to be used by the client user.
$defs:
omap-mbox-descriptor:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
The omap-mbox-descriptor is made of up of 3 cells and represents a single
uni-directional communication channel. A typical sub-mailbox device uses
two such channels - one for transmitting (Tx) and one for receiving (Rx).
items:
- description:
mailbox fifo id used either for transmitting on ti,mbox-tx channel or
for receiving on ti,mbox-rx channel (fifo_id). This is the hardware
fifo number within a mailbox cluster.
- description:
irq identifier index number to use from the parent's interrupts data.
Should be 0 for most of the cases, a positive index value is seen only
on mailboxes that have multiple interrupt lines connected to the MPU
processor (irq_id). This is an index number in the listed interrupts
property in the DT nodes.
- description:
mailbox user id for identifying the interrupt line associated with
generating a tx/rx fifo interrupt (usr_id). This is the hardware
user id number within a mailbox cluster.
omap-sub-mailbox:
type: object
description:
The omap-sub-mailbox is a child node within a Mailbox controller device
node and represents the actual communication channel used to send and
receive messages between the host processor and a remote processor. Each
child node should have a unique node name across all the different mailbox
device nodes.
properties:
ti,mbox-tx:
$ref: "#/$defs/omap-mbox-descriptor"
description: sub-mailbox descriptor property defining a Tx fifo.
ti,mbox-rx:
$ref: "#/$defs/omap-mbox-descriptor"
description: sub-mailbox descriptor property defining a Rx fifo.
ti,mbox-send-noirq:
type: boolean
description:
Quirk flag to allow the client user of this sub-mailbox to send
messages without triggering a Tx ready interrupt, and to control
the Tx ticker. Should be used only on sub-mailboxes used to
communicate with WkupM3 remote processor on AM33xx/AM43xx SoCs.
required:
- ti,mbox-tx
- ti,mbox-rx
properties:
compatible:
enum:
- ti,omap2-mailbox # for OMAP2420, OMAP2430 SoCs
- ti,omap3-mailbox # for OMAP3430, OMAP3630 SoCs
- ti,omap4-mailbox # for OMAP44xx, OMAP54xx, AM33xx, AM43xx and DRA7xx SoCs
- ti,am654-mailbox # for K3 AM65x, J721E and J7200 SoCs
- ti,am64-mailbox # for K3 AM64x SoCs
reg:
maxItems: 1
interrupts:
description:
Contains the interrupt information for the mailbox device. The format is
dependent on which interrupt controller the Mailbox device uses. The
number of interrupts listed will at most be the value specified in
ti,mbox-num-users property, but is usually limited by the number of
interrupts reaching the main processor. An interrupt-parent property
is required on SoCs where the interrupt lines are connected through a
Interrupt Router before reaching the main processor's GIC.
"#mbox-cells":
const: 1
description:
The specifier is a phandle to an omap-sub-mailbox device.
ti,mbox-num-users:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Number of targets (processor devices) that the mailbox device can
interrupt.
ti,mbox-num-fifos:
$ref: /schemas/types.yaml#/definitions/uint32
description: Number of h/w fifo queues within the mailbox IP block.
ti,hwmods:
$ref: /schemas/types.yaml#/definitions/string
deprecated: true
description:
Name of the hwmod associated with the mailbox. This should be defined
in the mailbox node only if the node is not defined as a child node of
a corresponding sysc interconnect node.
This property is only needed on some legacy OMAP SoCs which have not
yet been converted to the ti,sysc interconnect hierarachy, but is
otherwise considered obsolete.
patternProperties:
"^mbox-[a-z0-9-]+$":
$ref: "#/$defs/omap-sub-mailbox"
required:
- compatible
- reg
- interrupts
- "#mbox-cells"
- ti,mbox-num-users
- ti,mbox-num-fifos
allOf:
- if:
properties:
compatible:
enum:
- ti,am654-mailbox
then:
required:
- interrupt-parent
- if:
properties:
compatible:
enum:
- ti,am654-mailbox
- ti,am64-mailbox
then:
properties:
ti,mbox-num-users:
const: 4
ti,mbox-num-fifos:
const: 16
interrupts:
minItems: 1
maxItems: 4
- if:
properties:
compatible:
enum:
- ti,omap4-mailbox
then:
properties:
ti,mbox-num-users:
enum: [3, 4]
ti,mbox-num-fifos:
enum: [8, 12]
interrupts:
minItems: 1
maxItems: 4
- if:
properties:
compatible:
enum:
- ti,omap3-mailbox
then:
properties:
ti,mbox-num-users:
const: 2
ti,mbox-num-fifos:
const: 2
interrupts:
minItems: 1
maxItems: 1
- if:
properties:
compatible:
enum:
- ti,omap2-mailbox
then:
properties:
ti,mbox-num-users:
const: 4
ti,mbox-num-fifos:
const: 6
interrupts:
minItems: 1
maxItems: 2
additionalProperties: false
examples:
- |
/* OMAP4 */
#include <dt-bindings/interrupt-controller/arm-gic.h>
mailbox: mailbox@4a0f4000 {
compatible = "ti,omap4-mailbox";
reg = <0x4a0f4000 0x200>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
#mbox-cells = <1>;
ti,mbox-num-users = <3>;
ti,mbox-num-fifos = <8>;
mbox_ipu: mbox-ipu {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <1 0 0>;
};
mbox_dsp: mbox-dsp {
ti,mbox-tx = <3 0 0>;
ti,mbox-rx = <2 0 0>;
};
};
dsp {
mboxes = <&mailbox &mbox_dsp>;
};
- |
/* AM33xx */
mailbox1: mailbox@480c8000 {
compatible = "ti,omap4-mailbox";
reg = <0x480c8000 0x200>;
interrupts = <77>;
#mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <8>;
mbox_wkupm3: mbox-wkup-m3 {
ti,mbox-tx = <0 0 0>;
ti,mbox-rx = <0 0 3>;
ti,mbox-send-noirq;
};
};
- |
/* AM65x */
mailbox0_cluster0: mailbox@31f80000 {
compatible = "ti,am654-mailbox";
reg = <0x31f80000 0x200>;
#mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <16>;
interrupt-parent = <&intr_main_navss>;
interrupts = <436>;
mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 {
ti,mbox-tx = <1 0 0>;
ti,mbox-rx = <0 0 0>;
};
};

1
Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml
View File

@ -67,7 +67,6 @@ properties:
clock-names:
minItems: 4
maxItems: 5
items:
- const: dos_parser
- const: dos

8
Documentation/devicetree/bindings/media/i2c/adv7180.yaml
View File

@ -36,7 +36,13 @@ properties:
maxItems: 1
port:
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
ports: true

1
Documentation/devicetree/bindings/media/i2c/adv7604.yaml
View File

@ -30,7 +30,6 @@ properties:
reg-names:
minItems: 1
maxItems: 13
items:
- const: main
- enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]

2
Documentation/devicetree/bindings/media/i2c/imx258.yaml
View File

@ -49,7 +49,7 @@ properties:
# See ../video-interfaces.txt for more details
port:
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:

23
Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
View File

@ -111,17 +111,10 @@ properties:
i2c-mux:
type: object
$ref: /schemas/i2c/i2c-mux.yaml#
unevaluatedProperties: false
description: |
Each GMSL link is modelled as a child bus of an i2c bus
multiplexer/switch, in accordance with bindings described in
Documentation/devicetree/bindings/i2c/i2c-mux.txt.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
Each GMSL link is modelled as a child bus of an i2c bus multiplexer/switch.
patternProperties:
"^i2c@[0-3]$":
@ -133,12 +126,6 @@ properties:
channels.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
reg:
description: The index of the GMSL channel.
maxItems: 1
@ -173,10 +160,6 @@ properties:
additionalProperties: false
additionalProperties: false
additionalProperties: false
required:
- compatible
- reg

2
Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
View File

@ -45,7 +45,7 @@ properties:
port:
description: MIPI CSI-2 transmitter port
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:

2
Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
View File

@ -45,7 +45,7 @@ properties:
port:
description: MIPI CSI-2 transmitter port
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
additionalProperties: false
properties:

2
Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml
View File

@ -37,7 +37,7 @@ properties:
port:
additionalProperties: false
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
properties:
endpoint:

1
Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
View File

@ -43,7 +43,6 @@ properties:
clocks:
minItems: 1
maxItems: 3
items:
- description: AXI bus interface clock
- description: Peripheral clock

Some files were not shown because too many files have changed in this diff Show More