forked from Minki/linux
Merge drm/drm-next into drm-intel-next-queued
We need the rename of reservation_object to dma_resv.
The solution on this merge came from linux-next:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 14 Aug 2019 12:48:39 +1000
Subject: [PATCH] drm: fix up fallout from "dma-buf: rename reservation_object to dma_resv"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/gpu/drm/i915/gt/intel_engine_pool.c | 8 ++++----
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c b/drivers/gpu/drm/i915/gt/intel_engine_pool.c
index 03d90b49584a..4cd54c569911 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.c
@@ -43,12 +43,12 @@ static int pool_active(struct i915_active *ref)
{
struct intel_engine_pool_node *node =
container_of(ref, typeof(*node), active);
- struct reservation_object *resv = node->obj->base.resv;
+ struct dma_resv *resv = node->obj->base.resv;
int err;
- if (reservation_object_trylock(resv)) {
- reservation_object_add_excl_fence(resv, NULL);
- reservation_object_unlock(resv);
+ if (dma_resv_trylock(resv)) {
+ dma_resv_add_excl_fence(resv, NULL);
+ dma_resv_unlock(resv);
}
err = i915_gem_object_pin_pages(node->obj);
which is a simplified version from a previous one which had:
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This commit is contained in:
Rodrigo Vivi
commit
829e8def7b
3
.gitignore
vendored
3
.gitignore
vendored
@ -142,3 +142,6 @@ x509.genkey
|
||||
|
||||
# Kdevelop4
|
||||
*.kdev4
|
||||
|
||||
# Clang's compilation database file
|
||||
/compile_commands.json
|
||||
|
||||
3
.mailmap
3
.mailmap
@ -98,6 +98,7 @@ Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
||||
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
||||
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||
@ -116,6 +117,7 @@ John Stultz <johnstul@us.ibm.com>
|
||||
Juha Yrjola <at solidboot.com>
|
||||
Juha Yrjola <juha.yrjola@nokia.com>
|
||||
Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
Julien Thierry <julien.thierry.kdev@gmail.com> <julien.thierry@arm.com>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
@ -132,6 +134,7 @@ Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
|
||||
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
|
||||
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
|
||||
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
|
||||
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
|
||||
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
|
||||
|
||||
@ -403,7 +403,7 @@ That is, the recovery API only requires that:
|
||||
.. note::
|
||||
|
||||
Implementation details for the powerpc platform are discussed in
|
||||
the file Documentation/powerpc/eeh-pci-error-recovery.txt
|
||||
the file Documentation/powerpc/eeh-pci-error-recovery.rst
|
||||
|
||||
As of this writing, there is a growing list of device drivers with
|
||||
patches implementing error recovery. Not all of these patches are in
|
||||
@ -422,3 +422,6 @@ That is, the recovery API only requires that:
|
||||
- drivers/net/cxgb3
|
||||
- drivers/net/s2io.c
|
||||
- drivers/net/qlge
|
||||
|
||||
The End
|
||||
-------
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Using hlist_nulls to protect read-mostly linked lists and
|
||||
objects using SLAB_TYPESAFE_BY_RCU allocations.
|
||||
|
||||
Please read the basics in Documentation/RCU/listRCU.txt
|
||||
Please read the basics in Documentation/RCU/listRCU.rst
|
||||
|
||||
Using special makers (called 'nulls') is a convenient way
|
||||
to solve following problem :
|
||||
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = 'Linux Kernel User Documentation'
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'linux-user.tex', 'Linux Kernel User Documentation',
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -2545,7 +2545,7 @@
|
||||
mem_encrypt=on: Activate SME
|
||||
mem_encrypt=off: Do not activate SME
|
||||
|
||||
Refer to Documentation/virtual/kvm/amd-memory-encryption.rst
|
||||
Refer to Documentation/virt/kvm/amd-memory-encryption.rst
|
||||
for details on when memory encryption can be activated.
|
||||
|
||||
mem_sleep_default= [SUSPEND] Default system suspend mode:
|
||||
|
||||
@ -53,7 +53,7 @@ disabled, there is ``khugepaged`` daemon that scans memory and
|
||||
collapses sequences of basic pages into huge pages.
|
||||
|
||||
The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
|
||||
interface and using madivse(2) and prctl(2) system calls.
|
||||
interface and using madvise(2) and prctl(2) system calls.
|
||||
|
||||
Transparent Hugepage Support maximizes the usefulness of free memory
|
||||
if compared to the reservation approach of hugetlbfs by allowing all
|
||||
|
||||
@ -16,6 +16,8 @@ import sys
|
||||
import os
|
||||
import sphinx
|
||||
|
||||
from subprocess import check_output
|
||||
|
||||
# Get Sphinx version
|
||||
major, minor, patch = sphinx.version_info[:3]
|
||||
|
||||
@ -276,10 +278,21 @@ latex_elements = {
|
||||
\\setsansfont{DejaVu Sans}
|
||||
\\setromanfont{DejaVu Serif}
|
||||
\\setmonofont{DejaVu Sans Mono}
|
||||
|
||||
'''
|
||||
}
|
||||
|
||||
# At least one book (translations) may have Asian characters
|
||||
# with are only displayed if xeCJK is used
|
||||
|
||||
cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore')
|
||||
if cjk_cmd.find("Noto Sans CJK SC") >= 0:
|
||||
print ("enabling CJK for LaTeX builder")
|
||||
latex_elements['preamble'] += '''
|
||||
% This is needed for translations
|
||||
\\usepackage{xeCJK}
|
||||
\\setCJKmainfont{Noto Sans CJK SC}
|
||||
'''
|
||||
|
||||
# Fix reference escape troubles with Sphinx 1.4.x
|
||||
if major == 1 and minor > 3:
|
||||
latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n'
|
||||
@ -410,6 +423,21 @@ latex_documents = [
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
|
||||
# Add all other index files from Documentation/ subdirectories
|
||||
for fn in os.listdir('.'):
|
||||
doc = os.path.join(fn, "index")
|
||||
if os.path.exists(doc + ".rst"):
|
||||
has = False
|
||||
for l in latex_documents:
|
||||
if l[0] == doc:
|
||||
has = True
|
||||
break
|
||||
if not has:
|
||||
latex_documents.append((doc, fn + '.tex',
|
||||
'Linux %s Documentation' % fn.capitalize(),
|
||||
'The kernel development community',
|
||||
'manual'))
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
# the title page.
|
||||
#latex_logo = None
|
||||
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = "Core-API Documentation"
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'core-api.tex', project,
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = 'Linux Kernel Crypto API'
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'crypto-api.tex', 'Linux Kernel Crypto API manual',
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = "Development tools for the kernel"
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'dev-tools.tex', project,
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -703,4 +703,4 @@ cpus {
|
||||
https://www.devicetree.org/specifications/
|
||||
|
||||
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
|
||||
Documentation/arm64/booting.txt
|
||||
Documentation/arm64/booting.rst
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/shmobile.yaml#
|
||||
$id: http://devicetree.org/schemas/arm/renesas.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/milbeaut.yaml#
|
||||
$id: http://devicetree.org/schemas/arm/socionext/milbeaut.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Milbeaut platforms device tree bindings
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/ti/davinci.yaml#
|
||||
$id: http://devicetree.org/schemas/arm/ti/ti,davinci.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments DaVinci Platforms Device Tree Bindings
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/phy/allwinner,sun4i-a10-ccu.yaml#
|
||||
$id: http://devicetree.org/schemas/clock/allwinner,sun4i-a10-ccu.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Allwinner Clock Control Unit Device Tree Bindings
|
||||
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@ -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
Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
Normal file
137
Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
Normal 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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
@ -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
|
||||
|
||||
...
|
||||
@ -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.
|
||||
@ -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
|
||||
|
||||
...
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
@ -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.
|
||||
@ -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
|
||||
|
||||
...
|
||||
@ -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. |
|
||||
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -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
|
||||
...
|
||||
@ -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
Documentation/devicetree/bindings/display/panel/lvds.yaml
Normal file
107
Documentation/devicetree/bindings/display/panel/lvds.yaml
Normal 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
|
||||
|
||||
...
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -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 ]
|
||||
|
||||
...
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -1,4 +0,0 @@
|
||||
Common display properties
|
||||
-------------------------
|
||||
|
||||
- rotation: Display rotation in degrees counter clockwise (0,90,180,270)
|
||||
@ -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.
|
||||
@ -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
|
||||
|
||||
...
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -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,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 = <®_2v8_p>;
|
||||
iovcc-supply = <®_1v8_p>;
|
||||
};
|
||||
};
|
||||
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -1,28 +1 @@
|
||||
Simple display panel
|
||||
====================
|
||||
|
||||
panel node
|
||||
----------
|
||||
|
||||
Required properties:
|
||||
- power-supply: See panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
|
||||
- enable-gpios: GPIO pin to enable or disable the panel
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
- no-hpd: This panel is supposed to communicate that it's ready via HPD
|
||||
(hot plug detect) signal, but the signal isn't hooked up so we should
|
||||
hardcode the max delay from the panel spec when powering up the panel.
|
||||
|
||||
Example:
|
||||
|
||||
panel: panel {
|
||||
compatible = "cptt,claa101wb01";
|
||||
ddc-i2c-bus = <&panelddc>;
|
||||
|
||||
power-supply = <&vdd_pnl_reg>;
|
||||
enable-gpios = <&gpio 90 0>;
|
||||
|
||||
backlight = <&backlight>;
|
||||
};
|
||||
See panel-common.yaml in this directory.
|
||||
|
||||
@ -1,15 +0,0 @@
|
||||
TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with
|
||||
resistive touch
|
||||
|
||||
The panel is found on TI AM335x-evm.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "tfc,s9700rtwv43tr-01b"
|
||||
- power-supply: See panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- enable-gpios: GPIO pin to enable or disable the panel, if there is one
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
@ -0,0 +1,33 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/tfc,s9700rtwv43tr-01b.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with resistive touch
|
||||
|
||||
maintainers:
|
||||
- Jyri Sarha <jsarha@ti.com>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
description: |+
|
||||
The panel is found on TI AM335x-evm.
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: tfc,s9700rtwv43tr-01b
|
||||
|
||||
enable-gpios: true
|
||||
backlight: true
|
||||
port: true
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- power-supply
|
||||
|
||||
...
|
||||
@ -0,0 +1,36 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/ti,nspire.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments NSPIRE Display Panels
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,nspire-cx-lcd-panel
|
||||
- ti,nspire-classic-lcd-panel
|
||||
port: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
panel {
|
||||
compatible = "ti,nspire-cx-lcd-panel";
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&pads>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@ -1,70 +0,0 @@
|
||||
TPO TPG110 Panel
|
||||
================
|
||||
|
||||
This panel driver is a component that acts as an intermediary
|
||||
between an RGB output and a variety of panels. The panel
|
||||
driver is strapped up in electronics to the desired resolution
|
||||
and other properties, and has a control interface over 3WIRE
|
||||
SPI. By talking to the TPG110 over SPI, the strapped properties
|
||||
can be discovered and the hardware is therefore mostly
|
||||
self-describing.
|
||||
|
||||
+--------+
|
||||
SPI -> | TPO | -> physical display
|
||||
RGB -> | TPG110 |
|
||||
+--------+
|
||||
|
||||
If some electrical strap or alternate resolution is desired,
|
||||
this can be set up by taking software control of the display
|
||||
over the SPI interface. The interface can also adjust
|
||||
for properties of the display such as gamma correction and
|
||||
certain electrical driving levels.
|
||||
|
||||
The TPG110 does not know the physical dimensions of the panel
|
||||
connected, so this needs to be specified in the device tree.
|
||||
|
||||
It requires a GPIO line for control of its reset line.
|
||||
|
||||
The serial protocol has line names that resemble I2C but the
|
||||
protocol is not I2C but 3WIRE SPI.
|
||||
|
||||
Required properties:
|
||||
- compatible : one of:
|
||||
"ste,nomadik-nhk15-display", "tpo,tpg110"
|
||||
"tpo,tpg110"
|
||||
- grestb-gpios : panel reset GPIO
|
||||
- width-mm : see display/panel/panel-common.txt
|
||||
- height-mm : see display/panel/panel-common.txt
|
||||
|
||||
The device needs to be a child of an SPI bus, see
|
||||
spi/spi-bus.txt. The SPI child must set the following
|
||||
properties:
|
||||
- spi-3wire
|
||||
- spi-max-frequency = <3000000>;
|
||||
as these are characteristics of this device.
|
||||
|
||||
The device node can contain one 'port' child node with one child
|
||||
'endpoint' node, according to the bindings defined in
|
||||
media/video-interfaces.txt. This node should describe panel's video bus.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel: display@0 {
|
||||
compatible = "tpo,tpg110";
|
||||
reg = <0>;
|
||||
spi-3wire;
|
||||
/* 320 ns min period ~= 3 MHz */
|
||||
spi-max-frequency = <3000000>;
|
||||
/* Width and height from data sheet */
|
||||
width-mm = <116>;
|
||||
height-mm = <87>;
|
||||
grestb-gpios = <&foo_gpio 5 GPIO_ACTIVE_LOW>;
|
||||
backlight = <&bl>;
|
||||
|
||||
port {
|
||||
nomadik_clcd_panel: endpoint {
|
||||
remote-endpoint = <&foo>;
|
||||
};
|
||||
};
|
||||
};
|
||||
101
Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
Normal file
101
Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
Normal file
@ -0,0 +1,101 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/tpo,tpg110.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: TPO TPG110 Panel
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
|
||||
description: |+
|
||||
This panel driver is a component that acts as an intermediary
|
||||
between an RGB output and a variety of panels. The panel
|
||||
driver is strapped up in electronics to the desired resolution
|
||||
and other properties, and has a control interface over 3WIRE
|
||||
SPI. By talking to the TPG110 over SPI, the strapped properties
|
||||
can be discovered and the hardware is therefore mostly
|
||||
self-describing.
|
||||
|
||||
+--------+
|
||||
SPI -> | TPO | -> physical display
|
||||
RGB -> | TPG110 |
|
||||
+--------+
|
||||
|
||||
If some electrical strap or alternate resolution is desired,
|
||||
this can be set up by taking software control of the display
|
||||
over the SPI interface. The interface can also adjust
|
||||
for properties of the display such as gamma correction and
|
||||
certain electrical driving levels.
|
||||
|
||||
The TPG110 does not know the physical dimensions of the panel
|
||||
connected, so this needs to be specified in the device tree.
|
||||
|
||||
It requires a GPIO line for control of its reset line.
|
||||
|
||||
The serial protocol has line names that resemble I2C but the
|
||||
protocol is not I2C but 3WIRE SPI.
|
||||
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- ste,nomadik-nhk15-display
|
||||
- const: tpo,tpg110
|
||||
- const: tpo,tpg110
|
||||
|
||||
reg: true
|
||||
|
||||
grestb-gpios:
|
||||
maxItems: 1
|
||||
description: panel reset GPIO
|
||||
|
||||
spi-3wire: true
|
||||
|
||||
spi-max-frequency:
|
||||
const: 3000000
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- grestb-gpios
|
||||
- width-mm
|
||||
- height-mm
|
||||
- spi-3wire
|
||||
- spi-max-frequency
|
||||
- port
|
||||
|
||||
examples:
|
||||
- |+
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel: display@0 {
|
||||
compatible = "tpo,tpg110";
|
||||
reg = <0>;
|
||||
spi-3wire;
|
||||
/* 320 ns min period ~= 3 MHz */
|
||||
spi-max-frequency = <3000000>;
|
||||
/* Width and height from data sheet */
|
||||
width-mm = <116>;
|
||||
height-mm = <87>;
|
||||
grestb-gpios = <&foo_gpio 5 1>;
|
||||
backlight = <&bl>;
|
||||
|
||||
port {
|
||||
nomadik_clcd_panel: endpoint {
|
||||
remote-endpoint = <&foo>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -32,17 +32,6 @@ Their connections are modeled using the OF graph bindings specified in
|
||||
- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
|
||||
- video port 1 for either a panel or subsequent encoder
|
||||
|
||||
the lvds panel described by
|
||||
Documentation/devicetree/bindings/display/panel/simple-panel.txt
|
||||
|
||||
Panel required properties:
|
||||
- ports for remote LVDS output
|
||||
|
||||
Panel optional properties:
|
||||
- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
|
||||
This describes decribed by:
|
||||
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
|
||||
|
||||
Example:
|
||||
|
||||
lvds_panel: lvds-panel {
|
||||
|
||||
@ -27,6 +27,15 @@ Optional properties:
|
||||
- solomon,prechargep2: Length of precharge period (phase 2) in clock cycles.
|
||||
This needs to be the higher, the higher the capacitance
|
||||
of the OLED's pixels is
|
||||
- solomon,dclk-div: Clock divisor 1 to 16
|
||||
- solomon,dclk-frq: Clock frequency 0 to 15, higher value means higher
|
||||
frequency
|
||||
- solomon,lookup-table: 8 bit value array of current drive pulse widths for
|
||||
BANK0, and colors A, B, and C. Each value in range
|
||||
of 31 to 63 for pulse widths of 32 to 64. Color D
|
||||
is always width 64.
|
||||
- solomon,area-color-enable: Display uses color mode
|
||||
- solomon,low-power. Display runs in low power mode
|
||||
|
||||
[0]: Documentation/devicetree/bindings/pwm/pwm.txt
|
||||
|
||||
@ -46,4 +55,5 @@ ssd1306: oled@3c {
|
||||
solomon,com-lrremap;
|
||||
solomon,com-invdir;
|
||||
solomon,com-offset = <32>;
|
||||
solomon,lookup-table = /bits/ 8 <0x3f 0x3f 0x3f 0x3f>;
|
||||
};
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
# Copyright 2019 Linaro Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/firmware/intel-ixp4xx-network-processing-engine.yaml#"
|
||||
$id: "http://devicetree.org/schemas/firmware/intel,ixp4xx-network-processing-engine.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Intel IXP4xx Network Processing Engine
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/accelerometers/adi,adxl345.yaml#
|
||||
$id: http://devicetree.org/schemas/iio/accel/adi,adxl345.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/accelerometers/adi,adxl372.yaml#
|
||||
$id: http://devicetree.org/schemas/iio/accel/adi,adxl372.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
|
||||
|
||||
@ -5,21 +5,19 @@ Required properties:
|
||||
- compatible: should be "amazon,al-fic"
|
||||
- reg: physical base address and size of the registers
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
- #interrupt-cells: must be 2.
|
||||
First cell defines the index of the interrupt within the controller.
|
||||
Second cell is used to specify the trigger type and must be one of the
|
||||
following:
|
||||
- bits[3:0] trigger type and level flags
|
||||
1 = low-to-high edge triggered
|
||||
4 = active high level-sensitive
|
||||
- interrupt-parent: specifies the parent interrupt controller.
|
||||
- #interrupt-cells : must be 2. Specifies the number of cells needed to encode
|
||||
an interrupt source. Supported trigger types are low-to-high edge
|
||||
triggered and active high level-sensitive.
|
||||
- interrupts: describes which input line in the interrupt parent, this
|
||||
fic's output is connected to. This field property depends on the parent's
|
||||
binding
|
||||
|
||||
Please refer to interrupts.txt in this directory for details of the common
|
||||
Interrupt Controllers bindings used by client devices.
|
||||
|
||||
Example:
|
||||
|
||||
amazon_fic: interrupt-controller@0xfd8a8500 {
|
||||
amazon_fic: interrupt-controller@fd8a8500 {
|
||||
compatible = "amazon,al-fic";
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
# Copyright 2018 Linaro Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/interrupt/intel-ixp4xx-interrupt.yaml#"
|
||||
$id: "http://devicetree.org/schemas/interrupt-controller/intel,ixp4xx-interrupt.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Intel IXP4xx XScale Networking Processors Interrupt Controller
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
# Copyright 2019 Linaro Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/misc/intel-ixp4xx-ahb-queue-manager.yaml#"
|
||||
$id: "http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Intel IXP4xx AHB Queue Manager
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/allwinner,sun8i-a83t-gmac.yaml#
|
||||
$id: http://devicetree.org/schemas/net/allwinner,sun8i-a83t-emac.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Allwinner A83t EMAC Device Tree Bindings
|
||||
|
||||
@ -37,13 +37,13 @@ required:
|
||||
|
||||
examples:
|
||||
- |
|
||||
sid@1c23800 {
|
||||
efuse@1c23800 {
|
||||
compatible = "allwinner,sun4i-a10-sid";
|
||||
reg = <0x01c23800 0x10>;
|
||||
};
|
||||
|
||||
- |
|
||||
sid@1c23800 {
|
||||
efuse@1c23800 {
|
||||
compatible = "allwinner,sun7i-a20-sid";
|
||||
reg = <0x01c23800 0x200>;
|
||||
};
|
||||
|
||||
45
Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
Normal file
45
Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
Normal file
@ -0,0 +1,45 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/nvmem/nvmem-consumer.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVMEM (Non Volatile Memory) Consumer Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
|
||||
select: true
|
||||
|
||||
properties:
|
||||
nvmem:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
List of phandle to the nvmem providers.
|
||||
|
||||
nvmem-cells:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
List of phandle to the nvmem data cells.
|
||||
|
||||
nvmem-names:
|
||||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
description:
|
||||
Names for the each nvmem provider.
|
||||
|
||||
nvmem-cell-names:
|
||||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
description:
|
||||
Names for each nvmem-cells specified.
|
||||
|
||||
dependencies:
|
||||
nvmem-names: [ nvmem ]
|
||||
nvmem-cell-names: [ nvmem-cells ]
|
||||
|
||||
examples:
|
||||
- |
|
||||
tsens {
|
||||
/* ... */
|
||||
nvmem-cells = <&tsens_calibration>;
|
||||
nvmem-cell-names = "calibration";
|
||||
};
|
||||
@ -1,80 +1 @@
|
||||
= NVMEM(Non Volatile Memory) Data Device Tree Bindings =
|
||||
|
||||
This binding is intended to represent the location of hardware
|
||||
configuration data stored in NVMEMs like eeprom, efuses and so on.
|
||||
|
||||
On a significant proportion of boards, the manufacturer has stored
|
||||
some data on NVMEM, for the OS to be able to retrieve these information
|
||||
and act upon it. Obviously, the OS has to know about where to retrieve
|
||||
these data from, and where they are stored on the storage device.
|
||||
|
||||
This document is here to document this.
|
||||
|
||||
= Data providers =
|
||||
Contains bindings specific to provider drivers and data cells as children
|
||||
of this node.
|
||||
|
||||
Optional properties:
|
||||
read-only: Mark the provider as read only.
|
||||
|
||||
= Data cells =
|
||||
These are the child nodes of the provider which contain data cell
|
||||
information like offset and size in nvmem provider.
|
||||
|
||||
Required properties:
|
||||
reg: specifies the offset in byte within the storage device.
|
||||
|
||||
Optional properties:
|
||||
|
||||
bits: Is pair of bit location and number of bits, which specifies offset
|
||||
in bit and number of bits within the address range specified by reg property.
|
||||
Offset takes values from 0-7.
|
||||
|
||||
For example:
|
||||
|
||||
/* Provider */
|
||||
qfprom: qfprom@700000 {
|
||||
...
|
||||
|
||||
/* Data cells */
|
||||
tsens_calibration: calib@404 {
|
||||
reg = <0x404 0x10>;
|
||||
};
|
||||
|
||||
tsens_calibration_bckp: calib_bckp@504 {
|
||||
reg = <0x504 0x11>;
|
||||
bits = <6 128>
|
||||
};
|
||||
|
||||
pvs_version: pvs-version@6 {
|
||||
reg = <0x6 0x2>
|
||||
bits = <7 2>
|
||||
};
|
||||
|
||||
speed_bin: speed-bin@c{
|
||||
reg = <0xc 0x1>;
|
||||
bits = <2 3>;
|
||||
|
||||
};
|
||||
...
|
||||
};
|
||||
|
||||
= Data consumers =
|
||||
Are device nodes which consume nvmem data cells/providers.
|
||||
|
||||
Required-properties:
|
||||
nvmem-cells: list of phandle to the nvmem data cells.
|
||||
nvmem-cell-names: names for the each nvmem-cells specified. Required if
|
||||
nvmem-cells is used.
|
||||
|
||||
Optional-properties:
|
||||
nvmem : list of phandles to nvmem providers.
|
||||
nvmem-names: names for the each nvmem provider. required if nvmem is used.
|
||||
|
||||
For example:
|
||||
|
||||
tsens {
|
||||
...
|
||||
nvmem-cells = <&tsens_calibration>;
|
||||
nvmem-cell-names = "calibration";
|
||||
};
|
||||
This file has been moved to nvmem.yaml and nvmem-consumer.yaml.
|
||||
|
||||
93
Documentation/devicetree/bindings/nvmem/nvmem.yaml
Normal file
93
Documentation/devicetree/bindings/nvmem/nvmem.yaml
Normal file
@ -0,0 +1,93 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/nvmem/nvmem.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVMEM (Non Volatile Memory) Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
|
||||
description: |
|
||||
This binding is intended to represent the location of hardware
|
||||
configuration data stored in NVMEMs like eeprom, efuses and so on.
|
||||
|
||||
On a significant proportion of boards, the manufacturer has stored
|
||||
some data on NVMEM, for the OS to be able to retrieve these
|
||||
information and act upon it. Obviously, the OS has to know about
|
||||
where to retrieve these data from, and where they are stored on the
|
||||
storage device.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^(eeprom|efuse|nvram)(@.*|-[0-9a-f])*$"
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
read-only:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Mark the provider as read only.
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-9a-f]+$":
|
||||
type: object
|
||||
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
description:
|
||||
Offset and size in bytes within the storage device.
|
||||
|
||||
bits:
|
||||
maxItems: 1
|
||||
items:
|
||||
items:
|
||||
- minimum: 0
|
||||
maximum: 7
|
||||
description:
|
||||
Offset in bit within the address range specified by reg.
|
||||
- minimum: 1
|
||||
description:
|
||||
Size in bit within the address range specified by reg.
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
qfprom: eeprom@700000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
/* ... */
|
||||
|
||||
/* Data cells */
|
||||
tsens_calibration: calib@404 {
|
||||
reg = <0x404 0x10>;
|
||||
};
|
||||
|
||||
tsens_calibration_bckp: calib_bckp@504 {
|
||||
reg = <0x504 0x11>;
|
||||
bits = <6 128>;
|
||||
};
|
||||
|
||||
pvs_version: pvs-version@6 {
|
||||
reg = <0x6 0x2>;
|
||||
bits = <7 2>;
|
||||
};
|
||||
|
||||
speed_bin: speed-bin@c{
|
||||
reg = <0xc 0x1>;
|
||||
bits = <2 3>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/allwinner,sun6i-a31-mipi-dphy.yaml#
|
||||
$id: http://devicetree.org/schemas/phy/allwinner,sun6i-a31-mipi-dphy.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Allwinner A31 MIPI D-PHY Controller Device Tree Bindings
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
# Copyright 2018 Linaro Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/timer/intel-ixp4xx-timer.yaml#"
|
||||
$id: "http://devicetree.org/schemas/timer/intel,ixp4xx-timer.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Intel IXP4xx XScale Networking Processors Timers
|
||||
|
||||
@ -64,10 +64,8 @@ Optional properties :
|
||||
- power-on-time-ms : Specifies the time it takes from the time the host
|
||||
initiates the power-on sequence to a port until the port has adequate
|
||||
power. The value is given in ms in a 0 - 510 range (default is 100ms).
|
||||
- swap-dx-lanes : Specifies the downstream ports which will swap the
|
||||
differential-pair (D+/D-), default is not-swapped.
|
||||
- swap-us-lanes : Selects the upstream port differential-pair (D+/D-)
|
||||
swapping (boolean, default is not-swapped)
|
||||
- swap-dx-lanes : Specifies the ports which will swap the differential-pair
|
||||
(D+/D-), default is not-swapped.
|
||||
|
||||
Examples:
|
||||
usb2512b@2c {
|
||||
|
||||
@ -511,6 +511,8 @@ patternProperties:
|
||||
description: Lenovo Group Ltd.
|
||||
"^lg,.*":
|
||||
description: LG Corporation
|
||||
"^lgphilips,.*":
|
||||
description: LG Display
|
||||
"^libretech,.*":
|
||||
description: Shenzhen Libre Technology Co., Ltd
|
||||
"^licheepi,.*":
|
||||
@ -933,6 +935,9 @@ patternProperties:
|
||||
description: Tecon Microprocessor Technologies, LLC.
|
||||
"^topeet,.*":
|
||||
description: Topeet
|
||||
"^toppoly,.*":
|
||||
description: TPO (deprecated, use tpo)
|
||||
deprecated: true
|
||||
"^toradex,.*":
|
||||
description: Toradex AG
|
||||
"^toshiba,.*":
|
||||
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = 'Linux Kernel Documentation Guide'
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'kernel-doc-guide.tex', 'Linux Kernel Documentation Guide',
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = "Linux 802.11 Driver Developer's Guide"
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', '80211.tex', project,
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = "The Linux driver implementer's API guide"
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'driver-api.tex', project,
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -233,7 +233,7 @@ Userspace Interface
|
||||
Several sysfs attributes are generated by the Generic Counter interface,
|
||||
and reside under the /sys/bus/counter/devices/counterX directory, where
|
||||
counterX refers to the respective counter device. Please see
|
||||
Documentation/ABI/testing/sys-bus-counter-generic-sysfs for detailed
|
||||
Documentation/ABI/testing/sysfs-bus-counter for detailed
|
||||
information on each Generic Counter interface sysfs attribute.
|
||||
|
||||
Through these sysfs attributes, programs and scripts may interact with
|
||||
@ -325,7 +325,7 @@ sysfs attributes, where Y is the unique ID of the respective Count:
|
||||
|
||||
For a more detailed breakdown of the available Generic Counter interface
|
||||
sysfs attributes, please refer to the
|
||||
Documentation/ABI/testing/sys-bus-counter file.
|
||||
Documentation/ABI/testing/sysfs-bus-counter file.
|
||||
|
||||
The Signals and Counts associated with the Counter device are registered
|
||||
to the system as well by the counter_register function. The
|
||||
|
||||
@ -179,8 +179,8 @@ PHY Mappings
|
||||
|
||||
In order to get reference to a PHY without help from DeviceTree, the framework
|
||||
offers lookups which can be compared to clkdev that allow clk structures to be
|
||||
bound to devices. A lookup can be made be made during runtime when a handle to
|
||||
the struct phy already exists.
|
||||
bound to devices. A lookup can be made during runtime when a handle to the
|
||||
struct phy already exists.
|
||||
|
||||
The framework offers the following API for registering and unregistering the
|
||||
lookups::
|
||||
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = "Device Power Management"
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'pm.tex', project,
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = "Linux Filesystems API"
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'filesystems.tex', project,
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -1,10 +0,0 @@
|
||||
# -*- coding: utf-8; mode: python -*-
|
||||
|
||||
project = "Linux GPU Driver Developer's Guide"
|
||||
|
||||
tags.add("subproject")
|
||||
|
||||
latex_documents = [
|
||||
('index', 'gpu.tex', project,
|
||||
'The kernel development community', 'manual'),
|
||||
]
|
||||
@ -11,7 +11,6 @@ GPU Driver Documentation
|
||||
meson
|
||||
pl111
|
||||
tegra
|
||||
tinydrm
|
||||
tve200
|
||||
v3d
|
||||
vc4
|
||||
|
||||
@ -263,6 +263,18 @@ the MST topology helpers easier to understand
|
||||
drm_dp_mst_topology_put_port
|
||||
drm_dp_mst_get_mstb_malloc drm_dp_mst_put_mstb_malloc
|
||||
|
||||
MIPI DBI Helper Functions Reference
|
||||
===================================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mipi_dbi.c
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: include/drm/drm_mipi_dbi.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mipi_dbi.c
|
||||
:export:
|
||||
|
||||
MIPI DSI Helper Functions Reference
|
||||
===================================
|
||||
|
||||
|
||||
@ -433,43 +433,11 @@ PRIME is the cross device buffer sharing framework in drm, originally
|
||||
created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME
|
||||
buffers are dma-buf based file descriptors.
|
||||
|
||||
Overview and Driver Interface
|
||||
-----------------------------
|
||||
Overview and Lifetime Rules
|
||||
---------------------------
|
||||
|
||||
Similar to GEM global names, PRIME file descriptors are also used to
|
||||
share buffer objects across processes. They offer additional security:
|
||||
as file descriptors must be explicitly sent over UNIX domain sockets to
|
||||
be shared between applications, they can't be guessed like the globally
|
||||
unique GEM names.
|
||||
|
||||
Drivers that support the PRIME API must set the DRIVER_PRIME bit in the
|
||||
struct :c:type:`struct drm_driver <drm_driver>`
|
||||
driver_features field, and implement the prime_handle_to_fd and
|
||||
prime_fd_to_handle operations.
|
||||
|
||||
int (\*prime_handle_to_fd)(struct drm_device \*dev, struct drm_file
|
||||
\*file_priv, uint32_t handle, uint32_t flags, int \*prime_fd); int
|
||||
(\*prime_fd_to_handle)(struct drm_device \*dev, struct drm_file
|
||||
\*file_priv, int prime_fd, uint32_t \*handle); Those two operations
|
||||
convert a handle to a PRIME file descriptor and vice versa. Drivers must
|
||||
use the kernel dma-buf buffer sharing framework to manage the PRIME file
|
||||
descriptors. Similar to the mode setting API PRIME is agnostic to the
|
||||
underlying buffer object manager, as long as handles are 32bit unsigned
|
||||
integers.
|
||||
|
||||
While non-GEM drivers must implement the operations themselves, GEM
|
||||
drivers must use the :c:func:`drm_gem_prime_handle_to_fd()` and
|
||||
:c:func:`drm_gem_prime_fd_to_handle()` helper functions. Those
|
||||
helpers rely on the driver gem_prime_export and gem_prime_import
|
||||
operations to create a dma-buf instance from a GEM object (dma-buf
|
||||
exporter role) and to create a GEM object from a dma-buf instance
|
||||
(dma-buf importer role).
|
||||
|
||||
struct dma_buf \* (\*gem_prime_export)(struct drm_device \*dev,
|
||||
struct drm_gem_object \*obj, int flags); struct drm_gem_object \*
|
||||
(\*gem_prime_import)(struct drm_device \*dev, struct dma_buf
|
||||
\*dma_buf); These two operations are mandatory for GEM drivers that
|
||||
support PRIME.
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_prime.c
|
||||
:doc: overview and lifetime rules
|
||||
|
||||
PRIME Helper Functions
|
||||
----------------------
|
||||
|
||||
@ -51,6 +51,22 @@ and "FIXME" where the interface could be cleaned up.
|
||||
|
||||
Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`.
|
||||
|
||||
Documentation Requirements for kAPI
|
||||
-----------------------------------
|
||||
|
||||
All kernel APIs exported to other modules must be documented, including their
|
||||
datastructures and at least a short introductory section explaining the overall
|
||||
concepts. Documentation should be put into the code itself as kerneldoc comments
|
||||
as much as reasonable.
|
||||
|
||||
Do not blindly document everything, but document only what's relevant for driver
|
||||
authors: Internal functions of drm.ko and definitely static functions should not
|
||||
have formal kerneldoc comments. Use normal C comments if you feel like a comment
|
||||
is warranted. You may use kerneldoc syntax in the comment, but it shall not
|
||||
start with a /** kerneldoc marker. Similar for data structures, annotate
|
||||
anything entirely private with ``/* private: */`` comments as per the
|
||||
documentation guide.
|
||||
|
||||
Getting Started
|
||||
===============
|
||||
|
||||
|
||||
@ -1,30 +0,0 @@
|
||||
============================
|
||||
drm/tinydrm Tiny DRM drivers
|
||||
============================
|
||||
|
||||
tinydrm is a collection of DRM drivers that are so small they can fit in a
|
||||
single source file.
|
||||
|
||||
Helpers
|
||||
=======
|
||||
|
||||
.. kernel-doc:: include/drm/tinydrm/tinydrm-helpers.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
|
||||
:export:
|
||||
|
||||
MIPI DBI Compatible Controllers
|
||||
===============================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: include/drm/tinydrm/mipi-dbi.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c
|
||||
:export:
|
||||
@ -162,7 +162,7 @@ Clean up mmap forwarding
|
||||
|
||||
A lot of drivers forward gem mmap calls to dma-buf mmap for imported buffers.
|
||||
And also a lot of them forward dma-buf mmap to the gem mmap implementations.
|
||||
Would be great to refactor this all into a set of small common helpers.
|
||||
There's drm_gem_prime_mmap() for this now, but still needs to be rolled out.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
@ -196,15 +196,6 @@ Might be good to also have some igt testcases for this.
|
||||
|
||||
Contact: Daniel Vetter, Noralf Tronnes
|
||||
|
||||
Remove the ->gem_prime_res_obj callback
|
||||
--------------------------------------------
|
||||
|
||||
The ->gem_prime_res_obj callback can be removed from drivers by using the
|
||||
reservation_object in the drm_gem_object. It may also be possible to use the
|
||||
generic drm_gem_reservation_object_wait helper for waiting for a bo.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
idr_init_base()
|
||||
---------------
|
||||
|
||||
@ -215,22 +206,13 @@ efficient.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Defaults for .gem_prime_import and export
|
||||
-----------------------------------------
|
||||
|
||||
Most drivers don't need to set drm_driver->gem_prime_import and
|
||||
->gem_prime_export now that drm_gem_prime_import() and drm_gem_prime_export()
|
||||
are the default.
|
||||
|
||||
struct drm_gem_object_funcs
|
||||
---------------------------
|
||||
|
||||
GEM objects can now have a function table instead of having the callbacks on the
|
||||
DRM driver struct. This is now the preferred way and drivers can be moved over.
|
||||
|
||||
DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support this, but
|
||||
DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligned with the previous
|
||||
two. We also need a 2nd version of the CMA define that doesn't require the
|
||||
We also need a 2nd version of the CMA define that doesn't require the
|
||||
vmapping to be present (different hook for prime importing). Plus this needs to
|
||||
be rolled out to all drivers using their own implementations, too.
|
||||
|
||||
@ -317,19 +299,6 @@ In the end no .c file should need to include ``drmP.h`` anymore.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Add missing kerneldoc for exported functions
|
||||
--------------------------------------------
|
||||
|
||||
The DRM reference documentation is still lacking kerneldoc in a few areas. The
|
||||
task would be to clean up interfaces like moving functions around between
|
||||
files to better group them and improving the interfaces like dropping return
|
||||
values for functions that never fail. Then write kerneldoc for all exported
|
||||
functions and an overview section and integrate it all into the drm book.
|
||||
|
||||
See https://dri.freedesktop.org/docs/drm/ for what's there already.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Make panic handling work
|
||||
------------------------
|
||||
|
||||
@ -393,6 +362,9 @@ There's a bunch of issues with it:
|
||||
this (together with the drm_minor->drm_device move) would allow us to remove
|
||||
debugfs_init.
|
||||
|
||||
- Drop the return code and error checking from all debugfs functions. Greg KH is
|
||||
working on this already.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
KMS cleanups
|
||||
@ -440,39 +412,22 @@ fit the available time.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Backlight Refactoring
|
||||
---------------------
|
||||
|
||||
Backlight drivers have a triple enable/disable state, which is a bit overkill.
|
||||
Plan to fix this:
|
||||
|
||||
1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This
|
||||
has started already.
|
||||
2. In all, only look at one of the three status bits set by the above helpers.
|
||||
3. Remove the other two status bits.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Driver Specific
|
||||
===============
|
||||
|
||||
tinydrm
|
||||
-------
|
||||
|
||||
Tinydrm is the helper driver for really simple fb drivers. The goal is to make
|
||||
those drivers as simple as possible, so lots of room for refactoring:
|
||||
|
||||
- backlight helpers, probably best to put them into a new drm_backlight.c.
|
||||
This is because drivers/video is de-facto unmaintained. We could also
|
||||
move drivers/video/backlight to drivers/gpu/backlight and take it all
|
||||
over within drm-misc, but that's more work. Backlight helpers require a fair
|
||||
bit of reworking and refactoring. A simple example is the enabling of a backlight.
|
||||
Tinydrm has helpers for this. It would be good if other drivers can also use the
|
||||
helper. However, there are various cases we need to consider i.e different
|
||||
drivers seem to have different ways of enabling/disabling a backlight.
|
||||
We also need to consider the backlight drivers (like gpio_backlight). The situation
|
||||
is further complicated by the fact that the backlight is tied to fbdev
|
||||
via fb_notifier_callback() which has complicated logic. For further details, refer
|
||||
to the following discussion thread:
|
||||
https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA
|
||||
|
||||
- spi helpers, probably best put into spi core/helper code. Thierry said
|
||||
the spi maintainer is fast&reactive, so shouldn't be a big issue.
|
||||
|
||||
- extract the mipi-dbi helper (well, the non-tinydrm specific parts at
|
||||
least) into a separate helper, like we have for mipi-dsi already. Or follow
|
||||
one of the ideas for having a shared dsi/dbi helper, abstracting away the
|
||||
transport details more.
|
||||
|
||||
Contact: Noralf Trønnes, Daniel Vetter
|
||||
|
||||
AMD DC Display Driver
|
||||
---------------------
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ Supported chips:
|
||||
|
||||
Addresses scanned: PCI space
|
||||
|
||||
Datasheet: http://support.amd.com/us/Processor_TechDocs/32559.pdf
|
||||
Datasheet: http://www.amd.com/system/files/TechDocs/32559.pdf
|
||||
|
||||
Author: Rudolf Marek
|
||||
|
||||
|
||||
@ -111,9 +111,11 @@ needed).
|
||||
netlabel/index
|
||||
networking/index
|
||||
pcmcia/index
|
||||
power/index
|
||||
target/index
|
||||
timers/index
|
||||
watchdog/index
|
||||
virtual/index
|
||||
input/index
|
||||
hwmon/index
|
||||
gpu/index
|
||||
@ -143,6 +145,7 @@ implementation.
|
||||
arm64/index
|
||||
ia64/index
|
||||
m68k/index
|
||||
powerpc/index
|
||||
riscv/index
|
||||
s390/index
|
||||
sh/index
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user