Devicetree updates for v5.6:

- Update dtc to upstream v1.5.1-22-gc40aeb60b47a (plus 1 revert)
 
 - Fix for DMA coherent devices on Power
 
 - Rework and simplify the DT phandle cache code
 
 - DT schema conversions for LEDS, gpio-leds, STM32 dfsdm, STM32 UART,
   STM32 ROMEM, STM32 watchdog, STM32 DMAs, STM32 mlahb, STM32 RTC,
   STM32 RCC, STM32 syscon, rs485, Renesas rCar CSI2, Faraday FTIDE010,
   DWC2, Arm idle-states, Allwinner legacy resets, PRCM and clocks,
   Allwinner H6 OPP, Allwinner AHCI, Allwinner MBUS, Allwinner A31 CSI,
   Allwinner h/w codec, Allwinner A10 system ctrl, Allwinner SRAM,
   Allwinner USB PHY, Renesas CEU, generic PCI host, Arm Versatile PCI
 
 - New binding schemas for SATA and PATA controllers, TI and Infineon VR
   controllers, MAX31730
 
 - New compatible strings for i.MX8QM, WCN3991, renesas,r8a77961-wdt,
   renesas,etheravb-r8a77961
 
 - Add USB 'super-speed-plus' as a documented speed
 
 - Vendor prefixes for broadmobi, calaosystems, kam, and mps
 
 - Clean-up the multiple flavors of ST-Ericsson vendor prefixes
 -----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCgAuFiEEktVUI4SxYhzZyEuo+vtdtY28YcMFAl4x8eIQHHJvYmhAa2Vy
 bmVsLm9yZwAKCRD6+121jbxhw01FD/9MTmExKdgOc2I0u5MKIa+VXGeJKqfR0Liv
 irQBPVljPUAr7cDZJ4XX4YIuJ0Gh+MTLSF0QFp7kHyeVnfq+6rNMjwtUTpJSKCZb
 7nXQPguTDd2Guc0ycz1AG+nm2ZsFkaxg2GVFtDwA4aLGTho0oKYqFg8KUpZDAU9K
 HkDDyvDSFLZj48yn1yggs3d6kWh9ERTwK2ilDyHEsfJsZuD694X7GtSm0Vwlddti
 iuV/dTIsDfLPYFhDyz0sy21Kei/EWzMkB9sPIX/AhFQSd5/kgDqj1gL4SswbiV2a
 +pdjb0hcDpcpq4AxqGd5L4Jou4Zf9Agy+FNFkgia77MKZSwJo3lGq6GxZfXlu+L3
 XIV+lmjFILh6OtxHJBItDofqSO3jiGhj5THy16x0j6iwa/IHS3iGmp6MV4D75gvt
 +fvjRPrTwNmiaT8ZsjKG9EjnidLAWdwuhOrpqYi4hkQNRhwbA9pSr5ZUFz3G1LRS
 hLUXcBnZaQlfs8pgbzdv2n727WrGsUe1xFRj69nvl1GVIWPu2J14D1c4LU0+uCxH
 3kYcdyulTqwymRfDGBPEn1llp4N5sekJh0MYuYvNY3YtM/AQTE7FoKfR69xOk3Xa
 /Y1GddE0+suHAby7n2RLGGgpSv4notANYaEEsw0yiywgqkSr2kU67zI7hwU03Kux
 KAJZr365aQ==
 =dsEz
 -----END PGP SIGNATURE-----

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

Pull devicetree updates from Rob Herring:

 - Update dtc to upstream v1.5.1-22-gc40aeb60b47a (plus 1 revert)

 - Fix for DMA coherent devices on Power

 - Rework and simplify the DT phandle cache code

 - DT schema conversions for LEDS, gpio-leds, STM32 dfsdm, STM32 UART,
   STM32 ROMEM, STM32 watchdog, STM32 DMAs, STM32 mlahb, STM32 RTC,
   STM32 RCC, STM32 syscon, rs485, Renesas rCar CSI2, Faraday FTIDE010,
   DWC2, Arm idle-states, Allwinner legacy resets, PRCM and clocks,
   Allwinner H6 OPP, Allwinner AHCI, Allwinner MBUS, Allwinner A31 CSI,
   Allwinner h/w codec, Allwinner A10 system ctrl, Allwinner SRAM,
   Allwinner USB PHY, Renesas CEU, generic PCI host, Arm Versatile PCI

 - New binding schemas for SATA and PATA controllers, TI and Infineon VR
   controllers, MAX31730

 - New compatible strings for i.MX8QM, WCN3991, renesas,r8a77961-wdt,
   renesas,etheravb-r8a77961

 - Add USB 'super-speed-plus' as a documented speed

 - Vendor prefixes for broadmobi, calaosystems, kam, and mps

 - Clean-up the multiple flavors of ST-Ericsson vendor prefixes

* tag 'devicetree-for-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (66 commits)
  scripts/dtc: Revert "yamltree: Ensure consistent bracketing of properties with phandles"
  of: Add OF_DMA_DEFAULT_COHERENT & select it on powerpc
  dt-bindings: leds: Convert gpio-leds to DT schema
  dt-bindings: leds: Convert common LED binding to schema
  dt-bindings: PCI: Convert generic host binding to DT schema
  dt-bindings: PCI: Convert Arm Versatile binding to DT schema
  dt-bindings: Be explicit about installing deps
  dt-bindings: stm32: convert dfsdm to json-schema
  dt-bindings: serial: Convert STM32 UART to json-schema
  dt-bindings: serial: Convert rs485 bindings to json-schema
  dt-bindings: timer: Use non-empty ranges in example
  dt-bindings: arm-boards: typo fix
  dt-bindings: Add TI and Infineon VR Controllers as trivial devices
  dt-binding: usb: add "super-speed-plus"
  dt-bindings: rcar-csi2: Convert bindings to json-schema
  dt-bindings: iio: adc: ad7606: Fix wrong maxItems value
  dt-bindings: Convert Faraday FTIDE010 to DT schema
  dt-bindings: Create DT bindings for PATA controllers
  dt-bindings: Create DT bindings for SATA controllers
  dt: bindings: add vendor prefix for Kamstrup A/S
  ...
This commit is contained in:
Linus Torvalds 2020-01-30 07:47:58 -08:00
commit 893e591b59
157 changed files with 7605 additions and 3330 deletions

View File

@ -121,7 +121,7 @@ Required properties (in root node):
Required nodes:
- soc: some node of the RealView platforms must be the SoC
node that contain the SoC-specific devices, withe the compatible
node that contain the SoC-specific devices, with the compatible
string set to one of these tuples:
"arm,realview-eb-soc", "simple-bus"
"arm,realview-pb1176-soc", "simple-bus"

View File

@ -1,706 +0,0 @@
==========================================
ARM idle states binding description
==========================================
==========================================
1 - Introduction
==========================================
ARM systems contain HW capable of managing power consumption dynamically,
where cores can be put in different low-power states (ranging from simple
wfi to power gating) according to OS PM policies. The CPU states representing
the range of dynamic idle states that a processor can enter at run-time, can be
specified through device tree bindings representing the parameters required
to enter/exit specific idle states on a given processor.
According to the Server Base System Architecture document (SBSA, [3]), the
power states an ARM CPU can be put into are identified by the following list:
- Running
- Idle_standby
- Idle_retention
- Sleep
- Off
The power states described in the SBSA document define the basic CPU states on
top of which ARM platforms implement power management schemes that allow an OS
PM implementation to put the processor in different idle states (which include
states listed above; "off" state is not an idle state since it does not have
wake-up capabilities, hence it is not considered in this document).
Idle state parameters (e.g. entry latency) are platform specific and need to be
characterized with bindings that provide the required information to OS PM
code so that it can build the required tables and use them at runtime.
The device tree binding definition for ARM idle states is the subject of this
document.
===========================================
2 - idle-states definitions
===========================================
Idle states are characterized for a specific system through a set of
timing and energy related properties, that underline the HW behaviour
triggered upon idle states entry and exit.
The following diagram depicts the CPU execution phases and related timing
properties required to enter and exit an idle state:
..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__..
| | | | |
|<------ entry ------->|
| latency |
|<- exit ->|
| latency |
|<-------- min-residency -------->|
|<------- wakeup-latency ------->|
Diagram 1: CPU idle state execution phases
EXEC: Normal CPU execution.
PREP: Preparation phase before committing the hardware to idle mode
like cache flushing. This is abortable on pending wake-up
event conditions. The abort latency is assumed to be negligible
(i.e. less than the ENTRY + EXIT duration). If aborted, CPU
goes back to EXEC. This phase is optional. If not abortable,
this should be included in the ENTRY phase instead.
ENTRY: The hardware is committed to idle mode. This period must run
to completion up to IDLE before anything else can happen.
IDLE: This is the actual energy-saving idle period. This may last
between 0 and infinite time, until a wake-up event occurs.
EXIT: Period during which the CPU is brought back to operational
mode (EXEC).
entry-latency: Worst case latency required to enter the idle state. The
exit-latency may be guaranteed only after entry-latency has passed.
min-residency: Minimum period, including preparation and entry, for a given
idle state to be worthwhile energywise.
wakeup-latency: Maximum delay between the signaling of a wake-up event and the
CPU being able to execute normal code again. If not specified, this is assumed
to be entry-latency + exit-latency.
These timing parameters can be used by an OS in different circumstances.
An idle CPU requires the expected min-residency time to select the most
appropriate idle state based on the expected expiry time of the next IRQ
(i.e. wake-up) that causes the CPU to return to the EXEC phase.
An operating system scheduler may need to compute the shortest wake-up delay
for CPUs in the system by detecting how long will it take to get a CPU out
of an idle state, e.g.:
wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
In other words, the scheduler can make its scheduling decision by selecting
(e.g. waking-up) the CPU with the shortest wake-up delay.
The wake-up delay must take into account the entry latency if that period
has not expired. The abortable nature of the PREP period can be ignored
if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
the worst case since it depends on the CPU operating conditions, i.e. caches
state).
An OS has to reliably probe the wakeup-latency since some devices can enforce
latency constraint guarantees to work properly, so the OS has to detect the
worst case wake-up latency it can incur if a CPU is allowed to enter an
idle state, and possibly to prevent that to guarantee reliable device
functioning.
The min-residency time parameter deserves further explanation since it is
expressed in time units but must factor in energy consumption coefficients.
The energy consumption of a cpu when it enters a power state can be roughly
characterised by the following graph:
|
|
|
e |
n | /---
e | /------
r | /------
g | /-----
y | /------
| ----
| /|
| / |
| / |
| / |
| / |
| / |
|/ |
-----|-------+----------------------------------
0| 1 time(ms)
Graph 1: Energy vs time example
The graph is split in two parts delimited by time 1ms on the X-axis.
The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
and denotes the energy costs incurred while entering and leaving the idle
state.
The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
shallower slope and essentially represents the energy consumption of the idle
state.
min-residency is defined for a given idle state as the minimum expected
residency time for a state (inclusive of preparation and entry) after
which choosing that state become the most energy efficient option. A good
way to visualise this, is by taking the same graph above and comparing some
states energy consumptions plots.
For sake of simplicity, let's consider a system with two idle states IDLE1,
and IDLE2:
|
|
|
| /-- IDLE1
e | /---
n | /----
e | /---
r | /-----/--------- IDLE2
g | /-------/---------
y | ------------ /---|
| / /---- |
| / /--- |
| / /---- |
| / /--- |
| --- |
| / |
| / |
|/ | time
---/----------------------------+------------------------
|IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy
|
IDLE2-min-residency
Graph 2: idle states min-residency example
In graph 2 above, that takes into account idle states entry/exit energy
costs, it is clear that if the idle state residency time (i.e. time till next
wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
choice energywise.
This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
than IDLE2.
However, the lower power consumption (i.e. shallower energy curve slope) of
idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
efficient.
The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
shallower states in a system with multiple idle states) is defined
IDLE2-min-residency and corresponds to the time when energy consumption of
IDLE1 and IDLE2 states breaks even.
The definitions provided in this section underpin the idle states
properties specification that is the subject of the following sections.
===========================================
3 - idle-states node
===========================================
ARM processor idle states are defined within the idle-states node, which is
a direct child of the cpus node [1] and provides a container where the
processor idle states, defined as device tree nodes, are listed.
- idle-states node
Usage: Optional - On ARM systems, it is a container of processor idle
states nodes. If the system does not provide CPU
power management capabilities, or the processor just
supports idle_standby, an idle-states node is not
required.
Description: idle-states node is a container node, where its
subnodes describe the CPU idle states.
Node name must be "idle-states".
The idle-states node's parent node must be the cpus node.
The idle-states node's child nodes can be:
- one or more state nodes
Any other configuration is considered invalid.
An idle-states node defines the following properties:
- entry-method
Value type: <stringlist>
Usage and definition depend on ARM architecture version.
# On ARM v8 64-bit this property is required and must
be:
- "psci"
# On ARM 32-bit systems this property is optional
This assumes that the "enable-method" property is set to "psci" in the cpu
node[6] that is responsible for setting up CPU idle management in the OS
implementation.
The nodes describing the idle states (state) can only be defined
within the idle-states node, any other configuration is considered invalid
and therefore must be ignored.
===========================================
4 - state node
===========================================
A state node represents an idle state description and must be defined as
follows:
- state node
Description: must be child of the idle-states node
The state node name shall follow standard device tree naming
rules ([5], 2.2.1 "Node names"), in particular state nodes which
are siblings within a single common parent must be given a unique name.
The idle state entered by executing the wfi instruction (idle_standby
SBSA,[3][4]) is considered standard on all ARM platforms and therefore
must not be listed.
With the definitions provided above, the following list represents
the valid properties for a state node:
- compatible
Usage: Required
Value type: <stringlist>
Definition: Must be "arm,idle-state".
- local-timer-stop
Usage: See definition
Value type: <none>
Definition: if present the CPU local timer control logic is
lost on state entry, otherwise it is retained.
- entry-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency in
microseconds required to enter the idle state.
- exit-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency
in microseconds required to exit the idle state.
The exit-latency-us duration may be guaranteed
only after entry-latency-us has passed.
- min-residency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing minimum residency duration
in microseconds, inclusive of preparation and
entry, for this idle state to be considered
worthwhile energy wise (refer to section 2 of
this document for a complete description).
- wakeup-latency-us:
Usage: Optional
Value type: <prop-encoded-array>
Definition: u32 value representing maximum delay between the
signaling of a wake-up event and the CPU being
able to execute normal code again. If omitted,
this is assumed to be equal to:
entry-latency-us + exit-latency-us
It is important to supply this value on systems
where the duration of PREP phase (see diagram 1,
section 2) is non-neglibigle.
In such systems entry-latency-us + exit-latency-us
will exceed wakeup-latency-us by this duration.
- status:
Usage: Optional
Value type: <string>
Definition: A standard device tree property [5] that indicates
the operational status of an idle-state.
If present, it shall be:
"okay": to indicate that the idle state is
operational.
"disabled": to indicate that the idle state has
been disabled in firmware so it is not
operational.
If the property is not present the idle-state must
be considered operational.
- idle-state-name:
Usage: Optional
Value type: <string>
Definition: A string used as a descriptive name for the idle
state.
In addition to the properties listed above, a state node may require
additional properties specific to the entry-method defined in the
idle-states node. Please refer to the entry-method bindings
documentation for properties definitions.
===========================================
4 - Examples
===========================================
Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
cpus {
#size-cells = <0>;
#address-cells = <2>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU4: cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU5: cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU6: cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU7: cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
CPU8: cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU9: cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU10: cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU11: cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU12: cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU13: cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU14: cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
CPU15: cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
idle-states {
entry-method = "psci";
CPU_RETENTION_0_0: cpu-retention-0-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <80>;
};
CLUSTER_RETENTION_0: cluster-retention-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <250>;
wakeup-latency-us = <130>;
};
CPU_SLEEP_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <250>;
exit-latency-us = <500>;
min-residency-us = <950>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <600>;
exit-latency-us = <1100>;
min-residency-us = <2700>;
wakeup-latency-us = <1500>;
};
CPU_RETENTION_1_0: cpu-retention-1-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <90>;
};
CLUSTER_RETENTION_1: cluster-retention-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <270>;
wakeup-latency-us = <100>;
};
CPU_SLEEP_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <70>;
exit-latency-us = <100>;
min-residency-us = <300>;
wakeup-latency-us = <150>;
};
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <500>;
exit-latency-us = <1200>;
min-residency-us = <3500>;
wakeup-latency-us = <1300>;
};
};
};
Example 2 (ARM 32-bit, 8-cpu system, two clusters):
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
CPU4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU5: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU6: cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
CPU7: cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
};
idle-states {
CPU_SLEEP_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <200>;
exit-latency-us = <100>;
min-residency-us = <400>;
wakeup-latency-us = <250>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <500>;
exit-latency-us = <1500>;
min-residency-us = <2500>;
wakeup-latency-us = <1700>;
};
CPU_SLEEP_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <300>;
exit-latency-us = <500>;
min-residency-us = <900>;
wakeup-latency-us = <600>;
};
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <800>;
exit-latency-us = <2000>;
min-residency-us = <6500>;
wakeup-latency-us = <2300>;
};
};
};
===========================================
5 - References
===========================================
[1] ARM Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/arm/cpus.yaml
[2] ARM Linux Kernel documentation - PSCI bindings
Documentation/devicetree/bindings/arm/psci.yaml
[3] ARM Server Base System Architecture (SBSA)
http://infocenter.arm.com/help/index.jsp
[4] ARM Architecture Reference Manuals
http://infocenter.arm.com/help/index.jsp
[5] Devicetree Specification
https://www.devicetree.org/specifications/
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
Documentation/arm64/booting.rst

View File

@ -0,0 +1,661 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/idle-states.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM idle states binding description
maintainers:
- Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
description: |+
==========================================
1 - Introduction
==========================================
ARM systems contain HW capable of managing power consumption dynamically,
where cores can be put in different low-power states (ranging from simple wfi
to power gating) according to OS PM policies. The CPU states representing the
range of dynamic idle states that a processor can enter at run-time, can be
specified through device tree bindings representing the parameters required to
enter/exit specific idle states on a given processor.
According to the Server Base System Architecture document (SBSA, [3]), the
power states an ARM CPU can be put into are identified by the following list:
- Running
- Idle_standby
- Idle_retention
- Sleep
- Off
The power states described in the SBSA document define the basic CPU states on
top of which ARM platforms implement power management schemes that allow an OS
PM implementation to put the processor in different idle states (which include
states listed above; "off" state is not an idle state since it does not have
wake-up capabilities, hence it is not considered in this document).
Idle state parameters (e.g. entry latency) are platform specific and need to
be characterized with bindings that provide the required information to OS PM
code so that it can build the required tables and use them at runtime.
The device tree binding definition for ARM idle states is the subject of this
document.
===========================================
2 - idle-states definitions
===========================================
Idle states are characterized for a specific system through a set of
timing and energy related properties, that underline the HW behaviour
triggered upon idle states entry and exit.
The following diagram depicts the CPU execution phases and related timing
properties required to enter and exit an idle state:
..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__..
| | | | |
|<------ entry ------->|
| latency |
|<- exit ->|
| latency |
|<-------- min-residency -------->|
|<------- wakeup-latency ------->|
Diagram 1: CPU idle state execution phases
EXEC: Normal CPU execution.
PREP: Preparation phase before committing the hardware to idle mode
like cache flushing. This is abortable on pending wake-up
event conditions. The abort latency is assumed to be negligible
(i.e. less than the ENTRY + EXIT duration). If aborted, CPU
goes back to EXEC. This phase is optional. If not abortable,
this should be included in the ENTRY phase instead.
ENTRY: The hardware is committed to idle mode. This period must run
to completion up to IDLE before anything else can happen.
IDLE: This is the actual energy-saving idle period. This may last
between 0 and infinite time, until a wake-up event occurs.
EXIT: Period during which the CPU is brought back to operational
mode (EXEC).
entry-latency: Worst case latency required to enter the idle state. The
exit-latency may be guaranteed only after entry-latency has passed.
min-residency: Minimum period, including preparation and entry, for a given
idle state to be worthwhile energywise.
wakeup-latency: Maximum delay between the signaling of a wake-up event and the
CPU being able to execute normal code again. If not specified, this is assumed
to be entry-latency + exit-latency.
These timing parameters can be used by an OS in different circumstances.
An idle CPU requires the expected min-residency time to select the most
appropriate idle state based on the expected expiry time of the next IRQ
(i.e. wake-up) that causes the CPU to return to the EXEC phase.
An operating system scheduler may need to compute the shortest wake-up delay
for CPUs in the system by detecting how long will it take to get a CPU out
of an idle state, e.g.:
wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
In other words, the scheduler can make its scheduling decision by selecting
(e.g. waking-up) the CPU with the shortest wake-up delay.
The wake-up delay must take into account the entry latency if that period
has not expired. The abortable nature of the PREP period can be ignored
if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
the worst case since it depends on the CPU operating conditions, i.e. caches
state).
An OS has to reliably probe the wakeup-latency since some devices can enforce
latency constraint guarantees to work properly, so the OS has to detect the
worst case wake-up latency it can incur if a CPU is allowed to enter an
idle state, and possibly to prevent that to guarantee reliable device
functioning.
The min-residency time parameter deserves further explanation since it is
expressed in time units but must factor in energy consumption coefficients.
The energy consumption of a cpu when it enters a power state can be roughly
characterised by the following graph:
|
|
|
e |
n | /---
e | /------
r | /------
g | /-----
y | /------
| ----
| /|
| / |
| / |
| / |
| / |
| / |
|/ |
-----|-------+----------------------------------
0| 1 time(ms)
Graph 1: Energy vs time example
The graph is split in two parts delimited by time 1ms on the X-axis.
The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
and denotes the energy costs incurred while entering and leaving the idle
state.
The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
shallower slope and essentially represents the energy consumption of the idle
state.
min-residency is defined for a given idle state as the minimum expected
residency time for a state (inclusive of preparation and entry) after
which choosing that state become the most energy efficient option. A good
way to visualise this, is by taking the same graph above and comparing some
states energy consumptions plots.
For sake of simplicity, let's consider a system with two idle states IDLE1,
and IDLE2:
|
|
|
| /-- IDLE1
e | /---
n | /----
e | /---
r | /-----/--------- IDLE2
g | /-------/---------
y | ------------ /---|
| / /---- |
| / /--- |
| / /---- |
| / /--- |
| --- |
| / |
| / |
|/ | time
---/----------------------------+------------------------
|IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy
|
IDLE2-min-residency
Graph 2: idle states min-residency example
In graph 2 above, that takes into account idle states entry/exit energy
costs, it is clear that if the idle state residency time (i.e. time till next
wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
choice energywise.
This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
than IDLE2.
However, the lower power consumption (i.e. shallower energy curve slope) of
idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
efficient.
The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
shallower states in a system with multiple idle states) is defined
IDLE2-min-residency and corresponds to the time when energy consumption of
IDLE1 and IDLE2 states breaks even.
The definitions provided in this section underpin the idle states
properties specification that is the subject of the following sections.
===========================================
3 - idle-states node
===========================================
ARM processor idle states are defined within the idle-states node, which is
a direct child of the cpus node [1] and provides a container where the
processor idle states, defined as device tree nodes, are listed.
On ARM systems, it is a container of processor idle states nodes. If the
system does not provide CPU power management capabilities, or the processor
just supports idle_standby, an idle-states node is not required.
===========================================
4 - References
===========================================
[1] ARM Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/arm/cpus.yaml
[2] ARM Linux Kernel documentation - PSCI bindings
Documentation/devicetree/bindings/arm/psci.yaml
[3] ARM Server Base System Architecture (SBSA)
http://infocenter.arm.com/help/index.jsp
[4] ARM Architecture Reference Manuals
http://infocenter.arm.com/help/index.jsp
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
Documentation/arm64/booting.rst
properties:
$nodename:
const: idle-states
entry-method:
description: |
Usage and definition depend on ARM architecture version.
On ARM v8 64-bit this property is required.
On ARM 32-bit systems this property is optional
This assumes that the "enable-method" property is set to "psci" in the cpu
node[6] that is responsible for setting up CPU idle management in the OS
implementation.
const: psci
patternProperties:
"^(cpu|cluster)-":
type: object
description: |
Each state node represents an idle state description and must be defined
as follows.
The idle state entered by executing the wfi instruction (idle_standby
SBSA,[3][4]) is considered standard on all ARM platforms and therefore
must not be listed.
In addition to the properties listed above, a state node may require
additional properties specific to the entry-method defined in the
idle-states node. Please refer to the entry-method bindings
documentation for properties definitions.
properties:
compatible:
const: arm,idle-state
local-timer-stop:
description:
If present the CPU local timer control logic is
lost on state entry, otherwise it is retained.
type: boolean
entry-latency-us:
description:
Worst case latency in microseconds required to enter the idle state.
exit-latency-us:
description:
Worst case latency in microseconds required to exit the idle state.
The exit-latency-us duration may be guaranteed only after
entry-latency-us has passed.
min-residency-us:
description:
Minimum residency duration in microseconds, inclusive of preparation
and entry, for this idle state to be considered worthwhile energy wise
(refer to section 2 of this document for a complete description).
wakeup-latency-us:
description: |
Maximum delay between the signaling of a wake-up event and the CPU
being able to execute normal code again. If omitted, this is assumed
to be equal to:
entry-latency-us + exit-latency-us
It is important to supply this value on systems where the duration of
PREP phase (see diagram 1, section 2) is non-neglibigle. In such
systems entry-latency-us + exit-latency-us will exceed
wakeup-latency-us by this duration.
idle-state-name:
$ref: /schemas/types.yaml#definitions/string
description:
A string used as a descriptive name for the idle state.
required:
- compatible
- entry-latency-us
- exit-latency-us
- min-residency-us
additionalProperties: false
examples:
- |
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
&CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
};
cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x0>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x1>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10000>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10001>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10100>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x1 0x10101>;
enable-method = "psci";
cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
&CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
};
idle-states {
entry-method = "psci";
CPU_RETENTION_0_0: cpu-retention-0-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <80>;
};
CLUSTER_RETENTION_0: cluster-retention-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <250>;
wakeup-latency-us = <130>;
};
CPU_SLEEP_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <250>;
exit-latency-us = <500>;
min-residency-us = <950>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <600>;
exit-latency-us = <1100>;
min-residency-us = <2700>;
wakeup-latency-us = <1500>;
};
CPU_RETENTION_1_0: cpu-retention-1-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <20>;
exit-latency-us = <40>;
min-residency-us = <90>;
};
CLUSTER_RETENTION_1: cluster-retention-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <50>;
exit-latency-us = <100>;
min-residency-us = <270>;
wakeup-latency-us = <100>;
};
CPU_SLEEP_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x0010000>;
entry-latency-us = <70>;
exit-latency-us = <100>;
min-residency-us = <300>;
wakeup-latency-us = <150>;
};
CLUSTER_SLEEP_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
arm,psci-suspend-param = <0x1010000>;
entry-latency-us = <500>;
exit-latency-us = <1200>;
min-residency-us = <3500>;
wakeup-latency-us = <1300>;
};
};
};
- |
// Example 2 (ARM 32-bit, 8-cpu system, two clusters):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>;
};
cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>;
};
cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>;
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>;
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>;
};
cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>;
};
cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>;
};
idle-states {
cpu_sleep_0_0: cpu-sleep-0-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <200>;
exit-latency-us = <100>;
min-residency-us = <400>;
wakeup-latency-us = <250>;
};
cluster_sleep_0: cluster-sleep-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <500>;
exit-latency-us = <1500>;
min-residency-us = <2500>;
wakeup-latency-us = <1700>;
};
cpu_sleep_1_0: cpu-sleep-1-0 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <300>;
exit-latency-us = <500>;
min-residency-us = <900>;
wakeup-latency-us = <600>;
};
cluster_sleep_1: cluster-sleep-1 {
compatible = "arm,idle-state";
local-timer-stop;
entry-latency-us = <800>;
exit-latency-us = <2000>;
min-residency-us = <6500>;
wakeup-latency-us = <2300>;
};
};
};
...

View File

@ -1,37 +0,0 @@
ML-AHB interconnect bindings
These bindings describe the STM32 SoCs ML-AHB interconnect bus which connects
a Cortex-M subsystem with dedicated memories.
The MCU SRAM and RETRAM memory parts can be accessed through different addresses
(see "RAM aliases" in [1]) using different buses (see [2]) : balancing the
Cortex-M firmware accesses among those ports allows to tune the system
performance.
[1]: https://www.st.com/resource/en/reference_manual/dm00327659.pdf
[2]: https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping
Required properties:
- compatible: should be "simple-bus"
- dma-ranges: describes memory addresses translation between the local CPU and
the remote Cortex-M processor. Each memory region, is declared with
3 parameters:
- param 1: device base address (Cortex-M processor address)
- param 2: physical base address (local CPU address)
- param 3: size of the memory region.
The Cortex-M remote processor accessed via the mlahb interconnect is described
by a child node.
Example:
mlahb {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
dma-ranges = <0x00000000 0x38000000 0x10000>,
<0x10000000 0x10000000 0x60000>,
<0x30000000 0x30000000 0x60000>;
m4_rproc: m4@10000000 {
...
};
};

View File

@ -0,0 +1,70 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/stm32/st,mlahb.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: STMicroelectronics STM32 ML-AHB interconnect bindings
maintainers:
- Fabien Dessenne <fabien.dessenne@st.com>
- Arnaud Pouliquen <arnaud.pouliquen@st.com>
description: |
These bindings describe the STM32 SoCs ML-AHB interconnect bus which connects
a Cortex-M subsystem with dedicated memories. The MCU SRAM and RETRAM memory
parts can be accessed through different addresses (see "RAM aliases" in [1])
using different buses (see [2]): balancing the Cortex-M firmware accesses
among those ports allows to tune the system performance.
[1]: https://www.st.com/resource/en/reference_manual/dm00327659.pdf
[2]: https://wiki.st.com/stm32mpu/wiki/STM32MP15_RAM_mapping
allOf:
- $ref: /schemas/simple-bus.yaml#
properties:
compatible:
contains:
enum:
- st,mlahb
dma-ranges:
description: |
Describe memory addresses translation between the local CPU and the
remote Cortex-M processor. Each memory region, is declared with
3 parameters:
- param 1: device base address (Cortex-M processor address)
- param 2: physical base address (local CPU address)
- param 3: size of the memory region.
maxItems: 3
'#address-cells':
const: 1
'#size-cells':
const: 1
required:
- compatible
- '#address-cells'
- '#size-cells'
- dma-ranges
examples:
- |
mlahb: ahb {
compatible = "st,mlahb", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x10000000 0x40000>;
ranges;
dma-ranges = <0x00000000 0x38000000 0x10000>,
<0x10000000 0x10000000 0x60000>,
<0x30000000 0x30000000 0x60000>;
m4_rproc: m4@10000000 {
reg = <0x10000000 0x40000>;
};
};
...

View File

@ -0,0 +1,41 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/stm32/st,stm32-syscon.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: STMicroelectronics STM32 Platforms System Controller bindings
maintainers:
- Alexandre Torgue <alexandre.torgue@st.com>
- Christophe Roullier <christophe.roullier@st.com>
properties:
compatible:
oneOf:
- items:
- enum:
- st,stm32mp157-syscfg
- const: syscon
reg:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- clocks
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>
syscfg: syscon@50020000 {
compatible = "st,stm32mp157-syscfg", "syscon";
reg = <0x50020000 0x400>;
clocks = <&rcc SYSCFG>;
};
...

View File

@ -1,16 +0,0 @@
STMicroelectronics STM32 Platforms System Controller
Properties:
- compatible : should contain two values. First value must be :
- " st,stm32mp157-syscfg " - for stm32mp157 based SoCs,
second value must be always "syscon".
- reg : offset and length of the register set.
- clocks: phandle to the syscfg clock
Example:
syscfg: syscon@50020000 {
compatible = "st,stm32mp157-syscfg", "syscon";
reg = <0x50020000 0x400>;
clocks = <&rcc SYSCFG>;
};

View File

@ -0,0 +1,65 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun4i-a10-mbus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner Memory Bus (MBUS) controller
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
description: |
The MBUS controller drives the MBUS that other devices in the SoC
will use to perform DMA. It also has a register interface that
allows to monitor and control the bandwidth and priorities for
masters on that bus.
Each device having to perform their DMA through the MBUS must have
the interconnects and interconnect-names properties set to the MBUS
controller and with "dma-mem" as the interconnect name.
properties:
"#interconnect-cells":
const: 1
description:
The content of the cell is the MBUS ID.
compatible:
enum:
- allwinner,sun5i-a13-mbus
- allwinner,sun8i-h3-mbus
reg:
maxItems: 1
clocks:
maxItems: 1
dma-ranges:
description:
See section 2.3.9 of the DeviceTree Specification.
required:
- "#interconnect-cells"
- compatible
- reg
- clocks
- dma-ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/sun5i-ccu.h>
mbus: dram-controller@1c01000 {
compatible = "allwinner,sun5i-a13-mbus";
reg = <0x01c01000 0x1000>;
clocks = <&ccu CLK_MBUS>;
dma-ranges = <0x00000000 0x40000000 0x20000000>;
#interconnect-cells = <1>;
};
...

View File

@ -1,37 +0,0 @@
Allwinner Memory Bus (MBUS) controller
The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.
Required properties:
- compatible: Must be one of:
- allwinner,sun5i-a13-mbus
- allwinner,sun8i-h3-mbus
- reg: Offset and length of the register set for the controller
- clocks: phandle to the clock driving the controller
- dma-ranges: See section 2.3.9 of the DeviceTree Specification
- #interconnect-cells: Must be one, with the argument being the MBUS
port ID
Each device having to perform their DMA through the MBUS must have the
interconnects and interconnect-names properties set to the MBUS
controller and with "dma-mem" as the interconnect name.
Example:
mbus: dram-controller@1c01000 {
compatible = "allwinner,sun5i-a13-mbus";
reg = <0x01c01000 0x1000>;
clocks = <&ccu CLK_MBUS>;
dma-ranges = <0x00000000 0x40000000 0x20000000>;
#interconnect-cells = <1>;
};
fe0: display-frontend@1e00000 {
compatible = "allwinner,sun5i-a13-display-frontend";
...
interconnects = <&mbus 19>;
interconnect-names = "dma-mem";
};

View File

@ -9,8 +9,6 @@ PHYs.
Required properties:
- compatible : compatible string, one of:
- "allwinner,sun4i-a10-ahci"
- "allwinner,sun8i-r40-ahci"
- "brcm,iproc-ahci"
- "hisilicon,hisi-ahci"
- "cavium,octeon-7130-ahci"
@ -45,8 +43,6 @@ Required properties when using sub-nodes:
- #address-cells : number of cells to encode an address
- #size-cells : number of cells representing the size of an address
For allwinner,sun8i-r40-ahci, the reset property must be present.
Sub-nodes required properties:
- reg : the port number
And at least one of the following properties:
@ -60,14 +56,6 @@ Examples:
interrupts = <115>;
};
ahci: sata@1c18000 {
compatible = "allwinner,sun4i-a10-ahci";
reg = <0x01c18000 0x1000>;
interrupts = <56>;
clocks = <&pll6 0>, <&ahb_gates 25>;
target-supply = <&reg_ahci_5v>;
};
With sub-nodes:
sata@f7e90000 {
compatible = "marvell,berlin2q-achi", "generic-ahci";

View File

@ -0,0 +1,47 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/allwinner,sun4i-a10-ahci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 AHCI SATA Controller bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:
const: allwinner,sun4i-a10-ahci
reg:
maxItems: 1
clocks:
items:
- description: AHCI Bus Clock
- description: AHCI Module Clock
interrupts:
maxItems: 1
target-supply:
description: Regulator for SATA target power
required:
- compatible
- reg
- clocks
- interrupts
additionalProperties: false
examples:
- |
ahci: sata@1c18000 {
compatible = "allwinner,sun4i-a10-ahci";
reg = <0x01c18000 0x1000>;
interrupts = <56>;
clocks = <&pll6 0>, <&ahb_gates 25>;
target-supply = <&reg_ahci_5v>;
};

View File

@ -0,0 +1,67 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/allwinner,sun8i-r40-ahci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner R40 AHCI SATA Controller bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:
const: allwinner,sun8i-r40-ahci
reg:
maxItems: 1
clocks:
items:
- description: AHCI Bus Clock
- description: AHCI Module Clock
interrupts:
maxItems: 1
resets:
maxItems: 1
reset-names:
const: ahci
ahci-supply:
description: Regulator for the AHCI controller
phy-supply:
description: Regulator for the SATA PHY power
required:
- compatible
- reg
- clocks
- interrupts
- resets
- reset-names
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/sun8i-r40-ccu.h>
#include <dt-bindings/reset/sun8i-r40-ccu.h>
ahci: sata@1c18000 {
compatible = "allwinner,sun8i-r40-ahci";
reg = <0x01c18000 0x1000>;
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_SATA>, <&ccu CLK_SATA>;
resets = <&ccu RST_BUS_SATA>;
reset-names = "ahci";
ahci-supply = <&reg_dldo4>;
phy-supply = <&reg_eldo3>;
};
...

View File

@ -1,38 +0,0 @@
* Faraday Technology FTIDE010 PATA controller
This controller is the first Faraday IDE interface block, used in the
StorLink SL2312 and SL3516, later known as the Cortina Systems Gemini
platform. The controller can do PIO modes 0 through 4, Multi-word DMA
(MWDM)modes 0 through 2 and Ultra DMA modes 0 through 6.
On the Gemini platform, this PATA block is accompanied by a PATA to
SATA bridge in order to support SATA. This is why a phandle to that
controller is compulsory on that platform.
The timing properties are unique per-SoC, not per-board.
Required properties:
- compatible: should be one of
"cortina,gemini-pata", "faraday,ftide010"
"faraday,ftide010"
- interrupts: interrupt for the block
- reg: registers and size for the block
Optional properties:
- clocks: a SoC clock running the peripheral.
- clock-names: should be set to "PCLK" for the peripheral clock.
Required properties for "cortina,gemini-pata" compatible:
- sata: a phande to the Gemini PATA to SATA bridge, see
cortina,gemini-sata-bridge.txt for details.
Example:
ata@63000000 {
compatible = "cortina,gemini-pata", "faraday,ftide010";
reg = <0x63000000 0x100>;
interrupts = <4 IRQ_TYPE_EDGE_RISING>;
clocks = <&gcc GEMINI_CLK_GATE_IDE>;
clock-names = "PCLK";
sata = <&sata>;
};

View File

@ -0,0 +1,89 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/faraday,ftide010.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Faraday Technology FTIDE010 PATA controller
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
This controller is the first Faraday IDE interface block, used in the
StorLink SL3512 and SL3516, later known as the Cortina Systems Gemini
platform. The controller can do PIO modes 0 through 4, Multi-word DMA
(MWDM) modes 0 through 2 and Ultra DMA modes 0 through 6.
On the Gemini platform, this PATA block is accompanied by a PATA to
SATA bridge in order to support SATA. This is why a phandle to that
controller is compulsory on that platform.
The timing properties are unique per-SoC, not per-board.
properties:
compatible:
oneOf:
- const: faraday,ftide010
- items:
- const: cortina,gemini-pata
- const: faraday,ftide010
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 1
clock-names:
const: PCLK
sata:
description:
phandle to the Gemini PATA to SATA bridge, if available
$ref: /schemas/types.yaml#/definitions/phandle
required:
- compatible
- reg
- interrupts
allOf:
- $ref: pata-common.yaml#
- if:
properties:
compatible:
contains:
const: cortina,gemini-pata
then:
required:
- sata
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/cortina,gemini-clock.h>
ide@63000000 {
compatible = "cortina,gemini-pata", "faraday,ftide010";
reg = <0x63000000 0x100>;
interrupts = <4 IRQ_TYPE_EDGE_RISING>;
clocks = <&gcc GEMINI_CLK_GATE_IDE>;
clock-names = "PCLK";
sata = <&sata>;
#address-cells = <1>;
#size-cells = <0>;
ide-port@0 {
reg = <0>;
};
ide-port@1 {
reg = <1>;
};
};
...

View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/pata-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common Properties for Parallel AT attachment (PATA) controllers
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
This document defines device tree properties common to most Parallel
ATA (PATA, also known as IDE) AT attachment storage devices.
It doesn't constitue a device tree binding specification by itself but is
meant to be referenced by device tree bindings.
The PATA (IDE) controller-specific device tree bindings are responsible for
defining whether each property is required or optional.
properties:
$nodename:
pattern: "^ide(@.*)?$"
description:
Specifies the host controller node. PATA host controller nodes are named
"ide".
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^ide-port@[0-1]$":
description: |
DT nodes for ports connected on the PATA host. The master drive will have
ID number 0 and the slave drive will have ID number 1. The PATA port
nodes will be named "ide-port".
type: object
properties:
reg:
minimum: 0
maximum: 1
description:
The ID number of the drive port, 0 for the master port and 1 for the
slave port.
...

View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/sata-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common Properties for Serial AT attachment (SATA) controllers
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
This document defines device tree properties common to most Serial
AT attachment (SATA) storage devices. It doesn't constitute a device tree
binding specification by itself but is meant to be referenced by device
tree bindings.
The SATA controller-specific device tree bindings are responsible for
defining whether each property is required or optional.
properties:
$nodename:
pattern: "^sata(@.*)?$"
description:
Specifies the host controller node. SATA host controller nodes are named
"sata"
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^sata-port@[0-9a-e]$":
description: |
DT nodes for ports connected on the SATA host. The SATA port
nodes will be named "sata-port".
type: object
properties:
reg:
minimum: 0
maximum: 14
description:
The ID number of the drive port SATA can potentially use a port
multiplier making it possible to connect up to 15 disks to a single
SATA port.
...

View File

@ -0,0 +1,108 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-ahb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 AHB Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
enum:
- allwinner,sun4i-a10-ahb-clk
- allwinner,sun6i-a31-ahb1-clk
- allwinner,sun8i-h3-ahb2-clk
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: allwinner,sun4i-a10-ahb-clk
then:
properties:
clocks:
maxItems: 1
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-ahb1-clk
then:
properties:
clocks:
maxItems: 4
- if:
properties:
compatible:
contains:
const: allwinner,sun8i-h3-ahb2-clk
then:
properties:
clocks:
maxItems: 2
examples:
- |
ahb@1c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-ahb-clk";
reg = <0x01c20054 0x4>;
clocks = <&axi>;
clock-output-names = "ahb";
};
- |
ahb1@1c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun6i-a31-ahb1-clk";
reg = <0x01c20054 0x4>;
clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
clock-output-names = "ahb1";
};
- |
ahb2_clk@1c2005c {
#clock-cells = <0>;
compatible = "allwinner,sun8i-h3-ahb2-clk";
reg = <0x01c2005c 0x4>;
clocks = <&ahb1>, <&pll6d2>;
clock-output-names = "ahb2";
};
...

View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-apb0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 APB0 Bus Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-apb0-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
apb0@1c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-apb0-clk";
reg = <0x01c20054 0x4>;
clocks = <&ahb>;
clock-output-names = "apb0";
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-apb1-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 APB1 Bus Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-apb1-clk
reg:
maxItems: 1
clocks:
maxItems: 3
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20058 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-apb1-clk";
reg = <0x01c20058 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&osc32k>;
clock-output-names = "apb1";
};
...

View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-axi-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 AXI Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
enum:
- allwinner,sun4i-a10-axi-clk
- allwinner,sun8i-a23-axi-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
axi@1c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-axi-clk";
reg = <0x01c20054 0x4>;
clocks = <&cpu>;
clock-output-names = "axi";
};
- |
axi_clk@1c20050 {
#clock-cells = <0>;
compatible = "allwinner,sun8i-a23-axi-clk";
reg = <0x01c20050 0x4>;
clocks = <&cpu>;
clock-output-names = "axi";
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-cpu-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 CPU Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-cpu-clk
reg:
maxItems: 1
clocks:
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
cpu@1c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-cpu-clk";
reg = <0x01c20054 0x4>;
clocks = <&osc32k>, <&osc24M>, <&pll1>, <&dummy>;
clock-output-names = "cpu";
};
...

View File

@ -0,0 +1,57 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-display-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Display Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
"#reset-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-display-clk
reg:
maxItems: 1
clocks:
maxItems: 3
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20104 {
#clock-cells = <0>;
#reset-cells = <0>;
compatible = "allwinner,sun4i-a10-display-clk";
reg = <0x01c20104 0x4>;
clocks = <&pll3>, <&pll7>, <&pll5 1>;
clock-output-names = "de-be";
};
...

View File

@ -0,0 +1,152 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-gates-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Bus Gates Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
This additional argument passed to that clock is the offset of
the bit controlling this particular gate in the register.
compatible:
oneOf:
- const: allwinner,sun4i-a10-gates-clk
- const: allwinner,sun4i-a10-axi-gates-clk
- const: allwinner,sun4i-a10-ahb-gates-clk
- const: allwinner,sun5i-a10s-ahb-gates-clk
- const: allwinner,sun5i-a13-ahb-gates-clk
- const: allwinner,sun7i-a20-ahb-gates-clk
- const: allwinner,sun6i-a31-ahb1-gates-clk
- const: allwinner,sun8i-a23-ahb1-gates-clk
- const: allwinner,sun9i-a80-ahb0-gates-clk
- const: allwinner,sun9i-a80-ahb1-gates-clk
- const: allwinner,sun9i-a80-ahb2-gates-clk
- const: allwinner,sun4i-a10-apb0-gates-clk
- const: allwinner,sun5i-a10s-apb0-gates-clk
- const: allwinner,sun5i-a13-apb0-gates-clk
- const: allwinner,sun7i-a20-apb0-gates-clk
- const: allwinner,sun9i-a80-apb0-gates-clk
- const: allwinner,sun8i-a83t-apb0-gates-clk
- const: allwinner,sun4i-a10-apb1-gates-clk
- const: allwinner,sun5i-a13-apb1-gates-clk
- const: allwinner,sun5i-a10s-apb1-gates-clk
- const: allwinner,sun6i-a31-apb1-gates-clk
- const: allwinner,sun7i-a20-apb1-gates-clk
- const: allwinner,sun8i-a23-apb1-gates-clk
- const: allwinner,sun9i-a80-apb1-gates-clk
- const: allwinner,sun6i-a31-apb2-gates-clk
- const: allwinner,sun8i-a23-apb2-gates-clk
- const: allwinner,sun8i-a83t-bus-gates-clk
- const: allwinner,sun9i-a80-apbs-gates-clk
- const: allwinner,sun4i-a10-dram-gates-clk
- items:
- const: allwinner,sun5i-a13-dram-gates-clk
- const: allwinner,sun4i-a10-gates-clk
- items:
- const: allwinner,sun8i-h3-apb0-gates-clk
- const: allwinner,sun4i-a10-gates-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-indices:
minItems: 1
maxItems: 64
clock-output-names:
minItems: 1
maxItems: 64
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-indices
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c2005c {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-axi-gates-clk";
reg = <0x01c2005c 0x4>;
clocks = <&axi>;
clock-indices = <0>;
clock-output-names = "axi_dram";
};
- |
clk@1c20060 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-ahb-gates-clk";
reg = <0x01c20060 0x8>;
clocks = <&ahb>;
clock-indices = <0>, <1>,
<2>, <3>,
<4>, <5>, <6>,
<7>, <8>, <9>,
<10>, <11>, <12>,
<13>, <14>, <16>,
<17>, <18>, <20>,
<21>, <22>, <23>,
<24>, <25>, <26>,
<32>, <33>, <34>,
<35>, <36>, <37>,
<40>, <41>, <43>,
<44>, <45>,
<46>, <47>,
<50>, <52>;
clock-output-names = "ahb_usb0", "ahb_ehci0",
"ahb_ohci0", "ahb_ehci1",
"ahb_ohci1", "ahb_ss", "ahb_dma",
"ahb_bist", "ahb_mmc0", "ahb_mmc1",
"ahb_mmc2", "ahb_mmc3", "ahb_ms",
"ahb_nand", "ahb_sdram", "ahb_ace",
"ahb_emac", "ahb_ts", "ahb_spi0",
"ahb_spi1", "ahb_spi2", "ahb_spi3",
"ahb_pata", "ahb_sata", "ahb_gps",
"ahb_ve", "ahb_tvd", "ahb_tve0",
"ahb_tve1", "ahb_lcd0", "ahb_lcd1",
"ahb_csi0", "ahb_csi1", "ahb_hdmi",
"ahb_de_be0", "ahb_de_be1",
"ahb_de_fe0", "ahb_de_fe1",
"ahb_mp", "ahb_mali400";
};
- |
clk@1c20068 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-apb0-gates-clk";
reg = <0x01c20068 0x4>;
clocks = <&apb0>;
clock-indices = <0>, <1>,
<2>, <3>,
<5>, <6>,
<7>, <10>;
clock-output-names = "apb0_codec", "apb0_spdif",
"apb0_ac97", "apb0_iis",
"apb0_pio", "apb0_ir0",
"apb0_ir1", "apb0_keypad";
};
...

View File

@ -0,0 +1,63 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mbus-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 MBUS Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
enum:
- allwinner,sun5i-a13-mbus-clk
- allwinner,sun8i-a23-mbus-clk
reg:
maxItems: 1
clocks:
maxItems: 3
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c2015c {
#clock-cells = <0>;
compatible = "allwinner,sun5i-a13-mbus-clk";
reg = <0x01c2015c 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "mbus";
};
- |
clk@1c2015c {
#clock-cells = <0>;
compatible = "allwinner,sun8i-a23-mbus-clk";
reg = <0x01c2015c 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&pll5>;
clock-output-names = "mbus";
};
...

View File

@ -0,0 +1,87 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mmc-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Module 1 Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
There is three different outputs: the main clock, with the ID 0,
and the output and sample clocks, with the IDs 1 and 2,
respectively.
compatible:
enum:
- allwinner,sun4i-a10-mmc-clk
- allwinner,sun9i-a80-mmc-clk
reg:
maxItems: 1
clocks:
minItems: 2
maxItems: 3
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 3
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
if:
properties:
compatible:
contains:
const: allwinner,sun4i-a10-mmc-clk
then:
properties:
clocks:
maxItems: 3
else:
properties:
clocks:
maxItems: 2
examples:
- |
clk@1c20088 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
reg = <0x01c20088 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "mmc0",
"mmc0_output",
"mmc0_sample";
};
- |
clk@6000410 {
#clock-cells = <1>;
compatible = "allwinner,sun9i-a80-mmc-clk";
reg = <0x06000410 0x4>;
clocks = <&osc24M>, <&pll4>;
clock-output-names = "mmc0", "mmc0_output",
"mmc0_sample";
};
...

View File

@ -0,0 +1,80 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mod0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Module 0 Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
select:
properties:
compatible:
contains:
enum:
- allwinner,sun4i-a10-mod0-clk
- allwinner,sun9i-a80-mod0-clk
# The PRCM on the A31 and A23 will have the reg property missing,
# since it's set at the upper level node, and will be validated by
# PRCM's schema. Make sure we only validate standalone nodes.
required:
- compatible
- reg
properties:
"#clock-cells":
const: 0
compatible:
enum:
- allwinner,sun4i-a10-mod0-clk
- allwinner,sun9i-a80-mod0-clk
reg:
maxItems: 1
clocks:
# On the A80, the PRCM mod0 clocks have 2 parents.
minItems: 2
maxItems: 3
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20080 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c20080 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "nand";
};
- |
clk@8001454 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x08001454 0x4>;
clocks = <&osc32k>, <&osc24M>;
clock-output-names = "r_ir";
};
...

View File

@ -0,0 +1,57 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-mod1-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Module 1 Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-mod1-clk
reg:
maxItems: 1
clocks:
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/sun4i-a10-pll2.h>
clk@1c200c0 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod1-clk";
reg = <0x01c200c0 0x4>;
clocks = <&pll2 SUN4I_A10_PLL2_8X>,
<&pll2 SUN4I_A10_PLL2_4X>,
<&pll2 SUN4I_A10_PLL2_2X>,
<&pll2 SUN4I_A10_PLL2_1X>;
clock-output-names = "spdif";
};
...

View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-osc-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Gatable Oscillator Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-osc-clk
reg:
maxItems: 1
clock-frequency:
description: >
Frequency of the main oscillator.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clock-frequency
- clock-output-names
additionalProperties: false
examples:
- |
osc24M: clk@01c20050 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-osc-clk";
reg = <0x01c20050 0x4>;
clock-frequency = <24000000>;
clock-output-names = "osc24M";
};
...

View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll1-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 CPU PLL Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
enum:
- allwinner,sun4i-a10-pll1-clk
- allwinner,sun6i-a31-pll1-clk
- allwinner,sun8i-a23-pll1-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20000 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-pll1";
reg = <0x01c20000 0x4>;
clocks = <&osc24M>;
clock-output-names = "osc24M";
};
- |
clk@1c20000 {
#clock-cells = <0>;
compatible = "allwinner,sun6i-a31-pll1-clk";
reg = <0x01c20000 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll1";
};
- |
clk@1c20000 {
#clock-cells = <0>;
compatible = "allwinner,sun8i-a23-pll1-clk";
reg = <0x01c20000 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll1";
};
...

View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll3-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Video PLL Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-pll3-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20010 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-pll3-clk";
reg = <0x01c20010 0x4>;
clocks = <&osc3M>;
clock-output-names = "pll3";
};
...

View File

@ -0,0 +1,53 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll5-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 DRAM PLL Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
The first output is the DRAM clock output, the second is meant
for peripherals on the SoC.
compatible:
const: allwinner,sun4i-a10-pll5-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 2
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20020 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-pll5-clk";
reg = <0x01c20020 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll5_ddr", "pll5_other";
};
...

View File

@ -0,0 +1,53 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-pll6-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Peripheral PLL Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
The first output is the SATA clock output, the second is the
regular PLL output, the third is a PLL output at twice the rate.
compatible:
const: allwinner,sun4i-a10-pll6-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 3
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20028 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-pll6-clk";
reg = <0x01c20028 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll6_sata", "pll6_other", "pll6";
};
...

View File

@ -0,0 +1,77 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-tcon-ch0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 TCON Channel 0 Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
"#reset-cells":
const: 1
compatible:
enum:
- allwinner,sun4i-a10-tcon-ch0-clk
- allwinner,sun4i-a10-tcon-ch1-clk
reg:
maxItems: 1
clocks:
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
if:
properties:
compatible:
contains:
const: allwinner,sun4i-a10-tcon-ch0-clk
then:
required:
- "#reset-cells"
additionalProperties: false
examples:
- |
clk@1c20118 {
#clock-cells = <0>;
#reset-cells = <1>;
compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
reg = <0x01c20118 0x4>;
clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
clock-output-names = "tcon-ch0-sclk";
};
- |
clk@1c2012c {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
reg = <0x01c2012c 0x4>;
clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
clock-output-names = "tcon-ch1-sclk";
};
...

View File

@ -0,0 +1,166 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-usb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 USB Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
The additional ID argument passed to the clock shall refer to
the index of the output.
"#reset-cells":
const: 1
compatible:
enum:
- allwinner,sun4i-a10-usb-clk
- allwinner,sun5i-a13-usb-clk
- allwinner,sun6i-a31-usb-clk
- allwinner,sun8i-a23-usb-clk
- allwinner,sun8i-h3-usb-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
minItems: 2
maxItems: 8
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: allwinner,sun4i-a10-usb-clk
then:
properties:
clock-output-names:
maxItems: 3
- if:
properties:
compatible:
contains:
const: allwinner,sun5i-a13-usb-clk
then:
properties:
clock-output-names:
maxItems: 2
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-usb-clk
then:
properties:
clock-output-names:
maxItems: 6
- if:
properties:
compatible:
contains:
const: allwinner,sun8i-a23-usb-clk
then:
properties:
clock-output-names:
maxItems: 5
- if:
properties:
compatible:
contains:
const: allwinner,sun8i-h3-usb-clk
then:
properties:
clock-output-names:
maxItems: 8
examples:
- |
clk@1c200cc {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun4i-a10-usb-clk";
reg = <0x01c200cc 0x4>;
clocks = <&pll6 1>;
clock-output-names = "usb_ohci0", "usb_ohci1", "usb_phy";
};
- |
clk@1c200cc {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun5i-a13-usb-clk";
reg = <0x01c200cc 0x4>;
clocks = <&pll6 1>;
clock-output-names = "usb_ohci0", "usb_phy";
};
- |
clk@1c200cc {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun6i-a31-usb-clk";
reg = <0x01c200cc 0x4>;
clocks = <&osc24M>;
clock-output-names = "usb_phy0", "usb_phy1", "usb_phy2",
"usb_ohci0", "usb_ohci1",
"usb_ohci2";
};
- |
clk@1c200cc {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun8i-a23-usb-clk";
reg = <0x01c200cc 0x4>;
clocks = <&osc24M>;
clock-output-names = "usb_phy0", "usb_phy1", "usb_hsic",
"usb_hsic_12M", "usb_ohci0";
};
- |
clk@1c200cc {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun8i-h3-usb-clk";
reg = <0x01c200cc 0x4>;
clocks = <&osc24M>;
clock-output-names = "usb_phy0", "usb_phy1",
"usb_phy2", "usb_phy3",
"usb_ohci0", "usb_ohci1",
"usb_ohci2", "usb_ohci3";
};
...

View File

@ -0,0 +1,55 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-ve-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Video Engine Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
"#reset-cells":
const: 0
compatible:
const: allwinner,sun4i-a10-ve-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c2013c {
#clock-cells = <0>;
#reset-cells = <0>;
compatible = "allwinner,sun4i-a10-ve-clk";
reg = <0x01c2013c 0x4>;
clocks = <&pll4>;
clock-output-names = "ve";
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun5i-a13-ahb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A13 AHB Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun5i-a13-ahb-clk
reg:
maxItems: 1
clocks:
maxItems: 3
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
ahb@1c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun5i-a13-ahb-clk";
reg = <0x01c20054 0x4>;
clocks = <&axi>, <&cpu>, <&pll6 1>;
clock-output-names = "ahb";
};
...

View File

@ -0,0 +1,53 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun6i-a31-pll6-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A31 Peripheral PLL Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
The first output is the regular PLL output, the second is a PLL
output at twice the rate.
compatible:
const: allwinner,sun6i-a31-pll6-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 2
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20028 {
#clock-cells = <1>;
compatible = "allwinner,sun6i-a31-pll6-clk";
reg = <0x01c20028 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll6", "pll6x2";
};
...

View File

@ -0,0 +1,51 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun7i-a20-gmac-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A20 GMAC TX Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun7i-a20-gmac-clk
reg:
maxItems: 1
clocks:
maxItems: 2
description: >
The parent clocks shall be fixed rate dummy clocks at 25 MHz and
125 MHz, respectively.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20164 {
#clock-cells = <0>;
compatible = "allwinner,sun7i-a20-gmac-clk";
reg = <0x01c20164 0x4>;
clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
clock-output-names = "gmac_tx";
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun7i-a20-out-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A20 Output Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun7i-a20-out-clk
reg:
maxItems: 1
clocks:
maxItems: 3
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c201f0 {
#clock-cells = <0>;
compatible = "allwinner,sun7i-a20-out-clk";
reg = <0x01c201f0 0x4>;
clocks = <&osc24M_32k>, <&osc32k>, <&osc24M>;
clock-output-names = "clk_out_a";
};
...

View File

@ -0,0 +1,103 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun8i-h3-bus-gates-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Bus Gates Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
This additional argument passed to that clock is the offset of
the bit controlling this particular gate in the register.
compatible:
const: allwinner,sun8i-h3-bus-gates-clk
reg:
maxItems: 1
clocks:
maxItems: 4
clock-names:
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-indices:
minItems: 1
maxItems: 64
clock-output-names:
minItems: 1
maxItems: 64
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-indices
- clock-names
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c20060 {
#clock-cells = <1>;
compatible = "allwinner,sun8i-h3-bus-gates-clk";
reg = <0x01c20060 0x14>;
clocks = <&ahb1>, <&ahb2>, <&apb1>, <&apb2>;
clock-names = "ahb1", "ahb2", "apb1", "apb2";
clock-indices = <5>, <6>, <8>,
<9>, <10>, <13>,
<14>, <17>, <18>,
<19>, <20>,
<21>, <23>,
<24>, <25>,
<26>, <27>,
<28>, <29>,
<30>, <31>, <32>,
<35>, <36>, <37>,
<40>, <41>, <43>,
<44>, <52>, <53>,
<54>, <64>,
<65>, <69>, <72>,
<76>, <77>, <78>,
<96>, <97>, <98>,
<112>, <113>,
<114>, <115>,
<116>, <128>, <135>;
clock-output-names = "bus_ce", "bus_dma", "bus_mmc0",
"bus_mmc1", "bus_mmc2", "bus_nand",
"bus_sdram", "bus_gmac", "bus_ts",
"bus_hstimer", "bus_spi0",
"bus_spi1", "bus_otg",
"bus_otg_ehci0", "bus_ehci1",
"bus_ehci2", "bus_ehci3",
"bus_otg_ohci0", "bus_ohci1",
"bus_ohci2", "bus_ohci3", "bus_ve",
"bus_lcd0", "bus_lcd1", "bus_deint",
"bus_csi", "bus_tve", "bus_hdmi",
"bus_de", "bus_gpu", "bus_msgbox",
"bus_spinlock", "bus_codec",
"bus_spdif", "bus_pio", "bus_ths",
"bus_i2s0", "bus_i2s1", "bus_i2s2",
"bus_i2c0", "bus_i2c1", "bus_i2c2",
"bus_uart0", "bus_uart1",
"bus_uart2", "bus_uart3",
"bus_scr", "bus_ephy", "bus_dbg";
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-ahb-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 AHB Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun9i-a80-ahb-clk
reg:
maxItems: 1
clocks:
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@6000060 {
#clock-cells = <0>;
compatible = "allwinner,sun9i-a80-ahb-clk";
reg = <0x06000060 0x4>;
clocks = <&gt_clk>, <&pll4>, <&pll12>, <&pll12>;
clock-output-names = "ahb0";
};
...

View File

@ -0,0 +1,63 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-apb0-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 APB0 Bus Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
enum:
- allwinner,sun9i-a80-apb0-clk
- allwinner,sun9i-a80-apb1-clk
reg:
maxItems: 1
clocks:
maxItems: 2
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@6000070 {
#clock-cells = <0>;
compatible = "allwinner,sun9i-a80-apb0-clk";
reg = <0x06000070 0x4>;
clocks = <&osc24M>, <&pll4>;
clock-output-names = "apb0";
};
- |
clk@6000074 {
#clock-cells = <0>;
compatible = "allwinner,sun9i-a80-apb1-clk";
reg = <0x06000074 0x4>;
clocks = <&osc24M>, <&pll4>;
clock-output-names = "apb1";
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-cpus-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 CPUS Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun9i-a80-cpus-clk
reg:
maxItems: 1
clocks:
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@8001410 {
compatible = "allwinner,sun9i-a80-cpus-clk";
reg = <0x08001410 0x4>;
#clock-cells = <0>;
clocks = <&osc32k>, <&osc24M>, <&pll4>, <&pll3>;
clock-output-names = "cpus";
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-gt-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 GT Bus Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun9i-a80-gt-clk
reg:
maxItems: 1
clocks:
maxItems: 4
description: >
The parent order must match the hardware programming order.
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@0600005c {
#clock-cells = <0>;
compatible = "allwinner,sun9i-a80-gt-clk";
reg = <0x0600005c 0x4>;
clocks = <&osc24M>, <&pll4>, <&pll12>, <&pll12>;
clock-output-names = "gt";
};
...

View File

@ -0,0 +1,68 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-mmc-config-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 MMC Configuration Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
description: >
There is one clock/reset output per mmc controller. The number of
outputs is determined by the size of the address block, which is
related to the overall mmc block.
properties:
"#clock-cells":
const: 1
description: >
The additional ID argument passed to the clock shall refer to
the index of the output.
"#reset-cells":
const: 1
compatible:
const: allwinner,sun9i-a80-mmc-config-clk
reg:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
clock-output-names:
maxItems: 4
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@1c13000 {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun9i-a80-mmc-config-clk";
reg = <0x01c13000 0x10>;
clocks = <&ahb0_gates 8>;
resets = <&ahb0_resets 8>;
clock-output-names = "mmc0_config", "mmc1_config",
"mmc2_config", "mmc3_config";
};
...

View File

@ -0,0 +1,50 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-pll4-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 Peripheral PLL Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 0
compatible:
const: allwinner,sun9i-a80-pll4-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@600000c {
#clock-cells = <0>;
compatible = "allwinner,sun9i-a80-pll4-clk";
reg = <0x0600000c 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll4";
};
...

View File

@ -0,0 +1,60 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-usb-mod-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 USB Module Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
The additional ID argument passed to the clock shall refer to
the index of the output.
"#reset-cells":
const: 1
compatible:
const: allwinner,sun9i-a80-usb-mod-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 6
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@a08000 {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun9i-a80-usb-mod-clk";
reg = <0x00a08000 0x4>;
clocks = <&ahb1_gates 1>;
clock-output-names = "usb0_ahb", "usb_ohci0",
"usb1_ahb", "usb_ohci1",
"usb2_ahb", "usb_ohci2";
};
...

View File

@ -0,0 +1,60 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/allwinner,sun9i-a80-usb-phy-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A80 USB PHY Clock Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
"#clock-cells":
const: 1
description: >
The additional ID argument passed to the clock shall refer to
the index of the output.
"#reset-cells":
const: 1
compatible:
const: allwinner,sun9i-a80-usb-phy-clk
reg:
maxItems: 1
clocks:
maxItems: 1
clock-output-names:
maxItems: 6
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
- clocks
- clock-output-names
additionalProperties: false
examples:
- |
clk@a08004 {
#clock-cells = <1>;
#reset-cells = <1>;
compatible = "allwinner,sun9i-a80-usb-phy-clk";
reg = <0x00a08004 0x4>;
clocks = <&ahb1_gates 1>;
clock-output-names = "usb_phy0", "usb_hsic1_480M",
"usb_phy1", "usb_hsic2_480M",
"usb_phy2", "usb_hsic_12M";
};
...

View File

@ -1,60 +0,0 @@
STMicroelectronics STM32 Peripheral Reset Clock Controller
==========================================================
The RCC IP is both a reset and a clock controller.
RCC makes also power management (resume/supend and wakeup interrupt).
Please also refer to reset.txt for common reset controller binding usage.
Please also refer to clock-bindings.txt for common clock controller
binding usage.
Required properties:
- compatible: "st,stm32mp1-rcc", "syscon"
- reg: should be register base and length as documented in the datasheet
- #clock-cells: 1, device nodes should specify the clock in their
"clocks" property, containing a phandle to the clock device node,
an index specifying the clock to use.
- #reset-cells: Shall be 1
- interrupts: Should contain a general interrupt line and a interrupt line
to the wake-up of processor (CSTOP).
Example:
rcc: rcc@50000000 {
compatible = "st,stm32mp1-rcc", "syscon";
reg = <0x50000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>,
<GIC_SPI 145 IRQ_TYPE_NONE>;
};
Specifying clocks
=================
All available clocks are defined as preprocessor macros in
dt-bindings/clock/stm32mp1-clks.h header and can be used in device
tree sources.
Specifying softreset control of devices
=======================================
Device nodes should specify the reset channel required in their "resets"
property, containing a phandle to the reset device node and an index specifying
which channel to use.
The index is the bit number within the RCC registers bank, starting from RCC
base address.
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
Where bit_offset is the bit offset within the register.
For example on STM32MP1, for LTDC reset:
ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
= 0x180 / 4 * 32 + 0 = 3072
The list of valid indices for STM32MP1 is available in:
include/dt-bindings/reset-controller/stm32mp1-resets.h
This file implements defines like:
#define LTDC_R 3072

View File

@ -0,0 +1,79 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/clock/st,stm32mp1-rcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Reset Clock Controller Binding
maintainers:
- Gabriel Fernandez <gabriel.fernandez@st.com>
description: |
The RCC IP is both a reset and a clock controller.
RCC makes also power management (resume/supend and wakeup interrupt).
Please also refer to reset.txt for common reset controller binding usage.
This binding uses common clock bindings
Documentation/devicetree/bindings/clock/clock-bindings.txt
Specifying clocks
=================
All available clocks are defined as preprocessor macros in
dt-bindings/clock/stm32mp1-clks.h header and can be used in device
tree sources.
Specifying softreset control of devices
=======================================
Device nodes should specify the reset channel required in their "resets"
property, containing a phandle to the reset device node and an index specifying
which channel to use.
The index is the bit number within the RCC registers bank, starting from RCC
base address.
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
Where bit_offset is the bit offset within the register.
For example on STM32MP1, for LTDC reset:
ltdc = APB4_RSTSETR_offset / 4 * 32 + LTDC_bit_offset
= 0x180 / 4 * 32 + 0 = 3072
The list of valid indices for STM32MP1 is available in:
include/dt-bindings/reset-controller/stm32mp1-resets.h
This file implements defines like:
#define LTDC_R 3072
properties:
"#clock-cells":
const: 1
"#reset-cells":
const: 1
compatible:
items:
- const: st,stm32mp1-rcc
- const: syscon
reg:
maxItems: 1
required:
- "#clock-cells"
- "#reset-cells"
- compatible
- reg
additionalProperties: false
examples:
- |
rcc: rcc@50000000 {
compatible = "st,stm32mp1-rcc", "syscon";
reg = <0x50000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
...

View File

@ -1,225 +0,0 @@
Device Tree Clock bindings for arch-sunxi
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"allwinner,sun4i-a10-osc-clk" - for a gatable oscillator
"allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
"allwinner,sun4i-a10-pll3-clk" - for the video PLL clock on A10
"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
"allwinner,sun9i-a80-gt-clk" - for the GT bus clock on A80
"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-a10-axi-clk" - for the AXI clock
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
"allwinner,sun4i-a10-gates-clk" - for generic gates on all compatible SoCs
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
"allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13
"allwinner,sun9i-a80-ahb-clk" - for the AHB bus clocks on A80
"allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
"allwinner,sun9i-a80-cpus-clk" - for the CPUS on A80
"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
"allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
"allwinner,sun9i-a80-ahb1-gates-clk" - for the AHB1 gates on A80
"allwinner,sun9i-a80-ahb2-gates-clk" - for the AHB2 gates on A80
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
"allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
"allwinner,sun8i-a83t-apb0-gates-clk" - for the APB0 gates on A83T
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
"allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
"allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
"allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T
"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
"allwinner,sun4i-a10-display-clk" - for the display clocks on the A10
"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
"allwinner,sun5i-a13-dram-gates-clk" - for the DRAM gates on A13
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
"allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
"allwinner,sun9i-a80-mmc-config-clk" - for mmc gates + resets on A80
"allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
"allwinner,sun9i-a80-mod0-clk" - for module 0 (storage) clocks on A80
"allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
"allwinner,sun4i-a10-tcon-ch0-clk" - for the TCON channel 0 clock on the A10
"allwinner,sun4i-a10-tcon-ch1-clk" - for the TCON channel 1 clock on the A10
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
"allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
"allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
"allwinner,sun8i-a23-usb-clk" - for usb gates + resets on A23
"allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
"allwinner,sun6i-a31-display-clk" - for the display clocks
Required properties for all clocks:
- reg : shall be the control register address for the clock.
- clocks : shall be the input parent clock(s) phandle for the clock. For
multiplexed clocks, the list order must match the hardware
programming order.
- #clock-cells : from common clock binding; shall be set to 0 except for
the following compatibles where it shall be set to 1:
"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
"allwinner,*-usb-clk", "allwinner,*-mmc-clk",
"allwinner,*-mmc-config-clk"
- clock-output-names : shall be the corresponding names of the outputs.
If the clock module only has one output, the name shall be the
module name.
And "allwinner,*-usb-clk" clocks also require:
- reset-cells : shall be set to 1
The "allwinner,sun4i-a10-ve-clk" clock also requires:
- reset-cells : shall be set to 0
The "allwinner,sun9i-a80-mmc-config-clk" clock also requires:
- #reset-cells : shall be set to 1
- resets : shall be the reset control phandle for the mmc block.
For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
dummy clocks at 25 MHz and 125 MHz, respectively. See example.
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
offset of the bit controlling this particular gate in the register.
For the other clocks with "#clock-cells" = 1, the additional ID shall
refer to the index of the output.
For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
is the normal PLL6 output, or "pll6". The second output is rate doubled
PLL6, or "pll6x2".
The "allwinner,*-mmc-clk" clocks have three different outputs: the
main clock, with the ID 0, and the output and sample clocks, with the
IDs 1 and 2, respectively.
The "allwinner,sun9i-a80-mmc-config-clk" clock has one clock/reset output
per mmc controller. The number of outputs is determined by the size of
the address block, which is related to the overall mmc block.
For example:
osc24M: clk@1c20050 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-osc-clk";
reg = <0x01c20050 0x4>;
clocks = <&osc24M_fixed>;
clock-output-names = "osc24M";
};
pll1: clk@1c20000 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-pll1-clk";
reg = <0x01c20000 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll1";
};
pll5: clk@1c20020 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-pll5-clk";
reg = <0x01c20020 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll5_ddr", "pll5_other";
};
pll6: clk@1c20028 {
#clock-cells = <1>;
compatible = "allwinner,sun6i-a31-pll6-clk";
reg = <0x01c20028 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll6", "pll6x2";
};
cpu: cpu@1c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-cpu-clk";
reg = <0x01c20054 0x4>;
clocks = <&osc32k>, <&osc24M>, <&pll1>;
clock-output-names = "cpu";
};
mmc0_clk: clk@1c20088 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
reg = <0x01c20088 0x4>;
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "mmc0", "mmc0_output", "mmc0_sample";
};
mii_phy_tx_clk: clk@2 {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <25000000>;
clock-output-names = "mii_phy_tx";
};
gmac_int_tx_clk: clk@3 {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <125000000>;
clock-output-names = "gmac_int_tx";
};
gmac_clk: clk@1c20164 {
#clock-cells = <0>;
compatible = "allwinner,sun7i-a20-gmac-clk";
reg = <0x01c20164 0x4>;
/*
* The first clock must be fixed at 25MHz;
* the second clock must be fixed at 125MHz
*/
clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
clock-output-names = "gmac";
};
mmc_config_clk: clk@1c13000 {
compatible = "allwinner,sun9i-a80-mmc-config-clk";
reg = <0x01c13000 0x10>;
clocks = <&ahb0_gates 8>;
clock-names = "ahb";
resets = <&ahb0_resets 8>;
reset-names = "ahb";
#clock-cells = <1>;
#reset-cells = <1>;
clock-output-names = "mmc0_config", "mmc1_config",
"mmc2_config", "mmc3_config";
};

View File

@ -0,0 +1,102 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/st,stm32-dma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 DMA Controller bindings
description: |
The STM32 DMA is a general-purpose direct memory access controller capable of
supporting 8 independent DMA channels. Each channel can have up to 8 requests.
DMA clients connected to the STM32 DMA controller must use the format
described in the dma.txt file, using a four-cell specifier for each
channel: a phandle to the DMA controller plus the following four integer cells:
1. The channel id
2. The request line number
3. A 32bit mask specifying the DMA channel configuration which are device
dependent:
-bit 9: Peripheral Increment Address
0x0: no address increment between transfers
0x1: increment address between transfers
-bit 10: Memory Increment Address
0x0: no address increment between transfers
0x1: increment address between transfers
-bit 15: Peripheral Increment Offset Size
0x0: offset size is linked to the peripheral bus width
0x1: offset size is fixed to 4 (32-bit alignment)
-bit 16-17: Priority level
0x0: low
0x1: medium
0x2: high
0x3: very high
4. A 32bit bitfield value specifying DMA features which are device dependent:
-bit 0-1: DMA FIFO threshold selection
0x0: 1/4 full FIFO
0x1: 1/2 full FIFO
0x2: 3/4 full FIFO
0x3: full FIFO
maintainers:
- Amelie Delaunay <amelie.delaunay@st.com>
allOf:
- $ref: "dma-controller.yaml#"
properties:
"#dma-cells":
const: 4
compatible:
const: st,stm32-dma
reg:
maxItems: 1
clocks:
maxItems: 1
interrupts:
maxItems: 8
description: Should contain all of the per-channel DMA
interrupts in ascending order with respect to the
DMA channel index.
resets:
maxItems: 1
st,mem2mem:
$ref: /schemas/types.yaml#/definitions/flag
description: if defined, it indicates that the controller
supports memory-to-memory transfer
required:
- compatible
- reg
- clocks
- interrupts
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
dma-controller@40026400 {
compatible = "st,stm32-dma";
reg = <0x40026400 0x400>;
interrupts = <56>,
<57>,
<58>,
<59>,
<60>,
<68>,
<69>,
<70>;
clocks = <&clk_hclk>;
#dma-cells = <4>;
st,mem2mem;
resets = <&rcc 150>;
dma-requests = <8>;
};
...

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/st,stm32-dmamux.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 DMA MUX (DMA request router) bindings
maintainers:
- Amelie Delaunay <amelie.delaunay@st.com>
allOf:
- $ref: "dma-router.yaml#"
properties:
"#dma-cells":
const: 3
compatible:
const: st,stm32h7-dmamux
reg:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
required:
- compatible
- reg
- dma-masters
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
dma-router@40020800 {
compatible = "st,stm32h7-dmamux";
reg = <0x40020800 0x3c>;
#dma-cells = <3>;
dma-requests = <128>;
dma-channels = <16>;
dma-masters = <&dma1 &dma2>;
clocks = <&timer_clk>;
};
...

View File

@ -0,0 +1,105 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/st,stm32-mdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 MDMA Controller bindings
description: |
The STM32 MDMA is a general-purpose direct memory access controller capable of
supporting 64 independent DMA channels with 256 HW requests.
DMA clients connected to the STM32 MDMA controller must use the format
described in the dma.txt file, using a five-cell specifier for each channel:
a phandle to the MDMA controller plus the following five integer cells:
1. The request line number
2. The priority level
0x0: Low
0x1: Medium
0x2: High
0x3: Very high
3. A 32bit mask specifying the DMA channel configuration
-bit 0-1: Source increment mode
0x0: Source address pointer is fixed
0x2: Source address pointer is incremented after each data transfer
0x3: Source address pointer is decremented after each data transfer
-bit 2-3: Destination increment mode
0x0: Destination address pointer is fixed
0x2: Destination address pointer is incremented after each data transfer
0x3: Destination address pointer is decremented after each data transfer
-bit 8-9: Source increment offset size
0x0: byte (8bit)
0x1: half-word (16bit)
0x2: word (32bit)
0x3: double-word (64bit)
-bit 10-11: Destination increment offset size
0x0: byte (8bit)
0x1: half-word (16bit)
0x2: word (32bit)
0x3: double-word (64bit)
-bit 25-18: The number of bytes to be transferred in a single transfer
(min = 1 byte, max = 128 bytes)
-bit 29:28: Trigger Mode
0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
0x1: Each MDMA request triggers a block transfer (max 64K bytes)
0x2: Each MDMA request triggers a repeated block transfer
0x3: Each MDMA request triggers a linked list transfer
4. A 32bit value specifying the register to be used to acknowledge the request
if no HW ack signal is used by the MDMA client
5. A 32bit mask specifying the value to be written to acknowledge the request
if no HW ack signal is used by the MDMA client
maintainers:
- Amelie Delaunay <amelie.delaunay@st.com>
allOf:
- $ref: "dma-controller.yaml#"
properties:
"#dma-cells":
const: 5
compatible:
const: st,stm32h7-mdma
reg:
maxItems: 1
clocks:
maxItems: 1
interrupts:
maxItems: 1
resets:
maxItems: 1
st,ahb-addr-masks:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: Array of u32 mask to list memory devices addressed via AHB bus.
required:
- compatible
- reg
- clocks
- interrupts
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/reset/stm32mp1-resets.h>
dma-controller@52000000 {
compatible = "st,stm32h7-mdma";
reg = <0x52000000 0x1000>;
interrupts = <122>;
clocks = <&timer_clk>;
resets = <&rcc 992>;
#dma-cells = <5>;
dma-channels = <16>;
dma-requests = <32>;
st,ahb-addr-masks = <0x20000000>, <0x00000000>;
};
...

View File

@ -1,83 +0,0 @@
* STMicroelectronics STM32 DMA controller
The STM32 DMA is a general-purpose direct memory access controller capable of
supporting 8 independent DMA channels. Each channel can have up to 8 requests.
Required properties:
- compatible: Should be "st,stm32-dma"
- reg: Should contain DMA registers location and length. This should include
all of the per-channel registers.
- interrupts: Should contain all of the per-channel DMA interrupts in
ascending order with respect to the DMA channel index.
- clocks: Should contain the input clock of the DMA instance.
- #dma-cells : Must be <4>. See DMA client paragraph for more details.
Optional properties:
- dma-requests : Number of DMA requests supported.
- resets: Reference to a reset controller asserting the DMA controller
- st,mem2mem: boolean; if defined, it indicates that the controller supports
memory-to-memory transfer
Example:
dma2: dma-controller@40026400 {
compatible = "st,stm32-dma";
reg = <0x40026400 0x400>;
interrupts = <56>,
<57>,
<58>,
<59>,
<60>,
<68>,
<69>,
<70>;
clocks = <&clk_hclk>;
#dma-cells = <4>;
st,mem2mem;
resets = <&rcc 150>;
dma-requests = <8>;
};
* DMA client
DMA clients connected to the STM32 DMA controller must use the format
described in the dma.txt file, using a four-cell specifier for each
channel: a phandle to the DMA controller plus the following four integer cells:
1. The channel id
2. The request line number
3. A 32bit mask specifying the DMA channel configuration which are device
dependent:
-bit 9: Peripheral Increment Address
0x0: no address increment between transfers
0x1: increment address between transfers
-bit 10: Memory Increment Address
0x0: no address increment between transfers
0x1: increment address between transfers
-bit 15: Peripheral Increment Offset Size
0x0: offset size is linked to the peripheral bus width
0x1: offset size is fixed to 4 (32-bit alignment)
-bit 16-17: Priority level
0x0: low
0x1: medium
0x2: high
0x3: very high
4. A 32bit bitfield value specifying DMA features which are device dependent:
-bit 0-1: DMA FIFO threshold selection
0x0: 1/4 full FIFO
0x1: 1/2 full FIFO
0x2: 3/4 full FIFO
0x3: full FIFO
Example:
usart1: serial@40011000 {
compatible = "st,stm32-uart";
reg = <0x40011000 0x400>;
interrupts = <37>;
clocks = <&clk_pclk2>;
dmas = <&dma2 2 4 0x10400 0x3>,
<&dma2 7 5 0x10200 0x3>;
dma-names = "rx", "tx";
};

View File

@ -1,84 +0,0 @@
STM32 DMA MUX (DMA request router)
Required properties:
- compatible: "st,stm32h7-dmamux"
- reg: Memory map for accessing module
- #dma-cells: Should be set to <3>.
First parameter is request line number.
Second is DMA channel configuration
Third is Fifo threshold
For more details about the three cells, please see
stm32-dma.txt documentation binding file
- dma-masters: Phandle pointing to the DMA controllers.
Several controllers are allowed. Only "st,stm32-dma" DMA
compatible are supported.
Optional properties:
- dma-channels : Number of DMA requests supported.
- dma-requests : Number of DMAMUX requests supported.
- resets: Reference to a reset controller asserting the DMA controller
- clocks: Input clock of the DMAMUX instance.
Example:
/* DMA controller 1 */
dma1: dma-controller@40020000 {
compatible = "st,stm32-dma";
reg = <0x40020000 0x400>;
interrupts = <11>,
<12>,
<13>,
<14>,
<15>,
<16>,
<17>,
<47>;
clocks = <&timer_clk>;
#dma-cells = <4>;
st,mem2mem;
resets = <&rcc 150>;
dma-channels = <8>;
dma-requests = <8>;
};
/* DMA controller 1 */
dma2: dma@40020400 {
compatible = "st,stm32-dma";
reg = <0x40020400 0x400>;
interrupts = <56>,
<57>,
<58>,
<59>,
<60>,
<68>,
<69>,
<70>;
clocks = <&timer_clk>;
#dma-cells = <4>;
st,mem2mem;
resets = <&rcc 150>;
dma-channels = <8>;
dma-requests = <8>;
};
/* DMA mux */
dmamux1: dma-router@40020800 {
compatible = "st,stm32h7-dmamux";
reg = <0x40020800 0x3c>;
#dma-cells = <3>;
dma-requests = <128>;
dma-channels = <16>;
dma-masters = <&dma1 &dma2>;
clocks = <&timer_clk>;
};
/* DMA client */
usart1: serial@40011000 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40011000 0x400>;
interrupts = <37>;
clocks = <&timer_clk>;
dmas = <&dmamux1 41 0x414 0>,
<&dmamux1 42 0x414 0>;
dma-names = "rx", "tx";
};

View File

@ -1,94 +0,0 @@
* STMicroelectronics STM32 MDMA controller
The STM32 MDMA is a general-purpose direct memory access controller capable of
supporting 64 independent DMA channels with 256 HW requests.
Required properties:
- compatible: Should be "st,stm32h7-mdma"
- reg: Should contain MDMA registers location and length. This should include
all of the per-channel registers.
- interrupts: Should contain the MDMA interrupt.
- clocks: Should contain the input clock of the DMA instance.
- resets: Reference to a reset controller asserting the DMA controller.
- #dma-cells : Must be <5>. See DMA client paragraph for more details.
Optional properties:
- dma-channels: Number of DMA channels supported by the controller.
- dma-requests: Number of DMA request signals supported by the controller.
- st,ahb-addr-masks: Array of u32 mask to list memory devices addressed via
AHB bus.
Example:
mdma1: dma@52000000 {
compatible = "st,stm32h7-mdma";
reg = <0x52000000 0x1000>;
interrupts = <122>;
clocks = <&timer_clk>;
resets = <&rcc 992>;
#dma-cells = <5>;
dma-channels = <16>;
dma-requests = <32>;
st,ahb-addr-masks = <0x20000000>, <0x00000000>;
};
* DMA client
DMA clients connected to the STM32 MDMA controller must use the format
described in the dma.txt file, using a five-cell specifier for each channel:
a phandle to the MDMA controller plus the following five integer cells:
1. The request line number
2. The priority level
0x00: Low
0x01: Medium
0x10: High
0x11: Very high
3. A 32bit mask specifying the DMA channel configuration
-bit 0-1: Source increment mode
0x00: Source address pointer is fixed
0x10: Source address pointer is incremented after each data transfer
0x11: Source address pointer is decremented after each data transfer
-bit 2-3: Destination increment mode
0x00: Destination address pointer is fixed
0x10: Destination address pointer is incremented after each data
transfer
0x11: Destination address pointer is decremented after each data
transfer
-bit 8-9: Source increment offset size
0x00: byte (8bit)
0x01: half-word (16bit)
0x10: word (32bit)
0x11: double-word (64bit)
-bit 10-11: Destination increment offset size
0x00: byte (8bit)
0x01: half-word (16bit)
0x10: word (32bit)
0x11: double-word (64bit)
-bit 25-18: The number of bytes to be transferred in a single transfer
(min = 1 byte, max = 128 bytes)
-bit 29:28: Trigger Mode
0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
0x01: Each MDMA request triggers a block transfer (max 64K bytes)
0x10: Each MDMA request triggers a repeated block transfer
0x11: Each MDMA request triggers a linked list transfer
4. A 32bit value specifying the register to be used to acknowledge the request
if no HW ack signal is used by the MDMA client
5. A 32bit mask specifying the value to be written to acknowledge the request
if no HW ack signal is used by the MDMA client
Example:
i2c4: i2c@5c002000 {
compatible = "st,stm32f7-i2c";
reg = <0x5c002000 0x400>;
interrupts = <95>,
<96>;
clocks = <&timer_clk>;
#address-cells = <1>;
#size-cells = <0>;
dmas = <&mdma1 36 0x0 0x40008 0x0 0x0>,
<&mdma1 37 0x0 0x40002 0x0 0x0>;
dma-names = "rx", "tx";
status = "disabled";
};

View File

@ -4,6 +4,7 @@ Required properties:
- compatible :
- "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc
- "fsl,imx8qxp-lpi2c" for LPI2C compatible with the one integrated on i.MX8QXP soc
- "fsl,imx8qm-lpi2c" for LPI2C compatible with the one integrated on i.MX8QM soc
- reg : address and length of the lpi2c master registers
- interrupts : lpi2c interrupt
- clocks : lpi2c clock specifier

View File

@ -82,7 +82,7 @@ properties:
Must be the device tree identifier of the over-sampling
mode pins. As the line is active high, it should be marked
GPIO_ACTIVE_HIGH.
maxItems: 1
maxItems: 3
adi,sw-mode:
description:
@ -125,9 +125,9 @@ examples:
adi,conversion-start-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
adi,first-data-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>;
adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH
&gpio 23 GPIO_ACTIVE_HIGH
&gpio 26 GPIO_ACTIVE_HIGH>;
adi,oversampling-ratio-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>,
<&gpio 23 GPIO_ACTIVE_HIGH>,
<&gpio 26 GPIO_ACTIVE_HIGH>;
standby-gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
adi,sw-mode;
};

View File

@ -1,135 +0,0 @@
STMicroelectronics STM32 DFSDM ADC device driver
STM32 DFSDM ADC is a sigma delta analog-to-digital converter dedicated to
interface external sigma delta modulators to STM32 micro controllers.
It is mainly targeted for:
- Sigma delta modulators (motor control, metering...)
- PDM microphones (audio digital microphone)
It features up to 8 serial digital interfaces (SPI or Manchester) and
up to 4 filters on stm32h7 or 6 filters on stm32mp1.
Each child node match with a filter instance.
Contents of a STM32 DFSDM root node:
------------------------------------
Required properties:
- compatible: Should be one of:
"st,stm32h7-dfsdm"
"st,stm32mp1-dfsdm"
- reg: Offset and length of the DFSDM block register set.
- clocks: IP and serial interfaces clocking. Should be set according
to rcc clock ID and "clock-names".
- clock-names: Input clock name "dfsdm" must be defined,
"audio" is optional. If defined CLKOUT is based on the audio
clock, else "dfsdm" is used.
- #interrupt-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties:
- spi-max-frequency: Requested only for SPI master mode.
SPI clock OUT frequency (Hz). This clock must be set according
to "clock" property. Frequency must be a multiple of the rcc
clock frequency. If not, SPI CLKOUT frequency will not be
accurate.
- pinctrl-names: Set to "default".
- pinctrl-0: List of phandles pointing to pin configuration
nodes to set pins in mode of operation for dfsdm
on external pin.
Contents of a STM32 DFSDM child nodes:
--------------------------------------
Required properties:
- compatible: Must be:
"st,stm32-dfsdm-adc" for sigma delta ADCs
"st,stm32-dfsdm-dmic" for audio digital microphone.
- reg: Specifies the DFSDM filter instance used.
Valid values are from 0 to 3 on stm32h7, 0 to 5 on stm32mp1.
- interrupts: IRQ lines connected to each DFSDM filter instance.
- st,adc-channels: List of single-ended channels muxed for this ADC.
valid values:
"st,stm32h7-dfsdm" compatibility: 0 to 7.
- st,adc-channel-names: List of single-ended channel names.
- st,filter-order: SinC filter order from 0 to 5.
0: FastSinC
[1-5]: order 1 to 5.
For audio purpose it is recommended to use order 3 to 5.
- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers".
Required properties for "st,stm32-dfsdm-adc" compatibility:
- io-channels: From common IIO binding. Used to pipe external sigma delta
modulator or internal ADC output to DFSDM channel.
This is not required for "st,stm32-dfsdm-pdm" compatibility as
PDM microphone is binded in Audio DT node.
Required properties for "st,stm32-dfsdm-pdm" compatibility:
- #sound-dai-cells: Must be set to 0.
- dma: DMA controller phandle and DMA request line associated to the
filter instance (specified by the field "reg")
- dma-names: Must be "rx"
Optional properties:
- st,adc-channel-types: Single-ended channel input type.
- "SPI_R": SPI with data on rising edge (default)
- "SPI_F": SPI with data on falling edge
- "MANCH_R": manchester codec, rising edge = logic 0, falling edge = logic 1
- "MANCH_F": manchester codec, rising edge = logic 1, falling edge = logic 0
- st,adc-channel-clk-src: Conversion clock source.
- "CLKIN": external SPI clock (CLKIN x)
- "CLKOUT": internal SPI clock (CLKOUT) (default)
- "CLKOUT_F": internal SPI clock divided by 2 (falling edge).
- "CLKOUT_R": internal SPI clock divided by 2 (rising edge).
- st,adc-alt-channel: Must be defined if two sigma delta modulator are
connected on same SPI input.
If not set, channel n is connected to SPI input n.
If set, channel n is connected to SPI input n + 1.
- st,filter0-sync: Set to 1 to synchronize with DFSDM filter instance 0.
Used for multi microphones synchronization.
Example of a sigma delta adc connected on DFSDM SPI port 0
and a pdm microphone connected on DFSDM SPI port 1:
ads1202: simple_sd_adc@0 {
compatible = "ads1202";
#io-channel-cells = <1>;
};
dfsdm: dfsdm@40017000 {
compatible = "st,stm32h7-dfsdm";
reg = <0x40017000 0x400>;
clocks = <&rcc DFSDM1_CK>;
clock-names = "dfsdm";
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
dfsdm_adc0: filter@0 {
compatible = "st,stm32-dfsdm-adc";
#io-channel-cells = <1>;
reg = <0>;
interrupts = <110>;
st,adc-channels = <0>;
st,adc-channel-names = "sd_adc0";
st,adc-channel-types = "SPI_F";
st,adc-channel-clk-src = "CLKOUT";
io-channels = <&ads1202 0>;
st,filter-order = <3>;
};
dfsdm_pdm1: filter@1 {
compatible = "st,stm32-dfsdm-dmic";
reg = <1>;
interrupts = <111>;
dmas = <&dmamux1 102 0x400 0x00>;
dma-names = "rx";
st,adc-channels = <1>;
st,adc-channel-names = "dmic1";
st,adc-channel-types = "SPI_R";
st,adc-channel-clk-src = "CLKOUT";
st,filter-order = <5>;
};
}

View File

@ -0,0 +1,332 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/st,stm32-dfsdm-adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 DFSDM ADC device driver
maintainers:
- Fabrice Gasnier <fabrice.gasnier@st.com>
- Olivier Moysan <olivier.moysan@st.com>
description: |
STM32 DFSDM ADC is a sigma delta analog-to-digital converter dedicated to
interface external sigma delta modulators to STM32 micro controllers.
It is mainly targeted for:
- Sigma delta modulators (motor control, metering...)
- PDM microphones (audio digital microphone)
It features up to 8 serial digital interfaces (SPI or Manchester) and
up to 4 filters on stm32h7 or 6 filters on stm32mp1.
Each child node matches with a filter instance.
properties:
compatible:
enum:
- st,stm32h7-dfsdm
- st,stm32mp1-dfsdm
reg:
maxItems: 1
clocks:
items:
- description:
Internal clock used for DFSDM digital processing and control blocks.
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
"#size-cells":
const: 0
spi-max-frequency:
description:
SPI clock OUT frequency (Hz). Requested only for SPI master mode.
This clock must be set according to the "clock" property.
Frequency must be a multiple of the rcc clock frequency.
If not, SPI CLKOUT frequency will not be accurate.
maximum: 20000000
required:
- compatible
- reg
- clocks
- clock-names
- "#address-cells"
- "#size-cells"
patternProperties:
"^filter@[0-9]+$":
type: object
description: child node
properties:
compatible:
enum:
- st,stm32-dfsdm-adc
- st,stm32-dfsdm-dmic
reg:
description: Specifies the DFSDM filter instance used.
maxItems: 1
interrupts:
maxItems: 1
st,adc-channels:
description: |
List of single-ended channels muxed for this ADC.
On stm32h7 and stm32mp1:
- For st,stm32-dfsdm-adc: up to 8 channels numbered from 0 to 7.
- For st,stm32-dfsdm-dmic: 1 channel numbered from 0 to 7.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
minimum: 0
maximum: 7
st,adc-channel-names:
description: List of single-ended channel names.
allOf:
- $ref: /schemas/types.yaml#/definitions/string-array
st,filter-order:
description: |
SinC filter order from 0 to 5.
- 0: FastSinC
- [1-5]: order 1 to 5.
For audio purpose it is recommended to use order 3 to 5.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- items:
minimum: 0
maximum: 5
"#io-channel-cells":
const: 1
st,adc-channel-types:
description: |
Single-ended channel input type.
- "SPI_R": SPI with data on rising edge (default)
- "SPI_F": SPI with data on falling edge
- "MANCH_R": manchester codec, rising edge = logic 0, falling edge = logic 1
- "MANCH_F": manchester codec, rising edge = logic 1, falling edge = logic 0
items:
enum: [ SPI_R, SPI_F, MANCH_R, MANCH_F ]
allOf:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
st,adc-channel-clk-src:
description: |
Conversion clock source.
- "CLKIN": external SPI clock (CLKIN x)
- "CLKOUT": internal SPI clock (CLKOUT) (default)
- "CLKOUT_F": internal SPI clock divided by 2 (falling edge).
- "CLKOUT_R": internal SPI clock divided by 2 (rising edge).
items:
enum: [ CLKIN, CLKOUT, CLKOUT_F, CLKOUT_R ]
allOf:
- $ref: /schemas/types.yaml#/definitions/non-unique-string-array
st,adc-alt-channel:
description:
Must be defined if two sigma delta modulators are
connected on same SPI input.
If not set, channel n is connected to SPI input n.
If set, channel n is connected to SPI input n + 1.
type: boolean
st,filter0-sync:
description:
Set to 1 to synchronize with DFSDM filter instance 0.
Used for multi microphones synchronization.
type: boolean
dmas:
maxItems: 1
dma-names:
items:
- const: rx
required:
- compatible
- reg
- interrupts
- st,adc-channels
- st,adc-channel-names
- st,filter-order
- "#io-channel-cells"
allOf:
- if:
properties:
compatible:
contains:
const: st,stm32-dfsdm-adc
- then:
properties:
st,adc-channels:
minItems: 1
maxItems: 8
st,adc-channel-names:
minItems: 1
maxItems: 8
st,adc-channel-types:
minItems: 1
maxItems: 8
st,adc-channel-clk-src:
minItems: 1
maxItems: 8
io-channels:
description:
From common IIO binding. Used to pipe external sigma delta
modulator or internal ADC output to DFSDM channel.
This is not required for "st,stm32-dfsdm-pdm" compatibility as
PDM microphone is binded in Audio DT node.
required:
- io-channels
- if:
properties:
compatible:
contains:
const: st,stm32-dfsdm-dmic
- then:
properties:
st,adc-channels:
maxItems: 1
st,adc-channel-names:
maxItems: 1
st,adc-channel-types:
maxItems: 1
st,adc-channel-clk-src:
maxItems: 1
required:
- dmas
- dma-names
patternProperties:
"^dfsdm-dai+$":
type: object
description: child node
properties:
"#sound-dai-cells":
const: 0
io-channels:
description:
From common IIO binding. Used to pipe external sigma delta
modulator or internal ADC output to DFSDM channel.
required:
- "#sound-dai-cells"
- io-channels
allOf:
- if:
properties:
compatible:
contains:
const: st,stm32h7-dfsdm
- then:
patternProperties:
"^filter@[0-9]+$":
properties:
reg:
items:
minimum: 0
maximum: 3
- if:
properties:
compatible:
contains:
const: st,stm32mp1-dfsdm
- then:
patternProperties:
"^filter@[0-9]+$":
properties:
reg:
items:
minimum: 0
maximum: 5
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
dfsdm: dfsdm@4400d000 {
compatible = "st,stm32mp1-dfsdm";
reg = <0x4400d000 0x800>;
clocks = <&rcc DFSDM_K>, <&rcc ADFSDM_K>;
clock-names = "dfsdm", "audio";
#address-cells = <1>;
#size-cells = <0>;
dfsdm0: filter@0 {
compatible = "st,stm32-dfsdm-dmic";
reg = <0>;
interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&dmamux1 101 0x400 0x01>;
dma-names = "rx";
#io-channel-cells = <1>;
st,adc-channels = <1>;
st,adc-channel-names = "dmic0";
st,adc-channel-types = "SPI_R";
st,adc-channel-clk-src = "CLKOUT";
st,filter-order = <5>;
asoc_pdm0: dfsdm-dai {
compatible = "st,stm32h7-dfsdm-dai";
#sound-dai-cells = <0>;
io-channels = <&dfsdm0 0>;
};
};
dfsdm_pdm1: filter@1 {
compatible = "st,stm32-dfsdm-adc";
reg = <1>;
interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&dmamux1 102 0x400 0x01>;
dma-names = "rx";
#io-channel-cells = <1>;
st,adc-channels = <2 3>;
st,adc-channel-names = "in2", "in3";
st,adc-channel-types = "SPI_R", "SPI_R";
st,adc-channel-clk-src = "CLKOUT_F", "CLKOUT_F";
io-channels = <&sd_adc2 &sd_adc3>;
st,filter-order = <1>;
};
};
...

View File

@ -1,173 +1 @@
* Common leds properties.
LED and flash LED devices provide the same basic functionality as current
regulators, but extended with LED and flash LED specific features like
blinking patterns, flash timeout, flash faults and external flash strobe mode.
Many LED devices expose more than one current output that can be connected
to one or more discrete LED component. Since the arrangement of connections
can influence the way of the LED device initialization, the LED components
have to be tightly coupled with the LED device binding. They are represented
by child nodes of the parent LED device binding.
Optional properties for child nodes:
- led-sources : List of device current outputs the LED is connected to. The
outputs are identified by the numbers that must be defined
in the LED device binding documentation.
- function: LED functon. Use one of the LED_FUNCTION_* prefixed definitions
from the header include/dt-bindings/leds/common.h.
If there is no matching LED_FUNCTION available, add a new one.
- color : Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions
from the header include/dt-bindings/leds/common.h.
If there is no matching LED_COLOR_ID available, add a new one.
- function-enumerator: Integer to be used when more than one instance
of the same function is needed, differing only with
an ordinal number.
- label : The label for this LED. If omitted, the label is taken from the node
name (excluding the unit address). It has to uniquely identify
a device, i.e. no other LED class device can be assigned the same
label. This property is deprecated - use 'function' and 'color'
properties instead. function-enumerator has no effect when this
property is present.
- default-state : The initial state of the LED. Valid values are "on", "off",
and "keep". If the LED is already on or off and the default-state property is
set the to same value, then no glitch should be produced where the LED
momentarily turns off (or on). The "keep" setting will keep the LED at
whatever its current state is, without producing a glitch. The default is
off if this property is not present.
- linux,default-trigger : This parameter, if present, is a
string defining the trigger assigned to the LED. Current triggers are:
"backlight" - LED will act as a back-light, controlled by the framebuffer
system
"default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/leds/leds-gpio.txt)
"heartbeat" - LED "double" flashes at a load average based rate
"disk-activity" - LED indicates disk activity
"ide-disk" - LED indicates IDE disk activity (deprecated),
in new implementations use "disk-activity"
"timer" - LED flashes at a fixed, configurable rate
"pattern" - LED alters the brightness for the specified duration with one
software timer (requires "led-pattern" property)
- led-pattern : Array of integers with default pattern for certain triggers.
Each trigger may parse this property differently:
- one-shot : two numbers specifying delay on and delay off (in ms),
- timer : two numbers specifying delay on and delay off (in ms),
- pattern : the pattern is given by a series of tuples, of
brightness and duration (in ms). The exact format is
described in:
Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
- led-max-microamp : Maximum LED supply current in microamperes. This property
can be made mandatory for the board configurations
introducing a risk of hardware damage in case an excessive
current is set.
For flash LED controllers with configurable current this
property is mandatory for the LEDs in the non-flash modes
(e.g. torch or indicator).
- panic-indicator : This property specifies that the LED should be used,
if at all possible, as a panic indicator.
- trigger-sources : List of devices which should be used as a source triggering
this LED activity. Some LEDs can be related to a specific
device and should somehow indicate its state. E.g. USB 2.0
LED may react to device(s) in a USB 2.0 port(s).
Another common example is switch or router with multiple
Ethernet ports each of them having its own LED assigned
(assuming they are not hardwired). In such cases this
property should contain phandle(s) of related source
device(s).
In many cases LED can be related to more than one device
(e.g. one USB LED vs. multiple USB ports). Each source
should be represented by a node in the device tree and be
referenced by a phandle and a set of phandle arguments. A
length of arguments should be specified by the
#trigger-source-cells property in the source node.
Required properties for flash LED child nodes:
- flash-max-microamp : Maximum flash LED supply current in microamperes.
- flash-max-timeout-us : Maximum timeout in microseconds after which the flash
LED is turned off.
For controllers that have no configurable current the flash-max-microamp
property can be omitted.
For controllers that have no configurable timeout the flash-max-timeout-us
property can be omitted.
* Trigger source providers
Each trigger source should be represented by a device tree node. It may be e.g.
a USB port or an Ethernet device.
Required properties for trigger source:
- #trigger-source-cells : Number of cells in a source trigger. Typically 0 for
nodes of simple trigger sources (e.g. a specific USB
port).
* Examples
#include <dt-bindings/leds/common.h>
led-controller@0 {
compatible = "gpio-leds";
led0 {
function = LED_FUNCTION_STATUS;
linux,default-trigger = "heartbeat";
gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
};
led1 {
function = LED_FUNCTION_USB;
gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
trigger-sources = <&ohci_port1>, <&ehci_port1>;
};
};
led-controller@0 {
compatible = "maxim,max77693-led";
led {
function = LED_FUNCTION_FLASH;
color = <LED_COLOR_ID_WHITE>;
led-sources = <0>, <1>;
led-max-microamp = <50000>;
flash-max-microamp = <320000>;
flash-max-timeout-us = <500000>;
};
};
led-controller@30 {
compatible = "panasonic,an30259a";
reg = <0x30>;
#address-cells = <1>;
#size-cells = <0>;
led@1 {
reg = <1>;
linux,default-trigger = "heartbeat";
function = LED_FUNCTION_INDICATOR;
function-enumerator = <1>;
};
led@2 {
reg = <2>;
function = LED_FUNCTION_INDICATOR;
function-enumerator = <2>;
};
led@3 {
reg = <3>;
function = LED_FUNCTION_INDICATOR;
function-enumerator = <3>;
};
};
This file has moved to ./common.yaml.

View File

@ -0,0 +1,228 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common leds properties
maintainers:
- Jacek Anaszewski <jacek.anaszewski@gmail.com>
- Pavel Machek <pavel@ucw.cz>
description:
LED and flash LED devices provide the same basic functionality as current
regulators, but extended with LED and flash LED specific features like
blinking patterns, flash timeout, flash faults and external flash strobe mode.
Many LED devices expose more than one current output that can be connected
to one or more discrete LED component. Since the arrangement of connections
can influence the way of the LED device initialization, the LED components
have to be tightly coupled with the LED device binding. They are represented
by child nodes of the parent LED device binding.
properties:
led-sources:
description:
List of device current outputs the LED is connected to. The outputs are
identified by the numbers that must be defined in the LED device binding
documentation.
$ref: /schemas/types.yaml#definitions/uint32-array
function:
description:
LED function. Use one of the LED_FUNCTION_* prefixed definitions
from the header include/dt-bindings/leds/common.h. If there is no
matching LED_FUNCTION available, add a new one.
$ref: /schemas/types.yaml#definitions/string
color:
description:
Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions from
the header include/dt-bindings/leds/common.h. If there is no matching
LED_COLOR_ID available, add a new one.
allOf:
- $ref: /schemas/types.yaml#definitions/uint32
minimum: 0
maximum: 8
function-enumerator:
description:
Integer to be used when more than one instance of the same function is
needed, differing only with an ordinal number.
$ref: /schemas/types.yaml#definitions/uint32
label:
description:
The label for this LED. If omitted, the label is taken from the node name
(excluding the unit address). It has to uniquely identify a device, i.e.
no other LED class device can be assigned the same label. This property is
deprecated - use 'function' and 'color' properties instead.
function-enumerator has no effect when this property is present.
default-state:
description:
The initial state of the LED. If the LED is already on or off and the
default-state property is set the to same value, then no glitch should be
produced where the LED momentarily turns off (or on). The "keep" setting
will keep the LED at whatever its current state is, without producing a
glitch.
allOf:
- $ref: /schemas/types.yaml#definitions/string
enum:
- on
- off
- keep
default: off
linux,default-trigger:
description:
This parameter, if present, is a string defining the trigger assigned to
the LED.
allOf:
- $ref: /schemas/types.yaml#definitions/string
enum:
# LED will act as a back-light, controlled by the framebuffer system
- backlight
# LED will turn on (but for leds-gpio see "default-state" property in
# Documentation/devicetree/bindings/leds/leds-gpio.txt)
- default-on
# LED "double" flashes at a load average based rate
- heartbeat
# LED indicates disk activity
- disk-activity
# LED indicates IDE disk activity (deprecated), in new implementations
# use "disk-activity"
- ide-disk
# LED flashes at a fixed, configurable rate
- timer
# LED alters the brightness for the specified duration with one software
# timer (requires "led-pattern" property)
- pattern
led-pattern:
description: |
Array of integers with default pattern for certain triggers.
Each trigger may parse this property differently:
- one-shot : two numbers specifying delay on and delay off (in ms),
- timer : two numbers specifying delay on and delay off (in ms),
- pattern : the pattern is given by a series of tuples, of
brightness and duration (in ms). The exact format is
described in:
Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
allOf:
- $ref: /schemas/types.yaml#definitions/uint32-matrix
items:
minItems: 2
maxItems: 2
led-max-microamp:
description:
Maximum LED supply current in microamperes. This property can be made
mandatory for the board configurations introducing a risk of hardware
damage in case an excessive current is set.
For flash LED controllers with configurable current this property is
mandatory for the LEDs in the non-flash modes (e.g. torch or indicator).
panic-indicator:
description:
This property specifies that the LED should be used, if at all possible,
as a panic indicator.
type: boolean
trigger-sources:
description: |
List of devices which should be used as a source triggering this LED
activity. Some LEDs can be related to a specific device and should somehow
indicate its state. E.g. USB 2.0 LED may react to device(s) in a USB 2.0
port(s).
Another common example is switch or router with multiple Ethernet ports
each of them having its own LED assigned (assuming they are not
hardwired). In such cases this property should contain phandle(s) of
related source device(s).
In many cases LED can be related to more than one device (e.g. one USB LED
vs. multiple USB ports). Each source should be represented by a node in
the device tree and be referenced by a phandle and a set of phandle
arguments. A length of arguments should be specified by the
#trigger-source-cells property in the source node.
$ref: /schemas/types.yaml#definitions/phandle-array
# Required properties for flash LED child nodes:
flash-max-microamp:
description:
Maximum flash LED supply current in microamperes. Required for flash LED
nodes with configurable current.
flash-max-timeout-us:
description:
Maximum timeout in microseconds after which the flash LED is turned off.
Required for flash LED nodes with configurable timeout.
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
led-controller {
compatible = "gpio-leds";
led0 {
function = LED_FUNCTION_STATUS;
linux,default-trigger = "heartbeat";
gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
};
led1 {
function = LED_FUNCTION_USB;
gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
trigger-sources = <&ohci_port1>, <&ehci_port1>;
};
};
led-controller@0 {
compatible = "maxim,max77693-led";
reg = <0 0x100>;
led {
function = LED_FUNCTION_FLASH;
color = <LED_COLOR_ID_WHITE>;
led-sources = <0>, <1>;
led-max-microamp = <50000>;
flash-max-microamp = <320000>;
flash-max-timeout-us = <500000>;
};
};
i2c {
#address-cells = <1>;
#size-cells = <0>;
led-controller@30 {
compatible = "panasonic,an30259a";
reg = <0x30>;
#address-cells = <1>;
#size-cells = <0>;
led@1 {
reg = <1>;
linux,default-trigger = "heartbeat";
function = LED_FUNCTION_INDICATOR;
function-enumerator = <1>;
};
led@2 {
reg = <2>;
function = LED_FUNCTION_INDICATOR;
function-enumerator = <2>;
};
led@3 {
reg = <3>;
function = LED_FUNCTION_INDICATOR;
function-enumerator = <3>;
};
};
};
...

View File

@ -8,7 +8,7 @@ Required properties:
- compatible: should be "ir-spi-led".
Optional properties:
- duty-cycle: 8 bit balue that represents the percentage of one period
- duty-cycle: 8 bit value that represents the percentage of one period
in which the signal is active. It can be 50, 60, 70, 75, 80 or 90.
- led-active-low: boolean value that specifies whether the output is
negated with a NOT gate.

View File

@ -1,75 +0,0 @@
LEDs connected to GPIO lines
Required properties:
- compatible : should be "gpio-leds".
Each LED is represented as a sub-node of the gpio-leds device. Each
node's name represents the name of the corresponding LED.
LED sub-node properties:
- gpios : Should specify the LED's GPIO, see "gpios property" in
Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
indicated using flags in the GPIO specifier.
- function : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- color : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt (deprecated)
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- default-state: (optional) The initial state of the LED.
see Documentation/devicetree/bindings/leds/common.txt
- retain-state-suspended: (optional) The suspend state can be retained.Such
as charge-led gpio.
- retain-state-shutdown: (optional) Retain the state of the LED on shutdown.
Useful in BMC systems, for example when the BMC is rebooted while the host
remains up.
- panic-indicator : (optional)
see Documentation/devicetree/bindings/leds/common.txt
Examples:
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
leds {
compatible = "gpio-leds";
led0 {
gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
linux,default-trigger = "disk-activity";
function = LED_FUNCTION_DISK;
};
led1 {
gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
/* Keep LED on if BIOS detected hardware fault */
default-state = "keep";
function = LED_FUNCTION_FAULT;
};
};
run-control {
compatible = "gpio-leds";
led0 {
gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_RED>;
default-state = "off";
};
led1 {
gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_GREEN>;
default-state = "on";
};
};
leds {
compatible = "gpio-leds";
led0 {
gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "max8903-charger-charging";
retain-state-suspended;
function = LED_FUNCTION_CHARGE;
};
};

View File

@ -0,0 +1,86 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LEDs connected to GPIO lines
maintainers:
- Jacek Anaszewski <jacek.anaszewski@gmail.com>
- Pavel Machek <pavel@ucw.cz>
description:
Each LED is represented as a sub-node of the gpio-leds device. Each
node's name represents the name of the corresponding LED.
properties:
compatible:
const: gpio-leds
patternProperties:
# The first form is preferred, but fall back to just 'led' anywhere in the
# node name to at least catch some child nodes.
"(^led-[0-9a-f]$|led)":
type: object
allOf:
- $ref: common.yaml#
properties:
gpios:
maxItems: 1
retain-state-suspended:
description:
The suspend state can be retained.Such as charge-led gpio.
type: boolean
retain-state-shutdown:
description:
Retain the state of the LED on shutdown. Useful in BMC systems, for
example when the BMC is rebooted while the host remains up.
type: boolean
required:
- gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/leds/common.h>
leds {
compatible = "gpio-leds";
led-0 {
gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
linux,default-trigger = "disk-activity";
function = LED_FUNCTION_DISK;
};
led-1 {
gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
/* Keep LED on if BIOS detected hardware fault */
default-state = "keep";
function = LED_FUNCTION_FAULT;
};
};
run-control {
compatible = "gpio-leds";
led-0 {
gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_RED>;
default-state = "off";
};
led-1 {
gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_GREEN>;
default-state = "on";
};
};
...

View File

@ -0,0 +1,24 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/trigger-source.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Trigger source providers
maintainers:
- Jacek Anaszewski <jacek.anaszewski@gmail.com>
- Pavel Machek <pavel@ucw.cz>
description:
Each trigger source provider should be represented by a device tree node. It
may be e.g. a USB port or an Ethernet device.
properties:
'#trigger-source-cells':
description:
Number of cells in a source trigger. Typically 0 for nodes of simple
trigger sources (e.g. a specific USB port).
enum: [ 0, 1 ]
...

View File

@ -0,0 +1,83 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/allwinner,sun4i-a10-video-engine.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Video Engine Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:
enum:
- allwinner,sun4i-a10-video-engine
- allwinner,sun5i-a13-video-engine
- allwinner,sun7i-a20-video-engine
- allwinner,sun8i-a33-video-engine
- allwinner,sun8i-h3-video-engine
- allwinner,sun50i-a64-video-engine
- allwinner,sun50i-h5-video-engine
- allwinner,sun50i-h6-video-engine
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: Bus Clock
- description: Module Clock
- description: RAM Clock
clock-names:
items:
- const: ahb
- const: mod
- const: ram
resets:
maxItems: 1
allwinner,sram:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: Phandle to the device SRAM
memory-region:
description:
CMA pool to use for buffers allocation instead of the default
CMA pool.
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- resets
- allwinner,sram
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/sun7i-a20-ccu.h>
#include <dt-bindings/reset/sun4i-a10-ccu.h>
video-codec@1c0e000 {
compatible = "allwinner,sun7i-a20-video-engine";
reg = <0x01c0e000 0x1000>;
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_AHB_VE>, <&ccu CLK_VE>,
<&ccu CLK_DRAM_VE>;
clock-names = "ahb", "mod", "ram";
resets = <&ccu RST_VE>;
allwinner,sram = <&ve_sram 1>;
};
...

View File

@ -0,0 +1,115 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-csi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A31 CMOS Sensor Interface (CSI) Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
properties:
compatible:
enum:
- allwinner,sun6i-a31-csi
- allwinner,sun8i-a83t-csi
- allwinner,sun8i-h3-csi
- allwinner,sun8i-v3s-csi
- allwinner,sun50i-a64-csi
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: Bus Clock
- description: Module Clock
- description: DRAM Clock
clock-names:
items:
- const: bus
- const: mod
- const: ram
resets:
maxItems: 1
# See ./video-interfaces.txt for details
port:
type: object
properties:
endpoint:
type: object
properties:
remote-endpoint: true
bus-width:
enum: [ 8, 10, 12, 16 ]
pclk-sample: true
hsync-active: true
vsync-active: true
required:
- bus-width
- remote-endpoint
required:
- endpoint
additionalProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- resets
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/sun8i-v3s-ccu.h>
#include <dt-bindings/reset/sun8i-v3s-ccu.h>
csi1: csi@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x1000>;
interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_CSI>,
<&ccu CLK_CSI1_SCLK>,
<&ccu CLK_DRAM_CSI>;
clock-names = "bus",
"mod",
"ram";
resets = <&ccu RST_BUS_CSI>;
port {
/* Parallel bus endpoint */
csi1_ep: endpoint {
remote-endpoint = <&adv7611_ep>;
bus-width = <16>;
/*
* If hsync-active/vsync-active are missing,
* embedded BT.656 sync is used.
*/
hsync-active = <0>; /* Active low */
vsync-active = <0>; /* Active low */
pclk-sample = <1>; /* Rising */
};
};
};
...

View File

@ -1,57 +0,0 @@
Device-tree bindings for the VPU found in Allwinner SoCs, referred to as the
Video Engine (VE) in Allwinner literature.
The VPU can only access the first 256 MiB of DRAM, that are DMA-mapped starting
from the DRAM base. This requires specific memory allocation and handling.
Required properties:
- compatible : must be one of the following compatibles:
- "allwinner,sun4i-a10-video-engine"
- "allwinner,sun5i-a13-video-engine"
- "allwinner,sun7i-a20-video-engine"
- "allwinner,sun8i-a33-video-engine"
- "allwinner,sun8i-h3-video-engine"
- "allwinner,sun50i-a64-video-engine"
- "allwinner,sun50i-h5-video-engine"
- "allwinner,sun50i-h6-video-engine"
- reg : register base and length of VE;
- clocks : list of clock specifiers, corresponding to entries in
the clock-names property;
- clock-names : should contain "ahb", "mod" and "ram" entries;
- resets : phandle for reset;
- interrupts : VE interrupt number;
- allwinner,sram : SRAM region to use with the VE.
Optional properties:
- memory-region : CMA pool to use for buffers allocation instead of the
default CMA pool.
Example:
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
/* Address must be kept in the lower 256 MiBs of DRAM for VE. */
cma_pool: default-pool {
compatible = "shared-dma-pool";
size = <0x6000000>;
alloc-ranges = <0x4a000000 0x6000000>;
reusable;
linux,cma-default;
};
};
video-codec@1c0e000 {
compatible = "allwinner,sun7i-a20-video-engine";
reg = <0x01c0e000 0x1000>;
clocks = <&ccu CLK_AHB_VE>, <&ccu CLK_VE>,
<&ccu CLK_DRAM_VE>;
clock-names = "ahb", "mod", "ram";
resets = <&ccu RST_VE>;
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
allwinner,sram = <&ve_sram 1>;
};

View File

@ -1,4 +1,4 @@
Samsung S5P/EXYNOS SoC series JPEG codec
Samsung S5P/Exynos SoC series JPEG codec
Required properties:

View File

@ -1,6 +1,6 @@
* Samsung Exynos5 G-Scaler device
G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
G-Scaler is used for scaling and color space conversion on Exynos5 SoCs.
Required properties:
- compatible: should be one of

View File

@ -1,86 +0,0 @@
Renesas Capture Engine Unit (CEU)
----------------------------------------------
The Capture Engine Unit is the image capture interface found in the Renesas
SH Mobile, R-Mobile and RZ SoCs.
The interface supports a single parallel input with data bus width of 8 or 16
bits.
Required properties:
- compatible: Shall be one of the following values:
"renesas,r7s72100-ceu" for CEU units found in RZ/A1H and RZ/A1M SoCs
"renesas,r8a7740-ceu" for CEU units found in R-Mobile A1 R8A7740 SoCs
- reg: Registers address base and size.
- interrupts: The interrupt specifier.
The CEU supports a single parallel input and should contain a single 'port'
subnode with a single 'endpoint'. Connection to input devices are modeled
according to the video interfaces OF bindings specified in:
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
Optional endpoint properties applicable to parallel input bus described in
the above mentioned "video-interfaces.txt" file are supported.
- hsync-active: See [1] for description. If property is not present,
default is active high.
- vsync-active: See [1] for description. If property is not present,
default is active high.
- bus-width: See [1] for description. Accepted values are '8' and '16'.
If property is not present, default is '8'.
- field-even-active: See [1] for description. If property is not present,
an even field is identified by a logic 0 (active-low signal).
Example:
The example describes the connection between the Capture Engine Unit and an
OV7670 image sensor connected to i2c1 interface.
ceu: ceu@e8210000 {
reg = <0xe8210000 0x209c>;
compatible = "renesas,r7s72100-ceu";
interrupts = <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&vio_pins>;
status = "okay";
port {
ceu_in: endpoint {
remote-endpoint = <&ov7670_out>;
hsync-active = <1>;
vsync-active = <0>;
};
};
};
i2c1: i2c@fcfee400 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
status = "okay";
clock-frequency = <100000>;
ov7670: camera@21 {
compatible = "ovti,ov7670";
reg = <0x21>;
pinctrl-names = "default";
pinctrl-0 = <&vio_pins>;
reset-gpios = <&port3 11 GPIO_ACTIVE_LOW>;
powerdown-gpios = <&port3 12 GPIO_ACTIVE_HIGH>;
port {
ov7670_out: endpoint {
remote-endpoint = <&ceu_in>;
hsync-active = <1>;
vsync-active = <0>;
};
};
};
};

View File

@ -0,0 +1,78 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/renesas,ceu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Capture Engine Unit (CEU) Bindings
maintainers:
- Jacopo Mondi <jacopo+renesas@jmondi.org>
- linux-renesas-soc@vger.kernel.org
description: |+
The Capture Engine Unit is the image capture interface found in the Renesas SH
Mobile, R-Mobile and RZ SoCs. The interface supports a single parallel input
with data bus width of 8 or 16 bits.
properties:
compatible:
enum:
- renesas,r7s72100-ceu
- renesas,r8a7740-ceu
reg:
maxItems: 1
interrupts:
maxItems: 1
port:
type: object
additionalProperties: false
properties:
endpoint:
type: object
additionalProperties: false
# Properties described in
# Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
remote-endpoint: true
hsync-active: true
vsync-active: true
field-even-active: false
bus-width:
enum: [8, 16]
default: 8
required:
- remote-endpoint
required:
- endpoint
required:
- compatible
- reg
- interrupts
- port
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
ceu: ceu@e8210000 {
reg = <0xe8210000 0x209c>;
compatible = "renesas,r7s72100-ceu";
interrupts = <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
port {
ceu_in: endpoint {
remote-endpoint = <&ov7670_out>;
hsync-active = <1>;
vsync-active = <0>;
};
};
};

View File

@ -1,107 +0,0 @@
Renesas R-Car MIPI CSI-2
------------------------
The R-Car CSI-2 receiver device provides MIPI CSI-2 capabilities for the
Renesas R-Car and RZ/G2 family of devices. It is used in conjunction with the
R-Car VIN module, which provides the video capture capabilities.
Mandatory properties
--------------------
- compatible: Must be one or more of the following
- "renesas,r8a774a1-csi2" for the R8A774A1 device.
- "renesas,r8a774b1-csi2" for the R8A774B1 device.
- "renesas,r8a774c0-csi2" for the R8A774C0 device.
- "renesas,r8a7795-csi2" for the R8A7795 device.
- "renesas,r8a7796-csi2" for the R8A7796 device.
- "renesas,r8a77965-csi2" for the R8A77965 device.
- "renesas,r8a77970-csi2" for the R8A77970 device.
- "renesas,r8a77980-csi2" for the R8A77980 device.
- "renesas,r8a77990-csi2" for the R8A77990 device.
- reg: the register base and size for the device registers
- interrupts: the interrupt for the device
- clocks: A phandle + clock specifier for the module clock
- resets: A phandle + reset specifier for the module reset
The device node shall contain two 'port' child nodes according to the
bindings defined in Documentation/devicetree/bindings/media/
video-interfaces.txt. port@0 shall connect to the CSI-2 source. port@1
shall connect to all the R-Car VIN modules that have a hardware
connection to the CSI-2 receiver.
- port@0- Video source (mandatory)
- endpoint@0 - sub-node describing the endpoint that is the video source
- port@1 - VIN instances (optional)
- One endpoint sub-node for every R-Car VIN instance which is connected
to the R-Car CSI-2 receiver.
Example:
csi20: csi2@fea80000 {
compatible = "renesas,r8a7796-csi2";
reg = <0 0xfea80000 0 0x10000>;
interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 714>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
resets = <&cpg 714>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
csi20_in: endpoint@0 {
reg = <0>;
clock-lanes = <0>;
data-lanes = <1>;
remote-endpoint = <&adv7482_txb>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
csi20vin0: endpoint@0 {
reg = <0>;
remote-endpoint = <&vin0csi20>;
};
csi20vin1: endpoint@1 {
reg = <1>;
remote-endpoint = <&vin1csi20>;
};
csi20vin2: endpoint@2 {
reg = <2>;
remote-endpoint = <&vin2csi20>;
};
csi20vin3: endpoint@3 {
reg = <3>;
remote-endpoint = <&vin3csi20>;
};
csi20vin4: endpoint@4 {
reg = <4>;
remote-endpoint = <&vin4csi20>;
};
csi20vin5: endpoint@5 {
reg = <5>;
remote-endpoint = <&vin5csi20>;
};
csi20vin6: endpoint@6 {
reg = <6>;
remote-endpoint = <&vin6csi20>;
};
csi20vin7: endpoint@7 {
reg = <7>;
remote-endpoint = <&vin7csi20>;
};
};
};
};

View File

@ -0,0 +1,198 @@
# SPDX-License-Identifier: GPL-2.0-only
# Copyright (C) 2020 Renesas Electronics Corp.
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/renesas,csi2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car MIPI CSI-2 receiver
maintainers:
- Niklas Söderlund <niklas.soderlund@ragnatech.se>
description:
The R-Car CSI-2 receiver device provides MIPI CSI-2 capabilities for the
Renesas R-Car and RZ/G2 family of devices. It is used in conjunction with the
R-Car VIN module, which provides the video capture capabilities.
properties:
compatible:
items:
- enum:
- renesas,r8a774a1-csi2 # RZ/G2M
- renesas,r8a774b1-csi2 # RZ/G2N
- renesas,r8a774c0-csi2 # RZ/G2E
- renesas,r8a7795-csi2 # R-Car H3
- renesas,r8a7796-csi2 # R-Car M3-W
- renesas,r8a77965-csi2 # R-Car M3-N
- renesas,r8a77970-csi2 # R-Car V3M
- renesas,r8a77980-csi2 # R-Car V3H
- renesas,r8a77990-csi2 # R-Car E3
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
ports:
type: object
description:
A node containing input and output port nodes with endpoint definitions
as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
properties:
port@0:
type: object
description:
Input port node, single endpoint describing the CSI-2 transmitter.
properties:
reg:
const: 0
endpoint:
type: object
properties:
clock-lanes:
maxItems: 1
data-lanes:
maxItems: 1
remote-endpoint: true
required:
- clock-lanes
- data-lanes
- remote-endpoint
additionalProperties: false
additionalProperties: false
port@1:
type: object
description:
Output port node, multiple endpoints describing all the R-Car VIN
modules connected the CSI-2 receiver.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
reg:
const: 1
patternProperties:
"^endpoint@[0-9a-f]$":
type: object
properties:
reg:
maxItems: 1
remote-endpoint: true
required:
- reg
- remote-endpoint
additionalProperties: false
additionalProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- power-domains
- resets
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7796-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7796-sysc.h>
csi20: csi2@fea80000 {
compatible = "renesas,r8a7796-csi2";
reg = <0 0xfea80000 0 0x10000>;
interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 714>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
resets = <&cpg 714>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
csi20_in: endpoint {
clock-lanes = <0>;
data-lanes = <1>;
remote-endpoint = <&adv7482_txb>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
csi20vin0: endpoint@0 {
reg = <0>;
remote-endpoint = <&vin0csi20>;
};
csi20vin1: endpoint@1 {
reg = <1>;
remote-endpoint = <&vin1csi20>;
};
csi20vin2: endpoint@2 {
reg = <2>;
remote-endpoint = <&vin2csi20>;
};
csi20vin3: endpoint@3 {
reg = <3>;
remote-endpoint = <&vin3csi20>;
};
csi20vin4: endpoint@4 {
reg = <4>;
remote-endpoint = <&vin4csi20>;
};
csi20vin5: endpoint@5 {
reg = <5>;
remote-endpoint = <&vin5csi20>;
};
csi20vin6: endpoint@6 {
reg = <6>;
remote-endpoint = <&vin6csi20>;
};
csi20vin7: endpoint@7 {
reg = <7>;
remote-endpoint = <&vin7csi20>;
};
};
};
};

View File

@ -1,4 +1,4 @@
Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC)
Samsung S5P/Exynos SoC Camera Subsystem (FIMC)
----------------------------------------------
The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices

View File

@ -1,4 +1,4 @@
Samsung S5P/EXYNOS SoC series MIPI CSI-2 receiver (MIPI CSIS)
Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS)
-------------------------------------------------------------
Required properties:

View File

@ -1,61 +0,0 @@
Allwinner V3s Camera Sensor Interface
-------------------------------------
Allwinner V3s SoC features a CSI module(CSI1) with parallel interface.
Required properties:
- compatible: value must be one of:
* "allwinner,sun6i-a31-csi"
* "allwinner,sun8i-a83t-csi"
* "allwinner,sun8i-h3-csi"
* "allwinner,sun8i-v3s-csi"
* "allwinner,sun50i-a64-csi"
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
- clocks: phandles to the clocks feeding the CSI
* bus: the CSI interface clock
* mod: the CSI module clock
* ram: the CSI DRAM clock
- clock-names: the clock names mentioned above
- resets: phandles to the reset line driving the CSI
The CSI node should contain one 'port' child node with one child 'endpoint'
node, according to the bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Endpoint node properties for CSI
---------------------------------
See the video-interfaces.txt for a detailed description of these properties.
- remote-endpoint : (required) a phandle to the bus receiver's endpoint
node
- bus-width: : (required) must be 8, 10, 12 or 16
- pclk-sample : (optional) (default: sample on falling edge)
- hsync-active : (required; parallel-only)
- vsync-active : (required; parallel-only)
Example:
csi1: csi@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x1000>;
interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_CSI>,
<&ccu CLK_CSI1_SCLK>,
<&ccu CLK_DRAM_CSI>;
clock-names = "bus", "mod", "ram";
resets = <&ccu RST_BUS_CSI>;
port {
/* Parallel bus endpoint */
csi1_ep: endpoint {
remote-endpoint = <&adv7611_ep>;
bus-width = <16>;
/* If hsync-active/vsync-active are missing,
embedded BT.656 sync is used */
hsync-active = <0>; /* Active low */
vsync-active = <0>; /* Active low */
pclk-sample = <1>; /* Rising */
};
};
};

View File

@ -0,0 +1,219 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/allwinner,sun6i-a31-prcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A31 PRCM Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
compatible:
const: allwinner,sun6i-a31-prcm
reg:
maxItems: 1
patternProperties:
"^.*_(clk|rst)$":
type: object
properties:
compatible:
enum:
- allwinner,sun4i-a10-mod0-clk
- allwinner,sun6i-a31-apb0-clk
- allwinner,sun6i-a31-apb0-gates-clk
- allwinner,sun6i-a31-ar100-clk
- allwinner,sun6i-a31-clock-reset
- fixed-factor-clock
allOf:
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-apb0-clk
then:
properties:
"#clock-cells":
const: 0
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-apb0-gates-clk
then:
properties:
"#clock-cells":
const: 1
description: >
This additional argument passed to that clock is the
offset of the bit controlling this particular gate in
the register.
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
clock-output-names:
minItems: 1
maxItems: 32
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-ar100-clk
then:
properties:
"#clock-cells":
const: 0
# Already checked in the main schema
compatible: true
clocks:
maxItems: 4
description: >
The parent order must match the hardware programming
order.
clock-output-names:
maxItems: 1
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-clock-reset
then:
properties:
"#reset-cells":
const: 1
# Already checked in the main schema
compatible: true
phandle: true
required:
- "#reset-cells"
- compatible
additionalProperties: false
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/sun6i-a31-ccu.h>
prcm@1f01400 {
compatible = "allwinner,sun6i-a31-prcm";
reg = <0x01f01400 0x200>;
ar100: ar100_clk {
compatible = "allwinner,sun6i-a31-ar100-clk";
#clock-cells = <0>;
clocks = <&rtc 0>, <&osc24M>,
<&ccu CLK_PLL_PERIPH>,
<&ccu CLK_PLL_PERIPH>;
clock-output-names = "ar100";
};
ahb0: ahb0_clk {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <1>;
clock-mult = <1>;
clocks = <&ar100>;
clock-output-names = "ahb0";
};
apb0: apb0_clk {
compatible = "allwinner,sun6i-a31-apb0-clk";
#clock-cells = <0>;
clocks = <&ahb0>;
clock-output-names = "apb0";
};
apb0_gates: apb0_gates_clk {
compatible = "allwinner,sun6i-a31-apb0-gates-clk";
#clock-cells = <1>;
clocks = <&apb0>;
clock-output-names = "apb0_pio", "apb0_ir",
"apb0_timer", "apb0_p2wi",
"apb0_uart", "apb0_1wire",
"apb0_i2c";
};
ir_clk: ir_clk {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
clocks = <&rtc 0>, <&osc24M>;
clock-output-names = "ir";
};
apb0_rst: apb0_rst {
compatible = "allwinner,sun6i-a31-clock-reset";
#reset-cells = <1>;
};
};
...

View File

@ -0,0 +1,200 @@
# SPDX-License-Identifier: GPL-2.0+
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/allwinner,sun8i-a23-prcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A23 PRCM Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
deprecated: true
properties:
compatible:
const: allwinner,sun8i-a23-prcm
reg:
maxItems: 1
patternProperties:
"^.*(clk|rst|codec).*$":
type: object
properties:
compatible:
enum:
- fixed-factor-clock
- allwinner,sun8i-a23-apb0-clk
- allwinner,sun8i-a23-apb0-gates-clk
- allwinner,sun6i-a31-clock-reset
- allwinner,sun8i-a23-codec-analog
required:
- compatible
allOf:
- if:
properties:
compatible:
contains:
const: allwinner,sun8i-a23-apb0-clk
then:
properties:
"#clock-cells":
const: 0
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
clock-output-names:
maxItems: 1
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
contains:
const: allwinner,sun8i-a23-apb0-gates-clk
then:
properties:
"#clock-cells":
const: 1
description: >
This additional argument passed to that clock is the
offset of the bit controlling this particular gate in
the register.
# Already checked in the main schema
compatible: true
clocks:
maxItems: 1
clock-output-names:
minItems: 1
maxItems: 32
phandle: true
required:
- "#clock-cells"
- compatible
- clocks
- clock-output-names
additionalProperties: false
- if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-clock-reset
then:
properties:
"#reset-cells":
const: 1
# Already checked in the main schema
compatible: true
phandle: true
required:
- "#reset-cells"
- compatible
additionalProperties: false
- if:
properties:
compatible:
contains:
const: allwinner,sun8i-a23-codec-analog
then:
properties:
# Already checked in the main schema
compatible: true
phandle: true
required:
- compatible
additionalProperties: false
required:
- compatible
- reg
additionalProperties: false
examples:
- |
prcm@1f01400 {
compatible = "allwinner,sun8i-a23-prcm";
reg = <0x01f01400 0x200>;
ar100: ar100_clk {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <1>;
clock-mult = <1>;
clocks = <&osc24M>;
clock-output-names = "ar100";
};
ahb0: ahb0_clk {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <1>;
clock-mult = <1>;
clocks = <&ar100>;
clock-output-names = "ahb0";
};
apb0: apb0_clk {
compatible = "allwinner,sun8i-a23-apb0-clk";
#clock-cells = <0>;
clocks = <&ahb0>;
clock-output-names = "apb0";
};
apb0_gates: apb0_gates_clk {
compatible = "allwinner,sun8i-a23-apb0-gates-clk";
#clock-cells = <1>;
clocks = <&apb0>;
clock-output-names = "apb0_pio", "apb0_timer",
"apb0_rsb", "apb0_uart",
"apb0_i2c";
};
apb0_rst: apb0_rst {
compatible = "allwinner,sun6i-a31-clock-reset";
#reset-cells = <1>;
};
codec_analog: codec-analog {
compatible = "allwinner,sun8i-a23-codec-analog";
};
};
...

View File

@ -1,59 +0,0 @@
* Allwinner PRCM (Power/Reset/Clock Management) Multi-Functional Device
PRCM is an MFD device exposing several Power Management related devices
(like clks and reset controllers).
Required properties:
- compatible: "allwinner,sun6i-a31-prcm" or "allwinner,sun8i-a23-prcm"
- reg: The PRCM registers range
The prcm node may contain several subdevices definitions:
- see Documentation/devicetree/bindings/clock/sunxi.txt for clock devices
- see Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt for reset
controller devices
Example:
prcm: prcm@1f01400 {
compatible = "allwinner,sun6i-a31-prcm";
reg = <0x01f01400 0x200>;
/* Put subdevices here */
ar100: ar100_clk {
compatible = "allwinner,sun6i-a31-ar100-clk";
#clock-cells = <0>;
clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
};
ahb0: ahb0_clk {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
clock-div = <1>;
clock-mult = <1>;
clocks = <&ar100_div>;
clock-output-names = "ahb0";
};
apb0: apb0_clk {
compatible = "allwinner,sun6i-a31-apb0-clk";
#clock-cells = <0>;
clocks = <&ahb0>;
clock-output-names = "apb0";
};
apb0_gates: apb0_gates_clk {
compatible = "allwinner,sun6i-a31-apb0-gates-clk";
#clock-cells = <1>;
clocks = <&apb0>;
clock-output-names = "apb0_pio", "apb0_ir",
"apb0_timer01", "apb0_p2wi",
"apb0_uart", "apb0_1wire",
"apb0_i2c";
};
apb0_rst: apb0_rst {
compatible = "allwinner,sun6i-a31-clock-reset";
#reset-cells = <1>;
};
};

View File

@ -22,6 +22,7 @@ Required properties:
"fsl,imx8mm-usdhc"
"fsl,imx8mn-usdhc"
"fsl,imx8mp-usdhc"
"fsl,imx8qm-usdhc"
"fsl,imx8qxp-usdhc"
Optional properties:

View File

@ -96,11 +96,10 @@ properties:
description:
When set, no physical write-protect line is present. This
property should only be specified when the controller has a
dedicated write-protect detection logic. If a GPIO is always
used for the write-protect detection. If a GPIO is always used
dedicated write-protect detection logic. If a GPIO is always used
for the write-protect detection logic, it is sufficient to not
specify the wp-gpios property in the absence of a write-protect
line.
line. Not used in combination with eMMC or SDIO.
wp-gpios:
description:

View File

@ -11,6 +11,7 @@ Required properties:
- compatible: should contain one of the following:
* "qcom,qca6174-bt"
* "qcom,wcn3990-bt"
* "qcom,wcn3991-bt"
* "qcom,wcn3998-bt"
Optional properties for compatible string qcom,qca6174-bt:

View File

@ -21,7 +21,8 @@ Required properties:
- "renesas,etheravb-r8a774b1" for the R8A774B1 SoC.
- "renesas,etheravb-r8a774c0" for the R8A774C0 SoC.
- "renesas,etheravb-r8a7795" for the R8A7795 SoC.
- "renesas,etheravb-r8a7796" for the R8A7796 SoC.
- "renesas,etheravb-r8a7796" for the R8A77960 SoC.
- "renesas,etheravb-r8a77961" for the R8A77961 SoC.
- "renesas,etheravb-r8a77965" for the R8A77965 SoC.
- "renesas,etheravb-r8a77970" for the R8A77970 SoC.
- "renesas,etheravb-r8a77980" for the R8A77980 SoC.
@ -37,8 +38,8 @@ Required properties:
- reg: Offset and length of (1) the register block and (2) the stream buffer.
The region for the register block is mandatory.
The region for the stream buffer is optional, as it is only present on
R-Car Gen2 and RZ/G1 SoCs, and on R-Car H3 (R8A7795), M3-W (R8A7796),
and M3-N (R8A77965).
R-Car Gen2 and RZ/G1 SoCs, and on R-Car H3 (R8A7795), M3-W (R8A77960),
M3-W+ (R8A77961), and M3-N (R8A77965).
- interrupts: A list of interrupt-specifiers, one for each entry in
interrupt-names.
If interrupt-names is not present, an interrupt specifier

View File

@ -1,31 +0,0 @@
STMicroelectronics STM32 Factory-programmed data device tree bindings
This represents STM32 Factory-programmed read only non-volatile area: locked
flash, OTP, read-only HW regs... This contains various information such as:
analog calibration data for temperature sensor (e.g. TS_CAL1, TS_CAL2),
internal vref (VREFIN_CAL), unique device ID...
Required properties:
- compatible: Should be one of:
"st,stm32f4-otp"
"st,stm32mp15-bsec"
- reg: Offset and length of factory-programmed area.
- #address-cells: Should be '<1>'.
- #size-cells: Should be '<1>'.
Optional Data cells:
- Must be child nodes as described in nvmem.txt.
Example on stm32f4:
romem: nvmem@1fff7800 {
compatible = "st,stm32f4-otp";
reg = <0x1fff7800 0x400>;
#address-cells = <1>;
#size-cells = <1>;
/* Data cells: ts_cal1 at 0x1fff7a2c */
ts_cal1: calib@22c {
reg = <0x22c 0x2>;
};
...
};

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/nvmem/st,stm32-romem.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 Factory-programmed data bindings
description: |
This represents STM32 Factory-programmed read only non-volatile area: locked
flash, OTP, read-only HW regs... This contains various information such as:
analog calibration data for temperature sensor (e.g. TS_CAL1, TS_CAL2),
internal vref (VREFIN_CAL), unique device ID...
maintainers:
- Fabrice Gasnier <fabrice.gasnier@st.com>
allOf:
- $ref: "nvmem.yaml#"
properties:
compatible:
enum:
- st,stm32f4-otp
- st,stm32mp15-bsec
required:
- "#address-cells"
- "#size-cells"
- compatible
- reg
examples:
- |
efuse@1fff7800 {
compatible = "st,stm32f4-otp";
reg = <0x1fff7800 0x400>;
#address-cells = <1>;
#size-cells = <1>;
calib@22c {
reg = <0x22c 0x2>;
};
};
...

View File

@ -0,0 +1,129 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/opp/allwinner,sun50i-h6-operating-points.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner H6 CPU OPP Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
description: |
For some SoCs, the CPU frequency subset and voltage value of each
OPP varies based on the silicon variant in use. Allwinner Process
Voltage Scaling Tables defines the voltage and frequency value based
on the speedbin blown in the efuse combination. The
sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
provide the OPP framework with required information.
properties:
compatible:
const: allwinner,sun50i-h6-operating-points
nvmem-cells:
description: |
A phandle pointing to a nvmem-cells node representing the efuse
registers that has information about the speedbin that is used
to select the right frequency/voltage value pair. Please refer
the for nvmem-cells bindings
Documentation/devicetree/bindings/nvmem/nvmem.txt and also
examples below.
required:
- compatible
- nvmem-cells
patternProperties:
"opp-[0-9]+":
type: object
properties:
opp-hz: true
patternProperties:
"opp-microvolt-.*": true
required:
- opp-hz
- opp-microvolt-speed0
- opp-microvolt-speed1
- opp-microvolt-speed2
unevaluatedProperties: false
unevaluatedProperties: false
examples:
- |
cpu_opp_table: opp-table {
compatible = "allwinner,sun50i-h6-operating-points";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp-480000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <480000000>;
opp-microvolt-speed0 = <880000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp-720000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <720000000>;
opp-microvolt-speed0 = <880000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp-816000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <816000000>;
opp-microvolt-speed0 = <880000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp-888000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <888000000>;
opp-microvolt-speed0 = <940000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp-1080000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1080000000>;
opp-microvolt-speed0 = <1060000>;
opp-microvolt-speed1 = <880000>;
opp-microvolt-speed2 = <840000>;
};
opp-1320000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1320000000>;
opp-microvolt-speed0 = <1160000>;
opp-microvolt-speed1 = <940000>;
opp-microvolt-speed2 = <900000>;
};
opp-1488000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1488000000>;
opp-microvolt-speed0 = <1160000>;
opp-microvolt-speed1 = <1000000>;
opp-microvolt-speed2 = <960000>;
};
};
...

View File

@ -1,167 +0,0 @@
Allwinner Technologies, Inc. NVMEM CPUFreq and OPP bindings
===================================
For some SoCs, the CPU frequency subset and voltage value of each OPP
varies based on the silicon variant in use. Allwinner Process Voltage
Scaling Tables defines the voltage and frequency value based on the
speedbin blown in the efuse combination. The sun50i-cpufreq-nvmem driver
reads the efuse value from the SoC to provide the OPP framework with
required information.
Required properties:
--------------------
In 'cpus' nodes:
- operating-points-v2: Phandle to the operating-points-v2 table to use.
In 'operating-points-v2' table:
- compatible: Should be
- 'allwinner,sun50i-h6-operating-points'.
- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
efuse registers that has information about the speedbin
that is used to select the right frequency/voltage value
pair. Please refer the for nvmem-cells bindings
Documentation/devicetree/bindings/nvmem/nvmem.txt and
also examples below.
In every OPP node:
- opp-microvolt-<name>: Voltage in micro Volts.
At runtime, the platform can pick a <name> and
matching opp-microvolt-<name> property.
[See: opp.txt]
HW: <name>:
sun50i-h6 speed0 speed1 speed2
Example 1:
---------
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <0>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
operating-points-v2 = <&cpu_opp_table>;
#cooling-cells = <2>;
};
cpu1: cpu@1 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <1>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
operating-points-v2 = <&cpu_opp_table>;
#cooling-cells = <2>;
};
cpu2: cpu@2 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <2>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
operating-points-v2 = <&cpu_opp_table>;
#cooling-cells = <2>;
};
cpu3: cpu@3 {
compatible = "arm,cortex-a53";
device_type = "cpu";
reg = <3>;
enable-method = "psci";
clocks = <&ccu CLK_CPUX>;
clock-latency-ns = <244144>; /* 8 32k periods */
operating-points-v2 = <&cpu_opp_table>;
#cooling-cells = <2>;
};
};
cpu_opp_table: opp_table {
compatible = "allwinner,sun50i-h6-operating-points";
nvmem-cells = <&speedbin_efuse>;
opp-shared;
opp@480000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <480000000>;
opp-microvolt-speed0 = <880000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp@720000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <720000000>;
opp-microvolt-speed0 = <880000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp@816000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <816000000>;
opp-microvolt-speed0 = <880000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp@888000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <888000000>;
opp-microvolt-speed0 = <940000>;
opp-microvolt-speed1 = <820000>;
opp-microvolt-speed2 = <800000>;
};
opp@1080000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1080000000>;
opp-microvolt-speed0 = <1060000>;
opp-microvolt-speed1 = <880000>;
opp-microvolt-speed2 = <840000>;
};
opp@1320000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1320000000>;
opp-microvolt-speed0 = <1160000>;
opp-microvolt-speed1 = <940000>;
opp-microvolt-speed2 = <900000>;
};
opp@1488000000 {
clock-latency-ns = <244144>; /* 8 32k periods */
opp-hz = /bits/ 64 <1488000000>;
opp-microvolt-speed0 = <1160000>;
opp-microvolt-speed1 = <1000000>;
opp-microvolt-speed2 = <960000>;
};
};
....
soc {
....
sid: sid@3006000 {
compatible = "allwinner,sun50i-h6-sid";
reg = <0x03006000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
....
speedbin_efuse: speed@1c {
reg = <0x1c 4>;
};
};
};

View File

@ -1,10 +0,0 @@
* ARM Juno R1 PCIe interface
This PCIe host controller is based on PLDA XpressRICH3-AXI IP
and thus inherits all the common properties defined in plda,xpressrich3-axi.txt
as well as the base properties defined in host-generic-pci.txt.
Required properties:
- compatible: "arm,juno-r1-pcie"
- dma-coherent: The host controller bridges the AXI transactions into PCIe bus
in a manner that makes the DMA operations to appear coherent to the CPUs.

View File

@ -1,42 +0,0 @@
* Synopsys DesignWare PCIe root complex in ECAM shift mode
In some cases, firmware may already have configured the Synopsys DesignWare
PCIe controller in RC mode with static ATU window mappings that cover all
config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion.
In this case, there is no need for the OS to perform any low level setup
of clocks, PHYs or device registers, nor is there any reason for the driver
to reconfigure ATU windows for config and/or IO space accesses at runtime.
In cases where the IP was synthesized with a minimum ATU window size of
64 KB, it cannot be supported by the generic ECAM driver, because it
requires special config space accessors that filter accesses to device #1
and beyond on the first bus.
Required properties:
- compatible: "marvell,armada8k-pcie-ecam" or
"socionext,synquacer-pcie-ecam" or
"snps,dw-pcie-ecam" (must be preceded by a more specific match)
Please refer to the binding document of "pci-host-ecam-generic" in the
file host-generic-pci.txt for a description of the remaining required
and optional properties.
Example:
pcie1: pcie@7f000000 {
compatible = "socionext,synquacer-pcie-ecam", "snps,dw-pcie-ecam";
device_type = "pci";
reg = <0x0 0x7f000000 0x0 0xf00000>;
bus-range = <0x0 0xe>;
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x1000000 0x00 0x00010000 0x00 0x7ff00000 0x0 0x00010000>,
<0x2000000 0x00 0x70000000 0x00 0x70000000 0x0 0x0f000000>,
<0x3000000 0x3f 0x00000000 0x3f 0x00000000 0x1 0x00000000>;
#interrupt-cells = <0x1>;
interrupt-map-mask = <0x0 0x0 0x0 0x0>;
interrupt-map = <0x0 0x0 0x0 0x0 &gic 0x0 0x0 0x0 182 0x4>;
msi-map = <0x0 &its 0x0 0x10000>;
dma-coherent;
};

View File

@ -41,45 +41,3 @@ Hip05 Example (note that Hip06 is the same except compatible):
0x0 0 0 3 &mbigen_pcie 3 12
0x0 0 0 4 &mbigen_pcie 4 13>;
};
HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description.
Some BIOSes place the host controller in a mode where it is ECAM
compliant for all devices other than the root complex. In such cases,
the host controller should be described as below.
The properties and their meanings are identical to those described in
host-generic-pci.txt except as listed below.
Properties of the host controller node that differ from
host-generic-pci.txt:
- compatible : Must be "hisilicon,hip06-pcie-ecam", or
"hisilicon,hip07-pcie-ecam"
- reg : Two entries: First the ECAM configuration space for any
other bus underneath the root bus. Second, the base
and size of the HiSilicon host bridge registers include
the RC's own config space.
Example:
pcie0: pcie@a0090000 {
compatible = "hisilicon,hip06-pcie-ecam";
reg = <0 0xb0000000 0 0x2000000>, /* ECAM configuration space */
<0 0xa0090000 0 0x10000>; /* host bridge registers */
bus-range = <0 31>;
msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
msi-map-mask = <0xffff>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
dma-coherent;
ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000
0x01000000 0 0 0 0xb7ff0000 0 0x10000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
0x0 0 0 2 &mbigen_pcie0 650 4
0x0 0 0 3 &mbigen_pcie0 650 4
0x0 0 0 4 &mbigen_pcie0 650 4>;
};

View File

@ -1,101 +0,0 @@
* Generic PCI host controller
Firmware-initialised PCI host controllers and PCI emulations, such as the
virtio-pci implementations found in kvmtool and other para-virtualised
systems, do not require driver support for complexities such as regulator
and clock management. In fact, the controller may not even require the
configuration of a control interface by the operating system, instead
presenting a set of fixed windows describing a subset of IO, Memory and
Configuration Spaces.
Such a controller can be described purely in terms of the standardized device
tree bindings communicated in pci.txt:
Properties of the host controller node:
- compatible : Must be "pci-host-cam-generic" or "pci-host-ecam-generic"
depending on the layout of configuration space (CAM vs
ECAM respectively).
- device_type : Must be "pci".
- ranges : As described in IEEE Std 1275-1994, but must provide
at least a definition of non-prefetchable memory. One
or both of prefetchable Memory and IO Space may also
be provided.
- bus-range : Optional property (also described in IEEE Std 1275-1994)
to indicate the range of bus numbers for this controller.
If absent, defaults to <0 255> (i.e. all buses).
- #address-cells : Must be 3.
- #size-cells : Must be 2.
- reg : The Configuration Space base address and size, as accessed
from the parent bus. The base address corresponds to
the first bus in the "bus-range" property. If no
"bus-range" is specified, this will be bus 0 (the default).
Properties of the /chosen node:
- linux,pci-probe-only
: Optional property which takes a single-cell argument.
If '0', then Linux will assign devices in its usual manner,
otherwise it will not try to assign devices and instead use
them as they are configured already.
Configuration Space is assumed to be memory-mapped (as opposed to being
accessed via an ioport) and laid out with a direct correspondence to the
geography of a PCI bus address by concatenating the various components to
form an offset.
For CAM, this 24-bit offset is:
cfg_offset(bus, device, function, register) =
bus << 16 | device << 11 | function << 8 | register
While ECAM extends this by 4 bits to accommodate 4k of function space:
cfg_offset(bus, device, function, register) =
bus << 20 | device << 15 | function << 12 | register
Interrupt mapping is exactly as described in `Open Firmware Recommended
Practice: Interrupt Mapping' and requires the following properties:
- #interrupt-cells : Must be 1
- interrupt-map : <see aforementioned specification>
- interrupt-map-mask : <see aforementioned specification>
Example:
pci {
compatible = "pci-host-cam-generic"
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x0 0x1>;
// CPU_PHYSICAL(2) SIZE(2)
reg = <0x0 0x40000000 0x0 0x1000000>;
// BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2)
ranges = <0x01000000 0x0 0x01000000 0x0 0x01000000 0x0 0x00010000>,
<0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
#interrupt-cells = <0x1>;
// PCI_DEVICE(3) INT#(1) CONTROLLER(PHANDLE) CONTROLLER_DATA(3)
interrupt-map = < 0x0 0x0 0x0 0x1 &gic 0x0 0x4 0x1
0x800 0x0 0x0 0x1 &gic 0x0 0x5 0x1
0x1000 0x0 0x0 0x1 &gic 0x0 0x6 0x1
0x1800 0x0 0x0 0x1 &gic 0x0 0x7 0x1>;
// PCI_DEVICE(3) INT#(1)
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
}

View File

@ -0,0 +1,172 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/host-generic-pci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Generic PCI host controller
maintainers:
- Will Deacon <will@kernel.org>
description: |
Firmware-initialised PCI host controllers and PCI emulations, such as the
virtio-pci implementations found in kvmtool and other para-virtualised
systems, do not require driver support for complexities such as regulator
and clock management. In fact, the controller may not even require the
configuration of a control interface by the operating system, instead
presenting a set of fixed windows describing a subset of IO, Memory and
Configuration Spaces.
Configuration Space is assumed to be memory-mapped (as opposed to being
accessed via an ioport) and laid out with a direct correspondence to the
geography of a PCI bus address by concatenating the various components to
form an offset.
For CAM, this 24-bit offset is:
cfg_offset(bus, device, function, register) =
bus << 16 | device << 11 | function << 8 | register
While ECAM extends this by 4 bits to accommodate 4k of function space:
cfg_offset(bus, device, function, register) =
bus << 20 | device << 15 | function << 12 | register
properties:
compatible:
description: Depends on the layout of configuration space (CAM vs ECAM
respectively). May also have more specific compatibles.
oneOf:
- description:
PCIe host controller in Arm Juno based on PLDA XpressRICH3-AXI IP
items:
- const: arm,juno-r1-pcie
- const: plda,xpressrich3-axi
- const: pci-host-ecam-generic
- description: |
ThunderX PCI host controller for pass-1.x silicon
Firmware-initialized PCI host controller to on-chip devices found on
some Cavium ThunderX processors. These devices have ECAM-based config
access, but the BARs are all at fixed addresses. We handle the fixed
addresses by synthesizing Enhanced Allocation (EA) capabilities for
these devices.
const: cavium,pci-host-thunder-ecam
- description:
Cavium ThunderX PEM firmware-initialized PCIe host controller
const: cavium,pci-host-thunder-pem
- description:
HiSilicon Hip06/Hip07 PCIe host bridge in almost-ECAM mode. Some
firmware places the host controller in a mode where it is ECAM
compliant for all devices other than the root complex.
enum:
- hisilicon,hip06-pcie-ecam
- hisilicon,hip07-pcie-ecam
- description: |
In some cases, firmware may already have configured the Synopsys
DesignWare PCIe controller in RC mode with static ATU window mappings
that cover all config, MMIO and I/O spaces in a [mostly] ECAM
compatible fashion. In this case, there is no need for the OS to
perform any low level setup of clocks, PHYs or device registers, nor
is there any reason for the driver to reconfigure ATU windows for
config and/or IO space accesses at runtime.
In cases where the IP was synthesized with a minimum ATU window size
of 64 KB, it cannot be supported by the generic ECAM driver, because
it requires special config space accessors that filter accesses to
device #1 and beyond on the first bus.
items:
- enum:
- marvell,armada8k-pcie-ecam
- socionext,synquacer-pcie-ecam
- const: snps,dw-pcie-ecam
- description:
CAM or ECAM compliant PCI host controllers without any quirks
enum:
- pci-host-cam-generic
- pci-host-ecam-generic
reg:
description:
The Configuration Space base address and size, as accessed from the parent
bus. The base address corresponds to the first bus in the "bus-range"
property. If no "bus-range" is specified, this will be bus 0 (the
default). Some host controllers have a 2nd non-compliant address range,
so 2 entries are allowed.
minItems: 1
maxItems: 2
ranges:
description:
As described in IEEE Std 1275-1994, but must provide at least a
definition of non-prefetchable memory. One or both of prefetchable Memory
and IO Space may also be provided.
minItems: 1
maxItems: 3
dma-coherent: true
required:
- compatible
- reg
- ranges
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
- if:
properties:
compatible:
contains:
const: arm,juno-r1-pcie
then:
required:
- dma-coherent
- if:
properties:
compatible:
not:
contains:
enum:
- cavium,pci-host-thunder-pem
- hisilicon,hip06-pcie-ecam
- hisilicon,hip07-pcie-ecam
then:
properties:
reg:
maxItems: 1
examples:
- |
bus {
#address-cells = <2>;
#size-cells = <2>;
pcie@40000000 {
compatible = "pci-host-cam-generic";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
bus-range = <0x0 0x1>;
// CPU_PHYSICAL(2) SIZE(2)
reg = <0x0 0x40000000 0x0 0x1000000>;
// BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2)
ranges = <0x01000000 0x0 0x01000000 0x0 0x01000000 0x0 0x00010000>,
<0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>;
#interrupt-cells = <0x1>;
// PCI_DEVICE(3) INT#(1) CONTROLLER(PHANDLE) CONTROLLER_DATA(3)
interrupt-map = < 0x0 0x0 0x0 0x1 &gic 0x0 0x4 0x1>,
< 0x800 0x0 0x0 0x1 &gic 0x0 0x5 0x1>,
<0x1000 0x0 0x0 0x1 &gic 0x0 0x6 0x1>,
<0x1800 0x0 0x0 0x1 &gic 0x0 0x7 0x1>;
// PCI_DEVICE(3) INT#(1)
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
};
};
...

View File

@ -1,30 +0,0 @@
* ThunderX PCI host controller for pass-1.x silicon
Firmware-initialized PCI host controller to on-chip devices found on
some Cavium ThunderX processors. These devices have ECAM-based config
access, but the BARs are all at fixed addresses. We handle the fixed
addresses by synthesizing Enhanced Allocation (EA) capabilities for
these devices.
The properties and their meanings are identical to those described in
host-generic-pci.txt except as listed below.
Properties of the host controller node that differ from
host-generic-pci.txt:
- compatible : Must be "cavium,pci-host-thunder-ecam"
Example:
pcie@84b000000000 {
compatible = "cavium,pci-host-thunder-ecam";
device_type = "pci";
msi-parent = <&its>;
msi-map = <0 &its 0x30000 0x10000>;
bus-range = <0 31>;
#size-cells = <2>;
#address-cells = <3>;
#stream-id-cells = <1>;
reg = <0x84b0 0x00000000 0 0x02000000>; /* Configuration space */
ranges = <0x03000000 0x8180 0x00000000 0x8180 0x00000000 0x80 0x00000000>; /* mem ranges */
};

View File

@ -1,43 +0,0 @@
* ThunderX PEM PCIe host controller
Firmware-initialized PCI host controller found on some Cavium
ThunderX processors.
The properties and their meanings are identical to those described in
host-generic-pci.txt except as listed below.
Properties of the host controller node that differ from
host-generic-pci.txt:
- compatible : Must be "cavium,pci-host-thunder-pem"
- reg : Two entries: First the configuration space for down
stream devices base address and size, as accessed
from the parent bus. Second, the register bank of
the PEM device PCIe bridge.
Example:
pci@87e0,c2000000 {
compatible = "cavium,pci-host-thunder-pem";
device_type = "pci";
msi-parent = <&its>;
msi-map = <0 &its 0x10000 0x10000>;
bus-range = <0x8f 0xc7>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0x8880 0x8f000000 0x0 0x39000000>, /* Configuration space */
<0x87e0 0xc2000000 0x0 0x00010000>; /* PEM space */
ranges = <0x01000000 0x00 0x00020000 0x88b0 0x00020000 0x00 0x00010000>, /* I/O */
<0x03000000 0x00 0x10000000 0x8890 0x10000000 0x0f 0xf0000000>, /* mem64 */
<0x43000000 0x10 0x00000000 0x88a0 0x00000000 0x10 0x00000000>, /* mem64-pref */
<0x03000000 0x87e0 0xc2f00000 0x87e0 0xc2000000 0x00 0x00100000>; /* mem64 PEM BAR4 */
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 &gic0 0 0 0 24 4>, /* INTA */
<0 0 0 2 &gic0 0 0 0 25 4>, /* INTB */
<0 0 0 3 &gic0 0 0 0 26 4>, /* INTC */
<0 0 0 4 &gic0 0 0 0 27 4>; /* INTD */
};

View File

@ -1,12 +0,0 @@
* PLDA XpressRICH3-AXI host controller
The PLDA XpressRICH3-AXI host controller can be configured in a manner that
makes it compliant with the SBSA[1] standard published by ARM Ltd. For those
scenarios, the host-generic-pci.txt bindings apply with the following additions
to the compatible property:
Required properties:
- compatible: should contain "plda,xpressrich3-axi" to identify the IP used.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/

View File

@ -1,59 +0,0 @@
* ARM Versatile Platform Baseboard PCI interface
PCI host controller found on the ARM Versatile PB board's FPGA.
Required properties:
- compatible: should contain "arm,versatile-pci" to identify the Versatile PCI
controller.
- reg: base addresses and lengths of the PCI controller. There must be 3
entries:
- Versatile-specific registers
- Self Config space
- Config space
- #address-cells: set to <3>
- #size-cells: set to <2>
- device_type: set to "pci"
- bus-range: set to <0 0xff>
- ranges: ranges for the PCI memory and I/O regions
- #interrupt-cells: set to <1>
- interrupt-map-mask and interrupt-map: standard PCI properties to define
the mapping of the PCI interface to interrupt numbers.
Example:
pci-controller@10001000 {
compatible = "arm,versatile-pci";
device_type = "pci";
reg = <0x10001000 0x1000
0x41000000 0x10000
0x42000000 0x100000>;
bus-range = <0 0xff>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
ranges = <0x01000000 0 0x00000000 0x43000000 0 0x00010000 /* downstream I/O */
0x02000000 0 0x50000000 0x50000000 0 0x10000000 /* non-prefetchable memory */
0x42000000 0 0x60000000 0x60000000 0 0x10000000>; /* prefetchable memory */
interrupt-map-mask = <0x1800 0 0 7>;
interrupt-map = <0x1800 0 0 1 &sic 28
0x1800 0 0 2 &sic 29
0x1800 0 0 3 &sic 30
0x1800 0 0 4 &sic 27
0x1000 0 0 1 &sic 27
0x1000 0 0 2 &sic 28
0x1000 0 0 3 &sic 29
0x1000 0 0 4 &sic 30
0x0800 0 0 1 &sic 30
0x0800 0 0 2 &sic 27
0x0800 0 0 3 &sic 28
0x0800 0 0 4 &sic 29
0x0000 0 0 1 &sic 29
0x0000 0 0 2 &sic 30
0x0000 0 0 3 &sic 27
0x0000 0 0 4 &sic 28>;
};

View File

@ -0,0 +1,92 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/versatile.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Platform Baseboard PCI interface
maintainers:
- Rob Herring <robh@kernel.org>
description: |+
PCI host controller found on the ARM Versatile PB board's FPGA.
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
properties:
compatible:
const: arm,versatile-pci
reg:
items:
- description: Versatile-specific registers
- description: Self Config space
- description: Config space
ranges:
maxItems: 3
"#interrupt-cells": true
interrupt-map:
maxItems: 16
interrupt-map-mask:
items:
- const: 0x1800
- const: 0
- const: 0
- const: 7
required:
- compatible
- reg
- ranges
- "#interrupt-cells"
- interrupt-map
- interrupt-map-mask
examples:
- |
pci@10001000 {
compatible = "arm,versatile-pci";
device_type = "pci";
reg = <0x10001000 0x1000>,
<0x41000000 0x10000>,
<0x42000000 0x100000>;
bus-range = <0 0xff>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
ranges =
<0x01000000 0 0x00000000 0x43000000 0 0x00010000>, /* downstream I/O */
<0x02000000 0 0x50000000 0x50000000 0 0x10000000>, /* non-prefetchable memory */
<0x42000000 0 0x60000000 0x60000000 0 0x10000000>; /* prefetchable memory */
interrupt-map-mask = <0x1800 0 0 7>;
interrupt-map = <0x1800 0 0 1 &sic 28>,
<0x1800 0 0 2 &sic 29>,
<0x1800 0 0 3 &sic 30>,
<0x1800 0 0 4 &sic 27>,
<0x1000 0 0 1 &sic 27>,
<0x1000 0 0 2 &sic 28>,
<0x1000 0 0 3 &sic 29>,
<0x1000 0 0 4 &sic 30>,
<0x0800 0 0 1 &sic 30>,
<0x0800 0 0 2 &sic 27>,
<0x0800 0 0 3 &sic 28>,
<0x0800 0 0 4 &sic 29>,
<0x0000 0 0 1 &sic 29>,
<0x0000 0 0 2 &sic 30>,
<0x0000 0 0 3 &sic 27>,
<0x0000 0 0 4 &sic 28>;
};
...

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