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 2019-08-21 22:47:35 -07:00
commit 829e8def7b
1747 changed files with 143350 additions and 23205 deletions

3
.gitignore vendored
View File

@ -142,3 +142,6 @@ x509.genkey
# Kdevelop4
*.kdev4
# Clang's compilation database file
/compile_commands.json

View File

@ -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>

View File

@ -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
-------

View File

@ -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 :

View File

@ -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'),
]

View File

@ -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:

View File

@ -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

View File

@ -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

View File

@ -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'),
]

View File

@ -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'),
]

View File

@ -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'),
]

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,137 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2019 BayLibre, SAS
%YAML 1.2
---
$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Amlogic Meson Display Controller
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
description: |
The Amlogic Meson Display controller is composed of several components
that are going to be documented below
DMC|---------------VPU (Video Processing Unit)----------------|------HHI------|
| vd1 _______ _____________ _________________ | |
D |-------| |----| | | | | HDMI PLL |
D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK |
R |-------| |----| Processing | | | | |
| osd2 | | | |---| Enci ----------|----|-----VDAC------|
R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----|
A | osd1 | | | Blenders | | Encl ----------|----|---------------|
M |-------|______|----|____________| |________________| | |
___|__________________________________________________________|_______________|
VIU: Video Input Unit
---------------------
The Video Input Unit is in charge of the pixel scanout from the DDR memory.
It fetches the frames addresses, stride and parameters from the "Canvas" memory.
This part is also in charge of the CSC (Colorspace Conversion).
It can handle 2 OSD Planes and 2 Video Planes.
VPP: Video Post Processing
--------------------------
The Video Post Processing is in charge of the scaling and blending of the
various planes into a single pixel stream.
There is a special "pre-blending" used by the video planes with a dedicated
scaler and a "post-blending" to merge with the OSD Planes.
The OSD planes also have a dedicated scaler for one of the OSD.
VENC: Video Encoders
--------------------
The VENC is composed of the multiple pixel encoders
- ENCI : Interlace Video encoder for CVBS and Interlace HDMI
- ENCP : Progressive Video Encoder for HDMI
- ENCL : LCD LVDS Encoder
The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock
tree and provides the scanout clock to the VPP and VIU.
The ENCI is connected to a single VDAC for Composite Output.
The ENCI and ENCP are connected to an on-chip HDMI Transceiver.
properties:
compatible:
oneOf:
- items:
- enum:
- amlogic,meson-gxbb-vpu # GXBB (S905)
- amlogic,meson-gxl-vpu # GXL (S905X, S905D)
- amlogic,meson-gxm-vpu # GXM (S912)
- const: amlogic,meson-gx-vpu
- enum:
- amlogic,meson-g12a-vpu # G12A (S905X2, S905Y2, S905D2)
reg:
maxItems: 2
reg-names:
items:
- const: vpu
- const: hhi
interrupts:
maxItems: 1
power-domains:
maxItems: 1
description: phandle to the associated power domain
port@0:
type: object
description:
A port node pointing to the CVBS VDAC port node.
port@1:
type: object
description:
A port node pointing to the HDMI-TX port node.
"#address-cells":
const: 1
"#size-cells":
const: 0
required:
- compatible
- reg
- interrupts
- port@0
- port@1
- "#address-cells"
- "#size-cells"
examples:
- |
vpu: vpu@d0100000 {
compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
reg = <0xd0100000 0x100000>, <0xc883c000 0x1000>;
reg-names = "vpu", "hhi";
interrupts = <3>;
#address-cells = <1>;
#size-cells = <0>;
/* CVBS VDAC output port */
port@0 {
reg = <0>;
cvbs_vdac_out: endpoint {
remote-endpoint = <&tv_connector_in>;
};
};
/* HDMI TX output port */
port@1 {
reg = <1>;
hdmi_tx_out: endpoint {
remote-endpoint = <&hdmi_tx_in>;
};
};
};

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,107 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/lvds.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LVDS Display Panel
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
- Thierry Reding <thierry.reding@gmail.com>
description: |+
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
incompatible data link layers have been used over time to transmit image data
to LVDS panels. This bindings supports display panels compatible with the
following specifications.
[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
Semiconductor
[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
Electronics Standards Association (VESA)
Device compatible with those specifications have been marketed under the
FPD-Link and FlatLink brands.
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
contains:
const: panel-lvds
description:
Shall contain "panel-lvds" in addition to a mandatory panel-specific
compatible string defined in individual panel bindings. The "panel-lvds"
value shall never be used on its own.
data-mapping:
enum:
- jeida-18
- jeida-24
- vesa-24
description: |
The color signals mapping order.
LVDS data mappings are defined as follows.
- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
[VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
specifications. Data are transferred as follows on 4 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
Data are transferred as follows on 4 LVDS lanes.
Slot 0 1 2 3 4 5 6
________________ _________________
Clock \_______________________/
______ ______ ______ ______ ______ ______ ______
DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
Control signals are mapped as follows.
CTL0: HSync
CTL1: VSync
CTL2: Data Enable
CTL3: 0
data-mirror:
type: boolean
description:
If set, reverse the bit order described in the data mappings below on all
data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6.
required:
- compatible
- data-mapping
- width-mm
- height-mm
- panel-timing
- port
...

View File

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

View File

@ -0,0 +1,75 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa104xd12.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mitsubishi AA104XD12 10.4" XGA LVDS Display Panel
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: lvds.yaml#
properties:
compatible:
items:
- const: mitsubishi,aa104xd12
- {} # panel-lvds, but not listed here to avoid false select
vcc-supply:
description: Reference to the regulator powering the panel VCC pins.
data-mapping:
const: jeida-24
width-mm:
const: 210
height-mm:
const: 158
panel-timing: true
port: true
additionalProperties: false
required:
- compatible
- vcc-supply
examples:
- |+
panel {
compatible = "mitsubishi,aa104xd12", "panel-lvds";
vcc-supply = <&vcc_3v3>;
width-mm = <210>;
height-mm = <158>;
data-mapping = "jeida-24";
panel-timing {
/* 1024x768 @65Hz */
clock-frequency = <65000000>;
hactive = <1024>;
vactive = <768>;
hsync-len = <136>;
hfront-porch = <20>;
hback-porch = <160>;
vfront-porch = <3>;
vback-porch = <29>;
vsync-len = <6>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};
...

View File

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

View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/mitsubishi,aa121td01.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mitsubishi AA121TD01 12.1" WXGA LVDS Display Panel
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: lvds.yaml#
properties:
compatible:
items:
- const: mitsubishi,aa121td01
- {} # panel-lvds, but not listed here to avoid false select
vcc-supply:
description: Reference to the regulator powering the panel VCC pins.
data-mapping:
const: jeida-24
width-mm:
const: 261
height-mm:
const: 163
panel-timing: true
port: true
additionalProperties: false
required:
- compatible
- vcc-supply
examples:
- |+
panel {
compatible = "mitsubishi,aa121td01", "panel-lvds";
vcc-supply = <&vcc_3v3>;
width-mm = <261>;
height-mm = <163>;
data-mapping = "jeida-24";
panel-timing {
/* 1280x800 @60Hz */
clock-frequency = <71000000>;
hactive = <1280>;
vactive = <800>;
hsync-len = <70>;
hfront-porch = <20>;
hback-porch = <70>;
vsync-len = <5>;
vfront-porch = <3>;
vback-porch = <15>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};
...

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,149 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-common.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Common Properties for Display Panels
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description: |
This document defines device tree properties common to several classes of
display panels. It doesn't constitue a device tree binding specification by
itself but is meant to be referenced by device tree bindings.
When referenced from panel device tree bindings the properties defined in this
document are defined as follows. The panel device tree bindings are
responsible for defining whether each property is required or optional.
properties:
# Descriptive Properties
width-mm:
description:
Specifies the width of the physical area where images are displayed. This
property is expressed in millimeters and rounded to the closest unit.
height-mm:
description:
Specifies the height of the physical area where images are displayed. This
property is expressed in millimeters and rounded to the closest unit.
label:
description: |
The label property specifies a symbolic name for the panel as a
string suitable for use by humans. It typically contains a name inscribed
on the system (e.g. as an affixed label) or specified in the system's
documentation (e.g. in the user's manual).
If no such name exists, and unless the property is mandatory according to
device tree bindings, it shall rather be omitted than constructed of
non-descriptive information. For instance an LCD panel in a system that
contains a single panel shall not be labelled "LCD" if that name is not
inscribed on the system or used in a descriptive fashion in system
documentation.
rotation:
description:
Display rotation in degrees counter clockwise (0,90,180,270)
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 0, 90, 180, 270 ]
# Display Timings
panel-timing:
type: object
description:
Most display panels are restricted to a single resolution and
require specific display timings. The panel-timing subnode expresses those
timings as specified in the timing subnode section of the display timing
bindings defined in
Documentation/devicetree/bindings/display/panel/display-timing.txt.
# Connectivity
port:
type: object
ports:
type: object
description:
Panels receive video data through one or multiple connections. While
the nature of those connections is specific to the panel type, the
connectivity is expressed in a standard fashion using ports as specified
in the device graph bindings defined in
Documentation/devicetree/bindings/graph.txt.
ddc-i2c-bus:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Some panels expose EDID information through an I2C-compatible
bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
phandle to the system I2C controller connected to that bus.
no-hpd:
type: boolean
description:
This panel is supposed to communicate that it's ready via HPD
(hot plug detect) signal, but the signal isn't hooked up so we should
hardcode the max delay from the panel spec when powering up the panel.
# Control I/Os
# Many display panels can be controlled through pins driven by GPIOs. The nature
# and timing of those control signals are device-specific and left for panel
# device tree bindings to specify. The following GPIO specifiers can however be
# used for panels that implement compatible control signals.
enable-gpios:
maxItems: 1
description: |
Specifier for a GPIO connected to the panel enable control signal. The
enable signal is active high and enables operation of the panel. This
property can also be used for panels implementing an active low power down
signal, which is a negated version of the enable signal. Active low enable
signals (or active high power down signals) can be supported by inverting
the GPIO specifier polarity flag.
Note that the enable signal control panel operation only and must not be
confused with a backlight enable signal.
reset-gpios:
maxItems: 1
description:
Specifier for a GPIO connected to the panel reset control signal.
The reset signal is active low and resets the panel internal logic
while active. Active high reset signals can be supported by inverting the
GPIO specifier polarity flag.
# Power
power-supply:
description:
Display panels require power to be supplied. While several panels need
more than one power supply with panel-specific constraints governing the
order and timings of the power supplies, in many cases a single power
supply is sufficient, either because the panel has a single power rail, or
because all its power rails can be driven by the same supply. In that case
the power-supply property specifies the supply powering the panel as a
phandle to a regulator.
# Backlight
# Most display panels include a backlight. Some of them also include a backlight
# controller exposed through a control bus such as I2C or DSI. Others expose
# backlight control through GPIO, PWM or other signals connected to an external
# backlight controller.
backlight:
$ref: /schemas/types.yaml#/definitions/phandle
description:
For panels whose backlight is controlled by an external backlight
controller, this property contains a phandle that references the
controller.
dependencies:
width-mm: [ height-mm ]
height-mm: [ width-mm ]
...

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/raspberrypi,7inch-touchscreen.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: The official 7" (800x480) Raspberry Pi touchscreen
maintainers:
- Eric Anholt <eric@anholt.net>
- Thierry Reding <thierry.reding@gmail.com>
description: |+
This DSI panel contains:
- TC358762 DSI->DPI bridge
- Atmel microcontroller on I2C for power sequencing the DSI bridge and
controlling backlight
- Touchscreen controller on I2C for touch input
and this binding covers the DSI display parts but not its touch input.
properties:
compatible:
const: raspberrypi,7inch-touchscreen-panel
reg:
const: 0x45
port: true
required:
- compatible
- reg
- port
additionalProperties: false
examples:
- |+
dsi1: dsi {
#address-cells = <1>;
#size-cells = <0>;
port {
dsi_out_port: endpoint {
remote-endpoint = <&panel_dsi_port>;
};
};
};
i2c_dsi: i2c {
compatible = "i2c-gpio";
#address-cells = <1>;
#size-cells = <0>;
scl-gpios = <&gpio 28 0>;
sda-gpios = <&gpio 29 0>;
lcd@45 {
compatible = "raspberrypi,7inch-touchscreen-panel";
reg = <0x45>;
port {
panel_dsi_port: endpoint {
remote-endpoint = <&dsi_out_port>;
};
};
};
};
...

View File

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

View File

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

View File

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

View File

@ -0,0 +1,68 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/sgd,gktw70sdae4se.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Solomon Goldentek Display GKTW70SDAE4SE 7" WVGA LVDS Display Panel
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
- Thierry Reding <thierry.reding@gmail.com>
allOf:
- $ref: lvds.yaml#
properties:
compatible:
items:
- const: sgd,gktw70sdae4se
- {} # panel-lvds, but not listed here to avoid false select
data-mapping:
const: jeida-18
width-mm:
const: 153
height-mm:
const: 86
panel-timing: true
port: true
additionalProperties: false
required:
- compatible
examples:
- |+
panel {
compatible = "sgd,gktw70sdae4se", "panel-lvds";
width-mm = <153>;
height-mm = <86>;
data-mapping = "jeida-18";
panel-timing {
clock-frequency = <32000000>;
hactive = <800>;
vactive = <480>;
hback-porch = <39>;
hfront-porch = <39>;
vback-porch = <29>;
vfront-porch = <13>;
hsync-len = <47>;
vsync-len = <2>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};
...

View File

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

View File

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

View File

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

View File

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

View File

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

View File

@ -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
...

View File

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

View File

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

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

View File

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

View File

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

View File

@ -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

View File

@ -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

View File

@ -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

View File

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

View File

@ -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

View File

@ -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

View File

@ -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

View File

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

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

View File

@ -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.

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

View File

@ -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

View File

@ -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

View File

@ -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 {

View File

@ -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,.*":

View File

@ -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'),
]

View File

@ -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'),
]

View File

@ -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'),
]

View File

@ -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

View File

@ -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::

View File

@ -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'),
]

View File

@ -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'),
]

View File

@ -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'),
]

View File

@ -11,7 +11,6 @@ GPU Driver Documentation
meson
pl111
tegra
tinydrm
tve200
v3d
vc4

View File

@ -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
===================================

View File

@ -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
----------------------

View File

@ -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
===============

View File

@ -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:

View File

@ -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
---------------------

View File

@ -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

View File

@ -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