sysmo-bts
/
barebox
9
0
Fork 0
Code Releases Activity

Merge branch 'for-next/dts'

This commit is contained in:
Sascha Hauer 2017-01-11 18:59:57 +01:00
parent c580e8422c 0049feeb2e
commit 4c46707809
794 changed files with 39863 additions and 9354 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
dts/Bindings/arm/amlogic,scpi.txt Normal file
View File

@ -0,0 +1,20 @@
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
----------------------------------------------------------
Required properties
- compatible : should be "amlogic,meson-gxbb-scpi"
AMLOGIC SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "amlogic,meson-gxbb-sram"
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
memory on Amlogic GXBB SoC.
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt

19
dts/Bindings/arm/amlogic.txt
View File

@ -17,6 +17,18 @@ Boards with the Amlogic Meson GXBaby SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson-gxbb";
Boards with the Amlogic Meson GXL S905X SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s905x", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXL S905D SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s905d", "amlogic,meson-gxl";
Boards with the Amlogic Meson GXM S912 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,s912", "amlogic,meson-gxm";
Board compatible values:
- "geniatech,atv1200" (Meson6)
- "minix,neo-x8" (Meson8)
@ -28,3 +40,10 @@ Board compatible values:
- "hardkernel,odroid-c2" (Meson gxbb)
- "amlogic,p200" (Meson gxbb)
- "amlogic,p201" (Meson gxbb)
- "amlogic,p212" (Meson gxl s905x)
- "amlogic,p230" (Meson gxl s905d)
- "amlogic,p231" (Meson gxl s905d)
- "amlogic,q200" (Meson gxm s912)
- "amlogic,q201" (Meson gxm s912)
- "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
- "nexbox,a1" (Meson gxm s912)

5
dts/Bindings/arm/arch_timer.txt
View File

@ -38,6 +38,11 @@ to deliver its interrupts via SPIs.
architecturally-defined reset values. Only supported for 32-bit
systems which follow the ARMv7 architected reset values.
- arm,no-tick-in-suspend : The main counter does not tick when the system is in
low-power system suspend on some SoCs. This behavior does not match the
Architecture Reference Manual's specification that the system counter "must
be implemented in an always-on power domain."
Example:

25
dts/Bindings/arm/arm,scpi.txt
View File

@ -7,7 +7,10 @@ by Linux to initiate various system control and power operations.
Required properties:
- compatible : should be "arm,scpi"
- compatible : should be
* "arm,scpi" : For implementations complying to SCPI v1.0 or above
* "arm,scpi-pre-1.0" : For implementations complying to all
unversioned releases prior to SCPI v1.0
- mboxes: List of phandle and mailbox channel specifiers
All the channels reserved by remote SCP firmware for use by
SCPI message protocol should be specified in any order
@ -59,18 +62,14 @@ SRAM and Shared Memory for SCPI
A small area of SRAM is reserved for SCPI communication between application
processors and SCP.
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
The rest of the properties should follow the generic mmio-sram description
found in ../../sram/sram.txt
The properties should follow the generic mmio-sram description found in [3]
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
shared memory
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
@ -81,11 +80,9 @@ Required properties:
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[2].
Valid cell values are raw identifiers (Sensor
ID) as used by the firmware. Refer to
platform documentation for your
implementation for the IDs to use. For Juno
R0 and Juno R1 refer to [3].
Valid cell values are raw identifiers (Sensor ID)
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Power domain bindings for the power domains based on SCPI Message Protocol
------------------------------------------------------------
@ -112,7 +109,7 @@ Required properties:
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal.txt
[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
[3] Documentation/devicetree/bindings/sram/sram.txt
[4] Documentation/devicetree/bindings/power/power_domain.txt
Example:

3
dts/Bindings/arm/arm-boards
View File

@ -148,11 +148,12 @@ Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
#include "skeleton.dtsi"
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
#address-cells = <1>;
#size-cells = <1>;
soc {
#address-cells = <1>;

16
dts/Bindings/arm/atmel-at91.txt
View File

@ -225,3 +225,19 @@ required properties:
compatible = "atmel,sama5d3-sfr", "syscon";
reg = <0xf0038000 0x60>;
};
Security Module (SECUMOD)
The Security Module macrocell provides all necessary secure functions to avoid
voltage, temperature, frequency and mechanical attacks on the chip. It also
embeds secure memories that can be scrambled
required properties:
- compatible: Should be "atmel,<chip>-secumod", "syscon".
<chip> can be "sama5d2".
- reg: Should contain registers location and length
secumod@fc040000 {
compatible = "atmel,sama5d2-secumod", "syscon";
reg = <0xfc040000 0x100>;
};

0
dts/Bindings/arm/bcm/ns2.txt → dts/Bindings/arm/bcm/brcm,ns2.txt
View File

236
dts/Bindings/arm/cpu-capacity.txt Normal file
View File

@ -0,0 +1,236 @@
==========================================
ARM CPUs capacity bindings
==========================================
==========================================
1 - Introduction
==========================================
ARM systems may be configured to have cpus with different power/performance
characteristics within the same chip. In this case, additional information has
to be made available to the kernel for it to be aware of such differences and
take decisions accordingly.
==========================================
2 - CPU capacity definition
==========================================
CPU capacity is a number that provides the scheduler information about CPUs
heterogeneity. Such heterogeneity can come from micro-architectural differences
(e.g., ARM big.LITTLE systems) or maximum frequency at which CPUs can run
(e.g., SMP systems with multiple frequency domains). Heterogeneity in this
context is about differing performance characteristics; this binding tries to
capture a first-order approximation of the relative performance of CPUs.
CPU capacities are obtained by running a suitable benchmark. This binding makes
no guarantees on the validity or suitability of any particular benchmark, the
final capacity should, however, be:
* A "single-threaded" or CPU affine benchmark
* Divided by the running frequency of the CPU executing the benchmark
* Not subject to dynamic frequency scaling of the CPU
For the time being we however advise usage of the Dhrystone benchmark. What
above thus becomes:
CPU capacities are obtained by running the Dhrystone benchmark on each CPU at
max frequency (with caches enabled). The obtained DMIPS score is then divided
by the frequency (in MHz) at which the benchmark has been run, so that
DMIPS/MHz are obtained. Such values are then normalized w.r.t. the highest
score obtained in the system.
==========================================
3 - capacity-dmips-mhz
==========================================
capacity-dmips-mhz is an optional cpu node [1] property: u32 value
representing CPU capacity expressed in normalized DMIPS/MHz. At boot time, the
maximum frequency available to the cpu is then used to calculate the capacity
value internally used by the kernel.
capacity-dmips-mhz property is all-or-nothing: if it is specified for a cpu
node, it has to be specified for every other cpu nodes, or the system will
fall back to the default capacity value for every CPU. If cpufreq is not
available, final capacities are calculated by directly using capacity-dmips-
mhz values (normalized w.r.t. the highest value found while parsing the DT).
===========================================
4 - Examples
===========================================
Example 1 (ARM 64-bit, 6-cpu system, two clusters):
capacities-dmips-mhz are scaled w.r.t. 1024 (cpu@0 and cpu@1)
supposing cluster0@max-freq=1100 and custer1@max-freq=850,
final capacities are 1024 for cluster0 and 446 for cluster1
cpus {
#address-cells = <2>;
#size-cells = <0>;
cpu-map {
cluster0 {
core0 {
cpu = <&A57_0>;
};
core1 {
cpu = <&A57_1>;
};
};
cluster1 {
core0 {
cpu = <&A53_0>;
};
core1 {
cpu = <&A53_1>;
};
core2 {
cpu = <&A53_2>;
};
core3 {
cpu = <&A53_3>;
};
};
};
idle-states {
entry-method = "arm,psci";
CPU_SLEEP_0: cpu-sleep-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x0010000>;
local-timer-stop;
entry-latency-us = <100>;
exit-latency-us = <250>;
min-residency-us = <150>;
};
CLUSTER_SLEEP_0: cluster-sleep-0 {
compatible = "arm,idle-state";
arm,psci-suspend-param = <0x1010000>;
local-timer-stop;
entry-latency-us = <800>;
exit-latency-us = <700>;
min-residency-us = <2500>;
};
};
A57_0: cpu@0 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A57_L2>;
clocks = <&scpi_dvfs 0>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <1024>;
};
A57_1: cpu@1 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x0 0x1>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A57_L2>;
clocks = <&scpi_dvfs 0>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <1024>;
};
A53_0: cpu@100 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A53_1: cpu@101 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x101>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A53_2: cpu@102 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x102>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A53_3: cpu@103 {
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x103>;
device_type = "cpu";
enable-method = "psci";
next-level-cache = <&A53_L2>;
clocks = <&scpi_dvfs 1>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <578>;
};
A57_L2: l2-cache0 {
compatible = "cache";
};
A53_L2: l2-cache1 {
compatible = "cache";
};
};
Example 2 (ARM 32-bit, 4-cpu system, two clusters,
cpus 0,1@1GHz, cpus 2,3@500MHz):
capacities-dmips-mhz are scaled w.r.t. 2 (cpu@0 and cpu@1), this means that first
cpu@0 and cpu@1 are twice fast than cpu@2 and cpu@3 (at the same frequency)
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0>;
capacity-dmips-mhz = <2>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <1>;
capacity-dmips-mhz = <2>;
};
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x100>;
capacity-dmips-mhz = <1>;
};
cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x101>;
capacity-dmips-mhz = <1>;
};
};
===========================================
5 - References
===========================================
[1] ARM Linux Kernel documentation - CPUs bindings
Documentation/devicetree/bindings/arm/cpus.txt

11
dts/Bindings/arm/cpus.txt
View File

@ -178,6 +178,7 @@ nodes to be present and contain the properties described below.
"marvell,pj4b"
"marvell,sheeva-v5"
"nvidia,tegra132-denver"
"nvidia,tegra186-denver"
"qcom,krait"
"qcom,kryo"
"qcom,scorpion"
@ -241,6 +242,14 @@ nodes to be present and contain the properties described below.
# List of phandles to idle state nodes supported
by this cpu [3].
- capacity-dmips-mhz
Usage: Optional
Value type: <u32>
Definition:
# u32 value representing CPU capacity [3] in
DMIPS/MHz, relative to highest capacity-dmips-mhz
in the system.
- rockchip,pmu
Usage: optional for systems that have an "enable-method"
property value of "rockchip,rk3066-smp"
@ -464,3 +473,5 @@ cpus {
[2] arm/msm/qcom,kpss-acc.txt
[3] ARM Linux kernel documentation - idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt
[3] ARM Linux kernel documentation - cpu capacity bindings
Documentation/devicetree/bindings/arm/cpu-capacity.txt

34
dts/Bindings/arm/fsl.txt
View File

@ -97,7 +97,7 @@ Freescale LS1021A Platform Device Tree Bindings
Required root node compatible properties:
- compatible = "fsl,ls1021a";
Freescale LS1021A SoC-specific Device Tree Bindings
Freescale SoC-specific Device Tree Bindings
-------------------------------------------
Freescale SCFG
@ -105,7 +105,11 @@ Freescale SCFG
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- compatible: should be "fsl,ls1021a-scfg"
- compatible: Should contain a chip-specific compatible string,
Chip-specific strings are of the form "fsl,<chip>-scfg",
The following <chip>s are known to be supported:
ls1021a, ls1043a, ls1046a, ls2080a.
- reg: should contain base address and length of SCFG memory-mapped registers
Example:
@ -119,7 +123,11 @@ Freescale DCFG
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- compatible: should be "fsl,ls1021a-dcfg"
- compatible: Should contain a chip-specific compatible string,
Chip-specific strings are of the form "fsl,<chip>-dcfg",
The following <chip>s are known to be supported:
ls1021a, ls1043a, ls1046a, ls2080a.
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
@ -131,6 +139,10 @@ Example:
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
----------------------------------------------------------------
LS1043A SoC
Required root node properties:
- compatible = "fsl,ls1043a";
LS1043A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1043a-rdb", "fsl,ls1043a";
@ -139,6 +151,22 @@ LS1043A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1043a-qds", "fsl,ls1043a";
LS1046A SoC
Required root node properties:
- compatible = "fsl,ls1046a";
LS1046A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1046a-qds", "fsl,ls1046a";
LS1046A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1046a-rdb", "fsl,ls1046a";
LS2080A SoC
Required root node properties:
- compatible = "fsl,ls2080a";
LS2080A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";

4
dts/Bindings/arm/hisilicon/hisilicon.txt
View File

@ -28,6 +28,10 @@ HiP06 D03 Board
Required root node properties:
- compatible = "hisilicon,hip06-d03";
HiP07 D05 Board
Required root node properties:
- compatible = "hisilicon,hip07-d05";
Hisilicon system controller
Required properties:

26
dts/Bindings/arm/juno,scpi.txt Normal file
View File

@ -0,0 +1,26 @@
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
Juno SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1.
For Juno R0 and Juno R1 refer to [1] for the
sensor identifiers
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html

81
dts/Bindings/arm/keystone/ti,sci.txt Normal file
View File

@ -0,0 +1,81 @@
Texas Instruments System Control Interface (TI-SCI) Message Protocol
--------------------------------------------------------------------
Texas Instrument's processors including those belonging to Keystone generation
of processors have separate hardware entity which is now responsible for the
management of the System on Chip (SoC) system. These include various system
level functions as well.
An example of such an SoC is K2G, which contains the system control hardware
block called Power Management Micro Controller (PMMC). This hardware block is
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
TI-SCI controller Device Node:
=============================
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.
Required properties:
-------------------
- compatible: should be "ti,k2g-sci"
- mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
property should contain a phandle to the mailbox controller device
node and an args specifier that will be the phandle to the intended
sub-mailbox child node to be used for communication.
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
about the generic mailbox controller and client driver bindings. Also see
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
controller that is used to communicate with this System controllers.
Optional Properties:
-------------------
- reg-names:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
mbox-names = "rx", "tx";
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
<&msgmgr &msgmgr_proxy_pmmc_tx>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
TI-SCI Client Device Node:
=========================
Client nodes are maintained as children of the relevant TI-SCI device node.
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
...
my_clk_node: clk_node {
...
...
};
my_pd_node: pd_node {
...
...
};
};

9
dts/Bindings/arm/omap/omap.txt
View File

@ -86,6 +86,9 @@ SoCs:
- DRA722
compatible = "ti,dra722", "ti,dra72", "ti,dra7"
- DRA718
compatible = "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
- AM5728
compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
@ -175,12 +178,18 @@ Boards:
- AM5728 IDK
compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
- AM5718 IDK
compatible = "ti,am5718-idk", "ti,am5718", "ti,dra7"
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
- DRA722 EVM: Software Development Board for DRA722
compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7"
- DRA718 EVM: Software Development Board for DRA718
compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
- DM3730 Logic PD Torpedo + Wireless: Commercial System on Module with WiFi and Bluetooth
compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3"

5
dts/Bindings/arm/oxnas.txt
View File

@ -5,5 +5,10 @@ Boards with the OX810SE SoC shall have the following properties:
Required root node property:
compatible: "oxsemi,ox810se"
Boards with the OX820 SoC shall have the following properties:
Required root node property:
compatible: "oxsemi,ox820"
Board compatible values:
- "wd,mbwe" (OX810SE)
- "cloudengines,pogoplugv3" (OX820)

3
dts/Bindings/arm/qcom.txt
View File

@ -21,7 +21,10 @@ The 'SoC' element must be one of the following strings:
apq8096
msm8916
msm8974
msm8992
msm8994
msm8996
mdm9615
The 'board' element must be one of the following strings:

16
dts/Bindings/arm/rockchip.txt
View File

@ -25,6 +25,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "radxa,rock2-square", "rockchip,rk3288";
- Rikomagic MK808 v1 board:
Required root node properties:
- compatible = "rikomagic,mk808", "rockchip,rk3066a";
- Firefly Firefly-RK3288 board:
Required root node properties:
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
@ -99,6 +103,18 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "mqmaker,miqi", "rockchip,rk3288";
- Rockchip PX3 Evaluation board:
Required root node properties:
- compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
- Rockchip PX5 Evaluation board:
Required root node properties:
- compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
- Rockchip RK1108 Evaluation board
Required root node properties:
- compatible = "rockchip,rk1108-evb", "rockchip,rk1108";
- Rockchip RK3368 evb:
Required root node properties:
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";

5
dts/Bindings/arm/samsung/samsung-boards.txt
View File

@ -15,6 +15,8 @@ Required root node properties:
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
- "samsung,tm2" - for Exynos5433-based Samsung TM2 board.
- "samsung,tm2e" - for Exynos5433-based Samsung TM2E board.
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
@ -22,6 +24,9 @@ Required root node properties:
* FriendlyARM
- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
TINY4412 board.
* TOPEET
- "topeet,itop4412-elite" - for Exynos4412-based TOPEET
Elite base board.
* Google
- "google,pi" - for Exynos5800-based Google Peach Pi

36
dts/Bindings/arm/shmobile.txt
View File

@ -13,6 +13,10 @@ SoCs:
compatible = "renesas,r8a73a4"
- R-Mobile A1 (R8A77400)
compatible = "renesas,r8a7740"
- RZ/G1M (R8A77430)
compatible = "renesas,r8a7743"
- RZ/G1E (R8A77450)
compatible = "renesas,r8a7745"
- R-Car M1A (R8A77781)
compatible = "renesas,r8a7778"
- R-Car H1 (R8A77790)
@ -35,7 +39,7 @@ SoCs:
Boards:
- Alt
- Alt (RTP0RC7794SEB00010S)
compatible = "renesas,alt", "renesas,r8a7794"
- APE6-EVM
compatible = "renesas,ape6evm", "renesas,r8a73a4"
@ -47,9 +51,9 @@ Boards:
compatible = "renesas,bockw", "renesas,r8a7778"
- Genmai (RTK772100BC00000BR)
compatible = "renesas,genmai", "renesas,r7s72100"
- Gose
- Gose (RTP0RC7793SEB00010S)
compatible = "renesas,gose", "renesas,r8a7793"
- H3ULCB (RTP0RC7795SKB00010S)
- H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
compatible = "renesas,h3ulcb", "renesas,r8a7795";
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
@ -61,7 +65,9 @@ Boards:
compatible = "renesas,kzm9g", "renesas,sh73a0"
- Lager (RTP0RC7790SEB00010S)
compatible = "renesas,lager", "renesas,r8a7790"
- Marzen
- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKB00010S)
compatible = "renesas,m3ulcb", "renesas,r8a7796";
- Marzen (R0P7779A00010S)
compatible = "renesas,marzen", "renesas,r8a7779"
- Porter (M2-LCDP)
compatible = "renesas,porter", "renesas,r8a7791"
@ -73,5 +79,27 @@ Boards:
compatible = "renesas,salvator-x", "renesas,r8a7796";
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"
- SK-RZG1E (YR8A77450S000BE)
compatible = "renesas,sk-rzg1e", "renesas,r8a7745"
- SK-RZG1M (YR8A77430S000BE)
compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
- Wheat
compatible = "renesas,wheat", "renesas,r8a7792"
Most Renesas ARM SoCs have a Product Register that allows to retrieve SoC
product and revision information. If present, a device node for this register
should be added.
Required properties:
- compatible: Must be "renesas,prr".
- reg: Base address and length of the register block.
Examples
--------
prr: chipid@ff000044 {
compatible = "renesas,prr";
reg = <0 0xff000044 0 4>;
};

1
dts/Bindings/arm/sunxi.txt
View File

@ -14,4 +14,5 @@ using one of the following compatible strings:
allwinner,sun8i-a83t
allwinner,sun8i-h3
allwinner,sun9i-a80
allwinner,sun50i-a64
nextthing,gr8

12
dts/Bindings/arm/swir.txt Normal file
View File

@ -0,0 +1,12 @@
Sierra Wireless Modules device tree bindings
--------------------------------------------
Supported Modules :
- WP8548 : Includes MDM9615 and PM8018 in a module
Sierra Wireless modules shall have the following properties :
Required root node property
- compatible: "swir,wp8548" for the WP8548 CF3 Module
Board compatible values:
- "swir,mangoh-green-wp8548" for the mangOH green board with the WP8548 module

2
dts/Bindings/ata/ahci-fsl-qoriq.txt
View File

@ -3,7 +3,7 @@ Binding for Freescale QorIQ AHCI SATA Controller
Required properties:
- reg: Physical base address and size of the controller's register area.
- compatible: Compatibility string. Must be 'fsl,<chip>-ahci', where
chip could be ls1021a, ls2080a, ls1043a etc.
chip could be ls1021a, ls1043a, ls1046a, ls2080a etc.
- clocks: Input clock specifier. Refer to common clock bindings.
- interrupts: Interrupt specifier. Refer to interrupt binding.

15
dts/Bindings/ata/ahci-st.txt
View File

@ -18,21 +18,6 @@ Optional properties:
Example:
/* Example for stih416 */
sata0: sata@fe380000 {
compatible = "st,ahci";
reg = <0xfe380000 0x1000>;
interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
interrupt-names = "hostc";
phys = <&phy_port0 PHY_TYPE_SATA>;
phy-names = "ahci_phy";
resets = <&powerdown STIH416_SATA0_POWERDOWN>,
<&softreset STIH416_SATA0_SOFTRESET>;
reset-names = "pwr-dwn", "sw-rst";
clocks = <&clk_s_a0_ls CLK_ICN_REG>;
clock-names = "ahci_clk";
};
/* Example for stih407 family silicon */
sata0: sata@9b20000 {
compatible = "st,ahci";

132
dts/Bindings/bus/nvidia,tegra20-gmi.txt Normal file
View File

@ -0,0 +1,132 @@
Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
The Generic Memory Interface bus enables memory transfers between internal and
external memory. Can be used to attach various high speed devices such as
synchronous/asynchronous NOR, FPGA, UARTS and more.
The actual devices are instantiated from the child nodes of a GMI node.
Required properties:
- compatible : Should contain one of the following:
For Tegra20 must contain "nvidia,tegra20-gmi".
For Tegra30 must contain "nvidia,tegra30-gmi".
- reg: Should contain GMI controller registers location and length.
- clocks: Must contain an entry for each entry in clock-names.
- clock-names: Must include the following entries: "gmi"
- resets : Must contain an entry for each entry in reset-names.
- reset-names : Must include the following entries: "gmi"
- #address-cells: The number of cells used to represent physical base
addresses in the GMI address space. Should be 2.
- #size-cells: The number of cells used to represent the size of an address
range in the GMI address space. Should be 1.
- ranges: Must be set up to reflect the memory layout with three integer values
for each chip-select line in use (only one entry is supported, see below
comments):
<cs-number> <offset> <physical address of mapping> <size>
Note that the GMI controller does not have any internal chip-select address
decoding, because of that chip-selects either need to be managed via software
or by employing external chip-select decoding logic.
If external chip-select logic is used to support multiple devices it is assumed
that the devices use the same timing and so are probably the same type. It also
assumes that they can fit in the 256MB address range. In this case only one
child device is supported which represents the active chip-select line, see
examples for more insight.
The chip-select number is decoded from the child nodes second address cell of
'ranges' property, if 'ranges' property is not present or empty chip-select will
then be decoded from the first cell of the 'reg' property.
Optional child cs node properties:
- nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
- nvidia,snor-mux-mode: Enable address/data MUX mode.
- nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data.
If omitted it will be asserted with data.
- nvidia,snor-rdy-active-high: RDY signal is active high
- nvidia,snor-adv-active-high: ADV signal is active high
- nvidia,snor-oe-active-high: WE/OE signal is active high
- nvidia,snor-cs-active-high: CS signal is active high
Note that there is some special handling for the timing values.
From Tegra TRM:
Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1
- nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the
bus. Valid values are 0-15, default is 1
- nvidia,snor-hold-width: Number of cycles CE stays asserted after the
de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N
(in case of MASTER Request). Valid values are 0-15, default is 1
- nvidia,snor-adv-width: Number of cycles during which ADV stays asserted.
Valid values are 0-15, default is 1.
- nvidia,snor-ce-width: Number of cycles before CE is asserted.
Valid values are 0-15, default is 4
- nvidia,snor-we-width: Number of cycles during which WE stays asserted.
Valid values are 0-15, default is 1
- nvidia,snor-oe-width: Number of cycles during which OE stays asserted.
Valid values are 0-255, default is 1
- nvidia,snor-wait-width: Number of cycles before READY is asserted.
Valid values are 0-255, default is 3
Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
controllers with a simple-bus node since they are all connected to the same
chip-select (CS4), in this example external address decoding is provided:
gmi@70090000 {
compatible = "nvidia,tegra20-gmi";
reg = <0x70009000 0x1000>;
#address-cells = <2>;
#size-cells = <1>;
clocks = <&tegra_car TEGRA20_CLK_NOR>;
clock-names = "gmi";
resets = <&tegra_car 42>;
reset-names = "gmi";
ranges = <4 0 0xd0000000 0xfffffff>;
status = "okay";
bus@4,0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 4 0 0x40100>;
nvidia,snor-mux-mode;
nvidia,snor-adv-active-high;
can@0 {
reg = <0 0x100>;
...
};
can@40000 {
reg = <0x40000 0x100>;
...
};
};
};
Example with one SJA1000 CAN controller connected to the GMI bus
on CS4:
gmi@70090000 {
compatible = "nvidia,tegra20-gmi";
reg = <0x70009000 0x1000>;
#address-cells = <2>;
#size-cells = <1>;
clocks = <&tegra_car TEGRA20_CLK_NOR>;
clock-names = "gmi";
resets = <&tegra_car 42>;
reset-names = "gmi";
ranges = <4 0 0xd0000000 0xfffffff>;
status = "okay";
can@4,0 {
reg = <4 0 0x100>;
nvidia,snor-mux-mode;
nvidia,snor-adv-active-high;
...
};
};

20
dts/Bindings/bus/ti,da850-mstpri.txt Normal file
View File

@ -0,0 +1,20 @@
* Device tree bindings for Texas Instruments da8xx master peripheral
priority driver
DA8XX SoCs feature a set of registers allowing to change the priority of all
peripherals classified as masters.
Documentation:
OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
Required properties:
- compatible: "ti,da850-mstpri" - for da850 based boards
- reg: offset and length of the mstpri registers
Example for da850-lcdk is shown below.
mstpri {
compatible = "ti,da850-mstpri";
reg = <0x14110 0x0c>;
};

13
dts/Bindings/clock/exynos5433-clock.txt
View File

@ -79,7 +79,7 @@ Required Properties:
Input clocks for fsys clock controller:
- oscclk
- sclk_ufs_mphy
- div_aclk_fsys_200
- aclk_fsys_200
- sclk_pcie_100_fsys
- sclk_ufsunipro_fsys
- sclk_mmc2_fsys
@ -104,6 +104,10 @@ Required Properties:
- sclk_decon_tv_vclk_disp
- aclk_disp_333
Input clocks for audio clock controller:
- oscclk
- fout_aud_pll
Input clocks for bus0 clock controller:
- aclk_bus0_400
@ -235,7 +239,7 @@ Example 2: Examples of clock controller nodes are listed below.
clock-names = "oscclk",
"sclk_ufs_mphy",
"div_aclk_fsys_200",
"aclk_fsys_200",
"sclk_pcie_100_fsys",
"sclk_ufsunipro_fsys",
"sclk_mmc2_fsys",
@ -245,7 +249,7 @@ Example 2: Examples of clock controller nodes are listed below.
"sclk_usbdrd30_fsys";
clocks = <&xxti>,
<&cmu_cpif CLK_SCLK_UFS_MPHY>,
<&cmu_top CLK_DIV_ACLK_FSYS_200>,
<&cmu_top CLK_ACLK_FSYS_200>,
<&cmu_top CLK_SCLK_PCIE_100_FSYS>,
<&cmu_top CLK_SCLK_UFSUNIPRO_FSYS>,
<&cmu_top CLK_SCLK_MMC2_FSYS>,
@ -297,6 +301,9 @@ Example 2: Examples of clock controller nodes are listed below.
compatible = "samsung,exynos5433-cmu-aud";
reg = <0x114c0000 0x0b04>;
#clock-cells = <1>;
clock-names = "oscclk", "fout_aud_pll";
clocks = <&xxti>, <&cmu_top CLK_FOUT_AUD_PLL>;
};
cmu_bus0: clock-controller@13600000 {

12
dts/Bindings/clock/hi3519-crg.txt → dts/Bindings/clock/hisi-crg.txt
View File

@ -1,7 +1,7 @@
* Hisilicon Hi3519 Clock and Reset Generator(CRG)
* HiSilicon Clock and Reset Generator(CRG)
The Hi3519 CRG module provides clock and reset signals to various
controllers within the SoC.
The CRG module provides clock and reset signals to various
modules within the SoC.
This binding uses the following bindings:
Documentation/devicetree/bindings/clock/clock-bindings.txt
@ -10,7 +10,11 @@ This binding uses the following bindings:
Required Properties:
- compatible: should be one of the following.
- "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
- "hisilicon,hi3516cv300-crg"
- "hisilicon,hi3516cv300-sysctrl"
- "hisilicon,hi3519-crg"
- "hisilicon,hi3798cv200-crg"
- "hisilicon,hi3798cv200-sysctrl"
- reg: physical base address of the controller and length of memory mapped
region.

2
dts/Bindings/clock/imx31-clock.txt
View File

@ -77,7 +77,7 @@ Examples:
clks: ccm@53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
interrupts = <0 31 0x04 0 53 0x04>;
interrupts = <31>, <53>;
#clock-cells = <1>;
};

19
dts/Bindings/clock/oxnas,stdclk.txt
View File

@ -5,22 +5,15 @@ Please also refer to clock-bindings.txt in this directory for common clock
bindings usage.
Required properties:
- compatible: Should be "oxsemi,ox810se-stdclk"
- compatible: For OX810SE, should be "oxsemi,ox810se-stdclk"
For OX820, should be "oxsemi,ox820-stdclk"
- #clock-cells: 1, see below
Parent node should have the following properties :
- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
For OX810SE, the clock indices are :
- 0: LEON
- 1: DMA_SGDMA
- 2: CIPHER
- 3: SATA
- 4: AUDIO
- 5: USBMPH
- 6: ETHA
- 7: PCIA
- 8: NAND
- compatible: For OX810SE, should be
"oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
For OX820, should be
"oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
example:

1
dts/Bindings/clock/qcom,gcc.txt
View File

@ -14,6 +14,7 @@ Required properties :
"qcom,gcc-msm8974"
"qcom,gcc-msm8974pro"
"qcom,gcc-msm8974pro-ac"
"qcom,gcc-msm8994"
"qcom,gcc-msm8996"
"qcom,gcc-mdm9615"

37
dts/Bindings/clock/qcom,rpmcc.txt Normal file
View File

@ -0,0 +1,37 @@
Qualcomm RPM Clock Controller Binding
------------------------------------------------
The RPM is a dedicated hardware engine for managing the shared
SoC resources in order to keep the lowest power profile. It
communicates with other hardware subsystems via shared memory
and accepts clock requests, aggregates the requests and turns
the clocks on/off or scales them on demand.
Required properties :
- compatible : shall contain only one of the following. The generic
compatible "qcom,rpmcc" should be also included.
"qcom,rpmcc-msm8916", "qcom,rpmcc"
"qcom,rpmcc-apq8064", "qcom,rpmcc"
- #clock-cells : shall contain 1
Example:
smd {
compatible = "qcom,smd";
rpm {
interrupts = <0 168 1>;
qcom,ipc = <&apcs 8 0>;
qcom,smd-edge = <15>;
rpm_requests {
compatible = "qcom,rpm-msm8916";
qcom,smd-channels = "rpm_requests";
rpmcc: clock-controller {
compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc";
#clock-cells = <1>;
};
};
};
};

3
dts/Bindings/clock/qoriq-clock.txt
View File

@ -32,6 +32,9 @@ Required properties:
* "fsl,b4420-clockgen"
* "fsl,b4860-clockgen"
* "fsl,ls1021a-clockgen"
* "fsl,ls1043a-clockgen"
* "fsl,ls1046a-clockgen"
* "fsl,ls2080a-clockgen"
Chassis-version clock strings include:
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks

5
dts/Bindings/clock/renesas,cpg-mssr.txt
View File

@ -13,6 +13,8 @@ They provide the following functionalities:
Required Properties:
- compatible: Must be one of:
- "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
- "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E)
- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
@ -22,8 +24,9 @@ Required Properties:
- clocks: References to external parent clocks, one entry for each entry in
clock-names
- clock-names: List of external parent clock names. Valid names are:
- "extal" (r8a7795, r8a7796)
- "extal" (r8a7743, r8a7745, r8a7795, r8a7796)
- "extalr" (r8a7795, r8a7796)
- "usb_extal" (r8a7743, r8a7745)
- #clock-cells: Must be 2
- For CPG core clocks, the two clock specifier cells must be "CPG_CORE"

59
dts/Bindings/clock/rockchip,rk1108-cru.txt Normal file
View File

@ -0,0 +1,59 @@
* Rockchip RK1108 Clock and Reset Unit
The RK1108 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk1108-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk1108-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "ext_vip" - external VIP clock - optional
- "ext_i2s" - external I2S clock - optional
- "ext_gmac" - external GMAC clock - optional
- "hdmiphy" - external clock input derived from HDMI PHY - optional
- "usbphy" - external clock input derived from USB PHY - optional
Example: Clock controller node:
cru: cru@20200000 {
compatible = "rockchip,rk1108-cru";
reg = <0x20200000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10230000 {
compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
reg = <0x10230000 0x100>;
interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&cru SCLK_UART0>;
};

4
dts/Bindings/clock/st,stm32-rcc.txt
View File

@ -7,7 +7,9 @@ Please refer to clock-bindings.txt for common clock controller binding usage.
Please also refer to reset.txt for common reset controller binding usage.
Required properties:
- compatible: Should be "st,stm32f42xx-rcc"
- compatible: Should be:
"st,stm32f42xx-rcc"
"st,stm32f469-rcc"
- reg: should be register base and length as documented in the
datasheet
- #reset-cells: 1, see below

1
dts/Bindings/clock/sunxi-ccu.txt
View File

@ -7,6 +7,7 @@ Required properties :
- "allwinner,sun8i-a23-ccu"
- "allwinner,sun8i-a33-ccu"
- "allwinner,sun8i-h3-ccu"
- "allwinner,sun50i-a64-ccu"
- reg: Must contain the registers base address and length
- clocks: phandle to the oscillators feeding the CCU. Two are needed:

16
dts/Bindings/clock/uniphier-clock.txt
View File

@ -24,7 +24,7 @@ Example:
reg = <0x61840000 0x4000>;
clock {
compatible = "socionext,uniphier-ld20-clock";
compatible = "socionext,uniphier-ld11-clock";
#clock-cells = <1>;
};
@ -43,8 +43,8 @@ Provided clocks:
21: USB3 ch1 PHY1
Media I/O (MIO) clock
---------------------
Media I/O (MIO) clock, SD clock
-------------------------------
Required properties:
- compatible: should be one of the following:
@ -52,10 +52,10 @@ Required properties:
"socionext,uniphier-ld4-mio-clock" - for LD4 SoC.
"socionext,uniphier-pro4-mio-clock" - for Pro4 SoC.
"socionext,uniphier-sld8-mio-clock" - for sLD8 SoC.
"socionext,uniphier-pro5-mio-clock" - for Pro5 SoC.
"socionext,uniphier-pxs2-mio-clock" - for PXs2/LD6b SoC.
"socionext,uniphier-pro5-sd-clock" - for Pro5 SoC.
"socionext,uniphier-pxs2-sd-clock" - for PXs2/LD6b SoC.
"socionext,uniphier-ld11-mio-clock" - for LD11 SoC.
"socionext,uniphier-ld20-mio-clock" - for LD20 SoC.
"socionext,uniphier-ld20-sd-clock" - for LD20 SoC.
- #clock-cells: should be 1.
Example:
@ -66,7 +66,7 @@ Example:
reg = <0x59810000 0x800>;
clock {
compatible = "socionext,uniphier-ld20-mio-clock";
compatible = "socionext,uniphier-ld11-mio-clock";
#clock-cells = <1>;
};
@ -112,7 +112,7 @@ Example:
reg = <0x59820000 0x200>;
clock {
compatible = "socionext,uniphier-ld20-peri-clock";
compatible = "socionext,uniphier-ld11-peri-clock";
#clock-cells = <1>;
};

78
dts/Bindings/cpufreq/brcm,stb-avs-cpu-freq.txt Normal file
View File

@ -0,0 +1,78 @@
Broadcom AVS mail box and interrupt register bindings
=====================================================
A total of three DT nodes are required. One node (brcm,avs-cpu-data-mem)
references the mailbox register used to communicate with the AVS CPU[1]. The
second node (brcm,avs-cpu-l2-intr) is required to trigger an interrupt on
the AVS CPU. The interrupt tells the AVS CPU that it needs to process a
command sent to it by a driver. Interrupting the AVS CPU is mandatory for
commands to be processed.
The interface also requires a reference to the AVS host interrupt controller,
so a driver can react to interrupts generated by the AVS CPU whenever a command
has been processed. See [2] for more information on the brcm,l2-intc node.
[1] The AVS CPU is an independent co-processor that runs proprietary
firmware. On some SoCs, this firmware supports DFS and DVFS in addition to
Adaptive Voltage Scaling.
[2] Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
Node brcm,avs-cpu-data-mem
--------------------------
Required properties:
- compatible: must include: brcm,avs-cpu-data-mem and
should include: one of brcm,bcm7271-avs-cpu-data-mem or
brcm,bcm7268-avs-cpu-data-mem
- reg: Specifies base physical address and size of the registers.
- interrupts: The interrupt that the AVS CPU will use to interrupt the host
when a command completed.
- interrupt-parent: The interrupt controller the above interrupt is routed
through.
- interrupt-names: The name of the interrupt used to interrupt the host.
Optional properties:
- None
Node brcm,avs-cpu-l2-intr
-------------------------
Required properties:
- compatible: must include: brcm,avs-cpu-l2-intr and
should include: one of brcm,bcm7271-avs-cpu-l2-intr or
brcm,bcm7268-avs-cpu-l2-intr
- reg: Specifies base physical address and size of the registers.
Optional properties:
- None
Example
=======
avs_host_l2_intc: interrupt-controller@f04d1200 {
#interrupt-cells = <1>;
compatible = "brcm,l2-intc";
interrupt-parent = <&intc>;
reg = <0xf04d1200 0x48>;
interrupt-controller;
interrupts = <0x0 0x19 0x0>;
interrupt-names = "avs";
};
avs-cpu-data-mem@f04c4000 {
compatible = "brcm,bcm7271-avs-cpu-data-mem",
"brcm,avs-cpu-data-mem";
reg = <0xf04c4000 0x60>;
interrupts = <0x1a>;
interrupt-parent = <&avs_host_l2_intc>;
interrupt-names = "sw_intr";
};
avs-cpu-l2-intr@f04d1100 {
compatible = "brcm,bcm7271-avs-cpu-l2-intr",
"brcm,avs-cpu-l2-intr";
reg = <0xf04d1100 0x10>;
};

20
dts/Bindings/crypto/fsl-sec4.txt
View File

@ -123,6 +123,9 @@ PROPERTIES
EXAMPLE
iMX6QDL/SX requires four clocks
crypto@300000 {
compatible = "fsl,sec-v4.0";
fsl,sec-era = <2>;
@ -139,6 +142,23 @@ EXAMPLE
clock-names = "mem", "aclk", "ipg", "emi_slow";
};
iMX6UL does only require three clocks
crypto: caam@2140000 {
compatible = "fsl,sec-v4.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x2140000 0x3c000>;
ranges = <0 0x2140000 0x3c000>;
interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_CAAM_MEM>,
<&clks IMX6UL_CLK_CAAM_ACLK>,
<&clks IMX6UL_CLK_CAAM_IPG>;
clock-names = "mem", "aclk", "ipg";
};
=====================================================================
Job Ring (JR) Node

112
dts/Bindings/display/amlogic,meson-vpu.txt Normal file
View File

@ -0,0 +1,112 @@
Amlogic Meson Display Controller
================================
The Amlogic Meson Display controller is composed of several components
that are going to be documented below:
DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
| vd1 _______ _____________ _________________ | |
D |-------| |----| | | | | HDMI PLL |
D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
R |-------| |----| Processing | | | | |
| osd2 | | | |---| Enci ----------|----|-----VDAC------|
R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
A | osd1 | | | Blenders | | Encl ----------|----|---------------|
M |-------|______|----|____________| |________________| | |
___|__________________________________________________________|_______________|
VIU: Video Input Unit
---------------------
The Video Input Unit is in charge of the pixel scanout from the DDR memory.
It fetches the frames addresses, stride and parameters from the "Canvas" memory.
This part is also in charge of the CSC (Colorspace Conversion).
It can handle 2 OSD Planes and 2 Video Planes.
VPP: Video Post Processing
--------------------------
The Video Post Processing is in charge of the scaling and blending of the
various planes into a single pixel stream.
There is a special "pre-blending" used by the video planes with a dedicated
scaler and a "post-blending" to merge with the OSD Planes.
The OSD planes also have a dedicated scaler for one of the OSD.
VENC: Video Encoders
--------------------
The VENC is composed of the multiple pixel encoders :
- ENCI : Interlace Video encoder for CVBS and Interlace HDMI
- ENCP : Progressive Video Encoder for HDMI
- ENCL : LCD LVDS Encoder
The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
tree and provides the scanout clock to the VPP and VIU.
The ENCI is connected to a single VDAC for Composite Output.
The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
Device Tree Bindings:
---------------------
VPU: Video Processing Unit
--------------------------
Required properties:
- compatible: value should be different for each SoC family as :
- GXBB (S905) : "amlogic,meson-gxbb-vpu"
- GXL (S905X, S905D) : "amlogic,meson-gxl-vpu"
- GXM (S912) : "amlogic,meson-gxm-vpu"
followed by the common "amlogic,meson-gx-vpu"
- reg: base address and size of he following memory-mapped regions :
- vpu
- hhi
- dmc
- reg-names: should contain the names of the previous memory regions
- interrupts: should contain the VENC Vsync interrupt number
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph
bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each VPU output.
Port 0 Port 1
-----------------------------------------
S905 (GXBB) CVBS VDAC HDMI-TX
S905X (GXL) CVBS VDAC HDMI-TX
S905D (GXL) CVBS VDAC HDMI-TX
S912 (GXM) CVBS VDAC HDMI-TX
Example:
tv-connector {
compatible = "composite-video-connector";
port {
tv_connector_in: endpoint {
remote-endpoint = <&cvbs_vdac_out>;
};
};
};
vpu: vpu@d0100000 {
compatible = "amlogic,meson-gxbb-vpu";
reg = <0x0 0xd0100000 0x0 0x100000>,
<0x0 0xc883c000 0x0 0x1000>,
<0x0 0xc8838000 0x0 0x1000>;
reg-names = "vpu", "hhi", "dmc";
interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
#address-cells = <1>;
#size-cells = <0>;
/* CVBS VDAC output port */
port@0 {
reg = <0>;
cvbs_vdac_out: endpoint {
remote-endpoint = <&tv_connector_in>;
};
};
};

14
dts/Bindings/display/brcm,bcm-vc4.txt
View File

@ -43,6 +43,13 @@ Required properties for DPI:
- port: Port node with a single endpoint connecting to the panel
device, as defined in [1]
Required properties for VEC:
- compatible: Should be "brcm,bcm2835-vec"
- reg: Physical base address and length of the registers
- clocks: The core clock the unit runs on
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for V3D:
- compatible: Should be "brcm,bcm2835-v3d"
- reg: Physical base address and length of the V3D's registers
@ -92,6 +99,13 @@ dpi: dpi@7e208000 {
};
};
vec: vec@7e806000 {
compatible = "brcm,bcm2835-vec";
reg = <0x7e806000 0x1000>;
clocks = <&clocks BCM2835_CLOCK_VEC>;
interrupts = <2 27>;
};
v3d: v3d@7ec00000 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec00000 0x1000>;

2
dts/Bindings/display/bridge/dumb-vga-dac.txt
View File

@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for RGB input
- Video port 1 for VGA output
Optional properties:
- vdd-supply: Power supply for DAC
Example
-------

4
dts/Bindings/display/bridge/dw_hdmi.txt
View File

@ -19,7 +19,9 @@ Required properties:
Optional properties
- reg-io-width: the width of the reg:1,4, default set to 1 if not present
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing,
if the property is omitted, a functionally reduced I2C bus
controller on DW HDMI is probed
- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
Example:

9
dts/Bindings/display/ti/ti,tfp410.txt → dts/Bindings/display/bridge/ti,tfp410.txt
View File

@ -6,10 +6,15 @@ Required properties:
Optional properties:
- powerdown-gpios: power-down gpio
- reg: I2C address. If and only if present the device node
should be placed into the i2c controller node where the
tfp410 i2c is connected to.
Required nodes:
- Video port 0 for DPI input
- Video port 1 for DVI output
- Video port 0 for DPI input [1].
- Video port 1 for DVI output [1].
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example
-------

42
dts/Bindings/display/ht16k33.txt Normal file
View File

@ -0,0 +1,42 @@
Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan
-------------------------------------------------------------------------------
Required properties:
- compatible: "holtek,ht16k33"
- reg: I2C slave address of the chip.
- interrupt-parent: A phandle pointing to the interrupt controller
serving the interrupt for this chip.
- interrupts: Interrupt specification for the key pressed interrupt.
- refresh-rate-hz: Display update interval in HZ.
- debounce-delay-ms: Debouncing interval time in milliseconds.
- linux,keymap: The keymap for keys as described in the binding
document (devicetree/bindings/input/matrix-keymap.txt).
Optional properties:
- linux,no-autorepeat: Disable keyrepeat.
- default-brightness-level: Initial brightness level [0-15] (default: 15).
Example:
&i2c1 {
ht16k33: ht16k33@70 {
compatible = "holtek,ht16k33";
reg = <0x70>;
refresh-rate-hz = <20>;
debounce-delay-ms = <50>;
interrupt-parent = <&gpio4>;
interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
linux,keymap = <
MATRIX_KEY(2, 0, KEY_F6)
MATRIX_KEY(3, 0, KEY_F8)
MATRIX_KEY(4, 0, KEY_F10)
MATRIX_KEY(5, 0, KEY_F4)
MATRIX_KEY(6, 0, KEY_F2)
MATRIX_KEY(2, 1, KEY_F5)
MATRIX_KEY(3, 1, KEY_F7)
MATRIX_KEY(4, 1, KEY_F9)
MATRIX_KEY(5, 1, KEY_F3)
MATRIX_KEY(6, 1, KEY_F1)
>;
};
};

53
dts/Bindings/display/mxsfb.txt
View File

@ -1,20 +1,57 @@
* Freescale MXS LCD Interface (LCDIF)
New bindings:
=============
Required properties:
- compatible: Should be "fsl,<chip>-lcdif". Supported chips include
imx23 and imx28.
- reg: Address and length of the register set for lcdif
- interrupts: Should contain lcdif interrupts
- display : phandle to display node (see below for details)
- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
Should be "fsl,imx28-lcdif" for i.MX28.
Should be "fsl,imx6sx-lcdif" for i.MX6SX.
- reg: Address and length of the register set for LCDIF
- interrupts: Should contain LCDIF interrupt
- clocks: A list of phandle + clock-specifier pairs, one for each
entry in 'clock-names'.
- clock-names: A list of clock names. For MXSFB it should contain:
- "pix" for the LCDIF block clock
- (MX6SX-only) "axi", "disp_axi" for the bus interface clock
Required sub-nodes:
- port: The connection to an encoder chip.
Example:
lcdif1: display-controller@2220000 {
compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
reg = <0x02220000 0x4000>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
<&clks IMX6SX_CLK_LCDIF_APB>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
clock-names = "pix", "axi", "disp_axi";
port {
parallel_out: endpoint {
remote-endpoint = <&panel_in_parallel>;
};
};
};
Deprecated bindings:
====================
Required properties:
- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
Should be "fsl,imx28-lcdif" for i.MX28.
- reg: Address and length of the register set for LCDIF
- interrupts: Should contain LCDIF interrupts
- display: phandle to display node (see below for details)
* display node
Required properties:
- bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
- bus-width : number of data lines. Could be <8>, <16>, <18> or <24>.
- bits-per-pixel: <16> for RGB565, <32> for RGB888/666.
- bus-width: number of data lines. Could be <8>, <16>, <18> or <24>.
Required sub-node:
- display-timings : Refer to binding doc display-timing.txt for details.
- display-timings: Refer to binding doc display-timing.txt for details.
Examples:

7
dts/Bindings/display/panel/auo,g133han01.txt Normal file
View File

@ -0,0 +1,7 @@
AU Optronics Corporation 13.3" FHD (1920x1080) TFT LCD panel
Required properties:
- compatible: should be "auo,g133han01"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
dts/Bindings/display/panel/auo,g185han01.txt Normal file
View File

@ -0,0 +1,7 @@
AU Optronics Corporation 18.5" FHD (1920x1080) TFT LCD panel
Required properties:
- compatible: should be "auo,g185han01"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
dts/Bindings/display/panel/auo,t215hvn01.txt Normal file
View File

@ -0,0 +1,7 @@
AU Optronics Corporation 21.5" FHD (1920x1080) color TFT LCD panel
Required properties:
- compatible: should be "auo,t215hvn01"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
dts/Bindings/display/panel/chunghwa,claa070wp03xg.txt Normal file
View File

@ -0,0 +1,7 @@
Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
Required properties:
- compatible: should be "chunghwa,claa070wp03xg"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

8
dts/Bindings/display/panel/display-timing.txt
View File

@ -32,6 +32,14 @@ optional properties:
- active low = drive pixel data on falling edge/
sample data on rising edge
- ignored = ignored
- syncclk-active: with
- active high = drive sync on rising edge/
sample sync on falling edge of pixel
clock
- active low = drive sync on falling edge/
sample sync on rising edge of pixel
clock
- omitted = same configuration as pixelclk-active
- interlaced (bool): boolean to enable interlaced mode
- doublescan (bool): boolean to enable doublescan mode
- doubleclk (bool): boolean to enable doubleclock mode

7
dts/Bindings/display/panel/nvd,9128.txt Normal file
View File

@ -0,0 +1,7 @@
New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
Required properties:
- compatible: should be "nvd,9128"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

36
dts/Bindings/display/panel/sharp,lq150x1lg11.txt Normal file
View File

@ -0,0 +1,36 @@
Sharp 15" LQ150X1LG11 XGA TFT LCD panel
Required properties:
- compatible: should be "sharp,lq150x1lg11"
- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
Optional properties:
- backlight: phandle of the backlight device
- rlud-gpios: a single GPIO for the RL/UD (rotate 180 degrees) pin.
- sellvds-gpios: a single GPIO for the SELLVDS pin.
If rlud-gpios and/or sellvds-gpios are not specified, the RL/UD and/or SELLVDS
pins are assumed to be handled appropriately by the hardware.
Example:
backlight: backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 100000>; /* VBR */
brightness-levels = <0 20 40 60 80 100>;
default-brightness-level = <2>;
power-supply = <&vdd_12v_reg>; /* VDD */
enable-gpios = <&gpio 42 GPIO_ACTIVE_HIGH>; /* XSTABY */
};
panel {
compatible = "sharp,lq150x1lg11";
power-supply = <&vcc_3v3_reg>; /* VCC */
backlight = <&backlight>;
rlud-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; /* RL/UD */
sellvds-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>; /* SELLVDS */
};

12
dts/Bindings/display/renesas,du.txt
View File

@ -6,9 +6,11 @@ Required Properties:
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
- "renesas,du-r8a7792" for R8A7792 (R-Car V2H) compatible DU
- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
- "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
- "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
- reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
@ -25,10 +27,10 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
- R8A779[01345] use one functional clock per channel and one clock per LVDS
encoder (if available). The functional clocks must be named "du.x" with
"x" being the channel numerical index. The LVDS clocks must be named
"lvds.x" with "x" being the LVDS encoder numerical index.
- R8A779[0123456] use one functional clock per channel and one clock per
LVDS encoder (if available). The functional clocks must be named "du.x"
with "x" being the channel numerical index. The LVDS clocks must be
named "lvds.x" with "x" being the LVDS encoder numerical index.
- In addition to the functional and encoder clocks, all DU versions also
support externally supplied pixel clocks. Those clocks are optional.
When supplied they must be named "dclkin.x" with "x" being the input
@ -47,9 +49,11 @@ corresponding to each DU output.
R8A7779 (H1) DPAD 0 DPAD 1 - -
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
R8A7791 (M2-W) DPAD LVDS 0 - -
R8A7792 (V2H) DPAD 0 DPAD 1 - -
R8A7793 (M2-N) DPAD LVDS 0 - -
R8A7794 (E2) DPAD 0 DPAD 1 - -
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
R8A7796 (M3-W) DPAD HDMI LVDS -
Example: R8A7790 (R-Car H2) DU

10
dts/Bindings/display/sunxi/sun4i-drm.txt
View File

@ -28,6 +28,8 @@ The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
Required properties:
- compatible: value must be either:
* allwinner,sun5i-a13-tcon
* allwinner,sun6i-a31-tcon
* allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
@ -50,7 +52,7 @@ Required properties:
second the block connected to the TCON channel 1 (usually the TV
encoder)
On the A13, there is one more clock required:
On SoCs other than the A33, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
DRC
@ -64,6 +66,8 @@ adaptive backlight control.
Required properties:
- compatible: value must be one of:
* allwinner,sun6i-a31-drc
* allwinner,sun6i-a31s-drc
* allwinner,sun8i-a33-drc
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
@ -87,6 +91,7 @@ system.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-backend
* allwinner,sun6i-a31-display-backend
* allwinner,sun8i-a33-display-backend
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the frontend and backend
@ -117,6 +122,7 @@ deinterlacing and color space conversion.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-frontend
* allwinner,sun6i-a31-display-frontend
* allwinner,sun8i-a33-display-frontend
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
@ -142,6 +148,8 @@ extra node.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-engine
* allwinner,sun6i-a31-display-engine
* allwinner,sun6i-a31s-display-engine
* allwinner,sun8i-a33-display-engine
- allwinner,pipelines: list of phandle to the display engine

6
dts/Bindings/display/tilcdc/tilcdc.txt
View File

@ -1,7 +1,9 @@
Device-Tree bindings for tilcdc DRM driver
Required properties:
- compatible: value should be "ti,am33xx-tilcdc".
- compatible: value should be one of the following:
- "ti,am33xx-tilcdc" for AM335x based boards
- "ti,da850-tilcdc" for DA850/AM18x/OMAP-L138 based boards
- interrupts: the interrupt number
- reg: base address and size of the LCDC device
@ -51,7 +53,7 @@ Optional nodes:
Example:
fb: fb@4830e000 {
compatible = "ti,am33xx-tilcdc";
compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
reg = <0x4830e000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <36>;

84
dts/Bindings/display/zte,vou.txt Normal file
View File

@ -0,0 +1,84 @@
ZTE VOU Display Controller
This is a display controller found on ZTE ZX296718 SoC. It includes multiple
Graphic Layer (GL) and Video Layer (VL), two Mixers/Channels, and a few blocks
handling scaling, color space conversion etc. VOU also integrates the support
for typical output devices, like HDMI, TV Encoder, VGA, and RGB LCD.
* Master VOU node
It must be the parent node of all the sub-device nodes.
Required properties:
- compatible: should be "zte,zx296718-vou"
- #address-cells: should be <1>
- #size-cells: should be <1>
- ranges: list of address translations between VOU and sub-devices
* VOU DPC device
Required properties:
- compatible: should be "zte,zx296718-dpc"
- reg: Physical base address and length of DPC register regions, one for each
entry in 'reg-names'
- reg-names: The names of register regions. The following regions are required:
"osd"
"timing_ctrl"
"dtrc"
"vou_ctrl"
"otfppu"
- interrupts: VOU DPC interrupt number to CPU
- clocks: A list of phandle + clock-specifier pairs, one for each entry
in 'clock-names'
- clock-names: A list of clock names. The following clocks are required:
"aclk"
"ppu_wclk"
"main_wclk"
"aux_wclk"
* HDMI output device
Required properties:
- compatible: should be "zte,zx296718-hdmi"
- reg: Physical base address and length of the HDMI device IO region
- interrupts : HDMI interrupt number to CPU
- clocks: A list of phandle + clock-specifier pairs, one for each entry
in 'clock-names'
- clock-names: A list of clock names. The following clocks are required:
"osc_cec"
"osc_clk"
"xclk"
Example:
vou: vou@1440000 {
compatible = "zte,zx296718-vou";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1440000 0x10000>;
dpc: dpc@0 {
compatible = "zte,zx296718-dpc";
reg = <0x0000 0x1000>, <0x1000 0x1000>,
<0x5000 0x1000>, <0x6000 0x1000>,
<0xa000 0x1000>;
reg-names = "osd", "timing_ctrl",
"dtrc", "vou_ctrl",
"otfppu";
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&topcrm VOU_ACLK>, <&topcrm VOU_PPU_WCLK>,
<&topcrm VOU_MAIN_WCLK>, <&topcrm VOU_AUX_WCLK>;
clock-names = "aclk", "ppu_wclk",
"main_wclk", "aux_wclk";
};
hdmi: hdmi@c000 {
compatible = "zte,zx296718-hdmi";
reg = <0xc000 0x4000>;
interrupts = <GIC_SPI 82 IRQ_TYPE_EDGE_RISING>;
clocks = <&topcrm HDMI_OSC_CEC>,
<&topcrm HDMI_OSC_CLK>,
<&topcrm HDMI_XCLK>;
clock-names = "osc_cec", "osc_clk", "xclk";
};
};

8
dts/Bindings/dma/nbpfaxi.txt
View File

@ -23,6 +23,14 @@ Required properties
#define NBPF_SLAVE_RQ_LEVEL 4
Optional properties:
- max-burst-mem-read: limit burst size for memory reads
(DMA_MEM_TO_MEM/DMA_MEM_TO_DEV) to this value, specified in bytes, rather
than using the maximum burst size allowed by the hardware's buffer size.
- max-burst-mem-write: limit burst size for memory writes
(DMA_DEV_TO_MEM/DMA_MEM_TO_MEM) to this value, specified in bytes, rather
than using the maximum burst size allowed by the hardware's buffer size.
If both max-burst-mem-read and max-burst-mem-write are set, DMA_MEM_TO_MEM
will use the lower value.
You can use dma-channels and dma-requests as described in dma.txt, although they
won't be used, this information is derived from the compatibility string.

12
dts/Bindings/dma/qcom_hidma_mgmt.txt
View File

@ -5,13 +5,13 @@ memcpy and memset capabilities. It has been designed for virtualized
environments.
Each HIDMA HW instance consists of multiple DMA channels. These channels
share the same bandwidth. The bandwidth utilization can be parititioned
share the same bandwidth. The bandwidth utilization can be partitioned
among channels based on the priority and weight assignments.
There are only two priority levels and 15 weigh assignments possible.
Other parameters here determine how much of the system bus this HIDMA
instance can use like maximum read/write request and and number of bytes to
instance can use like maximum read/write request and number of bytes to
read/write in a single burst.
Main node required properties:
@ -47,12 +47,18 @@ When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
- compatible: must contain "qcom,hidma-1.0"
- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
for MSI capable HW.
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
- iommus: required a iommu node
Optional properties for MSI:
- msi-parent : See the generic MSI binding described in
devicetree/bindings/interrupt-controller/msi.txt for a description of the
msi-parent property.
Example:
Hypervisor OS configuration:

1
dts/Bindings/dma/renesas,rcar-dmac.txt
View File

@ -24,6 +24,7 @@ Required Properties:
- "renesas,dmac-r8a7793" (R-Car M2-N)
- "renesas,dmac-r8a7794" (R-Car E2)
- "renesas,dmac-r8a7795" (R-Car H3)
- "renesas,dmac-r8a7796" (R-Car M3-W)
- reg: base address and length of the registers block for the DMAC

2
dts/Bindings/dma/snps-dma.txt
View File

@ -27,6 +27,8 @@ Optional properties:
that services interrupts for this device
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
- multi-block: Multi block transfers supported by hardware. Array property with
one cell per channel. 0: not supported, 1 (default): supported.
Example:

87
dts/Bindings/dma/st_fdma.txt Normal file
View File

@ -0,0 +1,87 @@
* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
The FDMA is a general-purpose direct memory access controller capable of
supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
The FDMA is based on a Slim processor which requires a firmware.
* FDMA Controller
Required properties:
- compatible : Should be one of
- st,stih407-fdma-mpe31-11, "st,slim-rproc";
- st,stih407-fdma-mpe31-12, "st,slim-rproc";
- st,stih407-fdma-mpe31-13, "st,slim-rproc";
- reg : Should contain an entry for each name in reg-names
- reg-names : Must contain "slimcore", "dmem", "peripherals", "imem" entries
- interrupts : Should contain one interrupt shared by all channels
- dma-channels : Number of channels supported by the controller
- #dma-cells : Must be <3>. See DMA client section below
- clocks : Must contain an entry for each clock
See: Documentation/devicetree/bindings/clock/clock-bindings.txt
Example:
fdma0: dma-controller@8e20000 {
compatible = "st,stih407-fdma-mpe31-11", "st,slim-rproc";
reg = <0x8e20000 0x8000>,
<0x8e30000 0x3000>,
<0x8e37000 0x1000>,
<0x8e38000 0x8000>;
reg-names = "slimcore", "dmem", "peripherals", "imem";
clocks = <&clk_s_c0_flexgen CLK_FDMA>,
<&clk_s_c0_flexgen CLK_EXT2F_A9>,
<&clk_s_c0_flexgen CLK_EXT2F_A9>,
<&clk_s_c0_flexgen CLK_EXT2F_A9>;
interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
dma-channels = <16>;
#dma-cells = <3>;
};
* DMA client
Required properties:
- dmas: Comma separated list of dma channel requests
- dma-names: Names of the aforementioned requested channels
Each dmas request consists of 4 cells:
1. A phandle pointing to the FDMA controller
2. The request line number
3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
-bit 2-0: Holdoff value, dreq will be masked for
0x0: 0-0.5us
0x1: 0.5-1us
0x2: 1-1.5us
-bit 17: data swap
0x0: disabled
0x1: enabled
-bit 21: Increment Address
0x0: no address increment between transfers
0x1: increment address between transfers
-bit 22: 2 STBus Initiator Coprocessor interface
0x0: high priority port
0x1: low priority port
4. transfers type
0 free running
1 paced
Example:
sti_uni_player2: sti-uni-player@2 {
compatible = "st,sti-uni-player";
status = "disabled";
#sound-dai-cells = <0>;
st,syscfg = <&syscfg_core>;
clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
assigned-clocks = <&clk_s_d0_flexgen CLK_PCM_2>;
assigned-clock-parents = <&clk_s_d0_quadfs 2>;
assigned-clock-rates = <50000000>;
reg = <0x8D82000 0x158>;
interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
dmas = <&fdma0 4 0 1>;
dai-name = "Uni Player #1 (DAC)";
dma-names = "tx";
st,uniperiph-id = <2>;
st,version = <5>;
st,mode = "PCM";
};

3
dts/Bindings/extcon/extcon-usb-gpio.txt
View File

@ -5,7 +5,10 @@ connected to a GPIO pin.
Required properties:
- compatible: Should be "linux,extcon-usb-gpio"
Either one of id-gpio or vbus-gpio must be present. Both can be present as well.
- id-gpio: gpio for USB ID pin. See gpio binding.
- vbus-gpio: gpio for USB VBUS pin.
Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
extcon_usb1 {

108
dts/Bindings/firmware/nvidia,tegra186-bpmp.txt Normal file
View File

@ -0,0 +1,108 @@
NVIDIA Tegra Boot and Power Management Processor (BPMP)
The BPMP is a specific processor in Tegra chip, which is designed for
booting process handling and offloading the power management, clock
management, and reset control tasks from the CPU. The binding document
defines the resources that would be used by the BPMP firmware driver,
which can create the interprocessor communication (IPC) between the CPU
and BPMP.
Required properties:
- name : Should be bpmp
- compatible
Array of strings
One of:
- "nvidia,tegra186-bpmp"
- mboxes : The phandle of mailbox controller and the mailbox specifier.
- shmem : List of the phandle of the TX and RX shared memory area that
the IPC between CPU and BPMP is based on.
- #clock-cells : Should be 1.
- #power-domain-cells : Should be 1.
- #reset-cells : Should be 1.
This node is a mailbox consumer. See the following files for details of
the mailbox subsystem, and the specifiers implemented by the relevant
provider(s):
- .../mailbox/mailbox.txt
- .../mailbox/nvidia,tegra186-hsp.txt
This node is a clock, power domain, and reset provider. See the following
files for general documentation of those features, and the specifiers
implemented by this node:
- .../clock/clock-bindings.txt
- <dt-bindings/clock/tegra186-clock.h>
- ../power/power_domain.txt
- <dt-bindings/power/tegra186-powergate.h>
- .../reset/reset.txt
- <dt-bindings/reset/tegra186-reset.h>
The BPMP implements some services which must be represented by separate nodes.
For example, it can provide access to certain I2C controllers, and the I2C
bindings represent each I2C controller as a device tree node. Such nodes should
be nested directly inside the main BPMP node.
Software can determine whether a child node of the BPMP node represents a device
by checking for a compatible property. Any node with a compatible property
represents a device that can be instantiated. Nodes without a compatible
property may be used to provide configuration information regarding the BPMP
itself, although no such configuration nodes are currently defined by this
binding.
The BPMP firmware defines no single global name-/numbering-space for such
services. Put another way, the numbering scheme for I2C buses is distinct from
the numbering scheme for any other service the BPMP may provide (e.g. a future
hypothetical SPI bus service). As such, child device nodes will have no reg
property, and the BPMP node will have no #address-cells or #size-cells property.
The shared memory bindings for BPMP
-----------------------------------
The shared memory area for the IPC TX and RX between CPU and BPMP are
predefined and work on top of sysram, which is an SRAM inside the chip.
See ".../sram/sram.txt" for the bindings.
Example:
hsp_top0: hsp@03c00000 {
...
#mbox-cells = <2>;
};
sysram@30000000 {
compatible = "nvidia,tegra186-sysram", "mmio-sram";
reg = <0x0 0x30000000 0x0 0x50000>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0 0x0 0x0 0x30000000 0x0 0x50000>;
cpu_bpmp_tx: shmem@4e000 {
compatible = "nvidia,tegra186-bpmp-shmem";
reg = <0x0 0x4e000 0x0 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
cpu_bpmp_rx: shmem@4f000 {
compatible = "nvidia,tegra186-bpmp-shmem";
reg = <0x0 0x4f000 0x0 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
};
bpmp {
compatible = "nvidia,tegra186-bpmp";
mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
#clock-cells = <1>;
#power-domain-cells = <1>;
#reset-cells = <1>;
i2c {
compatible = "...";
...
};
};

2
dts/Bindings/firmware/qcom,scm.txt
View File

@ -10,8 +10,10 @@ Required properties:
* "qcom,scm-apq8064" for APQ8064 platforms
* "qcom,scm-msm8660" for MSM8660 platforms
* "qcom,scm-msm8690" for MSM8690 platforms
* "qcom,scm-msm8996" for MSM8996 platforms
* "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
- clocks: One to three clocks may be required based on compatible.
* No clock required for "qcom,scm-msm8996"
* Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
* Core, iface, and bus clocks required for "qcom,scm"
- clock-names: Must contain "core" for the core clock, "iface" for the interface

16
dts/Bindings/fpga/altera-fpga2sdram-bridge.txt Normal file
View File

@ -0,0 +1,16 @@
Altera FPGA To SDRAM Bridge Driver
Required properties:
- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
Optional properties:
- bridge-enable : 0 if driver should disable bridge at startup
1 if driver should enable bridge at startup
Default is to leave bridge in current state.
Example:
fpga_bridge3: fpga-bridge@ffc25080 {
compatible = "altr,socfpga-fpga2sdram-bridge";
reg = <0xffc25080 0x4>;
bridge-enable = <0>;
};

23
dts/Bindings/fpga/altera-freeze-bridge.txt Normal file
View File

@ -0,0 +1,23 @@
Altera Freeze Bridge Controller Driver
The Altera Freeze Bridge Controller manages one or more freeze bridges.
The controller can freeze/disable the bridges which prevents signal
changes from passing through the bridge. The controller can also
unfreeze/enable the bridges which allows traffic to pass through the
bridge normally.
Required properties:
- compatible : Should contain "altr,freeze-bridge-controller"
- regs : base address and size for freeze bridge module
Optional properties:
- bridge-enable : 0 if driver should disable bridge at startup
1 if driver should enable bridge at startup
Default is to leave bridge in current state.
Example:
freeze-controller@100000450 {
compatible = "altr,freeze-bridge-controller";
regs = <0x1000 0x10>;
bridge-enable = <0>;
};

39
dts/Bindings/fpga/altera-hps2fpga-bridge.txt Normal file
View File

@ -0,0 +1,39 @@
Altera FPGA/HPS Bridge Driver
Required properties:
- regs : base address and size for AXI bridge module
- compatible : Should contain one of:
"altr,socfpga-lwhps2fpga-bridge",
"altr,socfpga-hps2fpga-bridge", or
"altr,socfpga-fpga2hps-bridge"
- resets : Phandle and reset specifier for this bridge's reset
- clocks : Clocks used by this module.
Optional properties:
- bridge-enable : 0 if driver should disable bridge at startup.
1 if driver should enable bridge at startup.
Default is to leave bridge in its current state.
Example:
fpga_bridge0: fpga-bridge@ff400000 {
compatible = "altr,socfpga-lwhps2fpga-bridge";
reg = <0xff400000 0x100000>;
resets = <&rst LWHPS2FPGA_RESET>;
clocks = <&l4_main_clk>;
bridge-enable = <0>;
};
fpga_bridge1: fpga-bridge@ff500000 {
compatible = "altr,socfpga-hps2fpga-bridge";
reg = <0xff500000 0x10000>;
resets = <&rst HPS2FPGA_RESET>;
clocks = <&l4_main_clk>;
bridge-enable = <1>;
};
fpga_bridge2: fpga-bridge@ff600000 {
compatible = "altr,socfpga-fpga2hps-bridge";
reg = <0xff600000 0x100000>;
resets = <&rst FPGA2HPS_RESET>;
clocks = <&l4_main_clk>;
};

19
dts/Bindings/fpga/altera-socfpga-a10-fpga-mgr.txt Normal file
View File

@ -0,0 +1,19 @@
Altera SOCFPGA Arria10 FPGA Manager
Required properties:
- compatible : should contain "altr,socfpga-a10-fpga-mgr"
- reg : base address and size for memory mapped io.
- The first index is for FPGA manager register access.
- The second index is for writing FPGA configuration data.
- resets : Phandle and reset specifier for the device's reset.
- clocks : Clocks used by the device.
Example:
fpga_mgr: fpga-mgr@ffd03000 {
compatible = "altr,socfpga-a10-fpga-mgr";
reg = <0xffd03000 0x100
0xffcfe400 0x20>;
clocks = <&l4_mp_clk>;
resets = <&rst FPGAMGR_RESET>;
};

494
dts/Bindings/fpga/fpga-region.txt Normal file
View File

@ -0,0 +1,494 @@
FPGA Region Device Tree Binding
Alan Tull 2016
CONTENTS
- Introduction
- Terminology
- Sequence
- FPGA Region
- Supported Use Models
- Device Tree Examples
- Constraints
Introduction
============
FPGA Regions represent FPGA's and partial reconfiguration regions of FPGA's in
the Device Tree. FPGA Regions provide a way to program FPGAs under device tree
control.
This device tree binding document hits some of the high points of FPGA usage and
attempts to include terminology used by both major FPGA manufacturers. This
document isn't a replacement for any manufacturers specifications for FPGA
usage.
Terminology
===========
Full Reconfiguration
* The entire FPGA is programmed.
Partial Reconfiguration (PR)
* A section of an FPGA is reprogrammed while the rest of the FPGA is not
affected.
* Not all FPGA's support PR.
Partial Reconfiguration Region (PRR)
* Also called a "reconfigurable partition"
* A PRR is a specific section of a FPGA reserved for reconfiguration.
* A base (or static) FPGA image may create a set of PRR's that later may
be independently reprogrammed many times.
* The size and specific location of each PRR is fixed.
* The connections at the edge of each PRR are fixed. The image that is loaded
into a PRR must fit and must use a subset of the region's connections.
* The busses within the FPGA are split such that each region gets its own
branch that may be gated independently.
Persona
* Also called a "partial bit stream"
* An FPGA image that is designed to be loaded into a PRR. There may be
any number of personas designed to fit into a PRR, but only one at at time
may be loaded.
* A persona may create more regions.
FPGA Bridge
* FPGA Bridges gate bus signals between a host and FPGA.
* FPGA Bridges should be disabled while the FPGA is being programmed to
prevent spurious signals on the cpu bus and to the soft logic.
* FPGA bridges may be actual hardware or soft logic on an FPGA.
* During Full Reconfiguration, hardware bridges between the host and FPGA
will be disabled.
* During Partial Reconfiguration of a specific region, that region's bridge
will be used to gate the busses. Traffic to other regions is not affected.
* In some implementations, the FPGA Manager transparantly handles gating the
buses, eliminating the need to show the hardware FPGA bridges in the
device tree.
* An FPGA image may create a set of reprogrammable regions, each having its
own bridge and its own split of the busses in the FPGA.
FPGA Manager
* An FPGA Manager is a hardware block that programs an FPGA under the control
of a host processor.
Base Image
* Also called the "static image"
* An FPGA image that is designed to do full reconfiguration of the FPGA.
* A base image may set up a set of partial reconfiguration regions that may
later be reprogrammed.
---------------- ----------------------------------
| Host CPU | | FPGA |
| | | |
| ----| | ----------- -------- |
| | H | | |==>| Bridge0 |<==>| PRR0 | |
| | W | | | ----------- -------- |
| | | | | |
| | B |<=====>|<==| ----------- -------- |
| | R | | |==>| Bridge1 |<==>| PRR1 | |
| | I | | | ----------- -------- |
| | D | | | |
| | G | | | ----------- -------- |
| | E | | |==>| Bridge2 |<==>| PRR2 | |
| ----| | ----------- -------- |
| | | |
---------------- ----------------------------------
Figure 1: An FPGA set up with a base image that created three regions. Each
region (PRR0-2) gets its own split of the busses that is independently gated by
a soft logic bridge (Bridge0-2) in the FPGA. The contents of each PRR can be
reprogrammed independently while the rest of the system continues to function.
Sequence
========
When a DT overlay that targets a FPGA Region is applied, the FPGA Region will
do the following:
1. Disable appropriate FPGA bridges.
2. Program the FPGA using the FPGA manager.
3. Enable the FPGA bridges.
4. The Device Tree overlay is accepted into the live tree.
5. Child devices are populated.
When the overlay is removed, the child nodes will be removed and the FPGA Region
will disable the bridges.
FPGA Region
===========
FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA
Region brings together the elements needed to program on a running system and
add the child devices:
* FPGA Manager
* FPGA Bridges
* image-specific information needed to to the programming.
* child nodes
The intended use is that a Device Tree overlay (DTO) can be used to reprogram an
FPGA while an operating system is running.
An FPGA Region that exists in the live Device Tree reflects the current state.
If the live tree shows a "firmware-name" property or child nodes under a FPGA
Region, the FPGA already has been programmed. A DTO that targets a FPGA Region
and adds the "firmware-name" property is taken as a request to reprogram the
FPGA. After reprogramming is successful, the overlay is accepted into the live
tree.
The base FPGA Region in the device tree represents the FPGA and supports full
reconfiguration. It must include a phandle to an FPGA Manager. The base
FPGA region will be the child of one of the hardware bridges (the bridge that
allows register access) between the cpu and the FPGA. If there are more than
one bridge to control during FPGA programming, the region will also contain a
list of phandles to the additional hardware FPGA Bridges.
For partial reconfiguration (PR), each PR region will have an FPGA Region.
These FPGA regions are children of FPGA bridges which are then children of the
base FPGA region. The "Full Reconfiguration to add PRR's" example below shows
this.
If an FPGA Region does not specify a FPGA Manager, it will inherit the FPGA
Manager specified by its ancestor FPGA Region. This supports both the case
where the same FPGA Manager is used for all of a FPGA as well the case where
a different FPGA Manager is used for each region.
FPGA Regions do not inherit their ancestor FPGA regions' bridges. This prevents
shutting down bridges that are upstream from the other active regions while one
region is getting reconfigured (see Figure 1 above). During PR, the FPGA's
hardware bridges remain enabled. The PR regions' bridges will be FPGA bridges
within the static image of the FPGA.
Required properties:
- compatible : should contain "fpga-region"
- fpga-mgr : should contain a phandle to an FPGA Manager. Child FPGA Regions
inherit this property from their ancestor regions. A fpga-mgr property
in a region will override any inherited FPGA manager.
- #address-cells, #size-cells, ranges : must be present to handle address space
mapping for child nodes.
Optional properties:
- firmware-name : should contain the name of an FPGA image file located on the
firmware search path. If this property shows up in a live device tree
it indicates that the FPGA has already been programmed with this image.
If this property is in an overlay targeting a FPGA region, it is a
request to program the FPGA with that image.
- fpga-bridges : should contain a list of phandles to FPGA Bridges that must be
controlled during FPGA programming along with the parent FPGA bridge.
This property is optional if the FPGA Manager handles the bridges.
If the fpga-region is the child of a fpga-bridge, the list should not
contain the parent bridge.
- partial-fpga-config : boolean, set if partial reconfiguration is to be done,
otherwise full reconfiguration is done.
- external-fpga-config : boolean, set if the FPGA has already been configured
prior to OS boot up.
- region-unfreeze-timeout-us : The maximum time in microseconds to wait for
bridges to successfully become enabled after the region has been
programmed.
- region-freeze-timeout-us : The maximum time in microseconds to wait for
bridges to successfully become disabled before the region has been
programmed.
- child nodes : devices in the FPGA after programming.
In the example below, when an overlay is applied targeting fpga-region0,
fpga_mgr is used to program the FPGA. Two bridges are controlled during
programming: the parent fpga_bridge0 and fpga_bridge1. Because the region is
the child of fpga_bridge0, only fpga_bridge1 needs to be specified in the
fpga-bridges property. During programming, these bridges are disabled, the
firmware specified in the overlay is loaded to the FPGA using the FPGA manager
specified in the region. If FPGA programming succeeds, the bridges are
reenabled and the overlay makes it into the live device tree. The child devices
are then populated. If FPGA programming fails, the bridges are left disabled
and the overlay is rejected. The overlay's ranges property maps the lwhps
bridge's region (0xff200000) and the hps bridge's region (0xc0000000) for use by
the two child devices.
Example:
Base tree contains:
fpga_mgr: fpga-mgr@ff706000 {
compatible = "altr,socfpga-fpga-mgr";
reg = <0xff706000 0x1000
0xffb90000 0x20>;
interrupts = <0 175 4>;
};
fpga_bridge0: fpga-bridge@ff400000 {
compatible = "altr,socfpga-lwhps2fpga-bridge";
reg = <0xff400000 0x100000>;
resets = <&rst LWHPS2FPGA_RESET>;
clocks = <&l4_main_clk>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
fpga_region0: fpga-region0 {
compatible = "fpga-region";
fpga-mgr = <&fpga_mgr>;
};
};
fpga_bridge1: fpga-bridge@ff500000 {
compatible = "altr,socfpga-hps2fpga-bridge";
reg = <0xff500000 0x10000>;
resets = <&rst HPS2FPGA_RESET>;
clocks = <&l4_main_clk>;
};
Overlay contains:
/dts-v1/ /plugin/;
/ {
fragment@0 {
target = <&fpga_region0>;
#address-cells = <1>;
#size-cells = <1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <1>;
firmware-name = "soc_system.rbf";
fpga-bridges = <&fpga_bridge1>;
ranges = <0x20000 0xff200000 0x100000>,
<0x0 0xc0000000 0x20000000>;
gpio@10040 {
compatible = "altr,pio-1.0";
reg = <0x10040 0x20>;
altr,gpio-bank-width = <4>;
#gpio-cells = <2>;
clocks = <2>;
gpio-controller;
};
onchip-memory {
device_type = "memory";
compatible = "altr,onchipmem-15.1";
reg = <0x0 0x10000>;
};
};
};
};
Supported Use Models
====================
In all cases the live DT must have the FPGA Manager, FPGA Bridges (if any), and
a FPGA Region. The target of the Device Tree Overlay is the FPGA Region. Some
uses are specific to a FPGA device.
* No FPGA Bridges
In this case, the FPGA Manager which programs the FPGA also handles the
bridges behind the scenes. No FPGA Bridge devices are needed for full
reconfiguration.
* Full reconfiguration with hardware bridges
In this case, there are hardware bridges between the processor and FPGA that
need to be controlled during full reconfiguration. Before the overlay is
applied, the live DT must include the FPGA Manager, FPGA Bridges, and a
FPGA Region. The FPGA Region is the child of the bridge that allows
register access to the FPGA. Additional bridges may be listed in a
fpga-bridges property in the FPGA region or in the device tree overlay.
* Partial reconfiguration with bridges in the FPGA
In this case, the FPGA will have one or more PRR's that may be programmed
separately while the rest of the FPGA can remain active. To manage this,
bridges need to exist in the FPGA that can gate the buses going to each FPGA
region while the buses are enabled for other sections. Before any partial
reconfiguration can be done, a base FPGA image must be loaded which includes
PRR's with FPGA bridges. The device tree should have a FPGA region for each
PRR.
Device Tree Examples
====================
The intention of this section is to give some simple examples, focusing on
the placement of the elements detailed above, especially:
* FPGA Manager
* FPGA Bridges
* FPGA Region
* ranges
* target-path or target
For the purposes of this section, I'm dividing the Device Tree into two parts,
each with its own requirements. The two parts are:
* The live DT prior to the overlay being added
* The DT overlay
The live Device Tree must contain an FPGA Region, an FPGA Manager, and any FPGA
Bridges. The FPGA Region's "fpga-mgr" property specifies the manager by phandle
to handle programming the FPGA. If the FPGA Region is the child of another FPGA
Region, the parent's FPGA Manager is used. If FPGA Bridges need to be involved,
they are specified in the FPGA Region by the "fpga-bridges" property. During
FPGA programming, the FPGA Region will disable the bridges that are in its
"fpga-bridges" list and will re-enable them after FPGA programming has
succeeded.
The Device Tree Overlay will contain:
* "target-path" or "target"
The insertion point where the the contents of the overlay will go into the
live tree. target-path is a full path, while target is a phandle.
* "ranges"
The address space mapping from processor to FPGA bus(ses).
* "firmware-name"
Specifies the name of the FPGA image file on the firmware search
path. The search path is described in the firmware class documentation.
* "partial-fpga-config"
This binding is a boolean and should be present if partial reconfiguration
is to be done.
* child nodes corresponding to hardware that will be loaded in this region of
the FPGA.
Device Tree Example: Full Reconfiguration without Bridges
=========================================================
Live Device Tree contains:
fpga_mgr0: fpga-mgr@f8007000 {
compatible = "xlnx,zynq-devcfg-1.0";
reg = <0xf8007000 0x100>;
interrupt-parent = <&intc>;
interrupts = <0 8 4>;
clocks = <&clkc 12>;
clock-names = "ref_clk";
syscon = <&slcr>;
};
fpga_region0: fpga-region0 {
compatible = "fpga-region";
fpga-mgr = <&fpga_mgr0>;
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges;
};
DT Overlay contains:
/dts-v1/ /plugin/;
/ {
fragment@0 {
target = <&fpga_region0>;
#address-cells = <1>;
#size-cells = <1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <1>;
firmware-name = "zynq-gpio.bin";
gpio1: gpio@40000000 {
compatible = "xlnx,xps-gpio-1.00.a";
reg = <0x40000000 0x10000>;
gpio-controller;
#gpio-cells = <0x2>;
xlnx,gpio-width= <0x6>;
};
};
};
Device Tree Example: Full Reconfiguration to add PRR's
======================================================
The base FPGA Region is specified similar to the first example above.
This example programs the FPGA to have two regions that can later be partially
configured. Each region has its own bridge in the FPGA fabric.
DT Overlay contains:
/dts-v1/ /plugin/;
/ {
fragment@0 {
target = <&fpga_region0>;
#address-cells = <1>;
#size-cells = <1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <1>;
firmware-name = "base.rbf";
fpga-bridge@4400 {
compatible = "altr,freeze-bridge";
reg = <0x4400 0x10>;
fpga_region1: fpga-region1 {
compatible = "fpga-region";
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges;
};
};
fpga-bridge@4420 {
compatible = "altr,freeze-bridge";
reg = <0x4420 0x10>;
fpga_region2: fpga-region2 {
compatible = "fpga-region";
#address-cells = <0x1>;
#size-cells = <0x1>;
ranges;
};
};
};
};
};
Device Tree Example: Partial Reconfiguration
============================================
This example reprograms one of the PRR's set up in the previous example.
The sequence that occurs when this overlay is similar to the above, the only
differences are that the FPGA is partially reconfigured due to the
"partial-fpga-config" boolean and the only bridge that is controlled during
programming is the FPGA based bridge of fpga_region1.
/dts-v1/ /plugin/;
/ {
fragment@0 {
target = <&fpga_region1>;
#address-cells = <1>;
#size-cells = <1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <1>;
firmware-name = "soc_image2.rbf";
partial-fpga-config;
gpio@10040 {
compatible = "altr,pio-1.0";
reg = <0x10040 0x20>;
clocks = <0x2>;
altr,gpio-bank-width = <0x4>;
resetvalue = <0x0>;
#gpio-cells = <0x2>;
gpio-controller;
};
};
};
};
Constraints
===========
It is beyond the scope of this document to fully describe all the FPGA design
constraints required to make partial reconfiguration work[1] [2] [3], but a few
deserve quick mention.
A persona must have boundary connections that line up with those of the partion
or region it is designed to go into.
During programming, transactions through those connections must be stopped and
the connections must be held at a fixed logic level. This can be achieved by
FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration.
--
[1] www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf
[2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf
[3] http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf

41
dts/Bindings/gpio/gpio-sx150x.txt
View File

@ -1,41 +0,0 @@
SEMTECH SX150x GPIO expander bindings
Required properties:
- compatible: should be "semtech,sx1506q",
"semtech,sx1508q",
"semtech,sx1509q",
"semtech,sx1502q".
- reg: The I2C slave address for this device.
- interrupt-parent: phandle of the parent interrupt controller.
- interrupts: Interrupt specifier for the controllers interrupt.
- #gpio-cells: Should be 2. The first cell is the GPIO number and the
second cell is used to specify optional parameters:
bit 0: polarity (0: normal, 1: inverted)
- gpio-controller: Marks the device as a GPIO controller.
- interrupt-controller: Marks the device as a interrupt controller.
The GPIO expander can optionally be used as an interrupt controller, in
which case it uses the default two cell specifier as described in
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
Example:
i2c_gpio_expander@20{
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "semtech,sx1506q";
reg = <0x20>;
interrupt-parent = <&gpio_1>;
interrupts = <16 0>;
gpio-controller;
interrupt-controller;
};

2
dts/Bindings/gpio/gpio_oxnas.txt
View File

@ -3,7 +3,7 @@
Please refer to gpio.txt for generic information regarding GPIO bindings.
Required properties:
- compatible: "oxsemi,ox810se-gpio"
- compatible: "oxsemi,ox810se-gpio" or "oxsemi,ox820-gpio"
- reg: Base address and length for the device.
- interrupts: The port interrupt shared by all pins.
- gpio-controller: Marks the port as GPIO controller.

6
dts/Bindings/gpio/mrvl-gpio.txt
View File

@ -17,7 +17,9 @@ Required properties:
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source.
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be one. It is the pin number.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify flags. See gpio.txt for possible
values.
Example for a MMP platform:
@ -27,7 +29,7 @@ Example for a MMP platform:
interrupts = <49>;
interrupt-names = "gpio_mux";
gpio-controller;
#gpio-cells = <1>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <1>;
};

21
dts/Bindings/hwmon/mcp3021.txt Normal file
View File

@ -0,0 +1,21 @@
mcp3021 properties
Required properties:
- compatible: Must be one of the following:
- "microchip,mcp3021" for mcp3021
- "microchip,mcp3221" for mcp3221
- reg: I2C address
Optional properties:
- reference-voltage-microvolt
Reference voltage in microvolt (uV)
Example:
mcp3021@4d {
compatible = "microchip,mcp3021";
reg = <0x4d>;
reference-voltage-microvolt = <4500000>; /* 4.5 V */
};

14
dts/Bindings/hwmon/tmp108.txt Normal file
View File

@ -0,0 +1,14 @@
TMP108 temperature sensor
-------------------------
This device supports I2C only.
Requires node properties:
- compatible : "ti,tmp108"
- reg : the I2C address of the device. This is 0x48, 0x49, 0x4a, or 0x4b.
Example:
tmp108@48 {
compatible = "ti,tmp108";
reg = <0x48>;
};

20
dts/Bindings/i2c/i2c-imx-lpi2c.txt Normal file
View File

@ -0,0 +1,20 @@
* Freescale Low Power Inter IC (LPI2C) for i.MX
Required properties:
- compatible :
- "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc
- "fsl,imx8dv-lpi2c" for LPI2C compatible with the one integrated on i.MX8DV soc
- reg : address and length of the lpi2c master registers
- interrupt-parent : core interrupt controller
- interrupts : lpi2c interrupt
- clocks : lpi2c clock specifier
Examples:
lpi2c7: lpi2c7@40A50000 {
compatible = "fsl,imx8dv-lpi2c";
reg = <0x40A50000 0x10000>;
interrupt-parent = <&intc>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7ULP_CLK_LPI2C7>;
};

1
dts/Bindings/i2c/i2c-pxa.txt
View File

@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :

32
dts/Bindings/i2c/i2c-rcar.txt
View File

@ -1,17 +1,25 @@
I2C for R-Car platforms
Required properties:
- compatible: Must be one of
"renesas,i2c-rcar"
"renesas,i2c-r8a7778"
"renesas,i2c-r8a7779"
"renesas,i2c-r8a7790"
"renesas,i2c-r8a7791"
"renesas,i2c-r8a7792"
"renesas,i2c-r8a7793"
"renesas,i2c-r8a7794"
"renesas,i2c-r8a7795"
"renesas,i2c-r8a7796"
- compatible:
"renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
"renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
"renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
"renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC.
"renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC.
"renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC.
"renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC.
"renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC.
"renesas,i2c-r8a7796" if the device is a part of a R8A7796 SoC.
"renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device.
"renesas,rcar-gen2-i2c" for a generic R-Car Gen2 compatible device.
"renesas,rcar-gen3-i2c" for a generic R-Car Gen3 compatible device.
"renesas,i2c-rcar" (deprecated)
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first followed
by the generic version.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@ -33,7 +41,7 @@ Examples :
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "renesas,i2c-r8a7791";
compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;

17
dts/Bindings/i2c/i2c-sh_mobile.txt
View File

@ -1,8 +1,7 @@
Device tree configuration for Renesas IIC (sh_mobile) driver
Required properties:
- compatible : "renesas,iic-<soctype>". "renesas,rmobile-iic" as fallback
Examples with soctypes are:
- compatible :
- "renesas,iic-r8a73a4" (R-Mobile APE6)
- "renesas,iic-r8a7740" (R-Mobile A1)
- "renesas,iic-r8a7790" (R-Car H2)
@ -12,6 +11,17 @@ Required properties:
- "renesas,iic-r8a7794" (R-Car E2)
- "renesas,iic-r8a7795" (R-Car H3)
- "renesas,iic-sh73a0" (SH-Mobile AG5)
- "renesas,rcar-gen2-iic" (generic R-Car Gen2 compatible device)
- "renesas,rcar-gen3-iic" (generic R-Car Gen3 compatible device)
- "renesas,rmobile-iic" (generic device)
When compatible with a generic R-Car version, nodes
must list the SoC-specific version corresponding to
the platform first followed by the generic R-Car
version.
renesas,rmobile-iic must always follow.
- reg : address start and address range size of device
- interrupts : interrupt of device
- clocks : clock for device
@ -31,7 +41,8 @@ Pinctrl properties might be needed, too. See there.
Example:
iic0: i2c@e6500000 {
compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
"renesas,rmobile-iic";
reg = <0 0xe6500000 0 0x425>;
interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7790_CLK_IIC0>;

12
dts/Bindings/i2c/trivial-devices.txt
View File

@ -39,11 +39,13 @@ dallas,ds75 Digital Thermometer and Thermostat
dlg,da9053 DA9053: flexible system level PMIC with multicore support
dlg,da9063 DA9063: system PMIC for quad-core application processors
domintech,dmard09 DMARD09: 3-axis Accelerometer
domintech,dmard10 DMARD10: 3-axis Accelerometer
epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK MODULE
epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer
fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51
fsl,mma7660 MMA7660FC: 3-Axis Orientation/Motion Detection Sensor
fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
fsl,mpl3115 MPL3115: Absolute Digital Pressure Sensor
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
@ -57,6 +59,7 @@ maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
mc,rv3029c2 Real Time Clock Module with I2C-Bus
mcube,mc3230 mCube 3-axis 8-bit digital accelerometer
memsic,mxc6225 MEMSIC 2-axis 8-bit digital accelerometer
microchip,mcp4531-502 Microchip 7-bit Single I2C Digital Potentiometer (5k)
microchip,mcp4531-103 Microchip 7-bit Single I2C Digital Potentiometer (10k)
microchip,mcp4531-503 Microchip 7-bit Single I2C Digital Potentiometer (50k)
@ -121,6 +124,11 @@ microchip,mcp4662-502 Microchip 8-bit Dual I2C Digital Potentiometer with NV Mem
microchip,mcp4662-103 Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (10k)
microchip,mcp4662-503 Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (50k)
microchip,mcp4662-104 Microchip 8-bit Dual I2C Digital Potentiometer with NV Memory (100k)
microchip,tc654 PWM Fan Speed Controller With Fan Fault Detection
microchip,tc655 PWM Fan Speed Controller With Fan Fault Detection
miramems,da226 MiraMEMS DA226 2-axis 14-bit digital accelerometer
miramems,da280 MiraMEMS DA280 3-axis 14-bit digital accelerometer
miramems,da311 MiraMEMS DA311 3-axis 12-bit digital accelerometer
national,lm63 Temperature sensor with integrated fan control
national,lm75 I2C TEMP SENSOR
national,lm80 Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
@ -130,6 +138,8 @@ nuvoton,npct501 i2c trusted platform module (TPM)
nuvoton,npct601 i2c trusted platform module (TPM2)
nxp,pca9556 Octal SMBus and I2C registered interface
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
nxp,pcf2127 Real-time clock
nxp,pcf2129 Real-time clock
nxp,pcf8563 Real-time clock/calendar
nxp,pcf85063 Tiny Real-Time Clock
oki,ml86v7667 OKI ML86V7667 video decoder
@ -146,6 +156,7 @@ ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
sgx,vz89x SGX Sensortech VZ89X Sensors
sii,s35390a 2-wire CMOS real-time clock
silabs,si7020 Relative Humidity and Temperature Sensors
skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply
st,24c256 i2c serial eeprom (24cxx)
st,m41t00 Serial real-time clock (RTC)
@ -158,4 +169,5 @@ ti,tsc2003 I2C Touch-Screen Controller
ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
ti,tmp275 Digital Temperature Sensor
winbond,w83793 Winbond/Nuvoton H/W Monitor
winbond,wpct301 i2c trusted platform module (TPM)

54
dts/Bindings/iio/adc/envelope-detector.txt Normal file
View File

@ -0,0 +1,54 @@
Bindings for ADC envelope detector using a DAC and a comparator
The DAC is used to find the peak level of an alternating voltage input
signal by a binary search using the output of a comparator wired to
an interrupt pin. Like so:
_
| \
input +------>-------|+ \
| \
.-------. | }---.
| | | / |
| dac|-->--|- / |
| | |_/ |
| | |
| | |
| irq|------<-------'
| |
'-------'
Required properties:
- compatible: Should be "axentia,tse850-envelope-detector"
- io-channels: Channel node of the dac to be used for comparator input.
- io-channel-names: Should be "dac".
- interrupt specification for one client interrupt,
see ../../interrupt-controller/interrupts.txt for details.
- interrupt-names: Should be "comp".
Example:
&i2c {
dpot: mcp4651-104@28 {
compatible = "microchip,mcp4651-104";
reg = <0x28>;
#io-channel-cells = <1>;
};
};
dac: dac {
compatible = "dpot-dac";
vref-supply = <&reg_3v3>;
io-channels = <&dpot 0>;
io-channel-names = "dpot";
#io-channel-cells = <1>;
};
envelope-detector {
compatible = "axentia,tse850-envelope-detector";
io-channels = <&dac 0>;
io-channel-names = "dac";
interrupt-parent = <&gpio>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
interrupt-names = "comp";
};

83
dts/Bindings/iio/adc/st,stm32-adc.txt Normal file
View File

@ -0,0 +1,83 @@
STMicroelectronics STM32 ADC device driver
STM32 ADC is a successive approximation analog-to-digital converter.
It has several multiplexed input channels. Conversions can be performed
in single, continuous, scan or discontinuous mode. Result of the ADC is
stored in a left-aligned or right-aligned 32-bit data register.
Conversions can be launched in software or using hardware triggers.
The analog watchdog feature allows the application to detect if the input
voltage goes beyond the user-defined, higher or lower thresholds.
Each STM32 ADC block can have up to 3 ADC instances.
Each instance supports two contexts to manage conversions, each one has its
own configurable sequence and trigger:
- regular conversion can be done in sequence, running in background
- injected conversions have higher priority, and so have the ability to
interrupt regular conversion sequence (either triggered in SW or HW).
Regular sequence is resumed, in case it has been interrupted.
Contents of a stm32 adc root node:
-----------------------------------
Required properties:
- compatible: Should be "st,stm32f4-adc-core".
- reg: Offset and length of the ADC block register set.
- interrupts: Must contain the interrupt for ADC block.
- clocks: Clock for the analog circuitry (common to all ADCs).
- clock-names: Must be "adc".
- interrupt-controller: Identifies the controller node as interrupt-parent
- vref-supply: Phandle to the vref input analog reference voltage.
- #interrupt-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties:
- A pinctrl state named "default" for each ADC channel may be defined to set
inX ADC pins in mode of operation for analog input on external pin.
Contents of a stm32 adc child node:
-----------------------------------
An ADC block node should contain at least one subnode, representing an
ADC instance available on the machine.
Required properties:
- compatible: Should be "st,stm32f4-adc".
- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
- clocks: Input clock private to this ADC instance.
- interrupt-parent: Phandle to the parent interrupt controller.
- interrupts: IRQ Line for the ADC (e.g. may be 0 for adc@0, 1 for adc@100 or
2 for adc@200).
- st,adc-channels: List of single-ended channels muxed for this ADC.
It can have up to 16 channels, numbered from 0 to 15 (resp. for in0..in15).
- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
Documentation/devicetree/bindings/iio/iio-bindings.txt
Example:
adc: adc@40012000 {
compatible = "st,stm32f4-adc-core";
reg = <0x40012000 0x400>;
interrupts = <18>;
clocks = <&rcc 0 168>;
clock-names = "adc";
vref-supply = <&reg_vref>;
interrupt-controller;
pinctrl-names = "default";
pinctrl-0 = <&adc3_in8_pin>;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "st,stm32f4-adc";
#io-channel-cells = <1>;
reg = <0x0>;
clocks = <&rcc 0 168>;
interrupt-parent = <&adc>;
interrupts = <0>;
st,adc-channels = <8>;
};
...
other adc child nodes follow...
};

2
dts/Bindings/iio/adc/ti-adc161s626.txt
View File

@ -3,6 +3,7 @@
Required properties:
- compatible: Should be "ti,adc141s626" or "ti,adc161s626"
- reg: spi chip select number for the device
- vdda-supply: supply voltage to VDDA pin
Recommended properties:
- spi-max-frequency: Definition as per
@ -11,6 +12,7 @@ Recommended properties:
Example:
adc@0 {
compatible = "ti,adc161s626";
vdda-supply = <&vdda_fixed>;
reg = <0>;
spi-max-frequency = <4300000>;
};

41
dts/Bindings/iio/dac/dpot-dac.txt Normal file
View File

@ -0,0 +1,41 @@
Bindings for DAC emulation using a digital potentiometer
It is assumed that the dpot is used as a voltage divider between the
current dpot wiper setting and the maximum resistance of the dpot. The
divided voltage is provided by a vref regulator.
.------.
.-----------. | |
| vref |--' .---.
| regulator |--. | |
'-----------' | | d |
| | p |
| | o | wiper
| | t |<---------+
| | |
| '---' dac output voltage
| |
'------+------------+
Required properties:
- compatible: Should be "dpot-dac"
- vref-supply: The regulator supplying the voltage divider.
- io-channels: Channel node of the dpot to be used for the voltage division.
- io-channel-names: Should be "dpot".
Example:
&i2c {
dpot: mcp4651-503@28 {
compatible = "microchip,mcp4651-503";
reg = <0x28>;
#io-channel-cells = <1>;
};
};
dac {
compatible = "dpot-dac";
vref-supply = <&reg_3v3>;
io-channels = <&dpot 0>;
io-channel-names = "dpot";
};

35
dts/Bindings/iio/dac/mcp4725.txt Normal file
View File

@ -0,0 +1,35 @@
Microchip mcp4725 and mcp4726 DAC device driver
Required properties:
- compatible: Must be "microchip,mcp4725" or "microchip,mcp4726"
- reg: Should contain the DAC I2C address
- vdd-supply: Phandle to the Vdd power supply. This supply is used as a
voltage reference on mcp4725. It is used as a voltage reference on
mcp4726 if there is no vref-supply specified.
Optional properties (valid only for mcp4726):
- vref-supply: Optional phandle to the Vref power supply. Vref pin is
used as a voltage reference when this supply is specified.
- microchip,vref-buffered: Boolean to enable buffering of the external
Vref pin. This boolean is not valid without the vref-supply. Quoting
the datasheet: This is offered in cases where the reference voltage
does not have the current capability not to drop its voltage when
connected to the internal resistor ladder circuit.
Examples:
/* simple mcp4725 */
mcp4725@60 {
compatible = "microchip,mcp4725";
reg = <0x60>;
vdd-supply = <&vdac_vdd>;
};
/* mcp4726 with the buffered external reference voltage */
mcp4726@60 {
compatible = "microchip,mcp4726";
reg = <0x60>;
vdd-supply = <&vdac_vdd>;
vref-supply = <&vdac_vref>;
microchip,vref-buffered;
};

46
dts/Bindings/iio/gyroscope/invensense,mpu3050.txt Normal file
View File

@ -0,0 +1,46 @@
Invensense MPU-3050 Gyroscope device tree bindings
Required properties:
- compatible : should be "invensense,mpu3050"
- reg : the I2C address of the sensor
Optional properties:
- interrupt-parent : should be the phandle for the interrupt controller
- interrupts : interrupt mapping for the trigger interrupt from the
internal oscillator. The following IRQ modes are supported:
IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, IRQ_TYPE_LEVEL_HIGH and
IRQ_TYPE_LEVEL_LOW. The driver should detect and configure the hardware
for the desired interrupt type.
- vdd-supply : supply regulator for the main power voltage.
- vlogic-supply : supply regulator for the signal voltage.
- mount-matrix : see iio/mount-matrix.txt
Optional subnodes:
- The MPU-3050 will pass through and forward the I2C signals from the
incoming I2C bus, alternatively drive traffic to a slave device (usually
an accelerometer) on its own initiative. Therefore is supports a subnode
i2c gate node. For details see: i2c/i2c-gate.txt
Example:
mpu3050@68 {
compatible = "invensense,mpu3050";
reg = <0x68>;
interrupt-parent = <&foo>;
interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
vdd-supply = <&bar>;
vlogic-supply = <&baz>;
/* External I2C interface */
i2c-gate {
#address-cells = <1>;
#size-cells = <0>;
fnord@18 {
compatible = "fnord";
reg = <0x18>;
interrupt-parent = <&foo>;
interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
};
};
};

22
dts/Bindings/iio/humidity/hts221.txt Normal file
View File

@ -0,0 +1,22 @@
* HTS221 STM humidity + temperature sensor
Required properties:
- compatible: should be "st,hts221"
- reg: i2c address of the sensor / spi cs line
Optional properties:
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: interrupt mapping for IRQ. It should be configured with
flags IRQ_TYPE_LEVEL_HIGH or IRQ_TYPE_EDGE_RISING.
Refer to interrupt-controller/interrupts.txt for generic interrupt
client node bindings.
Example:
hts221@5f {
compatible = "st,hts221";
reg = <0x5f>;
interrupt-parent = <&gpio0>;
interrupts = <0 IRQ_TYPE_EDGE_RISING>;
};

28
dts/Bindings/iio/light/isl29018.txt Normal file
View File

@ -0,0 +1,28 @@
* ISL 29018/29023/29035 I2C ALS, Proximity, and Infrared sensor
Required properties:
- compatible: Should be one of
"isil,isl29018"
"isil,isl29023"
"isil,isl29035"
- reg: the I2C address of the device
Optional properties:
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: the sole interrupt generated by the device
Refer to interrupt-controller/interrupts.txt for generic interrupt client
node bindings.
- vcc-supply: phandle to the regulator that provides power to the sensor.
Example:
isl29018@44 {
compatible = "isil,isl29018";
reg = <0x44>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(Z, 2) IRQ_TYPE_LEVEL_HIGH>;
};

26
dts/Bindings/iio/light/tsl2583.txt Normal file
View File

@ -0,0 +1,26 @@
* TAOS TSL 2580/2581/2583 ALS sensor
Required properties:
- compatible: Should be one of
"amstaos,tsl2580"
"amstaos,tsl2581"
"amstaos,tsl2583"
- reg: the I2C address of the device
Optional properties:
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: the sole interrupt generated by the device
Refer to interrupt-controller/interrupts.txt for generic interrupt client
node bindings.
- vcc-supply: phandle to the regulator that provides power to the sensor.
Example:
tsl2581@29 {
compatible = "amstaos,tsl2581";
reg = <0x29>;
};

30
dts/Bindings/iio/potentiostat/lmp91000.txt Normal file
View File

@ -0,0 +1,30 @@
* Texas Instruments LMP91000 potentiostat
http://www.ti.com/lit/ds/symlink/lmp91000.pdf
Required properties:
- compatible: should be "ti,lmp91000"
- reg: the I2C address of the device
- io-channels: the phandle of the iio provider
- ti,external-tia-resistor: if the property ti,tia-gain-ohm is not defined this
needs to be set to signal that an external resistor value is being used.
Optional properties:
- ti,tia-gain-ohm: ohm value of the internal resistor for the transimpedance
amplifier. Must be 2750, 3500, 7000, 14000, 35000, 120000, or 350000 ohms.
- ti,rload-ohm: ohm value of the internal resistor load applied to the gas
sensor. Must be 10, 33, 50, or 100 (default) ohms.
Example:
lmp91000@48 {
compatible = "ti,lmp91000";
reg = <0x48>;
ti,tia-gain-ohm = <7500>;
ti,rload = <100>;
io-channels = <&adc>;
};

1
dts/Bindings/iio/st-sensors.txt
View File

@ -42,6 +42,7 @@ Accelerometers:
- st,lsm303agr-accel
- st,lis2dh12-accel
- st,h3lis331dl-accel
- st,lng2dm-accel
Gyroscopes:
- st,l3g4200d-gyro

47
dts/Bindings/input/da9062-onkey.txt
View File

@ -1,32 +1,47 @@
* Dialog DA9062/63 OnKey Module
* Dialog DA9061/62/63 OnKey Module
This module is part of the DA9062/DA9063. For more details about entire
chips see Documentation/devicetree/bindings/mfd/da9062.txt and
Documentation/devicetree/bindings/mfd/da9063.txt
This module is part of the DA9061/DA9062/DA9063. For more details about entire
DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
This module provides KEY_POWER, KEY_SLEEP and events.
This module provides the KEY_POWER event.
Required properties:
- compatible: should be one of:
dlg,da9062-onkey
dlg,da9063-onkey
- compatible: should be one of the following valid compatible string lines:
"dlg,da9061-onkey", "dlg,da9062-onkey"
"dlg,da9062-onkey"
"dlg,da9063-onkey"
Optional properties:
- dlg,disable-key-power : Disable power-down using a long key-press. If this
- dlg,disable-key-power : Disable power-down using a long key-press. If this
entry exists the OnKey driver will remove support for the KEY_POWER key
press. If this entry does not exist then by default the key-press
triggered power down is enabled and the OnKey will support both KEY_POWER
and KEY_SLEEP.
press when triggered using a long press of the OnKey.
Example:
pmic0: da9062@58 {
Example: DA9063
pmic0: da9063@58 {
onkey {
compatible = "dlg,da9063-onkey";
dlg,disable-key-power;
};
};
Example: DA9062
pmic0: da9062@58 {
onkey {
compatible = "dlg,da9062-onkey";
dlg,disable-key-power;
};
};
Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
pmic0: da9061@58 {
onkey {
compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
dlg,disable-key-power;
};
};

3
dts/Bindings/input/touchscreen/imx6ul_tsc.txt
View File

@ -17,6 +17,8 @@ Optional properties:
This value depends on the touch screen.
- pre-charge-time: the touch screen need some time to precharge.
This value depends on the touch screen.
- touchscreen-average-samples: Number of data samples which are averaged for
each read. Valid values are 1, 4, 8, 16 and 32.
Example:
tsc: tsc@02040000 {
@ -32,5 +34,6 @@ Example:
xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
measure-delay-time = <0xfff>;
pre-charge-time = <0xffff>;
touchscreen-average-samples = <32>;
status = "okay";
};

2
dts/Bindings/input/touchscreen/silead_gsl1680.txt
View File

@ -18,6 +18,8 @@ Optional properties:
- touchscreen-inverted-y : See touchscreen.txt
- touchscreen-swapped-x-y : See touchscreen.txt
- silead,max-fingers : maximum number of fingers the touchscreen can detect
- vddio-supply : regulator phandle for controller VDDIO
- avdd-supply : regulator phandle for controller AVDD
Example:

3
dts/Bindings/input/touchscreen/touchscreen.txt
View File

@ -14,6 +14,9 @@ Optional properties for Touchscreens:
- touchscreen-fuzz-pressure : pressure noise value of the absolute input
device (arbitrary range dependent on the
controller)
- touchscreen-average-samples : Number of data samples which are averaged
for each read (valid values dependent on the
controller)
- touchscreen-inverted-x : X axis is inverted (boolean)
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)

4
dts/Bindings/input/tps65218-pwrbutton.txt
View File

@ -8,8 +8,9 @@ This driver provides a simple power button event via an Interrupt.
Required properties:
- compatible: should be "ti,tps65217-pwrbutton" or "ti,tps65218-pwrbutton"
Required properties for TPS65218:
Required properties:
- interrupts: should be one of the following
- <2>: For controllers compatible with tps65217
- <3 IRQ_TYPE_EDGE_BOTH>: For controllers compatible with tps65218
Examples:
@ -17,6 +18,7 @@ Examples:
&tps {
tps65217-pwrbutton {
compatible = "ti,tps65217-pwrbutton";
interrupts = <2>;
};
};

4
dts/Bindings/ipmi/aspeed,ast2400-bt-bmc.txt → dts/Bindings/ipmi/aspeed,ast2400-ibt-bmc.txt
View File

@ -6,7 +6,7 @@ perform in-band IPMI communication with their host.
Required properties:
- compatible : should be "aspeed,ast2400-bt-bmc"
- compatible : should be "aspeed,ast2400-ibt-bmc"
- reg: physical address and size of the registers
Optional properties:
@ -17,7 +17,7 @@ Optional properties:
Example:
ibt@1e789140 {
compatible = "aspeed,ast2400-bt-bmc";
compatible = "aspeed,ast2400-ibt-bmc";
reg = <0x1e789140 0x18>;
interrupts = <8>;
};

3
dts/Bindings/leds/pca963x.txt
View File

@ -7,6 +7,9 @@ Optional properties:
- nxp,totem-pole : use totem pole (push-pull) instead of open-drain (pca9632 defaults
to open-drain, newer chips to totem pole)
- nxp,hw-blink : use hardware blinking instead of software blinking
- nxp,period-scale : In some configurations, the chip blinks faster than expected.
This parameter provides a scaling ratio (fixed point, decimal divided
by 1000) to compensate, e.g. 1300=1.3x and 750=0.75x.
Each led is represented as a sub-node of the nxp,pca963x device.

2
dts/Bindings/mailbox/brcm,bcm2835-mbox.txt
View File

@ -12,7 +12,7 @@ Required properties:
Example:
mailbox: mailbox@7e00b800 {
mailbox: mailbox@7e00b880 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;

52
dts/Bindings/mailbox/nvidia,tegra186-hsp.txt Normal file
View File

@ -0,0 +1,52 @@
NVIDIA Tegra Hardware Synchronization Primitives (HSP)
The HSP modules are used for the processors to share resources and communicate
together. It provides a set of hardware synchronization primitives for
interprocessor communication. So the interprocessor communication (IPC)
protocols can use hardware synchronization primitives, when operating between
two processors not in an SMP relationship.
The features that HSP supported are shared mailboxes, shared semaphores,
arbitrated semaphores and doorbells.
Required properties:
- name : Should be hsp
- compatible
Array of strings.
one of:
- "nvidia,tegra186-hsp"
- reg : Offset and length of the register set for the device.
- interrupt-names
Array of strings.
Contains a list of names for the interrupts described by the interrupt
property. May contain the following entries, in any order:
- "doorbell"
Users of this binding MUST look up entries in the interrupt property
by name, using this interrupt-names property to do so.
- interrupts
Array of interrupt specifiers.
Must contain one entry per entry in the interrupt-names property,
in a matching order.
- #mbox-cells : Should be 2.
The mbox specifier of the "mboxes" property in the client node should
contain two data. The first one should be the HSP type and the second
one should be the ID that the client is going to use. Those information
can be found in the following file.
- <dt-bindings/mailbox/tegra186-hsp.h>.
Example:
hsp_top0: hsp@3c00000 {
compatible = "nvidia,tegra186-hsp";
reg = <0x0 0x03c00000 0x0 0xa0000>;
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "doorbell";
#mbox-cells = <2>;
};
client {
...
mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_XXX>;
};

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