d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Import devicetree files from Linux 5.4

Browse Source
This commit is contained in:
Emmanuel Vadot 2019-11-28 19:05:03 +00:00
parent 01e5ca1705
commit c3f1cfc76c
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/vendor/device-tree/dist/; revision=355185
svn path=/vendor/device-tree/5.4/; revision=355186; tag=vendor/device-tree/5.4
856 changed files with 39328 additions and 9904 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.gitignore vendored
View File

@ -1,4 +0,0 @@
.*
!.gitignore
*.dtb

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"

38
Bindings/arm/actions.yaml Normal file
View File

@ -0,0 +1,38 @@
# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/actions.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Actions Semi platforms device tree bindings
maintainers:
- Andreas Färber <afaerber@suse.de>
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
properties:
compatible:
oneOf:
# The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC.
- items:
- enum:
- allo,sparky # Allo.com Sparky
- cubietech,cubieboard6 # Cubietech CubieBoard6
- const: actions,s500
- items:
- enum:
- lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B
- const: lemaker,guitar
- const: actions,s500
# The Actions Semi S700 is a quad-core ARM Cortex-A53 SoC.
- items:
- enum:
- cubietech,cubieboard7 # Cubietech CubieBoard7
- const: actions,s700
# The Actions Semi S900 is a quad-core ARM Cortex-A53 SoC.
- items:
- enum:
- ucrobotics,bubblegum-96 # uCRobotics Bubblegum-96
- const: actions,s900

21
Bindings/arm/amlogic.yaml
View File

@ -91,13 +91,11 @@ properties:
- description: Boards with the Amlogic Meson GXL S905X SoC
items:
- enum:
- amediatech,x96-max
- amlogic,p212
- hwacom,amazetv
- khadas,vim
- libretech,cc
- nexbox,a95x
- seirobotics,sei510
- const: amlogic,s905x
- const: amlogic,meson-gxl
@ -129,16 +127,33 @@ properties:
- const: amlogic,a113d
- const: amlogic,meson-axg
- description: Boards with the Amlogic Meson G12A S905D2 SoC
- description: Boards with the Amlogic Meson G12A S905D2/X2/Y2 SoC
items:
- enum:
- amediatech,x96-max
- amlogic,u200
- seirobotics,sei510
- const: amlogic,g12a
- description: Boards with the Amlogic Meson G12B A311D SoC
items:
- enum:
- khadas,vim3
- const: amlogic,a311d
- const: amlogic,g12b
- description: Boards with the Amlogic Meson G12B S922X SoC
items:
- enum:
- hardkernel,odroid-n2
- khadas,vim3
- const: amlogic,s922x
- const: amlogic,g12b
- description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC
items:
- enum:
- seirobotics,sei610
- khadas,vim3l
- const: amlogic,sm1
...

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

17
Bindings/arm/arm,scmi.txt
View File

@ -73,6 +73,16 @@ Required properties:
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Reset signal bindings for the reset domains based on SCMI Message Protocol
------------------------------------------------------------
This binding for the SCMI reset domain providers uses the generic reset
signal binding[5].
Required properties:
- #reset-cells : Should be 1. Contains the reset domain ID value used
by SCMI commands.
SRAM and Shared Memory for SCMI
-------------------------------
@ -93,6 +103,7 @@ Required sub-node properties:
[2] Documentation/devicetree/bindings/power/power_domain.txt
[3] Documentation/devicetree/bindings/thermal/thermal.txt
[4] Documentation/devicetree/bindings/sram/sram.txt
[5] Documentation/devicetree/bindings/reset/reset.txt
Example:
@ -152,6 +163,11 @@ firmware {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
scmi_reset: protocol@16 {
reg = <0x16>;
#reset-cells = <1>;
};
};
};
@ -166,6 +182,7 @@ hdlcd@7ff60000 {
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scmi_clk 4>;
power-domains = <&scmi_devpd 1>;
resets = <&scmi_reset 10>;
};
thermal-zones {

2
Bindings/arm/arm-boards
View File

@ -199,7 +199,7 @@ The description for the board must include:
A detailed description of the bindings used for "psci" nodes is present
in the psci.yaml file.
- a "cpus" node describing the available cores and their associated
"enable-method"s. For more details see cpus.txt file.
"enable-method"s. For more details see cpus.yaml file.
Example:

3
Bindings/arm/cpus.yaml
View File

@ -124,6 +124,7 @@ properties:
- arm,cortex-a15
- arm,cortex-a17
- arm,cortex-a53
- arm,cortex-a55
- arm,cortex-a57
- arm,cortex-a72
- arm,cortex-a73
@ -155,6 +156,7 @@ properties:
- qcom,krait
- qcom,kryo
- qcom,kryo385
- qcom,kryo485
- qcom,scorpion
enable-method:
@ -175,6 +177,7 @@ properties:
- amlogic,meson8-smp
- amlogic,meson8b-smp
- arm,realview-smp
- aspeed,ast2600-smp
- brcm,bcm11351-cpu-method
- brcm,bcm23550
- brcm,bcm2836-smp

4
Bindings/arm/freescale/fsl,scu.txt
View File

@ -136,7 +136,9 @@ Required properties:
OCOTP bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: Should be "fsl,imx8qxp-scu-ocotp"
- compatible: Should be one of:
"fsl,imx8qm-scu-ocotp",
"fsl,imx8qxp-scu-ocotp".
- #address-cells: Must be 1. Contains byte index
- #size-cells: Must be 1. Contains byte length

26
Bindings/arm/fsl.yaml
View File

@ -161,6 +161,20 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
- const: fsl,imx6ul
- description: Kontron N6310 S Board
items:
- const: kontron,imx6ul-n6310-s
- const: kontron,imx6ul-n6310-som
- const: fsl,imx6ul
- description: Kontron N6310 S 43 Board
items:
- const: kontron,imx6ul-n6310-s-43
- const: kontron,imx6ul-n6310-s
- const: kontron,imx6ul-n6310-som
- const: fsl,imx6ul
- description: i.MX6ULL based Boards
@ -188,6 +202,7 @@ properties:
- fsl,imx7d-sdb # i.MX7 SabreSD Board
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
- zii,imx7d-rmu2 # ZII RMU2 Board
- zii,imx7d-rpu2 # ZII RPU2 Board
- const: fsl,imx7d
@ -214,16 +229,26 @@ properties:
- fsl,imx8mm-evk # i.MX8MM EVK Board
- const: fsl,imx8mm
- description: i.MX8MN based Boards
items:
- enum:
- fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
- const: fsl,imx8mn
- description: i.MX8MQ based Boards
items:
- enum:
- boundary,imx8mq-nitrogen8m # i.MX8MQ NITROGEN Board
- fsl,imx8mq-evk # i.MX8MQ EVK Board
- purism,librem5-devkit # Purism Librem5 devkit
- solidrun,hummingboard-pulse # SolidRun Hummingboard Pulse
- technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk
- const: fsl,imx8mq
- description: i.MX8QXP based Boards
items:
- enum:
- einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board
- fsl,imx8qxp-mek # i.MX8QXP MEK Board
- const: fsl,imx8qxp
@ -283,6 +308,7 @@ properties:
- description: LS1046A based Boards
items:
- enum:
- fsl,ls1046a-frwy
- fsl,ls1046a-qds
- fsl,ls1046a-rdb
- const: fsl,ls1046a

32
Bindings/arm/idle-states.txt
View File

@ -28,7 +28,7 @@ PM implementation to put the processor in different idle states (which include
states listed above; "off" state is not an idle state since it does not have
wake-up capabilities, hence it is not considered in this document).
Idle state parameters (eg entry latency) are platform specific and need to be
Idle state parameters (e.g. entry latency) are platform specific and need to be
characterized with bindings that provide the required information to OS PM
code so that it can build the required tables and use them at runtime.
@ -90,24 +90,24 @@ These timing parameters can be used by an OS in different circumstances.
An idle CPU requires the expected min-residency time to select the most
appropriate idle state based on the expected expiry time of the next IRQ
(ie wake-up) that causes the CPU to return to the EXEC phase.
(i.e. wake-up) that causes the CPU to return to the EXEC phase.
An operating system scheduler may need to compute the shortest wake-up delay
for CPUs in the system by detecting how long will it take to get a CPU out
of an idle state, eg:
of an idle state, e.g.:
wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
In other words, the scheduler can make its scheduling decision by selecting
(eg waking-up) the CPU with the shortest wake-up latency.
The wake-up latency must take into account the entry latency if that period
(e.g. waking-up) the CPU with the shortest wake-up delay.
The wake-up delay must take into account the entry latency if that period
has not expired. The abortable nature of the PREP period can be ignored
if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
the worst case since it depends on the CPU operating conditions, ie caches
the worst case since it depends on the CPU operating conditions, i.e. caches
state).
An OS has to reliably probe the wakeup-latency since some devices can enforce
latency constraints guarantees to work properly, so the OS has to detect the
latency constraint guarantees to work properly, so the OS has to detect the
worst case wake-up latency it can incur if a CPU is allowed to enter an
idle state, and possibly to prevent that to guarantee reliable device
functioning.
@ -183,15 +183,15 @@ and IDLE2:
Graph 2: idle states min-residency example
In graph 2 above, that takes into account idle states entry/exit energy
costs, it is clear that if the idle state residency time (ie time till next
costs, it is clear that if the idle state residency time (i.e. time till next
wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
choice energywise.
This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
than IDLE2.
However, the lower power consumption (ie shallower energy curve slope) of idle
state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
However, the lower power consumption (i.e. shallower energy curve slope) of
idle state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
efficient.
The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
@ -214,8 +214,8 @@ processor idle states, defined as device tree nodes, are listed.
Usage: Optional - On ARM systems, it is a container of processor idle
states nodes. If the system does not provide CPU
power management capabilities or the processor just
supports idle_standby an idle-states node is not
power management capabilities, or the processor just
supports idle_standby, an idle-states node is not
required.
Description: idle-states node is a container node, where its
@ -287,14 +287,14 @@ follows:
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency in
microseconds required to enter the idle state.
The exit-latency-us duration may be guaranteed
only after entry-latency-us has passed.
- exit-latency-us
Usage: Required
Value type: <prop-encoded-array>
Definition: u32 value representing worst case latency
in microseconds required to exit the idle state.
The exit-latency-us duration may be guaranteed
only after entry-latency-us has passed.
- min-residency-us
Usage: Required
@ -342,8 +342,8 @@ follows:
state.
In addition to the properties listed above, a state node may require
additional properties specifics to the entry-method defined in the
idle-states node, please refer to the entry-method bindings
additional properties specific to the entry-method defined in the
idle-states node. Please refer to the entry-method bindings
documentation for properties definitions.
===========================================

4
Bindings/arm/l2c2x0.yaml
View File

@ -176,6 +176,10 @@ properties:
description: disable parity checking on the L2 cache (L220 or PL310).
type: boolean
marvell,ecc-enable:
description: enable ECC protection on the L2 cache
type: boolean
arm,outer-sync-disable:
description: disable the outer sync operation on the L2 cache.
Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that

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:

4
Bindings/arm/mediatek.yaml
View File

@ -46,6 +46,10 @@ properties:
- enum:
- mediatek,mt6765-evb
- const: mediatek,mt6765
- items:
- enum:
- mediatek,mt6779-evb
- const: mediatek,mt6779
- items:
- enum:
- mediatek,mt6795-evb

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,audsys.txt
View File

@ -7,6 +7,7 @@ Required Properties:
- compatible: Should be one of:
- "mediatek,mt2701-audsys", "syscon"
- "mediatek,mt6779-audio", "syscon"
- "mediatek,mt7622-audsys", "syscon"
- "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
- "mediatek,mt8183-audiosys", "syscon"

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

2
Bindings/arm/mediatek/mediatek,sgmiisys.txt
View File

@ -9,8 +9,6 @@ Required Properties:
- "mediatek,mt7622-sgmiisys", "syscon"
- "mediatek,mt7629-sgmiisys", "syscon"
- #clock-cells: Must be 1
- mediatek,physpeed: Should be one of "auto", "1000" or "2500" to match up
the capability of the target PHY.
The SGMIISYS controller uses the common clk binding from
Documentation/devicetree/bindings/clock/clock-bindings.txt

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"

8
Bindings/arm/qcom.yaml
View File

@ -45,6 +45,7 @@ description: |
mtp
sbc
hk01
qrd
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
@ -115,6 +116,13 @@ properties:
- const: qcom,msm8916-mtp
- const: qcom,msm8916
- items:
- enum:
- longcheer,l8150
- samsung,a3u-eur
- samsung,a5u-eur
- const: qcom,msm8916
- items:
- const: qcom,msm8996-mtp

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";

23
Bindings/arm/realtek.yaml Normal file
View File

@ -0,0 +1,23 @@
# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/realtek.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek platforms device tree bindings
maintainers:
- Andreas Färber <afaerber@suse.de>
properties:
$nodename:
const: '/'
compatible:
# RTD1295 SoC based boards
items:
- enum:
- mele,v9
- probox2,ava
- zidoo,x9s
- const: realtek,rtd1295
...

49
Bindings/arm/rockchip.yaml
View File

@ -128,6 +128,21 @@ properties:
- const: google,veyron
- const: rockchip,rk3288
- description: Google Fievel (AOPEN Chromebox Mini)
items:
- const: google,veyron-fievel-rev8
- const: google,veyron-fievel-rev7
- const: google,veyron-fievel-rev6
- const: google,veyron-fievel-rev5
- const: google,veyron-fievel-rev4
- const: google,veyron-fievel-rev3
- const: google,veyron-fievel-rev2
- const: google,veyron-fievel-rev1
- const: google,veyron-fievel-rev0
- const: google,veyron-fievel
- const: google,veyron
- const: rockchip,rk3288
- description: Google Gru (dev-board)
items:
- const: google,gru-rev15
@ -311,6 +326,21 @@ properties:
- const: google,veyron
- const: rockchip,rk3288
- description: Google Tiger (AOpen Chromebase Mini)
items:
- const: google,veyron-tiger-rev8
- const: google,veyron-tiger-rev7
- const: google,veyron-tiger-rev6
- const: google,veyron-tiger-rev5
- const: google,veyron-tiger-rev4
- const: google,veyron-tiger-rev3
- const: google,veyron-tiger-rev2
- const: google,veyron-tiger-rev1
- const: google,veyron-tiger-rev0
- const: google,veyron-tiger
- const: google,veyron
- const: rockchip,rk3288
- description: Haoyu MarsBoard RK3066
items:
- const: haoyu,marsboard-rk3066
@ -329,6 +359,16 @@ properties:
- khadas,edge-v
- const: rockchip,rk3399
- description: Mecer Xtreme Mini S6
items:
- const: mecer,xms6
- const: rockchip,rk3229
- description: Leez RK3399 P710
items:
- const: leez,p710
- const: rockchip,rk3399
- description: mqmaker MiQi
items:
- const: mqmaker,miqi
@ -424,11 +464,6 @@ properties:
- rockchip,rk3288-evb-rk808
- const: rockchip,rk3288
- description: Rockchip RK3288 Fennec
items:
- const: rockchip,rk3288-fennec
- const: rockchip,rk3288
- description: Rockchip RK3328 Evaluation board
items:
- const: rockchip,rk3328-evb
@ -461,12 +496,12 @@ properties:
- description: Theobroma Systems RK3368-uQ7 with Haikou baseboard
items:
- const: tsd,rk3368-uq7-haikou
- const: tsd,rk3368-lion-haikou
- const: rockchip,rk3368
- description: Theobroma Systems RK3399-Q7 with Haikou baseboard
items:
- const: tsd,rk3399-q7-haikou
- const: tsd,rk3399-puma-haikou
- const: rockchip,rk3399
- description: Tronsmart Orion R68 Meta

16
Bindings/arm/sunxi.yaml
View File

@ -353,6 +353,12 @@ properties:
- const: licheepi,licheepi-zero
- const: allwinner,sun8i-v3s
- description: Lichee Zero Plus (with S3, without eMMC/SPI Flash)
items:
- const: sipeed,lichee-zero-plus
- const: sochip,s3
- const: allwinner,sun8i-v3
- description: Linksprite PCDuino
items:
- const: linksprite,a10-pcduino
@ -568,6 +574,11 @@ properties:
- const: olimex,a64-olinuxino
- const: allwinner,sun50i-a64
- description: Olimex A64-OlinuXino (with eMMC)
items:
- const: olimex,a64-olinuxino-emmc
- const: allwinner,sun50i-a64
- description: Olimex A64 Teres-I
items:
- const: olimex,a64-teres-i
@ -671,6 +682,11 @@ properties:
- const: sinlinx,sina33
- const: allwinner,sun8i-a33
- description: Tanix TX6
items:
- const: oranth,tanix-tx6
- const: allwinner,sun50i-h6
- description: TBS A711 Tablet
items:
- const: tbs-biometrics,a711

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

85
Bindings/bus/allwinner,sun50i-a64-de2.yaml Normal file
View File

@ -0,0 +1,85 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/allwinner,sun50i-a64-de2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A64 Display Engine Bus Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
properties:
$nodename:
pattern: "^bus(@[0-9a-f]+)?$"
"#address-cells":
const: 1
"#size-cells":
const: 1
compatible:
oneOf:
- const: allwinner,sun50i-a64-de2
- items:
- const: allwinner,sun50i-h6-de3
- const: allwinner,sun50i-a64-de2
reg:
maxItems: 1
allwinner,sram:
allOf:
- $ref: /schemas/types.yaml#definitions/phandle-array
- maxItems: 1
description:
The SRAM that needs to be claimed to access the display engine
bus.
ranges: true
patternProperties:
# All other properties should be child nodes with unit-address and 'reg'
"^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$":
type: object
properties:
reg:
maxItems: 1
required:
- reg
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
- allwinner,sram
additionalProperties: false
examples:
- |
bus@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 52>, <&ccu 99>;
clock-names = "bus", "mod";
resets = <&ccu 30>;
#clock-cells = <1>;
#reset-cells = <1>;
};
};
...

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/allwinner,sun4i-a10-ccu.yaml
View File

@ -31,6 +31,7 @@ properties:
- allwinner,sun8i-h3-ccu
- allwinner,sun8i-h3-r-ccu
- allwinner,sun8i-r40-ccu
- allwinner,sun8i-v3-ccu
- allwinner,sun8i-v3s-ccu
- allwinner,sun9i-a80-ccu
- allwinner,sun50i-a64-ccu

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

1
Bindings/clock/amlogic,gxbb-clkc.txt
View File

@ -11,6 +11,7 @@ Required Properties:
"amlogic,axg-clkc" for AXG SoC.
"amlogic,g12a-clkc" for G12A SoC.
"amlogic,g12b-clkc" for G12B SoC.
"amlogic,sm1-clkc" for SM1 SoC.
- clocks : list of clock phandle, one for each entry clock-names.
- clock-names : should contain the following:
* "xtal": the platform xtal

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

112
Bindings/clock/imx8mn-clock.yaml Normal file
View File

@ -0,0 +1,112 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/clock/imx8mn-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX8M Nano Clock Control Module Binding
maintainers:
- Anson Huang <Anson.Huang@nxp.com>
description: |
NXP i.MX8M Nano clock control module is an integrated clock controller, which
generates and supplies to all modules.
properties:
compatible:
const: fsl,imx8mn-ccm
reg:
maxItems: 1
clocks:
items:
- description: 32k osc
- description: 24m osc
- description: ext1 clock input
- description: ext2 clock input
- description: ext3 clock input
- description: ext4 clock input
clock-names:
items:
- const: osc_32k
- const: osc_24m
- const: clk_ext1
- const: clk_ext2
- const: clk_ext3
- const: clk_ext4
'#clock-cells':
const: 1
description: |
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mn-clock.h
for the full list of i.MX8M Nano clock IDs.
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
examples:
# Clock Control Module node:
- |
clk: clock-controller@30380000 {
compatible = "fsl,imx8mn-ccm";
reg = <0x0 0x30380000 0x0 0x10000>;
#clock-cells = <1>;
clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
<&clk_ext2>, <&clk_ext3>, <&clk_ext4>;
clock-names = "osc_32k", "osc_24m", "clk_ext1",
"clk_ext2", "clk_ext3", "clk_ext4";
};
# Required external clocks for Clock Control Module node:
- |
osc_32k: clock-osc-32k {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
clock-output-names = "osc_32k";
};
osc_24m: clock-osc-24m {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <24000000>;
clock-output-names = "osc_24m";
};
clk_ext1: clock-ext1 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <133000000>;
clock-output-names = "clk_ext1";
};
clk_ext2: clock-ext2 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <133000000>;
clock-output-names = "clk_ext2";
};
clk_ext3: clock-ext3 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <133000000>;
clock-output-names = "clk_ext3";
};
clk_ext4: clock-ext4 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency= <133000000>;
clock-output-names = "clk_ext4";
};
...

21
Bindings/clock/qcom,gcc.txt
View File

@ -23,6 +23,7 @@ Required properties :
"qcom,gcc-sdm630"
"qcom,gcc-sdm660"
"qcom,gcc-sdm845"
"qcom,gcc-sm8150"
- reg : shall contain base register location and length
- #clock-cells : shall contain 1
@ -38,6 +39,13 @@ Documentation/devicetree/bindings/thermal/qcom-tsens.txt
- protected-clocks : Protected clock specifier list as per common clock
binding.
For SM8150 only:
- clocks: a list of phandles and clock-specifier pairs,
one for each entry in clock-names.
- clock-names: "bi_tcxo" (required)
"sleep_clk" (optional)
"aud_ref_clock" (optional)
Example:
clock-controller@900000 {
compatible = "qcom,gcc-msm8960";
@ -71,3 +79,16 @@ Example of GCC with protected-clocks properties:
<GCC_LPASS_Q6_AXI_CLK>,
<GCC_LPASS_SWAY_CLK>;
};
Example of GCC with clocks
gcc: clock-controller@100000 {
compatible = "qcom,gcc-sm8150";
reg = <0x00100000 0x1f0000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
clock-names = "bi_tcxo",
"sleep_clk";
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&sleep_clk>;
};

7
Bindings/clock/qcom,rpmh-clk.txt
View File

@ -6,9 +6,14 @@ some Qualcomm Technologies Inc. SoCs. It accepts clock requests from
other hardware subsystems via RSC to control clocks.
Required properties :
- compatible : shall contain "qcom,sdm845-rpmh-clk"
- compatible : must be one of:
"qcom,sdm845-rpmh-clk"
"qcom,sm8150-rpmh-clk"
- #clock-cells : must contain 1
- clocks: a list of phandles and clock-specifier pairs,
one for each entry in clock-names.
- clock-names: Parent board clock: "xo".
Example :

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/

79
Bindings/crypto/allwinner,sun4i-a10-crypto.yaml Normal file
View File

@ -0,0 +1,79 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/allwinner,sun4i-a10-crypto.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A10 Security System Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <maxime.ripard@bootlin.com>
properties:
compatible:
oneOf:
- const: allwinner,sun4i-a10-crypto
- items:
- const: allwinner,sun5i-a13-crypto
- const: allwinner,sun4i-a10-crypto
- items:
- const: allwinner,sun6i-a31-crypto
- const: allwinner,sun4i-a10-crypto
- items:
- const: allwinner,sun7i-a20-crypto
- const: allwinner,sun4i-a10-crypto
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: Bus Clock
- description: Module Clock
clock-names:
items:
- const: ahb
- const: mod
resets:
maxItems: 1
reset-names:
const: ahb
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
if:
properties:
compatible:
contains:
const: allwinner,sun6i-a31-crypto
then:
required:
- resets
- reset-names
additionalProperties: false
examples:
- |
crypto: crypto-engine@1c15000 {
compatible = "allwinner,sun4i-a10-crypto";
reg = <0x01c15000 0x1000>;
interrupts = <86>;
clocks = <&ahb_gates 5>, <&ss_clk>;
clock-names = "ahb", "mod";
};
...

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

5
Bindings/display/bridge/sii902x.txt
View File

@ -26,9 +26,8 @@ Optional properties:
- clocks: phandle and clock specifier for each clock listed in
the clock-names property
- clock-names: "mclk"
Describes SII902x MCLK input. MCLK is used to produce
HDMI audio CTS values. This property is required if
"#sound-dai-cells"-property is present. This property follows
Describes SII902x MCLK input. MCLK can be used to produce
HDMI audio CTS values. This property follows
Documentation/devicetree/bindings/clock/clock-bindings.txt
consumer binding.

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

42
Bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml Normal file
View File

@ -0,0 +1,42 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
maintainers:
- Yannick Fertre <yannick.fertre@st.com>
- Thierry Reding <treding@nvidia.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: ampire,am-480272h3tmqw-t01h
power-supply: true
enable-gpios: true
backlight: true
port: true
required:
- compatible
additionalProperties: false
examples:
- |
panel_rgb: panel {
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

33
Bindings/display/panel/armadeus,st0700-adapt.yaml Normal file
View File

@ -0,0 +1,33 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/armadeus,st0700-adapt.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Armadeus ST0700 Adapter
description:
A Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT with an adapter board.
maintainers:
- '"Sébastien Szymanski" <sebastien.szymanski@armadeus.com>'
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: armadeus,st0700-adapt
power-supply: true
backlight: true
port: true
additionalProperties: false
required:
- compatible
- power-supply
...

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.

31
Bindings/display/panel/bananapi,s070wv20-ct16.yaml Normal file
View File

@ -0,0 +1,31 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/bananapi,s070wv20-ct16.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Banana Pi 7" (S070WV20-CT16) TFT LCD Panel
maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: bananapi,s070wv20-ct16
power-supply: true
backlight: true
enable-gpios: true
port: true
additionalProperties: false
required:
- compatible
- power-supply
...

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.

31
Bindings/display/panel/dlc,dlc0700yzg-1.yaml Normal file
View File

@ -0,0 +1,31 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/dlc,dlc0700yzg-1.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: DLC Display Co. DLC0700YZG-1 7.0" WSVGA TFT LCD panel
maintainers:
- Philipp Zabel <p.zabel@pengutronix.de>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: dlc,dlc0700yzg-1
reset-gpios: true
enable-gpios: true
backlight: true
port: true
additionalProperties: false
required:
- compatible
- power-supply
...

2
Bindings/display/panel/edt,et-series.txt
View File

@ -40,7 +40,7 @@ simple-panel.txt
| Identifier | compatbile | description |
+=================+=====================+=====================================+
| ETM0700G0DH6 | edt,etm070080dh6 | WVGA TFT Display with capacitive |
| | | Touchscreen |
| | edt,etm0700g0dh6 | Touchscreen |
+-----------------+---------------------+-------------------------------------+
| ETM0700G0BDH6 | edt,etm070080bdh6 | Same as ETM0700G0DH6 but with |
| | | inverted pixel clock. |

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.

31
Bindings/display/panel/innolux,ee101ia-01d.yaml Normal file
View File

@ -0,0 +1,31 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel
maintainers:
- Heiko Stuebner <heiko.stuebner@bq.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: lvds.yaml#
properties:
compatible:
items:
- const: innolux,ee101ia-01d
- {} # panel-lvds, but not listed here to avoid false select
backlight: true
enable-gpios: true
power-supply: true
width-mm: true
height-mm: true
panel-timing: true
port: true
additionalProperties: false
...

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

107
Bindings/display/panel/lvds.yaml Normal file
View File

@ -0,0 +1,107 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/lvds.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LVDS Display Panel
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
- Thierry Reding <thierry.reding@gmail.com>
description: |+
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.
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
contains:
const: panel-lvds
description:
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.
data-mapping:
enum:
- jeida-18
- jeida-24
- vesa-24
description: |
The color signals mapping order.
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
data-mirror:
type: boolean
description:
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:
- compatible
- data-mapping
- width-mm
- height-mm
- panel-timing
- port
...

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

75
Bindings/display/panel/mitsubishi,aa104xd12.yaml Normal file
View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa104xd12.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mitsubishi AA104XD12 10.4" XGA LVDS Display Panel
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: lvds.yaml#
properties:
compatible:
items:
- const: mitsubishi,aa104xd12
- {} # panel-lvds, but not listed here to avoid false select
vcc-supply:
description: Reference to the regulator powering the panel VCC pins.
data-mapping:
const: jeida-24
width-mm:
const: 210
height-mm:
const: 158
panel-timing: true
port: true
additionalProperties: false
required:
- compatible
- vcc-supply
examples:
- |+
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>;
};
};
};

74
Bindings/display/panel/mitsubishi,aa121td01.yaml Normal file
View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa121td01.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mitsubishi AA121TD01 12.1" WXGA LVDS Display Panel
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: lvds.yaml#
properties:
compatible:
items:
- const: mitsubishi,aa121td01
- {} # panel-lvds, but not listed here to avoid false select
vcc-supply:
description: Reference to the regulator powering the panel VCC pins.
data-mapping:
const: jeida-24
width-mm:
const: 261
height-mm:
const: 163
panel-timing: true
port: true
additionalProperties: false
required:
- compatible
- vcc-supply
examples:
- |+
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>;
};
};
};
...

62
Bindings/display/panel/nec,nl8048hl11.yaml Normal file
View File

@ -0,0 +1,62 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/nec,nl8048hl11.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NEC NL8048HL11 4.1" WVGA TFT LCD panel
description:
The NEC NL8048HL11 is a 4.1" WVGA TFT LCD panel with a 24-bit RGB parallel
data interface and an SPI control interface.
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: nec,nl8048hl11
label: true
port: true
reg: true
reset-gpios: true
spi-max-frequency:
maximum: 10000000
required:
- compatible
- reg
- reset-gpios
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
spi0 {
#address-cells = <1>;
#size-cells = <0>;
lcd_panel: panel@0 {
compatible = "nec,nl8048hl11";
reg = <0>;
spi-max-frequency = <10000000>;
reset-gpios = <&gpio7 7 GPIO_ACTIVE_LOW>;
port {
lcd_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
};
};
...

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.

149
Bindings/display/panel/panel-common.yaml Normal file
View File

@ -0,0 +1,149 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common Properties for Display Panels
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description: |
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.
properties:
# Descriptive Properties
width-mm:
description:
Specifies the width of the physical area where images are displayed. This
property is expressed in millimeters and rounded to the closest unit.
height-mm:
description:
Specifies the height of the physical area where images are displayed. This
property is expressed in millimeters and rounded to the closest unit.
label:
description: |
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.
rotation:
description:
Display rotation in degrees counter clockwise (0,90,180,270)
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 90, 180, 270 ]
# Display Timings
panel-timing:
type: object
description:
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
port:
type: object
ports:
type: object
description:
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:
$ref: /schemas/types.yaml#/definitions/phandle
description:
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.
no-hpd:
type: boolean
description:
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.
# 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:
maxItems: 1
description: |
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:
maxItems: 1
description:
Specifier for a GPIO connected 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:
description:
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:
$ref: /schemas/types.yaml#/definitions/phandle
description:
For panels whose backlight is controlled by an external backlight
controller, this property contains a phandle that references the
controller.
dependencies:
width-mm: [ height-mm ]
height-mm: [ width-mm ]
...

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.

31
Bindings/display/panel/pda,91-00156-a0.yaml Normal file
View File

@ -0,0 +1,31 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/pda,91-00156-a0.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: PDA 91-00156-A0 5.0" WVGA TFT LCD panel
maintainers:
- Cristian Birsan <cristian.birsan@microchip.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: pda,91-00156-a0
power-supply: true
backlight: true
port: true
additionalProperties: false
required:
- compatible
- power-supply
- backlight
...

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

71
Bindings/display/panel/raspberrypi,7inch-touchscreen.yaml Normal file
View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/raspberrypi,7inch-touchscreen.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: The official 7" (800x480) Raspberry Pi touchscreen
maintainers:
- Eric Anholt <eric@anholt.net>
- Thierry Reding <thierry.reding@gmail.com>
description: |+
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.
properties:
compatible:
const: raspberrypi,7inch-touchscreen-panel
reg:
const: 0x45
port: true
required:
- compatible
- reg
- port
additionalProperties: false
examples:
- |+
dsi1: dsi {
#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>;
scl-gpios = <&gpio 28 0>;
sda-gpios = <&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>;
};
};
};

68
Bindings/display/panel/sgd,gktw70sdae4se.yaml Normal file
View File

@ -0,0 +1,68 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/sgd,gktw70sdae4se.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: lvds.yaml#
properties:
compatible:
items:
- const: sgd,gktw70sdae4se
- {} # panel-lvds, but not listed here to avoid false select
data-mapping:
const: jeida-18
width-mm:
const: 153
height-mm:
const: 86
panel-timing: true
port: true
additionalProperties: false
required:
- compatible
examples:
- |+
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.

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