Evolution-x-devices/kernel_xiaomi_sm8450-devicetrees
2
0
Fork 0
mirror of https://github.com/Evolution-X-Devices/kernel_xiaomi_sm8450-devicetrees synced 2026-01-29 04:24:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

dt-bindings: Add snapshot for 5.4-rc2

Browse Source 
Add the device-tree bindings' snapshot from tmp-abe0ec5a8133 for
5.4-rc2.

Change-Id: I346809db756dd18a509ce440499d98a7fefecd16
This commit is contained in:
Raghavendra Rao Ananta
2019-10-14 19:04:34 -07:00
parent 4cefd27db8
commit e4b1dcc77e
273 changed files with 5574 additions and 3386 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
bindings/arm/actions.txt
View File

@@ -1,56 +0,0 @@
Actions Semi platforms device tree bindings
-------------------------------------------
S500 SoC
========
Required root node properties:
- compatible : must contain "actions,s500"
Modules:
Root node property compatible must contain, depending on module:
- LeMaker Guitar: "lemaker,guitar"
Boards:
Root node property compatible must contain, depending on board:
- Allo.com Sparky: "allo,sparky"
- Cubietech CubieBoard6: "cubietech,cubieboard6"
- LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
S700 SoC
========
Required root node properties:
- compatible : must contain "actions,s700"
Boards:
Root node property compatible must contain, depending on board:
- Cubietech CubieBoard7: "cubietech,cubieboard7"
S900 SoC
========
Required root node properties:
- compatible : must contain "actions,s900"
Boards:
Root node property compatible must contain, depending on board:
- uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96"

28
bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
View File

@@ -1,28 +0,0 @@
Amlogic Meson Firmware registers Interface
------------------------------------------
The Meson SoCs have a register bank with status and data shared with the
secure firmware.
Required properties:
- compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon"
Properties should indentify components of this register interface :
Meson GX SoC Information
------------------------
A firmware register encodes the SoC type, package and revision information on
the Meson GX SoCs.
If present, the following property should be added :
Optional properties:
- amlogic,has-chip-id: If present, the interface gives the current SoC version.
Example
-------
ao-secure@140 {
compatible = "amlogic,meson-gx-ao-secure", "syscon";
reg = <0x0 0x140 0x0 0x140>;
amlogic,has-chip-id;
};

52
bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml Normal file
View File

@@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Amlogic Meson Firmware registers Interface
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
description: |
The Meson SoCs have a register bank with status and data shared with the
secure firmware.
# We need a select here so we don't match all nodes with 'syscon'
select:
properties:
compatible:
contains:
const: amlogic,meson-gx-ao-secure
required:
- compatible
properties:
compatible:
items:
- const: amlogic,meson-gx-ao-secure
- const: syscon
reg:
maxItems: 1
amlogic,has-chip-id:
description: |
A firmware register encodes the SoC type, package and revision
information on the Meson GX SoCs. If present, the interface gives
the current SoC version.
type: boolean
required:
- compatible
- reg
examples:
- |
ao-secure@140 {
compatible = "amlogic,meson-gx-ao-secure", "syscon";
reg = <0x140 0x140>;
amlogic,has-chip-id;
};

42
bindings/arm/marvell/ap806-system-controller.txt
View File

@@ -18,17 +18,19 @@ Clocks:
-------
The Device Tree node representing the AP806 system controller provides
a number of clocks:
The Device Tree node representing the AP806/AP807 system controller
provides a number of clocks:
- 0: clock of CPU cluster 0
- 1: clock of CPU cluster 1
- 0: reference clock of CPU cluster 0
- 1: reference clock of CPU cluster 1
- 2: fixed PLL at 1200 Mhz
- 3: MSS clock, derived from the fixed PLL
Required properties:
- compatible: must be: "marvell,ap806-clock"
- compatible: must be one of:
* "marvell,ap806-clock"
* "marvell,ap807-clock"
- #clock-cells: must be set to 1
Pinctrl:
@@ -143,3 +145,33 @@ ap_syscon1: system-controller@6f8000 {
#thermal-sensor-cells = <1>;
};
};
Cluster clocks:
---------------
Device Tree Clock bindings for cluster clock of Marvell
AP806/AP807. Each cluster contain up to 2 CPUs running at the same
frequency.
Required properties:
- compatible: must be one of:
* "marvell,ap806-cpu-clock"
* "marvell,ap807-cpu-clock"
- #clock-cells : should be set to 1.
- clocks : shall be the input parent clock(s) phandle for the clock
(one per cluster)
- reg: register range associated with the cluster clocks
ap_syscon1: system-controller@6f8000 {
compatible = "marvell,armada-ap806-syscon1", "syscon", "simple-mfd";
reg = <0x6f8000 0x1000>;
cpu_clk: clock-cpu@278 {
compatible = "marvell,ap806-cpu-clock";
clocks = <&ap_clk 0>, <&ap_clk 1>;
#clock-cells = <1>;
reg = <0x278 0xa30>;
};
};

8
bindings/arm/marvell/armada-37xx.txt
View File

@@ -48,3 +48,11 @@ avs: avs@11500 {
compatible = "marvell,armada-3700-avs", "syscon";
reg = <0x11500 0x40>;
}
CZ.NIC's Turris Mox SOHO router Device Tree Bindings
----------------------------------------------------
Required root node property:
- compatible: must contain "cznic,turris-mox"

4
bindings/arm/marvell/cp110-system-controller.txt
View File

@@ -78,8 +78,8 @@ Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
Required properties:
- compatible: "marvell,armada-7k-pinctrl",
"marvell,armada-8k-cpm-pinctrl" or "marvell,armada-8k-cps-pinctrl"
- compatible: "marvell,armada-7k-pinctrl", "marvell,armada-8k-cpm-pinctrl",
"marvell,armada-8k-cps-pinctrl" or "marvell,cp115-standalone-pinctrl"
depending on the specific variant of the SoC being used.
Available mpp pins/groups and functions:

1
bindings/arm/mediatek/mediatek,apmixedsys.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-apmixedsys"
- "mediatek,mt2712-apmixedsys", "syscon"
- "mediatek,mt6779-apmixedsys", "syscon"
- "mediatek,mt6797-apmixedsys"
- "mediatek,mt7622-apmixedsys"
- "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys"

1
bindings/arm/mediatek/mediatek,camsys.txt
View File

@@ -6,6 +6,7 @@ The MediaTek camsys controller provides various clocks to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt6779-camsys", "syscon"
- "mediatek,mt8183-camsys", "syscon"
- #clock-cells: Must be 1

1
bindings/arm/mediatek/mediatek,imgsys.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-imgsys", "syscon"
- "mediatek,mt2712-imgsys", "syscon"
- "mediatek,mt6779-imgsys", "syscon"
- "mediatek,mt6797-imgsys", "syscon"
- "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
- "mediatek,mt8173-imgsys", "syscon"

1
bindings/arm/mediatek/mediatek,infracfg.txt
View File

@@ -9,6 +9,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-infracfg", "syscon"
- "mediatek,mt2712-infracfg", "syscon"
- "mediatek,mt6779-infracfg_ao", "syscon"
- "mediatek,mt6797-infracfg", "syscon"
- "mediatek,mt7622-infracfg", "syscon"
- "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon"

22
bindings/arm/mediatek/mediatek,ipesys.txt Normal file
View File

@@ -0,0 +1,22 @@
Mediatek ipesys controller
============================
The Mediatek ipesys controller provides various clocks to the system.
Required Properties:
- compatible: Should be one of:
- "mediatek,mt6779-ipesys", "syscon"
- #clock-cells: Must be 1
The ipesys controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
Example:
ipesys: clock-controller@1b000000 {
compatible = "mediatek,mt6779-ipesys", "syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
};

1
bindings/arm/mediatek/mediatek,mfgcfg.txt
View File

@@ -7,6 +7,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2712-mfgcfg", "syscon"
- "mediatek,mt6779-mfgcfg", "syscon"
- "mediatek,mt8183-mfgcfg", "syscon"
- #clock-cells: Must be 1

1
bindings/arm/mediatek/mediatek,mmsys.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-mmsys", "syscon"
- "mediatek,mt2712-mmsys", "syscon"
- "mediatek,mt6779-mmsys", "syscon"
- "mediatek,mt6797-mmsys", "syscon"
- "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon"
- "mediatek,mt8173-mmsys", "syscon"

1
bindings/arm/mediatek/mediatek,pericfg.txt
View File

@@ -14,6 +14,7 @@ Required Properties:
- "mediatek,mt7629-pericfg", "syscon"
- "mediatek,mt8135-pericfg", "syscon"
- "mediatek,mt8173-pericfg", "syscon"
- "mediatek,mt8183-pericfg", "syscon"
- #clock-cells: Must be 1
- #reset-cells: Must be 1

1
bindings/arm/mediatek/mediatek,topckgen.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-topckgen"
- "mediatek,mt2712-topckgen", "syscon"
- "mediatek,mt6779-topckgen", "syscon"
- "mediatek,mt6797-topckgen"
- "mediatek,mt7622-topckgen"
- "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen"

1
bindings/arm/mediatek/mediatek,vdecsys.txt
View File

@@ -8,6 +8,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-vdecsys", "syscon"
- "mediatek,mt2712-vdecsys", "syscon"
- "mediatek,mt6779-vdecsys", "syscon"
- "mediatek,mt6797-vdecsys", "syscon"
- "mediatek,mt7623-vdecsys", "mediatek,mt2701-vdecsys", "syscon"
- "mediatek,mt8173-vdecsys", "syscon"

1
bindings/arm/mediatek/mediatek,vencsys.txt
View File

@@ -7,6 +7,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2712-vencsys", "syscon"
- "mediatek,mt6779-vencsys", "syscon"
- "mediatek,mt6797-vencsys", "syscon"
- "mediatek,mt8173-vencsys", "syscon"
- "mediatek,mt8183-vencsys", "syscon"

111
bindings/arm/psci.txt
View File

@@ -1,111 +0,0 @@
* Power State Coordination Interface (PSCI)
Firmware implementing the PSCI functions described in ARM document number
ARM DEN 0022A ("Power State Coordination Interface System Software on ARM
processors") can be used by Linux to initiate various CPU-centric power
operations.
Issue A of the specification describes functions for CPU suspend, hotplug
and migration of secure software.
Functions are invoked by trapping to the privilege level of the PSCI
firmware (specified as part of the binding below) and passing arguments
in a manner similar to that specified by AAPCS:
r0 => 32-bit Function ID / return value
{r1 - r3} => Parameters
Note that the immediate field of the trapping instruction must be set
to #0.
Main node required properties:
- compatible : should contain at least one of:
* "arm,psci" : For implementations complying to PSCI versions prior
to 0.2.
For these cases function IDs must be provided.
* "arm,psci-0.2" : For implementations complying to PSCI 0.2.
Function IDs are not required and should be ignored by
an OS with PSCI 0.2 support, but are permitted to be
present for compatibility with existing software when
"arm,psci" is later in the compatible list.
* "arm,psci-1.0" : For implementations complying to PSCI 1.0.
PSCI 1.0 is backward compatible with PSCI 0.2 with
minor specification updates, as defined in the PSCI
specification[2].
- method : The method of calling the PSCI firmware. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in this binding.
"hvc" : HVC #0, with the register assignments specified
in this binding.
Main node optional properties:
- cpu_suspend : Function ID for CPU_SUSPEND operation
- cpu_off : Function ID for CPU_OFF operation
- cpu_on : Function ID for CPU_ON operation
- migrate : Function ID for MIGRATE operation
Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
state nodes, as per bindings in [1]) must specify the following properties:
- arm,psci-suspend-param
Usage: Required for state nodes[1] if the corresponding
idle-states node entry-method property is set
to "psci".
Value type: <u32>
Definition: power_state parameter to pass to the PSCI
suspend call.
Example:
Case 1: PSCI v0.1 only.
psci {
compatible = "arm,psci";
method = "smc";
cpu_suspend = <0x95c10000>;
cpu_off = <0x95c10001>;
cpu_on = <0x95c10002>;
migrate = <0x95c10003>;
};
Case 2: PSCI v0.2 only
psci {
compatible = "arm,psci-0.2";
method = "smc";
};
Case 3: PSCI v0.2 and PSCI v0.1.
A DTB may provide IDs for use by kernels without PSCI 0.2 support,
enabling firmware and hypervisors to support existing and new kernels.
These IDs will be ignored by kernels with PSCI 0.2 support, which will
use the standard PSCI 0.2 IDs exclusively.
psci {
compatible = "arm,psci-0.2", "arm,psci";
method = "hvc";
cpu_on = < arbitrary value >;
cpu_off = < arbitrary value >;
...
};
[1] Kernel documentation - ARM idle states bindings
Documentation/devicetree/bindings/arm/idle-states.txt
[2] Power State Coordination Interface (PSCI) specification
http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

22
bindings/arm/realtek.txt
View File

@@ -1,22 +0,0 @@
Realtek platforms device tree bindings
--------------------------------------
RTD1295 SoC
===========
Required root node properties:
- compatible : must contain "realtek,rtd1295"
Root node property compatible must contain, depending on board:
- MeLE V9: "mele,v9"
- ProBox2 AVA: "probox2,ava"
- Zidoo X9S: "zidoo,x9s"
Example:
compatible = "zidoo,x9s", "realtek,rtd1295";

2
bindings/ata/ahci-platform.txt
View File

@@ -45,7 +45,7 @@ Required properties when using sub-nodes:
- #address-cells : number of cells to encode an address
- #size-cells : number of cells representing the size of an address
For allwinner,sun8i-r40-ahci, the reset propertie must be present.
For allwinner,sun8i-r40-ahci, the reset property must be present.
Sub-nodes required properties:
- reg : the port number

4
bindings/bus/imx-weim.txt
View File

@@ -44,6 +44,10 @@ Optional properties:
what bootloader sets up in IOMUXC_GPR1[11:0] will be
used.
- fsl,burst-clk-enable For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
devices, the presence of this property indicates that
the weim bus should operate in Burst Clock Mode.
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains timing values for the

46
bindings/bus/moxtet.txt Normal file
View File

@@ -0,0 +1,46 @@
Turris Mox module status and configuration bus (over SPI)
Required properties:
- compatible : Should be "cznic,moxtet"
- #address-cells : Has to be 1
- #size-cells : Has to be 0
- spi-cpol : Required inverted clock polarity
- spi-cpha : Required shifted clock phase
- interrupts : Must contain reference to the shared interrupt line
- interrupt-controller : Required
- #interrupt-cells : Has to be 1
For other required and optional properties of SPI slave nodes please refer to
../spi/spi-bus.txt.
Required properties of subnodes:
- reg : Should be position on the Moxtet bus (how many Moxtet
modules are between this module and CPU module, so
either 0 or a positive integer)
The driver finds the devices connected to the bus by itself, but it may be
needed to reference some of them from other parts of the device tree. In that
case the devices can be defined as subnodes of the moxtet node.
Example:
moxtet@1 {
compatible = "cznic,moxtet";
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
spi-max-frequency = <10000000>;
spi-cpol;
spi-cpha;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&gpiosb>;
interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
moxtet_sfp: gpio@0 {
compatible = "cznic,moxtet-gpio";
gpio-controller;
#gpio-cells = <2>;
reg = <0>;
}
};

2
bindings/bus/qcom,ebi2.txt
View File

@@ -71,7 +71,7 @@ Optional subnodes:
The following optional properties are properties that can be tagged onto
any device subnode. We are assuming that there can be only ONE device per
chipselect subnode, else the properties will become ambigous.
chipselect subnode, else the properties will become ambiguous.
Optional properties arrays for SLOW chip selects:
- qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to

40
bindings/bus/sun50i-de2-bus.txt
View File

@@ -1,40 +0,0 @@
Device tree bindings for Allwinner DE2/3 bus
The Allwinner A64 DE2 is on a special bus, which needs a SRAM region (SRAM C)
to be claimed for enabling the access. The DE3 on Allwinner H6 is at the same
situation, and the binding also applies.
Required properties:
- compatible: Should be one of:
- "allwinner,sun50i-a64-de2"
- "allwinner,sun50i-h6-de3", "allwinner,sun50i-a64-de2"
- reg: A resource specifier for the register space
- #address-cells: Must be set to 1
- #size-cells: Must be set to 1
- ranges: Must be set up to map the address space inside the
DE2, for the sub-blocks of DE2.
- allwinner,sram: the SRAM that needs to be claimed
Example:
de2@1000000 {
compatible = "allwinner,sun50i-a64-de2";
reg = <0x1000000 0x400000>;
allwinner,sram = <&de2_sram 1>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1000000 0x400000>;
display_clocks: clock@0 {
compatible = "allwinner,sun50i-a64-de2-clk";
reg = <0x0 0x100000>;
clocks = <&ccu CLK_DE>,
<&ccu CLK_BUS_DE>;
clock-names = "mod",
"bus";
resets = <&ccu RST_BUS_DE>;
#clock-cells = <1>;
#reset-cells = <1>;
};
};

1
bindings/clock/amlogic,axg-audio-clkc.txt
View File

@@ -22,6 +22,7 @@ Required Properties:
components.
- resets : phandle of the internal reset line
- #clock-cells : should be 1.
- #reset-cells : should be 1 on the g12a (and following) soc family
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

4
bindings/clock/brcm,bcm2835-cprman.txt
View File

@@ -12,7 +12,9 @@ clock generators, but a few (like the ARM or HDMI) will source from
the PLL dividers directly.
Required properties:
- compatible: Should be "brcm,bcm2835-cprman"
- compatible: should be one of the following,
"brcm,bcm2711-cprman"
"brcm,bcm2835-cprman"
- #clock-cells: Should be <1>. The permitted clock-specifier values can be
found in include/dt-bindings/clock/bcm2835.h
- reg: Specifies base physical address and size of the registers

0
bindings/clock/emev2-clock.txt → bindings/clock/renesas,emev2-smu.txt
View File

60
bindings/clock/rockchip,rk3308-cru.txt Normal file
View File

@@ -0,0 +1,60 @@
* Rockchip RK3308 Clock and Reset Unit
The RK3308 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: CRU should be "rockchip,rk3308-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/rk3308-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,
- "xin32k" - rtc clock - optional,
- "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in", "mclk_i2s2_8ch_in",
"mclk_i2s3_8ch_in", "mclk_i2s0_2ch_in",
"mclk_i2s1_2ch_in" - external I2S or SPDIF clock - optional,
- "mac_clkin" - external MAC clock - optional
Example: Clock controller node:
cru: clock-controller@ff500000 {
compatible = "rockchip,rk3308-cru";
reg = <0x0 0xff500000 0x0 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@ff0a0000 {
compatible = "rockchip,rk3308-uart", "snps,dw-apb-uart";
reg = <0x0 0xff0a0000 0x0 0x100>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
clock-names = "baudclk", "apb_pclk";
reg-shift = <2>;
reg-io-width = <4>;
status = "disabled";
};

4
bindings/clock/ti,cdce925.txt
View File

@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- xtal-load-pf: Crystal load-capacitor value to fine-tune performance on a
board, or to compensate for external influences.
- vdd-supply: A regulator node for Vdd
- vddout-supply: A regulator node for Vddout
For all PLL1, PLL2, ... an optional child node can be used to specify spread
spectrum clocking parameters for a board.
@@ -41,6 +43,8 @@ Example:
clocks = <&xtal_27Mhz>;
#clock-cells = <1>;
xtal-load-pf = <5>;
vdd-supply = <&1v8-reg>;
vddout-supply = <&3v3-reg>;
/* PLL options to get SSC 1% centered */
PLL2 {
spread-spectrum = <4>;

14
bindings/connector/usb-connector.txt
View File

@@ -17,6 +17,20 @@ Optional properties:
- self-powered: Set this property if the usb device that has its own power
source.
Optional properties for usb-b-connector:
- id-gpios: an input gpio for USB ID pin.
- vbus-gpios: an input gpio for USB VBUS pin, used to detect presence of
VBUS 5V.
see gpio/gpio.txt.
- vbus-supply: a phandle to the regulator for USB VBUS if needed when host
mode or dual role mode is supported.
Particularly, if use an output GPIO to control a VBUS regulator, should
model it as a regulator.
see regulator/fixed-regulator.yaml
- pinctrl-names : a pinctrl state named "default" is optional
- pinctrl-0 : pin control group
see pinctrl/pinctrl-bindings.txt
Optional properties for usb-c-connector:
- power-role: should be one of "source", "sink" or "dual"(DRP) if typec
connector has power support.

258
bindings/arm/topology.txt → bindings/cpu/cpu-topology.txt
View File

@@ -1,21 +1,19 @@
===========================================
ARM topology binding description
CPU topology binding description
===========================================
===========================================
1 - Introduction
===========================================
In an ARM system, the hierarchy of CPUs is defined through three entities that
In a SMP system, the hierarchy of CPUs is defined through three entities that
are used to describe the layout of physical CPUs in the system:
- socket
- cluster
- core
- thread
The cpu nodes (bindings defined in [1]) represent the devices that
correspond to physical CPUs and are to be mapped to the hierarchy levels.
The bottom hierarchy level sits at core or thread level depending on whether
symmetric multi-threading (SMT) is supported or not.
@@ -24,33 +22,31 @@ threads existing in the system and map to the hierarchy level "thread" above.
In systems where SMT is not supported "cpu" nodes represent all cores present
in the system and map to the hierarchy level "core" above.
ARM topology bindings allow one to associate cpu nodes with hierarchical groups
CPU topology bindings allow one to associate cpu nodes with hierarchical groups
corresponding to the system hierarchy; syntactically they are defined as device
tree nodes.
The remainder of this document provides the topology bindings for ARM, based
on the Devicetree Specification, available from:
Currently, only ARM/RISC-V intend to use this cpu topology binding but it may be
used for any other architecture as well.
https://www.devicetree.org/specifications/
The cpu nodes, as per bindings defined in [4], represent the devices that
correspond to physical CPUs and are to be mapped to the hierarchy levels.
If not stated otherwise, whenever a reference to a cpu node phandle is made its
value must point to a cpu node compliant with the cpu node bindings as
documented in [1].
A topology description containing phandles to cpu nodes that are not compliant
with bindings standardized in [1] is therefore considered invalid.
with bindings standardized in [4] is therefore considered invalid.
===========================================
2 - cpu-map node
===========================================
The ARM CPU topology is defined within the cpu-map node, which is a direct
The ARM/RISC-V CPU topology is defined within the cpu-map node, which is a direct
child of the cpus node and provides a container where the actual topology
nodes are listed.
- cpu-map node
Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
ARM uniprocessor systems do not require a topology
Usage: Optional - On SMP systems provide CPUs topology to the OS.
Uniprocessor systems do not require a topology
description and therefore should not define a
cpu-map node.
@@ -63,21 +59,23 @@ nodes are listed.
The cpu-map node's child nodes can be:
- one or more cluster nodes
- one or more cluster nodes or
- one or more socket nodes in a multi-socket system
Any other configuration is considered invalid.
The cpu-map node can only contain three types of child nodes:
The cpu-map node can only contain 4 types of child nodes:
- socket node
- cluster node
- core node
- thread node
whose bindings are described in paragraph 3.
The nodes describing the CPU topology (cluster/core/thread) can only
be defined within the cpu-map node and every core/thread in the system
must be defined within the topology. Any other configuration is
The nodes describing the CPU topology (socket/cluster/core/thread) can
only be defined within the cpu-map node and every core/thread in the
system must be defined within the topology. Any other configuration is
invalid and therefore must be ignored.
===========================================
@@ -85,26 +83,44 @@ invalid and therefore must be ignored.
===========================================
cpu-map child nodes must follow a naming convention where the node name
must be "clusterN", "coreN", "threadN" depending on the node type (ie
cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
are siblings within a single common parent node must be given a unique and
must be "socketN", "clusterN", "coreN", "threadN" depending on the node type
(ie socket/cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes
which are siblings within a single common parent node must be given a unique and
sequential N value, starting from 0).
cpu-map child nodes which do not share a common parent node can have the same
name (ie same number N as other cpu-map child nodes at different device tree
levels) since name uniqueness will be guaranteed by the device tree hierarchy.
===========================================
3 - cluster/core/thread node bindings
3 - socket/cluster/core/thread node bindings
===========================================
Bindings for cluster/cpu/thread nodes are defined as follows:
Bindings for socket/cluster/cpu/thread nodes are defined as follows:
- socket node
Description: must be declared within a cpu-map node, one node
per physical socket in the system. A system can
contain single or multiple physical socket.
The association of sockets and NUMA nodes is beyond
the scope of this bindings, please refer [2] for
NUMA bindings.
This node is optional for a single socket system.
The socket node name must be "socketN" as described in 2.1 above.
A socket node can not be a leaf node.
A socket node's child nodes must be one or more cluster nodes.
Any other configuration is considered invalid.
- cluster node
Description: must be declared within a cpu-map node, one node
per cluster. A system can contain several layers of
clustering and cluster nodes can be contained in parent
cluster nodes.
clustering within a single physical socket and cluster
nodes can be contained in parent cluster nodes.
The cluster node name must be "clusterN" as described in 2.1 above.
A cluster node can not be a leaf node.
@@ -164,90 +180,93 @@ Bindings for cluster/cpu/thread nodes are defined as follows:
4 - Example dts
===========================================
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters in a single
physical socket):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu-map {
cluster0 {
socket0 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU0>;
cluster0 {
core0 {
thread0 {
cpu = <&CPU0>;
};
thread1 {
cpu = <&CPU1>;
};
};
thread1 {
cpu = <&CPU1>;
core1 {
thread0 {
cpu = <&CPU2>;
};
thread1 {
cpu = <&CPU3>;
};
};
};
core1 {
thread0 {
cpu = <&CPU2>;
cluster1 {
core0 {
thread0 {
cpu = <&CPU4>;
};
thread1 {
cpu = <&CPU5>;
};
};
thread1 {
cpu = <&CPU3>;
core1 {
thread0 {
cpu = <&CPU6>;
};
thread1 {
cpu = <&CPU7>;
};
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU4>;
cluster0 {
core0 {
thread0 {
cpu = <&CPU8>;
};
thread1 {
cpu = <&CPU9>;
};
};
thread1 {
cpu = <&CPU5>;
core1 {
thread0 {
cpu = <&CPU10>;
};
thread1 {
cpu = <&CPU11>;
};
};
};
core1 {
thread0 {
cpu = <&CPU6>;
cluster1 {
core0 {
thread0 {
cpu = <&CPU12>;
};
thread1 {
cpu = <&CPU13>;
};
};
thread1 {
cpu = <&CPU7>;
};
};
};
};
cluster1 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU8>;
};
thread1 {
cpu = <&CPU9>;
};
};
core1 {
thread0 {
cpu = <&CPU10>;
};
thread1 {
cpu = <&CPU11>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU12>;
};
thread1 {
cpu = <&CPU13>;
};
};
core1 {
thread0 {
cpu = <&CPU14>;
};
thread1 {
cpu = <&CPU15>;
core1 {
thread0 {
cpu = <&CPU14>;
};
thread1 {
cpu = <&CPU15>;
};
};
};
};
@@ -470,6 +489,65 @@ cpus {
};
};
Example 3: HiFive Unleashed (RISC-V 64 bit, 4 core system)
{
#address-cells = <2>;
#size-cells = <2>;
compatible = "sifive,fu540g", "sifive,fu500";
model = "sifive,hifive-unleashed-a00";
...
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu-map {
socket0 {
cluster0 {
core0 {
cpu = <&CPU1>;
};
core1 {
cpu = <&CPU2>;
};
core2 {
cpu0 = <&CPU2>;
};
core3 {
cpu0 = <&CPU3>;
};
};
};
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x1>;
}
CPU2: cpu@2 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x2>;
}
CPU3: cpu@3 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x3>;
}
CPU4: cpu@4 {
device_type = "cpu";
compatible = "sifive,rocket0", "riscv";
reg = <0x4>;
}
}
};
===============================================================================
[1] ARM Linux kernel documentation
Documentation/devicetree/bindings/arm/cpus.yaml
[2] Devicetree NUMA binding description
Documentation/devicetree/bindings/numa.txt
[3] RISC-V Linux kernel documentation
Documentation/devicetree/bindings/riscv/cpus.txt
[4] https://www.devicetree.org/specifications/

23
bindings/crypto/sun4i-ss.txt
View File

@@ -1,23 +0,0 @@
* Allwinner Security System found on A20 SoC
Required properties:
- compatible : Should be "allwinner,sun4i-a10-crypto".
- reg: Should contain the Security System register location and length.
- interrupts: Should contain the IRQ line for the Security System.
- clocks : List of clock specifiers, corresponding to ahb and ss.
- clock-names : Name of the functional clock, should be
* "ahb" : AHB gating clock
* "mod" : SS controller clock
Optional properties:
- resets : phandle + reset specifier pair
- reset-names : must contain "ahb"
Example:
crypto: crypto-engine@1c15000 {
compatible = "allwinner,sun4i-a10-crypto";
reg = <0x01c15000 0x1000>;
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ahb_gates 5>, <&ss_clk>;
clock-names = "ahb", "mod";
};

119
bindings/display/amlogic,meson-dw-hdmi.txt
View File

@@ -1,119 +0,0 @@
Amlogic specific extensions to the Synopsys Designware HDMI Controller
======================================================================
The Amlogic Meson Synopsys Designware Integration is composed of :
- A Synopsys DesignWare HDMI Controller IP
- A TOP control block controlling the Clocks and PHY
- A custom HDMI PHY in order to convert video to TMDS signal
___________________________________
| HDMI TOP |<= HPD
|___________________________________|
| | |
| Synopsys HDMI | HDMI PHY |=> TMDS
| Controller |________________|
|___________________________________|<=> DDC
The HDMI TOP block only supports HPD sensing.
The Synopsys HDMI Controller interrupt is routed through the
TOP Block interrupt.
Communication to the TOP Block and the Synopsys HDMI Controller is done
via a pair of dedicated addr+read/write registers.
The HDMI PHY is configured by registers in the HHI register block.
Pixel data arrives in 4:4:4 format from the VENC block and the VPU HDMI mux
selects either the ENCI encoder for the 576i or 480i formats or the ENCP
encoder for all the other formats including interlaced HD formats.
The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
DVI timings for the HDMI controller.
Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
audio source interfaces.
Required properties:
- compatible: value should be different for each SoC family as :
- GXBB (S905) : "amlogic,meson-gxbb-dw-hdmi"
- GXL (S905X, S905D) : "amlogic,meson-gxl-dw-hdmi"
- GXM (S912) : "amlogic,meson-gxm-dw-hdmi"
followed by the common "amlogic,meson-gx-dw-hdmi"
- G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-dw-hdmi"
- reg: Physical base address and length of the controller's registers.
- interrupts: The HDMI interrupt number
- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks,
and the Amlogic Meson venci clocks as described in
Documentation/devicetree/bindings/clock/clock-bindings.txt,
the clocks are soc specific, the clock-names should be "iahb", "isfr", "venci"
- resets, resets-names: must have the phandles to the HDMI apb, glue and phy
resets as described in :
Documentation/devicetree/bindings/reset/reset.txt,
the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
Optional properties:
- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI
logic, as described in the file ../regulator/regulator.txt
Required nodes:
The connections to the HDMI 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 HDMI output and input.
Port 0 Port 1
-----------------------------------------
S905 (GXBB) VENC Input TMDS Output
S905X (GXL) VENC Input TMDS Output
S905D (GXL) VENC Input TMDS Output
S912 (GXM) VENC Input TMDS Output
S905X2 (G12A) VENC Input TMDS Output
S905Y2 (G12A) VENC Input TMDS Output
S905D2 (G12A) VENC Input TMDS Output
Example:
hdmi-connector {
compatible = "hdmi-connector";
type = "a";
port {
hdmi_connector_in: endpoint {
remote-endpoint = <&hdmi_tx_tmds_out>;
};
};
};
hdmi_tx: hdmi-tx@c883a000 {
compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
reg = <0x0 0xc883a000 0x0 0x1c>;
interrupts = <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
resets = <&reset RESET_HDMITX_CAPB3>,
<&reset RESET_HDMI_SYSTEM_RESET>,
<&reset RESET_HDMI_TX>;
reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
clocks = <&clkc CLKID_HDMI_PCLK>,
<&clkc CLKID_CLK81>,
<&clkc CLKID_GCLK_VENCI_INT0>;
clock-names = "isfr", "iahb", "venci";
#address-cells = <1>;
#size-cells = <0>;
/* VPU VENC Input */
hdmi_tx_venc_port: port@0 {
reg = <0>;
hdmi_tx_in: endpoint {
remote-endpoint = <&hdmi_tx_out>;
};
};
/* TMDS Output */
hdmi_tx_tmds_port: port@1 {
reg = <1>;
hdmi_tx_tmds_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
};

150
bindings/display/amlogic,meson-dw-hdmi.yaml Normal file
View File

@@ -0,0 +1,150 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
description: |
The Amlogic Meson Synopsys Designware Integration is composed of
- A Synopsys DesignWare HDMI Controller IP
- A TOP control block controlling the Clocks and PHY
- A custom HDMI PHY in order to convert video to TMDS signal
___________________________________
| HDMI TOP |<= HPD
|___________________________________|
| | |
| Synopsys HDMI | HDMI PHY |=> TMDS
| Controller |________________|
|___________________________________|<=> DDC
The HDMI TOP block only supports HPD sensing.
The Synopsys HDMI Controller interrupt is routed through the
TOP Block interrupt.
Communication to the TOP Block and the Synopsys HDMI Controller is done
via a pair of dedicated addr+read/write registers.
The HDMI PHY is configured by registers in the HHI register block.
Pixel data arrives in "4:4:4" format from the VENC block and the VPU HDMI mux
selects either the ENCI encoder for the 576i or 480i formats or the ENCP
encoder for all the other formats including interlaced HD formats.
The VENC uses a DVI encoder on top of the ENCI or ENCP encoders to generate
DVI timings for the HDMI controller.
Amlogic Meson GXBB, GXL and GXM SoCs families embeds the Synopsys DesignWare
HDMI TX IP version 2.01a with HDCP and I2C & S/PDIF
audio source interfaces.
properties:
compatible:
oneOf:
- items:
- enum:
- amlogic,meson-gxbb-dw-hdmi # GXBB (S905)
- amlogic,meson-gxl-dw-hdmi # GXL (S905X, S905D)
- amlogic,meson-gxm-dw-hdmi # GXM (S912)
- const: amlogic,meson-gx-dw-hdmi
- enum:
- amlogic,meson-g12a-dw-hdmi # G12A (S905X2, S905Y2, S905D2)
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 3
clock-names:
items:
- const: isfr
- const: iahb
- const: venci
resets:
minItems: 3
reset-names:
items:
- const: hdmitx_apb
- const: hdmitx
- const: hdmitx_phy
hdmi-supply:
description: phandle to an external 5V regulator to power the HDMI logic
allOf:
- $ref: /schemas/types.yaml#/definitions/phandle
port@0:
type: object
description:
A port node pointing to the VENC Input port node.
port@1:
type: object
description:
A port node pointing to the TMDS Output port node.
"#address-cells":
const: 1
"#size-cells":
const: 0
"#sound-dai-cells":
const: 0
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- resets
- reset-names
- port@0
- port@1
- "#address-cells"
- "#size-cells"
additionalProperties: false
examples:
- |
hdmi_tx: hdmi-tx@c883a000 {
compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
reg = <0xc883a000 0x1c>;
interrupts = <57>;
resets = <&reset_apb>, <&reset_hdmitx>, <&reset_hdmitx_phy>;
reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
clocks = <&clk_isfr>, <&clk_iahb>, <&clk_venci>;
clock-names = "isfr", "iahb", "venci";
#address-cells = <1>;
#size-cells = <0>;
/* VPU VENC Input */
hdmi_tx_venc_port: port@0 {
reg = <0>;
hdmi_tx_in: endpoint {
remote-endpoint = <&hdmi_tx_out>;
};
};
/* TMDS Output */
hdmi_tx_tmds_port: port@1 {
reg = <1>;
hdmi_tx_tmds_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
};

121
bindings/display/amlogic,meson-vpu.txt
View File

@@ -1,121 +0,0 @@
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"
- G12A (S905X2, S905Y2, S905D2) : "amlogic,meson-g12a-vpu"
- reg: base address and size of he following memory-mapped regions :
- vpu
- hhi
- reg-names: should contain the names of the previous memory regions
- interrupts: should contain the VENC Vsync interrupt number
- amlogic,canvas: phandle to canvas provider node as described in the file
../soc/amlogic/amlogic,canvas.txt
Optional properties:
- power-domains: Optional phandle to associated power domain as described in
the file ../power/power_domain.txt
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
S905X2 (G12A) CVBS VDAC HDMI-TX
S905Y2 (G12A) CVBS VDAC HDMI-TX
S905D2 (G12A) 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>;
};
};
};

137
bindings/display/amlogic,meson-vpu.yaml Normal file
View File

@@ -0,0 +1,137 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Amlogic Meson Display Controller
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
description: |
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.
properties:
compatible:
oneOf:
- items:
- enum:
- amlogic,meson-gxbb-vpu # GXBB (S905)
- amlogic,meson-gxl-vpu # GXL (S905X, S905D)
- amlogic,meson-gxm-vpu # GXM (S912)
- const: amlogic,meson-gx-vpu
- enum:
- amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2)
reg:
maxItems: 2
reg-names:
items:
- const: vpu
- const: hhi
interrupts:
maxItems: 1
power-domains:
maxItems: 1
description: phandle to the associated power domain
port@0:
type: object
description:
A port node pointing to the CVBS VDAC port node.
port@1:
type: object
description:
A port node pointing to the HDMI-TX port node.
"#address-cells":
const: 1
"#size-cells":
const: 0
required:
- compatible
- reg
- interrupts
- port@0
- port@1
- "#address-cells"
- "#size-cells"
examples:
- |
vpu: vpu@d0100000 {
compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
reg = <0xd0100000 0x100000>, <0xc883c000 0x1000>;
reg-names = "vpu", "hhi";
interrupts = <3>;
#address-cells = <1>;
#size-cells = <0>;
/* CVBS VDAC output port */
port@0 {
reg = <0>;
cvbs_vdac_out: endpoint {
remote-endpoint = <&tv_connector_in>;
};
};
/* HDMI TX output port */
port@1 {
reg = <1>;
hdmi_tx_out: endpoint {
remote-endpoint = <&hdmi_tx_in>;
};
};
};

9
bindings/display/arm,pl11x.txt
View File

@@ -39,9 +39,11 @@ Required sub-nodes:
- port: describes LCD panel signals, following the common binding
for video transmitter interfaces; see
Documentation/devicetree/bindings/media/video-interfaces.txt;
when it is a TFT panel, the port's endpoint must define the
following property:
Documentation/devicetree/bindings/media/video-interfaces.txt
Deprecated properties:
The port's endbpoint subnode had this, now deprecated property
in the past. Drivers should be able to survive without it:
- arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values,
defining the way CLD pads are wired up; first value
@@ -80,7 +82,6 @@ Example:
port {
clcd_pads: endpoint {
remote-endpoint = <&clcd_panel>;
arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
};
};

1
bindings/display/connector/hdmi-connector.txt
View File

@@ -9,6 +9,7 @@ Optional properties:
- label: a symbolic name for the connector
- hpd-gpios: HPD GPIO number
- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
- ddc-en-gpios: signal to enable DDC bus
Required nodes:
- Video port for HDMI input

26
bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
View File

@@ -1,26 +0,0 @@
Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.
Required properties:
- compatible: should be "ampire,am-480272h3tmqw-t01h"
Optional properties:
- power-supply: regulator to provide the supply voltage
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
Optional nodes:
- Video port for RGB input.
Example:
panel_rgb: panel-rgb {
compatible = "ampire,am-480272h3tmqw-t01h";
enable-gpios = <&gpioa 8 1>;
port {
panel_in_rgb: endpoint {
remote-endpoint = <&controller_out_rgb>;
};
};
};

2
bindings/display/panel/arm,versatile-tft-panel.txt
View File

@@ -10,7 +10,7 @@ Required properties:
- compatible: should be "arm,versatile-tft-panel"
Required subnodes:
- port: see display/panel/panel-common.txt, graph.txt
- port: see display/panel/panel-common.yaml, graph.txt
Example:

9
bindings/display/panel/armadeus,st0700-adapt.txt
View File

@@ -1,9 +0,0 @@
Armadeus ST0700 Adapt. A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with
an adapter board.
Required properties:
- compatible: "armadeus,st0700-adapt"
- power-supply: see panel-common.txt
Optional properties:
- backlight: see panel-common.txt

12
bindings/display/panel/bananapi,s070wv20-ct16.txt
View File

@@ -1,12 +0,0 @@
Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
Required properties:
- compatible: should be "bananapi,s070wv20-ct16"
- power-supply: see ./panel-common.txt
Optional properties:
- enable-gpios: see ./simple-panel.txt
- backlight: see ./simple-panel.txt
This binding is compatible with the simple-panel binding, which is specified
in ./simple-panel.txt.

24
bindings/display/panel/boe,himax8279d.txt Normal file
View File

@@ -0,0 +1,24 @@
Boe Himax8279d 1200x1920 TFT LCD panel
Required properties:
- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
- reg: DSI virtual channel of the peripheral
- enable-gpios: panel enable gpio
- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage
- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage
Optional properties:
- backlight: phandle of the backlight device attached to the panel
Example:
&mipi_dsi {
panel {
compatible = "boe,himax8279d8p", "boe,himax8279d10p";
reg = <0>;
backlight = <&backlight>;
enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>;
};
};

13
bindings/display/panel/dlc,dlc0700yzg-1.txt
View File

@@ -1,13 +0,0 @@
DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
Required properties:
- compatible: should be "dlc,dlc0700yzg-1"
- power-supply: See simple-panel.txt
Optional properties:
- reset-gpios: See panel-common.txt
- enable-gpios: See simple-panel.txt
- backlight: See simple-panel.txt
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

12
bindings/display/panel/giantplus,gpm940b0.txt Normal file
View File

@@ -0,0 +1,12 @@
GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel
Required properties:
- compatible: should be "giantplus,gpm940b0"
- power-supply: as specified in the base binding
Optional properties:
- backlight: as specified in the base binding
- enable-gpios: as specified in the base binding
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
bindings/display/panel/innolux,ee101ia-01d.txt
View File

@@ -1,7 +0,0 @@
Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
Required properties:
- compatible: should be "innolux,ee101ia-01d"
This binding is compatible with the lvds-panel binding, which is specified
in panel-lvds.txt in this directory.

42
bindings/display/panel/kingdisplay,kd035g6-54nt.txt Normal file
View File

@@ -0,0 +1,42 @@
King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel
Required properties:
- compatible: should be "kingdisplay,kd035g6-54nt"
- power-supply: See panel-common.txt
- reset-gpios: See panel-common.txt
Optional properties:
- backlight: see panel-common.txt
The generic bindings for the SPI slaves documented in [1] also apply.
The device node can contain one 'port' child node with one child
'endpoint' node, according to the bindings defined in [2]. This
node should describe panel's video bus.
[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
[2]: Documentation/devicetree/bindings/graph.txt
Example:
&spi {
panel@0 {
compatible = "kingdisplay,kd035g6-54nt";
reg = <0>;
spi-max-frequency = <3125000>;
spi-3wire;
spi-cs-high;
reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
backlight = <&backlight>;
power-supply = <&ldo6>;
port {
panel_input: endpoint {
remote-endpoint = <&panel_output>;
};
};
};
};

47
bindings/display/panel/mitsubishi,aa104xd12.txt
View File

@@ -1,47 +0,0 @@
Mitsubishi AA204XD12 LVDS Display Panel
=======================================
The AA104XD12 is a 10.4" XGA TFT-LCD display panel.
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
with the following device-specific properties.
Required properties:
- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
order.
- vcc-supply: Reference to the regulator powering the panel VCC pins.
Example
-------
panel {
compatible = "mitsubishi,aa104xd12", "panel-lvds";
vcc-supply = <&vcc_3v3>;
width-mm = <210>;
height-mm = <158>;
data-mapping = "jeida-24";
panel-timing {
/* 1024x768 @65Hz */
clock-frequency = <65000000>;
hactive = <1024>;
vactive = <768>;
hsync-len = <136>;
hfront-porch = <20>;
hback-porch = <160>;
vfront-porch = <3>;
vback-porch = <29>;
vsync-len = <6>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};

47
bindings/display/panel/mitsubishi,aa121td01.txt
View File

@@ -1,47 +0,0 @@
Mitsubishi AA121TD01 LVDS Display Panel
=======================================
The AA121TD01 is a 12.1" WXGA TFT-LCD display panel.
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
with the following device-specific properties.
Required properties:
- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
order.
- vcc-supply: Reference to the regulator powering the panel VCC pins.
Example
-------
panel {
compatible = "mitsubishi,aa121td01", "panel-lvds";
vcc-supply = <&vcc_3v3>;
width-mm = <261>;
height-mm = <163>;
data-mapping = "jeida-24";
panel-timing {
/* 1280x800 @60Hz */
clock-frequency = <71000000>;
hactive = <1280>;
vactive = <800>;
hsync-len = <70>;
hfront-porch = <20>;
hback-porch = <70>;
vsync-len = <5>;
vfront-porch = <3>;
vback-porch = <15>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};

12
bindings/display/panel/ortustech,com37h3m05dtc.txt Normal file
View File

@@ -0,0 +1,12 @@
OrtusTech COM37H3M05DTC Blanview 3.7" VGA portrait TFT-LCD panel
Required properties:
- compatible: should be "ortustech,com37h3m05dtc"
Optional properties:
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
- power-supply: phandle of the regulator that provides the supply voltage
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

12
bindings/display/panel/ortustech,com37h3m99dtc.txt Normal file
View File

@@ -0,0 +1,12 @@
OrtusTech COM37H3M99DTC Blanview 3.7" VGA portrait TFT-LCD panel
Required properties:
- compatible: should be "ortustech,com37h3m99dtc"
Optional properties:
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
- power-supply: phandle of the regulator that provides the supply voltage
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

101
bindings/display/panel/panel-common.txt
View File

@@ -1,101 +0,0 @@
Common Properties for Display Panel
===================================
This document defines device tree properties common to several classes of
display panels. It doesn't constitue a device tree binding specification by
itself but is meant to be referenced by device tree bindings.
When referenced from panel device tree bindings the properties defined in this
document are defined as follows. The panel device tree bindings are
responsible for defining whether each property is required or optional.
Descriptive Properties
----------------------
- width-mm,
- height-mm: The width-mm and height-mm specify the width and height of the
physical area where images are displayed. These properties are expressed in
millimeters and rounded to the closest unit.
- label: The label property specifies a symbolic name for the panel as a
string suitable for use by humans. It typically contains a name inscribed on
the system (e.g. as an affixed label) or specified in the system's
documentation (e.g. in the user's manual).
If no such name exists, and unless the property is mandatory according to
device tree bindings, it shall rather be omitted than constructed of
non-descriptive information. For instance an LCD panel in a system that
contains a single panel shall not be labelled "LCD" if that name is not
inscribed on the system or used in a descriptive fashion in system
documentation.
Display Timings
---------------
- panel-timing: Most display panels are restricted to a single resolution and
require specific display timings. The panel-timing subnode expresses those
timings as specified in the timing subnode section of the display timing
bindings defined in
Documentation/devicetree/bindings/display/panel/display-timing.txt.
Connectivity
------------
- ports: Panels receive video data through one or multiple connections. While
the nature of those connections is specific to the panel type, the
connectivity is expressed in a standard fashion using ports as specified in
the device graph bindings defined in
Documentation/devicetree/bindings/graph.txt.
- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible
bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
phandle to the system I2C controller connected to that bus.
Control I/Os
------------
Many display panels can be controlled through pins driven by GPIOs. The nature
and timing of those control signals are device-specific and left for panel
device tree bindings to specify. The following GPIO specifiers can however be
used for panels that implement compatible control signals.
- enable-gpios: Specifier for a GPIO connected to the panel enable control
signal. The enable signal is active high and enables operation of the panel.
This property can also be used for panels implementing an active low power
down signal, which is a negated version of the enable signal. Active low
enable signals (or active high power down signals) can be supported by
inverting the GPIO specifier polarity flag.
Note that the enable signal control panel operation only and must not be
confused with a backlight enable signal.
- reset-gpios: Specifier for a GPIO coonnected to the panel reset control
signal. The reset signal is active low and resets the panel internal logic
while active. Active high reset signals can be supported by inverting the
GPIO specifier polarity flag.
Power
-----
- power-supply: display panels require power to be supplied. While several
panels need more than one power supply with panel-specific constraints
governing the order and timings of the power supplies, in many cases a single
power supply is sufficient, either because the panel has a single power rail,
or because all its power rails can be driven by the same supply. In that case
the power-supply property specifies the supply powering the panel as a phandle
to a regulator.
Backlight
---------
Most display panels include a backlight. Some of them also include a backlight
controller exposed through a control bus such as I2C or DSI. Others expose
backlight control through GPIO, PWM or other signals connected to an external
backlight controller.
- backlight: For panels whose backlight is controlled by an external backlight
controller, this property contains a phandle that references the controller.

121
bindings/display/panel/panel-lvds.txt
View File

@@ -1,121 +0,0 @@
LVDS Display Panel
==================
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
incompatible data link layers have been used over time to transmit image data
to LVDS panels. This bindings supports display panels compatible with the
following specifications.
[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
Semiconductor
[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
Electronics Standards Association (VESA)
Device compatible with those specifications have been marketed under the
FPD-Link and FlatLink brands.
Required properties:
- compatible: Shall contain "panel-lvds" in addition to a mandatory
panel-specific compatible string defined in individual panel bindings. The
"panel-lvds" value shall never be used on its own.
- width-mm: See panel-common.txt.
- height-mm: See panel-common.txt.
- data-mapping: The color signals mapping order, "jeida-18", "jeida-24"
or "vesa-24".
Optional properties:
- label: See panel-common.txt.
- gpios: See panel-common.txt.
- backlight: See panel-common.txt.
- power-supply: See panel-common.txt.
- data-mirror: If set, reverse the bit order described in the data mappings
below on all data lanes, transmitting bits for slots 6 to 0 instead of
0 to 6.
Required nodes:
- panel-timing: See panel-common.txt.
- ports: See panel-common.txt. These bindings require a single port subnode
corresponding to the panel LVDS input.
LVDS data mappings are defined as follows.
- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
[VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
specifications. Data are transferred as follows on 4 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
Data are transferred as follows on 4 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
Control signals are mapped as follows.
CTL0: HSync
CTL1: VSync
CTL2: Data Enable
CTL3: 0
Example
-------
panel {
compatible = "mitsubishi,aa121td01", "panel-lvds";
width-mm = <261>;
height-mm = <163>;
data-mapping = "jeida-24";
panel-timing {
/* 1280x800 @60Hz */
clock-frequency = <71000000>;
hactive = <1280>;
vactive = <800>;
hsync-len = <70>;
hfront-porch = <20>;
hback-porch = <70>;
vsync-len = <5>;
vfront-porch = <3>;
vback-porch = <15>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};

4
bindings/display/panel/panel.txt
View File

@@ -1,4 +0,0 @@
Common display properties
-------------------------
- rotation: Display rotation in degrees counter clockwise (0,90,180,270)

14
bindings/display/panel/pda,91-00156-a0.txt
View File

@@ -1,14 +0,0 @@
PDA 91-00156-A0 5.0" WVGA TFT LCD panel
Required properties:
- compatible: should be "pda,91-00156-a0"
- power-supply: this panel requires a single power supply. A phandle to a
regulator needs to be specified here. Compatible with panel-common binding which
is specified in the panel-common.txt in this directory.
- backlight: this panel's backlight is controlled by an external backlight
controller. A phandle to this controller needs to be specified here.
Compatible with panel-common binding which is specified in the panel-common.txt
in this directory.
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

49
bindings/display/panel/raspberrypi,7inch-touchscreen.txt
View File

@@ -1,49 +0,0 @@
This binding covers the official 7" (800x480) Raspberry Pi touchscreen
panel.
This DSI panel contains:
- TC358762 DSI->DPI bridge
- Atmel microcontroller on I2C for power sequencing the DSI bridge and
controlling backlight
- Touchscreen controller on I2C for touch input
and this binding covers the DSI display parts but not its touch input.
Required properties:
- compatible: Must be "raspberrypi,7inch-touchscreen-panel"
- reg: Must be "45"
- port: See panel-common.txt
Example:
dsi1: dsi@7e700000 {
#address-cells = <1>;
#size-cells = <0>;
<...>
port {
dsi_out_port: endpoint {
remote-endpoint = <&panel_dsi_port>;
};
};
};
i2c_dsi: i2c {
compatible = "i2c-gpio";
#address-cells = <1>;
#size-cells = <0>;
gpios = <&gpio 28 0
&gpio 29 0>;
lcd@45 {
compatible = "raspberrypi,7inch-touchscreen-panel";
reg = <0x45>;
port {
panel_dsi_port: endpoint {
remote-endpoint = <&dsi_out_port>;
};
};
};
};

41
bindings/display/panel/raydium,rm67191.txt Normal file
View File

@@ -0,0 +1,41 @@
Raydium RM67171 OLED LCD panel with MIPI-DSI protocol
Required properties:
- compatible: "raydium,rm67191"
- reg: virtual channel for MIPI-DSI protocol
must be <0>
- dsi-lanes: number of DSI lanes to be used
must be <3> or <4>
- port: input port node with endpoint definition as
defined in Documentation/devicetree/bindings/graph.txt;
the input port should be connected to a MIPI-DSI device
driver
Optional properties:
- reset-gpios: a GPIO spec for the RST_B GPIO pin
- v3p3-supply: phandle to 3.3V regulator that powers the VDD_3V3 pin
- v1p8-supply: phandle to 1.8V regulator that powers the VDD_1V8 pin
- width-mm: see panel-common.txt
- height-mm: see panel-common.txt
- video-mode: 0 - burst-mode
1 - non-burst with sync event
2 - non-burst with sync pulse
Example:
panel@0 {
compatible = "raydium,rm67191";
reg = <0>;
pinctrl-0 = <&pinctrl_mipi_dsi_0_1_en>;
pinctrl-names = "default";
reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
dsi-lanes = <4>;
width-mm = <68>;
height-mm = <121>;
port {
panel_in: endpoint {
remote-endpoint = <&mipi_out>;
};
};
};

5
bindings/display/panel/rocktech,jh057n00900.txt
View File

@@ -5,6 +5,9 @@ Required properties:
- reg: DSI virtual channel of the peripheral
- reset-gpios: panel reset gpio
- backlight: phandle of the backlight device attached to the panel
- vcc-supply: phandle of the regulator that provides the vcc supply voltage.
- iovcc-supply: phandle of the regulator that provides the iovcc supply
voltage.
Example:
@@ -14,5 +17,7 @@ Example:
reg = <0>;
backlight = <&backlight>;
reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
vcc-supply = <&reg_2v8_p>;
iovcc-supply = <&reg_1v8_p>;
};
};

41
bindings/display/panel/sgd,gktw70sdae4se.txt
View File

@@ -1,41 +0,0 @@
Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel
==========================================================
The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel.
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
with the following device-specific properties.
Required properties:
- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that order.
Example
-------
panel {
compatible = "sgd,gktw70sdae4se", "panel-lvds";
width-mm = <153>;
height-mm = <86>;
data-mapping = "jeida-18";
panel-timing {
clock-frequency = <32000000>;
hactive = <800>;
vactive = <480>;
hback-porch = <39>;
hfront-porch = <39>;
vback-porch = <29>;
vfront-porch = <13>;
hsync-len = <47>;
vsync-len = <2>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};

26
bindings/display/panel/sharp,ld-d5116z01b.txt Normal file
View File

@@ -0,0 +1,26 @@
Sharp LD-D5116Z01B 12.3" WUXGA+ eDP panel
Required properties:
- compatible: should be "sharp,ld-d5116z01b"
- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
This binding is compatible with the simple-panel binding.
The device node can contain one 'port' child node with one child
'endpoint' node, according to the bindings defined in [1]. This
node should describe panel's video bus.
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
panel: panel {
compatible = "sharp,ld-d5116z01b";
power-supply = <&vlcd_3v3>;
port {
panel_ep: endpoint {
remote-endpoint = <&bridge_out_ep>;
};
};
};

12
bindings/display/panel/sharp,lq070y3dg3b.txt Normal file
View File

@@ -0,0 +1,12 @@
Sharp LQ070Y3DG3B 7.0" WVGA landscape TFT LCD panel
Required properties:
- compatible: should be "sharp,lq070y3dg3b"
Optional properties:
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
- power-supply: phandle of the regulator that provides the supply voltage
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

12
bindings/display/panel/sharp,ls020b1dd01d.txt Normal file
View File

@@ -0,0 +1,12 @@
Sharp 2.0" (240x160 pixels) 16-bit TFT LCD panel
Required properties:
- compatible: should be "sharp,ls020b1dd01d"
- power-supply: as specified in the base binding
Optional properties:
- backlight: as specified in the base binding
- enable-gpios: as specified in the base binding
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

29
bindings/display/panel/simple-panel.txt
View File

@@ -1,28 +1 @@
Simple display panel
====================
panel node
----------
Required properties:
- power-supply: See panel-common.txt
Optional properties:
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- enable-gpios: GPIO pin to enable or disable the panel
- backlight: phandle of the backlight device attached to the panel
- no-hpd: This panel is supposed to communicate that it's ready via HPD
(hot plug detect) signal, but the signal isn't hooked up so we should
hardcode the max delay from the panel spec when powering up the panel.
Example:
panel: panel {
compatible = "cptt,claa101wb01";
ddc-i2c-bus = <&panelddc>;
power-supply = <&vdd_pnl_reg>;
enable-gpios = <&gpio 90 0>;
backlight = <&backlight>;
};
See panel-common.yaml in this directory.

15
bindings/display/panel/tfc,s9700rtwv43tr-01b.txt
View File

@@ -1,15 +0,0 @@
TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with
resistive touch
The panel is found on TI AM335x-evm.
Required properties:
- compatible: should be "tfc,s9700rtwv43tr-01b"
- power-supply: See panel-common.txt
Optional properties:
- enable-gpios: GPIO pin to enable or disable the panel, if there is one
- backlight: phandle of the backlight device attached to the panel
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

36
bindings/display/panel/ti,nspire.yaml Normal file
View File

@@ -0,0 +1,36 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/ti,nspire.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Texas Instruments NSPIRE Display Panels
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
enum:
- ti,nspire-cx-lcd-panel
- ti,nspire-classic-lcd-panel
port: true
required:
- compatible
additionalProperties: false
examples:
- |
panel {
compatible = "ti,nspire-cx-lcd-panel";
port {
panel_in: endpoint {
remote-endpoint = <&pads>;
};
};
};

70
bindings/display/panel/tpo,tpg110.txt
View File

@@ -1,70 +0,0 @@
TPO TPG110 Panel
================
This panel driver is a component that acts as an intermediary
between an RGB output and a variety of panels. The panel
driver is strapped up in electronics to the desired resolution
and other properties, and has a control interface over 3WIRE
SPI. By talking to the TPG110 over SPI, the strapped properties
can be discovered and the hardware is therefore mostly
self-describing.
+--------+
SPI -> | TPO | -> physical display
RGB -> | TPG110 |
+--------+
If some electrical strap or alternate resolution is desired,
this can be set up by taking software control of the display
over the SPI interface. The interface can also adjust
for properties of the display such as gamma correction and
certain electrical driving levels.
The TPG110 does not know the physical dimensions of the panel
connected, so this needs to be specified in the device tree.
It requires a GPIO line for control of its reset line.
The serial protocol has line names that resemble I2C but the
protocol is not I2C but 3WIRE SPI.
Required properties:
- compatible : one of:
"ste,nomadik-nhk15-display", "tpo,tpg110"
"tpo,tpg110"
- grestb-gpios : panel reset GPIO
- width-mm : see display/panel/panel-common.txt
- height-mm : see display/panel/panel-common.txt
The device needs to be a child of an SPI bus, see
spi/spi-bus.txt. The SPI child must set the following
properties:
- spi-3wire
- spi-max-frequency = <3000000>;
as these are characteristics of this device.
The device node can contain one 'port' child node with one child
'endpoint' node, according to the bindings defined in
media/video-interfaces.txt. This node should describe panel's video bus.
Example
-------
panel: display@0 {
compatible = "tpo,tpg110";
reg = <0>;
spi-3wire;
/* 320 ns min period ~= 3 MHz */
spi-max-frequency = <3000000>;
/* Width and height from data sheet */
width-mm = <116>;
height-mm = <87>;
grestb-gpios = <&foo_gpio 5 GPIO_ACTIVE_LOW>;
backlight = <&bl>;
port {
nomadik_clcd_panel: endpoint {
remote-endpoint = <&foo>;
};
};
};

23
bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
View File

@@ -14,6 +14,8 @@ Required properties:
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
- ports: contain a port node with endpoint definitions as defined in [2].
For vopb,set the reg = <0> and set the reg = <1> for vopl.
- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
- video port 1 for either a panel or subsequent encoder
Optional properties:
- power-domains: a phandle to mipi dsi power domain node.
@@ -40,11 +42,12 @@ Example:
ports {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
mipi_in: port {
mipi_in: port@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
mipi_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <&vopb_out_mipi>;
@@ -54,6 +57,16 @@ Example:
remote-endpoint = <&vopl_out_mipi>;
};
};
mipi_out: port@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
mipi_out_panel: endpoint {
remote-endpoint = <&panel_in_mipi>;
};
};
};
panel {
@@ -64,5 +77,11 @@ Example:
pinctrl-names = "default";
pinctrl-0 = <&lcd_en>;
backlight = <&backlight>;
port {
panel_in_mipi: endpoint {
remote-endpoint = <&mipi_out_panel>;
};
};
};
};

11
bindings/display/rockchip/rockchip-lvds.txt
View File

@@ -32,17 +32,6 @@ Their connections are modeled using the OF graph bindings specified in
- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
- video port 1 for either a panel or subsequent encoder
the lvds panel described by
Documentation/devicetree/bindings/display/panel/simple-panel.txt
Panel required properties:
- ports for remote LVDS output
Panel optional properties:
- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
This describes decribed by:
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
Example:
lvds_panel: lvds-panel {

10
bindings/display/ssd1307fb.txt
View File

@@ -27,6 +27,15 @@ Optional properties:
- solomon,prechargep2: Length of precharge period (phase 2) in clock cycles.
This needs to be the higher, the higher the capacitance
of the OLED's pixels is
- solomon,dclk-div: Clock divisor 1 to 16
- solomon,dclk-frq: Clock frequency 0 to 15, higher value means higher
frequency
- solomon,lookup-table: 8 bit value array of current drive pulse widths for
BANK0, and colors A, B, and C. Each value in range
of 31 to 63 for pulse widths of 32 to 64. Color D
is always width 64.
- solomon,area-color-enable: Display uses color mode
- solomon,low-power. Display runs in low power mode
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
@@ -46,4 +55,5 @@ ssd1306: oled@3c {
solomon,com-lrremap;
solomon,com-invdir;
solomon,com-offset = <32>;
solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>;
};

114
bindings/dma/dma.txt
View File

@@ -1,113 +1 @@
* Generic DMA Controller and DMA request bindings
Generic binding to provide a way for a driver using DMA Engine to retrieve the
DMA request or channel information that goes from a hardware device to a DMA
controller.
* DMA controller
Required property:
- #dma-cells: Must be at least 1. Used to provide DMA controller
specific information. See DMA client binding below for
more details.
Optional properties:
- dma-channels: Number of DMA channels supported by the controller.
- dma-requests: Number of DMA request signals supported by the
controller.
- dma-channel-mask: Bitmask of available DMA channels in ascending order
that are not reserved by firmware and are available to
the kernel. i.e. first channel corresponds to LSB.
Example:
dma: dma@48000000 {
compatible = "ti,omap-sdma";
reg = <0x48000000 0x1000>;
interrupts = <0 12 0x4
0 13 0x4
0 14 0x4
0 15 0x4>;
#dma-cells = <1>;
dma-channels = <32>;
dma-requests = <127>;
dma-channel-mask = <0xfffe>
};
* DMA router
DMA routers are transparent IP blocks used to route DMA request lines from
devices to the DMA controller. Some SoCs (like TI DRA7x) have more peripherals
integrated with DMA requests than what the DMA controller can handle directly.
Required property:
- dma-masters: phandle of the DMA controller or list of phandles for
the DMA controllers the router can direct the signal to.
- #dma-cells: Must be at least 1. Used to provide DMA router specific
information. See DMA client binding below for more
details.
Optional properties:
- dma-requests: Number of incoming request lines the router can handle.
- In the node pointed by the dma-masters:
- dma-requests: The router driver might need to look for this in order
to configure the routing.
Example:
sdma_xbar: dma-router@4a002b78 {
compatible = "ti,dra7-dma-crossbar";
reg = <0x4a002b78 0xfc>;
#dma-cells = <1>;
dma-requests = <205>;
ti,dma-safe-map = <0>;
dma-masters = <&sdma>;
};
* DMA client
Client drivers should specify the DMA property using a phandle to the controller
followed by DMA controller specific data.
Required property:
- dmas: List of one or more DMA specifiers, each consisting of
- A phandle pointing to DMA controller node
- A number of integer cells, as determined by the
#dma-cells property in the node referenced by phandle
containing DMA controller specific information. This
typically contains a DMA request line number or a
channel number, but can contain any data that is
required for configuring a channel.
- dma-names: Contains one identifier string for each DMA specifier in
the dmas property. The specific strings that can be used
are defined in the binding of the DMA client device.
Multiple DMA specifiers can be used to represent
alternatives and in this case the dma-names for those
DMA specifiers must be identical (see examples).
Examples:
1. A device with one DMA read channel, one DMA write channel:
i2c1: i2c@1 {
...
dmas = <&dma 2 /* read channel */
&dma 3>; /* write channel */
dma-names = "rx", "tx";
...
};
2. A single read-write channel with three alternative DMA controllers:
dmas = <&dma1 5
&dma2 7
&dma3 2>;
dma-names = "rx-tx", "rx-tx", "rx-tx";
3. A device with three channels, one of which has two alternatives:
dmas = <&dma1 2 /* read channel */
&dma1 3 /* write channel */
&dma2 0 /* error read */
&dma3 0>; /* alternative error read */
dma-names = "rx", "tx", "error", "error";
This file has been moved to dma-controller.yaml.

0
bindings/dma/nbpfaxi.txt → bindings/dma/renesas,nbpfaxi.txt
View File

0
bindings/dma/shdma.txt → bindings/dma/renesas,shdma.txt
View File

45
bindings/dma/sun4i-dma.txt
View File

@@ -1,45 +0,0 @@
Allwinner A10 DMA Controller
This driver follows the generic DMA bindings defined in dma.txt.
Required properties:
- compatible: Must be "allwinner,sun4i-a10-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
- clocks: Should contain a reference to the parent AHB clock
- #dma-cells : Should be 2, first cell denoting normal or dedicated dma,
second cell holding the request line number.
Example:
dma: dma-controller@1c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
interrupts = <27>;
clocks = <&ahb_gates 6>;
#dma-cells = <2>;
};
Clients:
DMA clients connected to the Allwinner A10 DMA controller must use the
format described in the dma.txt file, using a three-cell specifier for
each channel: a phandle plus two integer cells.
The three cells in order are:
1. A phandle pointing to the DMA controller.
2. Whether it is using normal (0) or dedicated (1) channels
3. The port ID as specified in the datasheet
Example:
spi2: spi@1c17000 {
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c17000 0x1000>;
interrupts = <0 12 4>;
clocks = <&ahb_gates 22>, <&spi2_clk>;
clock-names = "ahb", "mod";
dmas = <&dma 1 29>, <&dma 1 28>;
dma-names = "rx", "tx";
#address-cells = <1>;
#size-cells = <0>;
};

81
bindings/dma/sun6i-dma.txt
View File

@@ -1,81 +0,0 @@
Allwinner A31 DMA Controller
This driver follows the generic DMA bindings defined in dma.txt.
Required properties:
- compatible: Must be one of
"allwinner,sun6i-a31-dma"
"allwinner,sun8i-a23-dma"
"allwinner,sun8i-a83t-dma"
"allwinner,sun8i-h3-dma"
"allwinner,sun8i-v3s-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
- clocks: Should contain a reference to the parent AHB clock
- resets: Should contain a reference to the reset controller asserting
this device in reset
- #dma-cells : Should be 1, a single cell holding a line request number
Example:
dma: dma-controller@1c02000 {
compatible = "allwinner,sun6i-a31-dma";
reg = <0x01c02000 0x1000>;
interrupts = <0 50 4>;
clocks = <&ahb1_gates 6>;
resets = <&ahb1_rst 6>;
#dma-cells = <1>;
};
------------------------------------------------------------------------------
For A64 and H6 DMA controller:
Required properties:
- compatible: Must be one of
"allwinner,sun50i-a64-dma"
"allwinner,sun50i-h6-dma"
- dma-channels: Number of DMA channels supported by the controller.
Refer to Documentation/devicetree/bindings/dma/dma.txt
- clocks: In addition to parent AHB clock, it should also contain mbus
clock (H6 only)
- clock-names: Should contain "bus" and "mbus" (H6 only)
- all properties above, i.e. reg, interrupts, clocks, resets and #dma-cells
Optional properties:
- dma-requests: Number of DMA request signals supported by the controller.
Refer to Documentation/devicetree/bindings/dma/dma.txt
Example:
dma: dma-controller@1c02000 {
compatible = "allwinner,sun50i-a64-dma";
reg = <0x01c02000 0x1000>;
interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&ccu CLK_BUS_DMA>;
dma-channels = <8>;
dma-requests = <27>;
resets = <&ccu RST_BUS_DMA>;
#dma-cells = <1>;
};
------------------------------------------------------------------------------
Clients:
DMA clients connected to the A31 DMA controller must use the format
described in the dma.txt file, using a two-cell specifier for each
channel: a phandle plus one integer cells.
The two cells in order are:
1. A phandle pointing to the DMA controller.
2. The port ID as specified in the datasheet
Example:
spi2: spi@1c6a000 {
compatible = "allwinner,sun6i-a31-spi";
reg = <0x01c6a000 0x1000>;
interrupts = <0 67 4>;
clocks = <&ahb1_gates 22>, <&spi2_clk>;
clock-names = "ahb", "mod";
dmas = <&dma 25>, <&dma 25>;
dma-names = "rx", "tx";
resets = <&ahb1_rst 22>;
};

89
bindings/dsp/fsl,dsp.yaml Normal file
View File

@@ -0,0 +1,89 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dsp/fsl,dsp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX8 DSP core
maintainers:
- Daniel Baluta <daniel.baluta@nxp.com>
description: |
Some boards from i.MX8 family contain a DSP core used for
advanced pre- and post- audio processing.
properties:
compatible:
enum:
- fsl,imx8qxp-dsp
reg:
description: Should contain register location and length
clocks:
items:
- description: ipg clock
- description: ocram clock
- description: core clock
clock-names:
items:
- const: ipg
- const: ocram
- const: core
power-domains:
description:
List of phandle and PM domain specifier as documented in
Documentation/devicetree/bindings/power/power_domain.txt
maxItems: 4
mboxes:
description:
List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB
(see mailbox/fsl,mu.txt)
maxItems: 4
mbox-names:
items:
- const: txdb0
- const: txdb1
- const: rxdb0
- const: rxdb1
memory-region:
description:
phandle to a node describing reserved memory (System RAM memory)
used by DSP (see bindings/reserved-memory/reserved-memory.txt)
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- power-domains
- mboxes
- mbox-names
- memory-region
examples:
- |
#include <dt-bindings/firmware/imx/rsrc.h>
#include <dt-bindings/clock/imx8-clock.h>
dsp@596e8000 {
compatible = "fsl,imx8qxp-dsp";
reg = <0x596e8000 0x88000>;
clocks = <&adma_lpcg IMX_ADMA_LPCG_DSP_IPG_CLK>,
<&adma_lpcg IMX_ADMA_LPCG_OCRAM_IPG_CLK>,
<&adma_lpcg IMX_ADMA_LPCG_DSP_CORE_CLK>;
clock-names = "ipg", "ocram", "core";
power-domains = <&pd IMX_SC_R_MU_13A>,
<&pd IMX_SC_R_MU_13B>,
<&pd IMX_SC_R_DSP>,
<&pd IMX_SC_R_DSP_RAM>;
mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
memory-region = <&dsp_reserved>;
};

1
bindings/eeprom/at25.txt
View File

@@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25.
Required properties:
- compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
Example "<vendor>,<type>" values:
"anvo,anv32e61w"
"microchip,25lc040"
"st,m95m02"
"st,m95256"

2
bindings/example-schema.yaml
View File

@@ -5,7 +5,7 @@
# All the top-level keys are standard json-schema keywords except for
# 'maintainers' and 'select'
# $id is a unique idenifier based on the filename. There may or may not be a
# $id is a unique identifier based on the filename. There may or may not be a
# file present at the URL.
$id: "http://devicetree.org/schemas/example-schema.yaml#"
# $schema is the meta-schema this schema should be validated with.

2
bindings/extcon/extcon-arizona.txt
View File

@@ -72,5 +72,5 @@ codec: wm8280@0 {
1 2 1 /* MICDET2 MICBIAS2 GPIO=high */
>;
wlf,gpsw = <0>;
wlf,gpsw = <ARIZONA_GPSW_OPEN>;
};

4
bindings/extcon/extcon-fsa9480.txt
View File

@@ -5,7 +5,9 @@ controlled using I2C and enables USB data, stereo and mono audio, video,
microphone, and UART data to use a common connector port.
Required properties:
- compatible : Must be "fcs,fsa9480"
- compatible : Must be one of
"fcs,fsa9480"
"fcs,fsa880"
- reg : Specifies i2c slave address. Must be 0x25.
- interrupts : Should contain one entry specifying interrupt signal of
interrupt parent to which interrupt pin of the chip is connected.

71
bindings/fieldbus/arcx,anybus-controller.txt
View File

@@ -1,71 +0,0 @@
* Arcx Anybus-S controller
This chip communicates with the SoC over a parallel bus. It is
expected that its Device Tree node is specified as the child of a node
corresponding to the parallel bus used for communication.
Required properties:
--------------------
- compatible : The following chip-specific string:
"arcx,anybus-controller"
- reg : three areas:
index 0: bus memory area where the cpld registers are located.
index 1: bus memory area of the first host's dual-port ram.
index 2: bus memory area of the second host's dual-port ram.
- reset-gpios : the GPIO pin connected to the reset line of the controller.
- interrupts : two interrupts:
index 0: interrupt connected to the first host
index 1: interrupt connected to the second host
Generic interrupt client node bindings are described in
interrupt-controller/interrupts.txt
Optional: use of subnodes
-------------------------
The card connected to a host may need additional properties. These can be
specified in subnodes to the controller node.
The subnodes are identified by the standard 'reg' property. Which information
exactly can be specified depends on the bindings for the function driver
for the subnode.
Required controller node properties when using subnodes:
- #address-cells: should be one.
- #size-cells: should be zero.
Required subnode properties:
- reg: Must contain the host index of the card this subnode describes:
<0> for the first host on the controller
<1> for the second host on the controller
Note that only a single card can be plugged into a host, so the host
index uniquely describes the card location.
Example of usage:
-----------------
This example places the bridge on top of the i.MX WEIM parallel bus, see:
Documentation/devicetree/bindings/bus/imx-weim.txt
&weim {
controller@0,0 {
compatible = "arcx,anybus-controller";
reg = <0 0 0x100>, <0 0x400000 0x800>, <1 0x400000 0x800>;
reset-gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;
interrupt-parent = <&gpio1>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>, <5 IRQ_TYPE_LEVEL_LOW>;
/* fsl,weim-cs-timing is a i.MX WEIM bus specific property */
fsl,weim-cs-timing = <0x024400b1 0x00001010 0x20081100
0x00000000 0xa0000240 0x00000000>;
/* optional subnode for a card plugged into the first host */
#address-cells = <1>;
#size-cells = <0>;
card@0 {
reg = <0>;
/* card specific properties go here */
};
};
};

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

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

4
bindings/firmware/qcom,scm.txt
View File

@@ -9,14 +9,16 @@ Required properties:
- compatible: must contain one of the following:
* "qcom,scm-apq8064"
* "qcom,scm-apq8084"
* "qcom,scm-ipq4019"
* "qcom,scm-msm8660"
* "qcom,scm-msm8916"
* "qcom,scm-msm8960"
* "qcom,scm-msm8974"
* "qcom,scm-msm8996"
* "qcom,scm-msm8998"
* "qcom,scm-ipq4019"
* "qcom,scm-sc7180"
* "qcom,scm-sdm845"
* "qcom,scm-sm8150"
and:
* "qcom,scm"
- clocks: Specifies clocks needed by the SCM interface, if any:

5
bindings/fpga/altera-fpga2sdram-bridge.txt
View File

@@ -3,10 +3,7 @@ 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.
See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
Example:
fpga_bridge3: fpga-bridge@ffc25080 {

5
bindings/fpga/altera-freeze-bridge.txt
View File

@@ -10,10 +10,7 @@ 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.
See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
Example:
freeze-controller@100000450 {

5
bindings/fpga/altera-hps2fpga-bridge.txt
View File

@@ -9,10 +9,7 @@ Required properties:
- 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.
See Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
Example:
fpga_bridge0: fpga-bridge@ff400000 {

13
bindings/fpga/fpga-bridge.txt Normal file
View File

@@ -0,0 +1,13 @@
FPGA Bridge Device Tree Binding
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>;
};

8
bindings/fpga/xilinx-pr-decoupler.txt
View File

@@ -18,12 +18,8 @@ Required properties:
- clocks : input clock to IP
- clock-names : should contain "aclk"
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.
See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic bindings.
See Documentation/devicetree/bindings/fpga/fpga-region.txt and
Documentation/devicetree/bindings/fpga/fpga-bridge.txt for generic bindings.
Example:
fpga-bridge@100000450 {

7
bindings/gpio/gpio-aspeed.txt
View File

@@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings
-------------------------------------------
Required properties:
- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio"
- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio",
or "aspeed,ast2600-gpio".
- #gpio-cells : Should be two
- First cell is the GPIO line number
@@ -17,7 +18,9 @@ Required properties:
Optional properties:
- clocks : A phandle to the clock to use for debounce timings
- clocks : A phandle to the clock to use for debounce timings
- ngpios : Number of GPIOs controlled by this controller. Should be set
when there are multiple GPIO controllers on a SoC (ast2600).
The gpio and interrupt properties are further described in their respective
bindings documentation:

18
bindings/gpio/gpio-moxtet.txt Normal file
View File

@@ -0,0 +1,18 @@
Turris Mox Moxtet GPIO expander via Moxtet bus
Required properties:
- compatible : Should be "cznic,moxtet-gpio".
- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two. For consumer use see gpio.txt.
Other properties are required for a Moxtet bus device, please refer to
Documentation/devicetree/bindings/bus/moxtet.txt.
Example:
moxtet_sfp: gpio@0 {
compatible = "cznic,moxtet-gpio";
gpio-controller;
#gpio-cells = <2>;
reg = <0>;
}

16
bindings/gpio/gpio-mpc8xxx.txt
View File

@@ -4,7 +4,7 @@ Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
ls1021a, ls1043a, ls2080a.
ls1021a, ls1043a, ls2080a, ls1028a, ls1088a.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
@@ -37,3 +37,17 @@ gpio0: gpio@2300000 {
interrupt-controller;
#interrupt-cells = <2>;
};
Example of gpio-controller node for a ls1028a/ls1088a SoC:
gpio1: gpio@2300000 {
compatible = "fsl,ls1028a-gpio", "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2300000 0x0 0x10000>;
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
little-endian;
};

45
bindings/gpio/sgpio-aspeed.txt Normal file
View File

@@ -0,0 +1,45 @@
Aspeed SGPIO controller Device Tree Bindings
--------------------------------------------
This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 full
featured Serial GPIOs. Each of the Serial GPIO pins can be programmed to
support the following options:
- Support interrupt option for each input port and various interrupt
sensitivity option (level-high, level-low, edge-high, edge-low)
- Support reset tolerance option for each output port
- Directly connected to APB bus and its shift clock is from APB bus clock
divided by a programmable value.
- Co-work with external signal-chained TTL components (74LV165/74LV595)
Required properties:
- compatible : Should be one of
"aspeed,ast2400-sgpio", "aspeed,ast2500-sgpio"
- #gpio-cells : Should be 2, see gpio.txt
- reg : Address and length of the register set for the device
- gpio-controller : Marks the device node as a GPIO controller
- interrupts : Interrupt specifier, see interrupt-controller/interrupts.txt
- interrupt-controller : Mark the GPIO controller as an interrupt-controller
- ngpios : number of GPIO lines, see gpio.txt
(should be multiple of 8, up to 80 pins)
- clocks : A phandle to the APB clock for SGPM clock division
- bus-frequency : SGPM CLK frequency
The sgpio and interrupt properties are further described in their respective
bindings documentation:
- Documentation/devicetree/bindings/gpio/gpio.txt
- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Example:
sgpio: sgpio@1e780200 {
#gpio-cells = <2>;
compatible = "aspeed,ast2500-sgpio";
gpio-controller;
interrupts = <40>;
reg = <0x1e780200 0x0100>;
clocks = <&syscon ASPEED_CLK_APB>;
interrupt-controller;
ngpios = <8>;
bus-frequency = <12000000>;
};

92
bindings/gpu/arm,mali-bifrost.txt
View File

@@ -1,92 +0,0 @@
ARM Mali Bifrost GPU
====================
Required properties:
- compatible :
* Since Mali Bifrost GPU model/revision is fully discoverable by reading
some determined registers, must contain the following:
+ "arm,mali-bifrost"
* which must be preceded by one of the following vendor specifics:
+ "amlogic,meson-g12a-mali"
- reg : Physical base address of the device and length of the register area.
- interrupts : Contains the three IRQ lines required by Mali Bifrost devices,
in the following defined order.
- interrupt-names : Contains the names of IRQ resources in this exact defined
order: "job", "mmu", "gpu".
Optional properties:
- clocks : Phandle to clock for the Mali Bifrost device.
- mali-supply : Phandle to regulator for the Mali device. Refer to
Documentation/devicetree/bindings/regulator/regulator.txt for details.
- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
for details.
- resets : Phandle of the GPU reset line.
Vendor-specific bindings
------------------------
The Mali GPU is integrated very differently from one SoC to
another. In order to accommodate those differences, you have the option
to specify one more vendor-specific compatible, among:
- "amlogic,meson-g12a-mali"
Required properties:
- resets : Should contain phandles of :
+ GPU reset line
+ GPU APB glue reset line
Example for a Mali-G31:
gpu@ffa30000 {
compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
reg = <0xffe40000 0x10000>;
interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "job", "mmu", "gpu";
clocks = <&clk CLKID_MALI>;
mali-supply = <&vdd_gpu>;
operating-points-v2 = <&gpu_opp_table>;
resets = <&reset RESET_DVALIN_CAPB3>, <&reset RESET_DVALIN>;
};
gpu_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp@533000000 {
opp-hz = /bits/ 64 <533000000>;
opp-microvolt = <1250000>;
};
opp@450000000 {
opp-hz = /bits/ 64 <450000000>;
opp-microvolt = <1150000>;
};
opp@400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1125000>;
};
opp@350000000 {
opp-hz = /bits/ 64 <350000000>;
opp-microvolt = <1075000>;
};
opp@266000000 {
opp-hz = /bits/ 64 <266000000>;
opp-microvolt = <1025000>;
};
opp@160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <925000>;
};
opp@100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <912500>;
};
};

119
bindings/gpu/arm,mali-midgard.txt
View File

@@ -1,119 +0,0 @@
ARM Mali Midgard GPU
====================
Required properties:
- compatible :
* Must contain one of the following:
+ "arm,mali-t604"
+ "arm,mali-t624"
+ "arm,mali-t628"
+ "arm,mali-t720"
+ "arm,mali-t760"
+ "arm,mali-t820"
+ "arm,mali-t830"
+ "arm,mali-t860"
+ "arm,mali-t880"
* which must be preceded by one of the following vendor specifics:
+ "allwinner,sun50i-h6-mali"
+ "amlogic,meson-gxm-mali"
+ "samsung,exynos5433-mali"
+ "rockchip,rk3288-mali"
+ "rockchip,rk3399-mali"
- reg : Physical base address of the device and length of the register area.
- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
- interrupt-names : Contains the names of IRQ resources in the order they were
provided in the interrupts property. Must contain: "job", "mmu", "gpu".
Optional properties:
- clocks : Phandle to clock for the Mali Midgard device.
- clock-names : Specify the names of the clocks specified in clocks
when multiple clocks are present.
* core: clock driving the GPU itself (When only one clock is present,
assume it's this clock.)
* bus: bus clock for the GPU
- mali-supply : Phandle to regulator for the Mali device. Refer to
Documentation/devicetree/bindings/regulator/regulator.txt for details.
- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
for details.
- #cooling-cells: Refer to Documentation/devicetree/bindings/thermal/thermal.txt
for details.
- resets : Phandle of the GPU reset line.
Vendor-specific bindings
------------------------
The Mali GPU is integrated very differently from one SoC to
another. In order to accommodate those differences, you have the option
to specify one more vendor-specific compatible, among:
- "allwinner,sun50i-h6-mali"
Required properties:
- clocks : phandles to core and bus clocks
- clock-names : must contain "core" and "bus"
- resets: phandle to GPU reset line
- "amlogic,meson-gxm-mali"
Required properties:
- resets : Should contain phandles of :
+ GPU reset line
+ GPU APB glue reset line
Example for a Mali-T760:
gpu@ffa30000 {
compatible = "rockchip,rk3288-mali", "arm,mali-t760";
reg = <0xffa30000 0x10000>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "job", "mmu", "gpu";
clocks = <&cru ACLK_GPU>;
mali-supply = <&vdd_gpu>;
operating-points-v2 = <&gpu_opp_table>;
power-domains = <&power RK3288_PD_GPU>;
#cooling-cells = <2>;
};
gpu_opp_table: opp_table0 {
compatible = "operating-points-v2";
opp@533000000 {
opp-hz = /bits/ 64 <533000000>;
opp-microvolt = <1250000>;
};
opp@450000000 {
opp-hz = /bits/ 64 <450000000>;
opp-microvolt = <1150000>;
};
opp@400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <1125000>;
};
opp@350000000 {
opp-hz = /bits/ 64 <350000000>;
opp-microvolt = <1075000>;
};
opp@266000000 {
opp-hz = /bits/ 64 <266000000>;
opp-microvolt = <1025000>;
};
opp@160000000 {
opp-hz = /bits/ 64 <160000000>;
opp-microvolt = <925000>;
};
opp@100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <912500>;
};
};

124
bindings/gpu/arm,mali-utgard.txt
View File

@@ -1,124 +0,0 @@
ARM Mali Utgard GPU
===================
Required properties:
- compatible
* Must be one of the following:
+ "arm,mali-300"
+ "arm,mali-400"
+ "arm,mali-450"
* And, optionally, one of the vendor specific compatible:
+ allwinner,sun4i-a10-mali
+ allwinner,sun7i-a20-mali
+ allwinner,sun8i-h3-mali
+ allwinner,sun50i-a64-mali
+ allwinner,sun50i-h5-mali
+ amlogic,meson8-mali
+ amlogic,meson8b-mali
+ amlogic,meson-gxbb-mali
+ amlogic,meson-gxl-mali
+ samsung,exynos4210-mali
+ rockchip,rk3036-mali
+ rockchip,rk3066-mali
+ rockchip,rk3188-mali
+ rockchip,rk3228-mali
+ rockchip,rk3328-mali
+ stericsson,db8500-mali
- reg: Physical base address and length of the GPU registers
- interrupts: an entry for each entry in interrupt-names.
See ../interrupt-controller/interrupts.txt for details.
- interrupt-names:
* ppX: Pixel Processor X interrupt (X from 0 to 7)
* ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7)
* pp: Pixel Processor broadcast interrupt (mali-450 only)
* gp: Geometry Processor interrupt
* gpmmu: Geometry Processor MMU interrupt
- clocks: an entry for each entry in clock-names
- clock-names:
* bus: bus clock for the GPU
* core: clock driving the GPU itself
Optional properties:
- interrupt-names and interrupts:
* pmu: Power Management Unit interrupt, if implemented in hardware
- memory-region:
Memory region to allocate from, as defined in
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
- mali-supply:
Phandle to regulator for the Mali device, as defined in
Documentation/devicetree/bindings/regulator/regulator.txt for details.
- operating-points-v2:
Operating Points for the GPU, as defined in
Documentation/devicetree/bindings/opp/opp.txt
- power-domains:
A power domain consumer specifier as defined in
Documentation/devicetree/bindings/power/power_domain.txt
Vendor-specific bindings
------------------------
The Mali GPU is integrated very differently from one SoC to
another. In order to accomodate those differences, you have the option
to specify one more vendor-specific compatible, among:
- allwinner,sun4i-a10-mali
Required properties:
* resets: phandle to the reset line for the GPU
- allwinner,sun7i-a20-mali
Required properties:
* resets: phandle to the reset line for the GPU
- allwinner,sun50i-a64-mali
Required properties:
* resets: phandle to the reset line for the GPU
- allwinner,sun50i-h5-mali
Required properties:
* resets: phandle to the reset line for the GPU
- amlogic,meson8-mali and amlogic,meson8b-mali
Required properties:
* resets: phandle to the reset line for the GPU
- Rockchip variants:
Required properties:
* resets: phandle to the reset line for the GPU
- stericsson,db8500-mali
Required properties:
* interrupt-names and interrupts:
+ combined: combined interrupt of all of the above lines
Example:
mali: gpu@1c40000 {
compatible = "allwinner,sun7i-a20-mali", "arm,mali-400";
reg = <0x01c40000 0x10000>;
interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "gp",
"gpmmu",
"pp0",
"ppmmu0",
"pp1",
"ppmmu1",
"pmu";
clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>;
clock-names = "bus", "core";
resets = <&ccu RST_BUS_GPU>;
};

11
bindings/hwmon/as370.txt Normal file
View File

@@ -0,0 +1,11 @@
Bindings for Synaptics AS370 PVT sensors
Required properties:
- compatible : "syna,as370-hwmon"
- reg : address and length of the register set.
Example:
hwmon@ea0810 {
compatible = "syna,as370-hwmon";
reg = <0xea0810 0xc>;
};

8
bindings/hwmon/ibm,cffps1.txt
View File

@@ -1,8 +1,10 @@
Device-tree bindings for IBM Common Form Factor Power Supply Version 1
----------------------------------------------------------------------
Device-tree bindings for IBM Common Form Factor Power Supply Versions 1 and 2
-----------------------------------------------------------------------------
Required properties:
- compatible = "ibm,cffps1";
- compatible : Must be one of the following:
"ibm,cffps1"
"ibm,cffps2"
- reg = < I2C bus address >; : Address of the power supply on the
I2C bus.

1
bindings/hwmon/lm75.txt
View File

@@ -15,6 +15,7 @@ Required properties:
"maxim,max31725",
"maxim,max31726",
"maxim,mcp980x",
"nxp,pct2075",
"st,stds75",
"st,stlm75",
"microchip,tcn75",

4
bindings/i2c/brcm,bcm2835-i2c.txt
View File

@@ -1,7 +1,9 @@
Broadcom BCM2835 I2C controller
Required properties:
- compatible : Should be "brcm,bcm2835-i2c".
- compatible : Should be one of:
"brcm,bcm2711-i2c"
"brcm,bcm2835-i2c"
- reg: Should contain register location and length.
- interrupts: Should contain interrupt.
- clocks : The clock feeding the I2C controller.

2
bindings/i2c/i2c-mux-gpmux.txt
View File

@@ -42,7 +42,7 @@ Optional properties:
This means that no unrelated I2C transactions are allowed on the parent I2C
adapter for the complete multiplexed I2C transaction.
The properties of mux-locked and parent-locked multiplexers are discussed
in more detail in Documentation/i2c/i2c-topology.
in more detail in Documentation/i2c/i2c-topology.rst.
For each i2c child node, an I2C child bus will be created. They will
be numbered based on their order in the device tree.

0
bindings/i2c/i2c-rcar.txt → bindings/i2c/renesas,i2c.txt
View File

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