Merge tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm

Pull drm updates from Dave Airlie:
 "New xilinx displayport driver, AMD support for two new GPUs (more
  header files), i915 initial support for RocketLake and some work on
  their DG1 (discrete chip).

  The core also grew some lockdep annotations to try and constrain what
  drivers do with dma-fences, and added some documentation on why the
  idea of indefinite fences doesn't work.

  The long list is below.

  I do have some fixes trees outstanding, but I'll follow up with those
  later.

  core:
   - add user def flag to cmd line modes
   - dma_fence_wait added might_sleep
   - dma-fence lockdep annotations
   - indefinite fences are bad documentation
   - gem CMA functions used in more drivers
   - struct mutex removal
   - more drm_ debug macro usage
   - set/drop master api fixes
   - fix for drm/mm hole size comparison
   - drm/mm remove invalid entry optimization
   - optimise drm/mm hole handling
   - VRR debugfs added
   - uncompressed AFBC modifier support
   - multiple display id blocks in EDID
   - multiple driver sg handling fixes
   - __drm_atomic_helper_crtc_reset in all drivers
   - managed vram helpers

  ttm:
   - ttm_mem_reg handling cleanup
   - remove bo offset field
   - drop CMA memtype flag
   - drop mappable flag

  xilinx:
   - New Xilinx ZynqMP DisplayPort Subsystem driver

  nouveau:
   - add CRC support
   - start using NVIDIA published class header files
   - convert all push buffer emission to new macros
   - Proper push buffer space management for EVO/NVD channels.
   - firmware loading fixes
   - 2MiB system memory pages support on Pascal and newer

  vkms:
   - larger cursor support

  i915:
   - Rocketlake platform enablement
   - Early DG1 enablement
   - Numerous GEM refactorings
   - DP MST fixes
   - FBC, PSR, Cursor, Color, Gamma fixes
   - TGL, RKL, EHL workaround updates
   - TGL 8K display support fixes
   - SDVO/HDMI/DVI fixes

  amdgpu:
   - Initial support for Sienna Cichlid GPU
   - Initial support for Navy Flounder GPU
   - SI UVD/VCE support
   - expose rotation property
   - Add support for unique id on Arcturus
   - Enable runtime PM on vega10 boards that support BACO
   - Skip BAR resizing if the bios already did id
   - Major swSMU code cleanup
   - Fixes for DCN bandwidth calculations

  amdkfd:
   - Track SDMA usage per process
   - SMI events interface

  radeon:
   - Default to on chip GART for AGP boards on all arches
   - Runtime PM reference count fixes

  msm:
   - headers regenerated causing churn
   - a650/a640 display and GPU enablement
   - dpu dither support for 6bpc panels
   - dpu cursor fix
   - dsi/mdp5 enablement for sdm630/sdm636/sdm66

  tegra:
   - video capture prep support
   - reflection support

  mediatek:
   - convert mtk_dsi to bridge API

  meson:
   - FBC support

  sun4i:
   - iommu support

  rockchip:
   - register locking fix
   - per-pixel alpha support PX30 VOP

  mgag200:
   - ported to simple and shmem helpers
   - device init cleanups
   - use managed pci functions
   - dropped hw cursor support

  ast:
   - use managed pci functions
   - use managed VRAM helpers
   - rework cursor support

  malidp:
   - dev_groups support

  hibmc:
   - refactor hibmc_drv_vdac:

  vc4:
   - create TXP CRTC

  imx:
   - error path fixes and cleanups

  etnaviv:
   - clock handling and error handling cleanups
   - use pin_user_pages"

* tag 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm: (1747 commits)
  drm/msm: use kthread_create_worker instead of kthread_run
  drm/msm/mdp5: Add MDP5 configuration for SDM636/660
  drm/msm/dsi: Add DSI configuration for SDM660
  drm/msm/mdp5: Add MDP5 configuration for SDM630
  drm/msm/dsi: Add phy configuration for SDM630/636/660
  drm/msm/a6xx: add A640/A650 hwcg
  drm/msm/a6xx: hwcg tables in gpulist
  drm/msm/dpu: add SM8250 to hw catalog
  drm/msm/dpu: add SM8150 to hw catalog
  drm/msm/dpu: intf timing path for displayport
  drm/msm/dpu: set missing flush bits for INTF_2 and INTF_3
  drm/msm/dpu: don't use INTF_INPUT_CTRL feature on sdm845
  drm/msm/dpu: move some sspp caps to dpu_caps
  drm/msm/dpu: update UBWC config for sm8150 and sm8250
  drm/msm/dpu: use right setup_blend_config for sm8150 and sm8250
  drm/msm/a6xx: set ubwc config for A640 and A650
  drm/msm/adreno: un-open-code some packets
  drm/msm: sync generated headers
  drm/msm/a6xx: add build_bw_table for A640/A650
  drm/msm/a6xx: fix crashstate capture for A650
  ...
このコミットが含まれているのは:
Linus Torvalds
2020-08-05 19:50:06 -07:00
コミット 8186749621
1426個のファイルの変更273630行の追加30672行の削除

ファイルの表示

@@ -36,6 +36,9 @@ properties:
- const: bus
- const: mod
iommus:
maxItems: 1
resets:
maxItems: 1

ファイルの表示

@@ -1,174 +0,0 @@
Broadcom VC4 (VideoCore4) GPU
The VC4 device present on the Raspberry Pi includes a display system
with HDMI output and the HVS (Hardware Video Scaler) for compositing
display planes.
Required properties for VC4:
- compatible: Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
Required properties for Pixel Valve:
- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
"brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
- reg: Physical base address and length of the PV's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for HVS:
- compatible: Should be "brcm,bcm2835-hvs"
- reg: Physical base address and length of the HVS's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for HDMI
- compatible: Should be "brcm,bcm2835-hdmi"
- reg: Physical base address and length of the two register ranges
("HDMI" and "HD", in that order)
- interrupts: The interrupt numbers
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
- ddc: phandle of the I2C controller used for DDC EDID probing
- clocks: a) hdmi: The HDMI state machine clock
b) pixel: The pixel clock.
Optional properties for HDMI:
- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear
as an interrupt/status bit in the HDMI controller
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
- dmas: Should contain one entry pointing to the DMA channel used to
transfer audio data
- dma-names: Should contain "audio-rx"
Required properties for DPI:
- compatible: Should be "brcm,bcm2835-dpi"
- reg: Physical base address and length of the registers
- clocks: a) core: The core clock the unit runs on
b) pixel: The pixel clock that feeds the pixelvalve
- port: Port node with a single endpoint connecting to the panel
device, as defined in [1]
Required properties for VEC:
- compatible: Should be "brcm,bcm2835-vec"
- reg: Physical base address and length of the registers
- clocks: The core clock the unit runs on
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for V3D:
- compatible: Should be "brcm,bcm2835-v3d" or "brcm,cygnus-v3d"
- reg: Physical base address and length of the V3D's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Optional properties for V3D:
- clocks: The clock the unit runs on
Required properties for DSI:
- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1"
- reg: Physical base address and length of the DSI block's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
- clocks: a) phy: The DSI PLL clock feeding the DSI analog PHY
b) escape: The DSI ESC clock from CPRMAN
c) pixel: The DSI pixel clock from CPRMAN
- clock-output-names:
The 3 clocks output from the DSI analog PHY: dsi[01]_byte,
dsi[01]_ddr2, and dsi[01]_ddr
Required properties for the TXP (writeback) block:
- compatible: Should be "brcm,bcm2835-txp"
- reg: Physical base address and length of the TXP block's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
pixelvalve@7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
reg = <0x7e807000 0x100>;
interrupts = <2 10>; /* pixelvalve */
};
hvs@7e400000 {
compatible = "brcm,bcm2835-hvs";
reg = <0x7e400000 0x6000>;
interrupts = <2 1>;
};
hdmi: hdmi@7e902000 {
compatible = "brcm,bcm2835-hdmi";
reg = <0x7e902000 0x600>,
<0x7e808000 0x100>;
interrupts = <2 8>, <2 9>;
ddc = <&i2c2>;
hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
clocks = <&clocks BCM2835_PLLH_PIX>,
<&clocks BCM2835_CLOCK_HSM>;
clock-names = "pixel", "hdmi";
};
dpi: dpi@7e208000 {
compatible = "brcm,bcm2835-dpi";
reg = <0x7e208000 0x8c>;
clocks = <&clocks BCM2835_CLOCK_VPU>,
<&clocks BCM2835_CLOCK_DPI>;
clock-names = "core", "pixel";
#address-cells = <1>;
#size-cells = <0>;
port {
dpi_out: endpoint@0 {
remote-endpoint = <&panel_in>;
};
};
};
dsi1: dsi@7e700000 {
compatible = "brcm,bcm2835-dsi1";
reg = <0x7e700000 0x8c>;
interrupts = <2 12>;
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <1>;
clocks = <&clocks BCM2835_PLLD_DSI1>,
<&clocks BCM2835_CLOCK_DSI1E>,
<&clocks BCM2835_CLOCK_DSI1P>;
clock-names = "phy", "escape", "pixel";
clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr";
pitouchscreen: panel@0 {
compatible = "raspberrypi,touchscreen";
reg = <0>;
<...>
};
};
vec: vec@7e806000 {
compatible = "brcm,bcm2835-vec";
reg = <0x7e806000 0x1000>;
clocks = <&clocks BCM2835_CLOCK_VEC>;
interrupts = <2 27>;
};
v3d: v3d@7ec00000 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec00000 0x1000>;
interrupts = <1 10>;
};
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
panel: panel {
compatible = "ontat,yx700wv03", "simple-panel";
port {
panel_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
};

ファイルの表示

@@ -0,0 +1,62 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-dpi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) DPI Controller
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
compatible:
const: brcm,bcm2835-dpi
reg:
maxItems: 1
clocks:
items:
- description: The core clock the unit runs on
- description: The pixel clock that feeds the pixelvalve
clock-names:
items:
- const: core
- const: pixel
port:
type: object
description: >
Port node with a single endpoint connecting to the panel, as
defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
required:
- compatible
- reg
- clocks
- clock-names
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/bcm2835.h>
dpi: dpi@7e208000 {
compatible = "brcm,bcm2835-dpi";
reg = <0x7e208000 0x8c>;
clocks = <&clocks BCM2835_CLOCK_VPU>,
<&clocks BCM2835_CLOCK_DPI>;
clock-names = "core", "pixel";
port {
dpi_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
...

ファイルの表示

@@ -0,0 +1,84 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-dsi0.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) DSI Controller
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
"#clock-cells":
const: 1
compatible:
enum:
- brcm,bcm2835-dsi0
- brcm,bcm2835-dsi1
reg:
maxItems: 1
clocks:
items:
- description: The DSI PLL clock feeding the DSI analog PHY
- description: The DSI ESC clock
- description: The DSI pixel clock
clock-names:
items:
- const: phy
- const: escape
- const: pixel
clock-output-names: true
# FIXME: The meta-schemas don't seem to allow it for now
# items:
# - description: The DSI byte clock for the PHY
# - description: The DSI DDR2 clock
# - description: The DSI DDR clock
interrupts:
maxItems: 1
required:
- "#clock-cells"
- compatible
- reg
- clocks
- clock-names
- clock-output-names
- interrupts
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/bcm2835.h>
dsi1: dsi@7e700000 {
compatible = "brcm,bcm2835-dsi1";
reg = <0x7e700000 0x8c>;
interrupts = <2 12>;
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <1>;
clocks = <&clocks BCM2835_PLLD_DSI1>,
<&clocks BCM2835_CLOCK_DSI1E>,
<&clocks BCM2835_CLOCK_DSI1P>;
clock-names = "phy", "escape", "pixel";
clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr";
pitouchscreen: panel@0 {
compatible = "raspberrypi,touchscreen";
reg = <0>;
/* ... */
};
};
...

ファイルの表示

@@ -0,0 +1,80 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-hdmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) HDMI Controller
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
compatible:
const: brcm,bcm2835-hdmi
reg:
items:
- description: HDMI register range
- description: HD register range
interrupts:
minItems: 2
clocks:
items:
- description: The pixel clock
- description: The HDMI state machine clock
clock-names:
items:
- const: pixel
- const: hdmi
ddc:
allOf:
- $ref: /schemas/types.yaml#/definitions/phandle
description: >
Phandle of the I2C controller used for DDC EDID probing
hpd-gpios:
description: >
The GPIO pin for the HDMI hotplug detect (if it doesn't appear
as an interrupt/status bit in the HDMI controller itself)
dmas:
maxItems: 1
description: >
Should contain one entry pointing to the DMA channel used to
transfer audio data.
dma-names:
const: audio-rx
required:
- compatible
- reg
- interrupts
- clocks
- ddc
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/bcm2835.h>
#include <dt-bindings/gpio/gpio.h>
hdmi: hdmi@7e902000 {
compatible = "brcm,bcm2835-hdmi";
reg = <0x7e902000 0x600>,
<0x7e808000 0x100>;
interrupts = <2 8>, <2 9>;
ddc = <&i2c2>;
hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
clocks = <&clocks BCM2835_PLLH_PIX>,
<&clocks BCM2835_CLOCK_HSM>;
clock-names = "pixel", "hdmi";
};
...

ファイルの表示

@@ -0,0 +1,37 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-hvs.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) Hardware Video Scaler
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
compatible:
const: brcm,bcm2835-hvs
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
hvs@7e400000 {
compatible = "brcm,bcm2835-hvs";
reg = <0x7e400000 0x6000>;
interrupts = <2 1>;
};
...

ファイルの表示

@@ -0,0 +1,40 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-pixelvalve0.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) PixelValve
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
compatible:
enum:
- brcm,bcm2835-pixelvalve0
- brcm,bcm2835-pixelvalve1
- brcm,bcm2835-pixelvalve2
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
pixelvalve@7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
reg = <0x7e807000 0x100>;
interrupts = <2 10>; /* pixelvalve */
};
...

ファイルの表示

@@ -0,0 +1,37 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-txp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) TXP (writeback) Controller
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
compatible:
const: brcm,bcm2835-txp
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
txp: txp@7e004000 {
compatible = "brcm,bcm2835-txp";
reg = <0x7e004000 0x20>;
interrupts = <1 11>;
};
...

ファイルの表示

@@ -0,0 +1,42 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-v3d.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) V3D GPU
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
compatible:
enum:
- brcm,bcm2835-v3d
- brcm,cygnus-v3d
reg:
maxItems: 1
clocks:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
v3d: v3d@7ec00000 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec00000 0x1000>;
interrupts = <1 10>;
};
...

ファイルの表示

@@ -0,0 +1,34 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-vc4.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) GPU
maintainers:
- Eric Anholt <eric@anholt.net>
description: >
The VC4 device present on the Raspberry Pi includes a display system
with HDMI output and the HVS (Hardware Video Scaler) for compositing
display planes.
properties:
compatible:
enum:
- brcm,bcm2835-vc4
- brcm,cygnus-vc4
required:
- compatible
additionalProperties: false
examples:
- |
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
...

ファイルの表示

@@ -0,0 +1,44 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/brcm,bcm2835-vec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom VC4 (VideoCore4) VEC
maintainers:
- Eric Anholt <eric@anholt.net>
properties:
compatible:
const: brcm,bcm2835-vec
reg:
maxItems: 1
clocks:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
- clocks
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/bcm2835.h>
vec: vec@7e806000 {
compatible = "brcm,bcm2835-vec";
reg = <0x7e806000 0x1000>;
clocks = <&clocks BCM2835_CLOCK_VEC>;
interrupts = <2 27>;
};
...

ファイルの表示

@@ -165,6 +165,7 @@ examples:
- |
#include <dt-bindings/clock/imx8mq-clock.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/imx8mq-reset.h>
@@ -191,12 +192,12 @@ examples:
phy-names = "dphy";
panel@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "rocktech,jh057n00900";
reg = <0>;
port@0 {
reg = <0>;
vcc-supply = <&reg_2v8_p>;
iovcc-supply = <&reg_1v8_p>;
reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
port {
panel_in: endpoint {
remote-endpoint = <&mipi_dsi_out>;
};

ファイルの表示

@@ -1,85 +0,0 @@
Renesas R-Car LVDS Encoder
==========================
These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
Gen2, R-Car Gen3 and RZ/G SoCs.
Required properties:
- compatible : Shall contain one of
- "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders
- "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders
- "renesas,r8a774a1-lvds" for R8A774A1 (RZ/G2M) compatible LVDS encoders
- "renesas,r8a774b1-lvds" for R8A774B1 (RZ/G2N) compatible LVDS encoders
- "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders
- "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
- "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
- "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders
- "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
- "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
- "renesas,r8a77965-lvds" for R8A77965 (R-Car M3-N) compatible LVDS encoders
- "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders
- "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders
- "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders
- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders
- reg: Base address and length for the memory-mapped registers
- clocks: A list of phandles + clock-specifier pairs, one for each entry in
the clock-names property.
- clock-names: Name of the clocks. This property is model-dependent.
- The functional clock, which mandatory for all models, shall be listed
first, and shall be named "fck".
- On R8A77990, R8A77995 and R8A774C0, the LVDS encoder can use the EXTAL or
DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must be
named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN
numerical index.
- When the clocks property only contains the functional clock, the
clock-names property may be omitted.
- resets: A phandle + reset specifier for the module reset
Required nodes:
The LVDS encoder has two video ports. Their connections are modelled using the
OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 corresponds to the parallel RGB input
- Video port 1 corresponds to the LVDS output
Each port shall have a single endpoint.
Optional properties:
- renesas,companion : phandle to the companion LVDS encoder. This property is
mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to
the second encoder to be used as a companion in dual-link mode. It shall not
be set for any other LVDS encoder.
Example:
lvds0: lvds@feb90000 {
compatible = "renesas,r8a77990-lvds";
reg = <0 0xfeb90000 0 0x20>;
clocks = <&cpg CPG_MOD 727>;
power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
resets = <&cpg 727>;
renesas,companion = <&lvds1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds0_in: endpoint {
remote-endpoint = <&du_out_lvds0>;
};
};
port@1 {
reg = <1>;
lvds0_out: endpoint {
};
};
};
};

ファイルの表示

@@ -0,0 +1,248 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/renesas,lvds.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas R-Car LVDS Encoder
maintainers:
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
description: |
These DT bindings describe the LVDS encoder embedded in the Renesas R-Car
Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs.
properties:
compatible:
enum:
- renesas,r8a7743-lvds # for RZ/G1M compatible LVDS encoders
- renesas,r8a7744-lvds # for RZ/G1N compatible LVDS encoders
- renesas,r8a774a1-lvds # for RZ/G2M compatible LVDS encoders
- renesas,r8a774b1-lvds # for RZ/G2N compatible LVDS encoders
- renesas,r8a774c0-lvds # for RZ/G2E compatible LVDS encoders
- renesas,r8a7790-lvds # for R-Car H2 compatible LVDS encoders
- renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders
- renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders
- renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders
- renesas,r8a7796-lvds # for R-Car M3-W compatible LVDS encoders
- renesas,r8a77965-lvds # for R-Car M3-N compatible LVDS encoders
- renesas,r8a77970-lvds # for R-Car V3M compatible LVDS encoders
- renesas,r8a77980-lvds # for R-Car V3H compatible LVDS encoders
- renesas,r8a77990-lvds # for R-Car E3 compatible LVDS encoders
- renesas,r8a77995-lvds # for R-Car D3 compatible LVDS encoders
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 4
clock-names:
minItems: 1
maxItems: 4
resets:
maxItems: 1
ports:
type: object
description: |
This device has two video ports. Their connections are modelled using the
OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
Each port shall have a single endpoint.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
port@0:
type: object
description: Parallel RGB input port
port@1:
type: object
description: LVDS output port
required:
- port@0
- port@1
additionalProperties: false
power-domains:
maxItems: 1
renesas,companion:
$ref: /schemas/types.yaml#/definitions/phandle
description:
phandle to the companion LVDS encoder. This property is mandatory
for the first LVDS encoder on D3 and E3 SoCs, and shall point to
the second encoder to be used as a companion in dual-link mode. It
shall not be set for any other LVDS encoder.
required:
- compatible
- reg
- clocks
- power-domains
- resets
- ports
if:
properties:
compatible:
enum:
- renesas,r8a774c0-lvds
- renesas,r8a77990-lvds
- renesas,r8a77995-lvds
then:
properties:
clocks:
minItems: 1
maxItems: 4
items:
- description: Functional clock
- description: EXTAL input clock
- description: DU_DOTCLKIN0 input clock
- description: DU_DOTCLKIN1 input clock
clock-names:
minItems: 1
maxItems: 4
items:
- const: fck
# The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks.
# These clocks are optional.
- enum:
- extal
- dclkin.0
- dclkin.1
- enum:
- extal
- dclkin.0
- dclkin.1
- enum:
- extal
- dclkin.0
- dclkin.1
required:
- clock-names
else:
properties:
clocks:
maxItems: 1
items:
- description: Functional clock
clock-names:
maxItems: 1
items:
- const: fck
renesas,companion: false
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/renesas-cpg-mssr.h>
#include <dt-bindings/power/r8a7795-sysc.h>
lvds@feb90000 {
compatible = "renesas,r8a7795-lvds";
reg = <0xfeb90000 0x14>;
clocks = <&cpg CPG_MOD 727>;
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
resets = <&cpg 727>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds_in: endpoint {
remote-endpoint = <&du_out_lvds0>;
};
};
port@1 {
reg = <1>;
lvds_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};
- |
#include <dt-bindings/clock/renesas-cpg-mssr.h>
#include <dt-bindings/power/r8a77990-sysc.h>
lvds0: lvds@feb90000 {
compatible = "renesas,r8a77990-lvds";
reg = <0xfeb90000 0x20>;
clocks = <&cpg CPG_MOD 727>,
<&x13_clk>,
<&extal_clk>;
clock-names = "fck", "dclkin.0", "extal";
power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
resets = <&cpg 727>;
renesas,companion = <&lvds1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds0_in: endpoint {
remote-endpoint = <&du_out_lvds0>;
};
};
port@1 {
reg = <1>;
lvds0_out: endpoint {
remote-endpoint = <&panel_in1>;
};
};
};
};
lvds1: lvds@feb90100 {
compatible = "renesas,r8a77990-lvds";
reg = <0xfeb90100 0x20>;
clocks = <&cpg CPG_MOD 727>,
<&x13_clk>,
<&extal_clk>;
clock-names = "fck", "dclkin.0", "extal";
power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
resets = <&cpg 726>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
lvds1_in: endpoint {
remote-endpoint = <&du_out_lvds1>;
};
};
port@1 {
reg = <1>;
lvds1_out: endpoint {
remote-endpoint = <&panel_in2>;
};
};
};
};
...

ファイルの表示

@@ -1,87 +0,0 @@
SN65DSI86 DSI to eDP bridge chip
--------------------------------
This is the binding for Texas Instruments SN65DSI86 bridge.
https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
Required properties:
- compatible: Must be "ti,sn65dsi86"
- reg: i2c address of the chip, 0x2d as per datasheet
- enable-gpios: gpio specification for bridge_en pin (active high)
- vccio-supply: A 1.8V supply that powers up the digital IOs.
- vpll-supply: A 1.8V supply that powers up the displayport PLL.
- vcca-supply: A 1.2V supply that powers up the analog circuits.
- vcc-supply: A 1.2V supply that powers up the digital core.
Optional properties:
- interrupts-extended: Specifier for the SN65DSI86 interrupt line.
- gpio-controller: Marks the device has a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../../gpio/gpio.txt for more information.
- #pwm-cells : Should be one. See ../../pwm/pwm.yaml for description of
the cell formats.
- clock-names: should be "refclk"
- clocks: Specification for input reference clock. The reference
clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
- data-lanes: See ../../media/video-interface.txt
- lane-polarities: See ../../media/video-interface.txt
- suspend-gpios: specification for GPIO1 pin on bridge (active low)
Required nodes:
This device has two video ports. Their connections are modelled using the
OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for DSI input
- Video port 1 for eDP output
Example
-------
edp-bridge@2d {
compatible = "ti,sn65dsi86";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x2d>;
enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>;
interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>;
vccio-supply = <&pm8916_l17>;
vcca-supply = <&pm8916_l6>;
vpll-supply = <&pm8916_l17>;
vcc-supply = <&pm8916_l6>;
clock-names = "refclk";
clocks = <&input_refclk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
edp_bridge_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
port@1 {
reg = <1>;
edp_bridge_out: endpoint {
data-lanes = <2 1 3 0>;
lane-polarities = <0 1 0 1>;
remote-endpoint = <&edp_panel_in>;
};
};
};
}

ファイルの表示

@@ -0,0 +1,293 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi86.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SN65DSI86 DSI to eDP bridge chip
maintainers:
- Sandeep Panda <spanda@codeaurora.org>
description: |
The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP.
https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
properties:
compatible:
const: ti,sn65dsi86
reg:
const: 0x2d
enable-gpios:
maxItems: 1
description: GPIO specifier for bridge_en pin (active high).
suspend-gpios:
maxItems: 1
description: GPIO specifier for GPIO1 pin on bridge (active low).
no-hpd:
type: boolean
description:
Set if the HPD line on the bridge isn't hooked up to anything or is
otherwise unusable.
vccio-supply:
description: A 1.8V supply that powers the digital IOs.
vpll-supply:
description: A 1.8V supply that powers the DisplayPort PLL.
vcca-supply:
description: A 1.2V supply that powers the analog circuits.
vcc-supply:
description: A 1.2V supply that powers the digital core.
interrupts:
maxItems: 1
clocks:
maxItems: 1
description:
Clock specifier for input reference clock. The reference clock rate must
be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
clock-names:
const: refclk
gpio-controller: true
'#gpio-cells':
const: 2
description:
First cell is pin number, second cell is flags. GPIO pin numbers are
1-based to match the datasheet. See ../../gpio/gpio.txt for more
information.
'#pwm-cells':
const: 1
description: See ../../pwm/pwm.yaml for description of the cell formats.
ports:
type: object
additionalProperties: false
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
port@0:
type: object
additionalProperties: false
description:
Video port for MIPI DSI input
properties:
reg:
const: 0
endpoint:
type: object
additionalProperties: false
properties:
remote-endpoint: true
required:
- reg
port@1:
type: object
additionalProperties: false
description:
Video port for eDP output (panel or connector).
properties:
reg:
const: 1
endpoint:
type: object
additionalProperties: false
properties:
remote-endpoint: true
data-lanes:
oneOf:
- minItems: 1
maxItems: 1
uniqueItems: true
items:
enum:
- 0
- 1
description:
If you have 1 logical lane the bridge supports routing
to either port 0 or port 1. Port 0 is suggested.
See ../../media/video-interface.txt for details.
- minItems: 2
maxItems: 2
uniqueItems: true
items:
enum:
- 0
- 1
description:
If you have 2 logical lanes the bridge supports
reordering but only on physical ports 0 and 1.
See ../../media/video-interface.txt for details.
- minItems: 4
maxItems: 4
uniqueItems: true
items:
enum:
- 0
- 1
- 2
- 3
description:
If you have 4 logical lanes the bridge supports
reordering in any way.
See ../../media/video-interface.txt for details.
lane-polarities:
minItems: 1
maxItems: 4
items:
enum:
- 0
- 1
description: See ../../media/video-interface.txt
dependencies:
lane-polarities: [data-lanes]
required:
- reg
required:
- "#address-cells"
- "#size-cells"
- port@0
- port@1
required:
- compatible
- reg
- enable-gpios
- vccio-supply
- vpll-supply
- vcca-supply
- vcc-supply
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
bridge@2d {
compatible = "ti,sn65dsi86";
reg = <0x2d>;
interrupt-parent = <&tlmm>;
interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
vpll-supply = <&src_pp1800_s4a>;
vccio-supply = <&src_pp1800_s4a>;
vcca-supply = <&src_pp1200_l2a>;
vcc-supply = <&src_pp1200_l2a>;
clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
clock-names = "refclk";
no-hpd;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
endpoint {
remote-endpoint = <&dsi0_out>;
};
};
port@1 {
reg = <1>;
endpoint {
remote-endpoint = <&panel_in_edp>;
};
};
};
};
};
- |
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
bridge@2d {
compatible = "ti,sn65dsi86";
reg = <0x2d>;
enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>;
interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>;
vccio-supply = <&pm8916_l17>;
vcca-supply = <&pm8916_l6>;
vpll-supply = <&pm8916_l17>;
vcc-supply = <&pm8916_l6>;
clock-names = "refclk";
clocks = <&input_refclk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
edp_bridge_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
port@1 {
reg = <1>;
edp_bridge_out: endpoint {
data-lanes = <2 1 3 0>;
lane-polarities = <0 1 0 1>;
remote-endpoint = <&edp_panel_in>;
};
};
};
};
};

ファイルの表示

@@ -1,66 +0,0 @@
TFP410 DPI to DVI encoder
=========================
Required properties:
- compatible: "ti,tfp410"
Optional properties:
- powerdown-gpios: power-down gpio
- reg: I2C address. If and only if present the device node should be placed
into the I2C controller node where the TFP410 I2C is connected to.
- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured
through th DK[3:1] pins. This property shall be present only if the TFP410
is not connected through I2C.
Required nodes:
This device has two video ports. Their connections are modeled using the OF
graph bindings specified in [1]. Each port node shall have a single endpoint.
- Port 0 is the DPI input port. Its endpoint subnode shall contain a
pclk-sample and bus-width property and a remote-endpoint property as specified
in [1].
- If pclk-sample is not defined, pclk-sample = 0 should be assumed for
backward compatibility.
- If bus-width is not defined then bus-width = 24 should be assumed for
backward compatibility.
bus-width = 24: 24 data lines are connected and single-edge mode
bus-width = 12: 12 data lines are connected and dual-edge mode
- Port 1 is the DVI output port. Its endpoint subnode shall contain a
remote-endpoint property is specified in [1].
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
Example
-------
tfp410: encoder@0 {
compatible = "ti,tfp410";
powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
ti,deskew = <4>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tfp410_in: endpoint@0 {
pclk-sample = <1>;
bus-width = <24>;
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
tfp410_out: endpoint@0 {
remote-endpoint = <&dvi_connector_in>;
};
};
};
};

ファイルの表示

@@ -0,0 +1,131 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TFP410 DPI to DVI encoder
maintainers:
- Tomi Valkeinen <tomi.valkeinen@ti.com>
- Jyri Sarha <jsarha@ti.com>
properties:
compatible:
const: ti,tfp410
reg:
description: I2C address of the device.
maxItems: 1
powerdown-gpios:
maxItems: 1
ti,deskew:
description:
Data de-skew value in 350ps increments, from 0 to 7, as configured
through the DK[3:1] pins. The de-skew multiplier is computed as
(DK[3:1] - 4), so it ranges from -4 to 3.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 7
ports:
description:
A node containing input and output port nodes with endpoint
definitions as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
type: object
properties:
port@0:
description: DPI input port.
type: object
properties:
reg:
const: 0
endpoint:
type: object
properties:
pclk-sample:
description:
Endpoint sampling edge.
enum:
- 0 # Falling edge
- 1 # Rising edge
default: 0
bus-width:
description:
Endpoint bus width.
enum:
- 12 # 12 data lines connected and dual-edge mode
- 24 # 24 data lines connected and single-edge mode
default: 24
port@1:
description: DVI output port.
type: object
properties:
reg:
const: 1
endpoint:
type: object
required:
- port@0
- port@1
required:
- compatible
- ports
if:
required:
- reg
then:
properties:
ti,deskew: false
else:
required:
- ti,deskew
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
tfp410: encoder {
compatible = "ti,tfp410";
powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
ti,deskew = <3>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tfp410_in: endpoint {
pclk-sample = <1>;
bus-width = <24>;
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
tfp410_out: endpoint {
remote-endpoint = <&dvi_connector_in>;
};
};
};
};
...

ファイルの表示

@@ -1,31 +0,0 @@
Analog TV Connector
===================
Required properties:
- compatible: "composite-video-connector" or "svideo-connector"
Optional properties:
- label: a symbolic name for the connector
- sdtv-standards: limit the supported TV standards on a connector to the given
ones. If not specified all TV standards are allowed.
Possible TV standards are defined in
include/dt-bindings/display/sdtv-standards.h.
Required nodes:
- Video port for TV input
Example
-------
#include <dt-bindings/display/sdtv-standards.h>
tv: connector {
compatible = "composite-video-connector";
label = "tv";
sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>;
port {
tv_connector_in: endpoint {
remote-endpoint = <&venc_out>;
};
};
};

ファイルの表示

@@ -0,0 +1,52 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/connector/analog-tv-connector.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog TV Connector
maintainers:
- Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
properties:
compatible:
enum:
- composite-video-connector
- svideo-connector
label: true
sdtv-standards:
description:
Limit the supported TV standards on a connector to the given ones. If
not specified all TV standards are allowed. Possible TV standards are
defined in include/dt-bindings/display/sdtv-standards.h.
$ref: /schemas/types.yaml#/definitions/uint32
port:
description: Connection to controller providing analog TV signals
required:
- compatible
- port
additionalProperties: false
examples:
- |
#include <dt-bindings/display/sdtv-standards.h>
connector {
compatible = "composite-video-connector";
label = "tv";
sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>;
port {
tv_connector_in: endpoint {
remote-endpoint = <&venc_out>;
};
};
};
...

ファイルの表示

@@ -1,36 +0,0 @@
DVI Connector
==============
Required properties:
- compatible: "dvi-connector"
Optional properties:
- label: a symbolic name for the connector
- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
- analog: the connector has DVI analog pins
- digital: the connector has DVI digital pins
- dual-link: the connector has pins for DVI dual-link
- hpd-gpios: HPD GPIO number
Required nodes:
- Video port for DVI input
Note: One (or both) of 'analog' or 'digital' must be set.
Example
-------
dvi0: connector@0 {
compatible = "dvi-connector";
label = "dvi";
digital;
ddc-i2c-bus = <&i2c3>;
port {
dvi_connector_in: endpoint {
remote-endpoint = <&tfp410_out>;
};
};
};

ファイルの表示

@@ -0,0 +1,70 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/connector/dvi-connector.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: DVI Connector
maintainers:
- Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
properties:
compatible:
const: dvi-connector
label: true
hpd-gpios:
description: A GPIO line connected to HPD
maxItems: 1
ddc-i2c-bus:
description: phandle link to the I2C controller used for DDC EDID probing
$ref: /schemas/types.yaml#/definitions/phandle
analog:
type: boolean
description: the connector has DVI analog pins
digital:
type: boolean
description: the connector has DVI digital pins
dual-link:
type: boolean
description: the connector has pins for DVI dual-link
port:
description: Connection to controller providing DVI signals
required:
- compatible
- port
anyOf:
- required:
- analog
- required:
- digital
additionalProperties: false
examples:
- |
connector {
compatible = "dvi-connector";
label = "dvi";
digital;
ddc-i2c-bus = <&i2c3>;
port {
dvi_connector_in: endpoint {
remote-endpoint = <&tfp410_out>;
};
};
};
...

ファイルの表示

@@ -1,31 +0,0 @@
HDMI Connector
==============
Required properties:
- compatible: "hdmi-connector"
- type: the HDMI connector type: "a", "b", "c", "d" or "e"
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
Example
-------
hdmi0: connector@1 {
compatible = "hdmi-connector";
label = "hdmi";
type = "a";
port {
hdmi_connector_in: endpoint {
remote-endpoint = <&tpd12s015_out>;
};
};
};

ファイルの表示

@@ -0,0 +1,64 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/connector/hdmi-connector.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: HDMI Connector
maintainers:
- Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
properties:
compatible:
const: hdmi-connector
type:
description: The HDMI connector type
enum:
- a # Standard full size
- b # Never deployed?
- c # Mini
- d # Micro
- e # automotive
label: true
hpd-gpios:
description: A GPIO line connected to HPD
maxItems: 1
ddc-i2c-bus:
description: phandle link to the I2C controller used for DDC EDID probing
$ref: /schemas/types.yaml#/definitions/phandle
ddc-en-gpios:
description: GPIO signal to enable DDC bus
maxItems: 1
port:
description: Connection to controller providing HDMI signals
required:
- compatible
- port
- type
additionalProperties: false
examples:
- |
connector {
compatible = "hdmi-connector";
label = "hdmi";
type = "a";
port {
hdmi_connector_in: endpoint {
remote-endpoint = <&tpd12s015_out>;
};
};
};
...

ファイルの表示

@@ -1,36 +0,0 @@
VGA Connector
=============
Required properties:
- compatible: "vga-connector"
Optional properties:
- label: a symbolic name for the connector corresponding to a hardware label
- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC
Required nodes:
The VGA connector internal connections are modeled using the OF graph bindings
specified in Documentation/devicetree/bindings/graph.txt.
The VGA connector has a single port that must be connected to a video source
port.
Example
-------
vga0: connector@0 {
compatible = "vga-connector";
label = "vga";
ddc-i2c-bus = <&i2c3>;
port {
vga_connector_in: endpoint {
remote-endpoint = <&adv7123_out>;
};
};
};

ファイルの表示

@@ -0,0 +1,46 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/connector/vga-connector.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: VGA Connector
maintainers:
- Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
properties:
compatible:
const: vga-connector
label: true
ddc-i2c-bus:
description: phandle link to the I2C controller used for DDC EDID probing
$ref: /schemas/types.yaml#/definitions/phandle
port:
description: Connection to controller providing VGA signals
required:
- compatible
- port
additionalProperties: false
examples:
- |
connector {
compatible = "vga-connector";
label = "vga";
ddc-i2c-bus = <&i2c3>;
port {
vga_connector_in: endpoint {
remote-endpoint = <&adv7123_out>;
};
};
};
...

ファイルの表示

@@ -0,0 +1,65 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/ingenic,ipu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ingenic SoCs Image Processing Unit (IPU) devicetree bindings
maintainers:
- Paul Cercueil <paul@crapouillou.net>
properties:
compatible:
oneOf:
- enum:
- ingenic,jz4725b-ipu
- ingenic,jz4760-ipu
- items:
- const: ingenic,jz4770-ipu
- const: ingenic,jz4760-ipu
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
clock-names:
const: ipu
patternProperties:
"^ports?$":
description: OF graph bindings (specified in bindings/graph.txt).
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/jz4770-cgu.h>
ipu@13080000 {
compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu";
reg = <0x13080000 0x800>;
interrupt-parent = <&intc>;
interrupts = <29>;
clocks = <&cgu JZ4770_CLK_IPU>;
clock-names = "ipu";
port {
ipu_ep: endpoint {
remote-endpoint = <&lcdc_ep>;
};
};
};

ファイルの表示

@@ -1,45 +0,0 @@
Ingenic JZ47xx LCD driver
Required properties:
- compatible: one of:
* ingenic,jz4740-lcd
* ingenic,jz4725b-lcd
* ingenic,jz4770-lcd
- reg: LCD registers location and length
- clocks: LCD pixclock and device clock specifiers.
The device clock is only required on the JZ4740.
- clock-names: "lcd_pclk" and "lcd"
- interrupts: Specifies the interrupt line the LCD controller is connected to.
Example:
panel {
compatible = "sharp,ls020b1dd01d";
backlight = <&backlight>;
power-supply = <&vcc>;
port {
panel_input: endpoint {
remote-endpoint = <&panel_output>;
};
};
};
lcd: lcd-controller@13050000 {
compatible = "ingenic,jz4725b-lcd";
reg = <0x13050000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <31>;
clocks = <&cgu JZ4725B_CLK_LCD>;
clock-names = "lcd";
port {
panel_output: endpoint {
remote-endpoint = <&panel_input>;
};
};
};

ファイルの表示

@@ -0,0 +1,126 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ingenic SoCs LCD controller devicetree bindings
maintainers:
- Paul Cercueil <paul@crapouillou.net>
properties:
$nodename:
pattern: "^lcd-controller@[0-9a-f]+$"
compatible:
enum:
- ingenic,jz4740-lcd
- ingenic,jz4725b-lcd
- ingenic,jz4770-lcd
- ingenic,jz4780-lcd
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: Pixel clock
- description: Module clock
minItems: 1
clock-names:
items:
- const: lcd_pclk
- const: lcd
minItems: 1
port:
description: OF graph bindings (specified in bindings/graph.txt).
ports:
description: OF graph bindings (specified in bindings/graph.txt).
type: object
properties:
port@0:
type: object
description: DPI output, to interface with TFT panels.
port@8:
type: object
description: Link to the Image Processing Unit (IPU).
(See ingenic,ipu.yaml).
required:
- port@0
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
if:
properties:
compatible:
contains:
enum:
- ingenic,jz4740-lcd
- ingenic,jz4780-lcd
then:
properties:
clocks:
minItems: 2
clock-names:
minItems: 2
else:
properties:
clocks:
maxItems: 1
clock-names:
maxItems: 1
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/jz4740-cgu.h>
lcd-controller@13050000 {
compatible = "ingenic,jz4740-lcd";
reg = <0x13050000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <30>;
clocks = <&cgu JZ4740_CLK_LCD_PCLK>, <&cgu JZ4740_CLK_LCD>;
clock-names = "lcd_pclk", "lcd";
port {
endpoint {
remote-endpoint = <&panel_input>;
};
};
};
- |
#include <dt-bindings/clock/jz4725b-cgu.h>
lcd-controller@13050000 {
compatible = "ingenic,jz4725b-lcd";
reg = <0x13050000 0x1000>;
interrupt-parent = <&intc>;
interrupts = <31>;
clocks = <&cgu JZ4725B_CLK_LCD>;
clock-names = "lcd_pclk";
port {
endpoint {
remote-endpoint = <&panel_input>;
};
};
};

ファイルの表示

@@ -87,6 +87,7 @@ Required properties:
* "qcom,dsi-phy-20nm"
* "qcom,dsi-phy-28nm-8960"
* "qcom,dsi-phy-14nm"
* "qcom,dsi-phy-14nm-660"
* "qcom,dsi-phy-10nm"
* "qcom,dsi-phy-10nm-8998"
- reg: Physical base address and length of the registers of PLL, PHY. Some

ファイルの表示

@@ -112,6 +112,34 @@ Example a6xx (with GMU):
interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
interconnect-names = "gfx-mem";
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-430000000 {
opp-hz = /bits/ 64 <430000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
opp-peak-kBps = <5412000>;
};
opp-355000000 {
opp-hz = /bits/ 64 <355000000>;
opp-level = <RPMH_REGULATOR_LEVEL_SVS>;
opp-peak-kBps = <3072000>;
};
opp-267000000 {
opp-hz = /bits/ 64 <267000000>;
opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
opp-peak-kBps = <3072000>;
};
opp-180000000 {
opp-hz = /bits/ 64 <180000000>;
opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>;
opp-peak-kBps = <1804000>;
};
};
qcom,gmu = <&gmu>;
zap-shader {

ファイルの表示

@@ -1,22 +0,0 @@
Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
Required properties:
- compatible: should be "innolux,p079zca"
- reg: DSI virtual channel of the peripheral
- power-supply: phandle of the regulator that provides the supply voltage
- enable-gpios: panel enable gpio
Optional properties:
- backlight: phandle of the backlight device attached to the panel
Example:
&mipi_dsi {
panel@0 {
compatible = "innolux,p079zca";
reg = <0>;
power-supply = <...>;
backlight = <&backlight>;
enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
};
};

ファイルの表示

@@ -1,29 +0,0 @@
Generic MIPI DSI Command Mode Panel
===================================
Required properties:
- compatible: "panel-dsi-cm"
Optional properties:
- label: a symbolic name for the panel
- reset-gpios: panel reset gpio
- te-gpios: panel TE gpio
Required nodes:
- Video port for DSI input
Example
-------
lcd0: display {
compatible = "tpo,taal", "panel-dsi-cm";
label = "lcd0";
reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
port {
lcd0_in: endpoint {
remote-endpoint = <&dsi1_out_ep>;
};
};
};

ファイルの表示

@@ -0,0 +1,86 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: DSI command mode panels
maintainers:
- Tomi Valkeinen <tomi.valkeinen@ti.com>
- Sebastian Reichel <sre@kernel.org>
description: |
This binding file is a collection of the DSI panels that
are usually driven in command mode. If no backlight is
referenced via the optional backlight property, the DSI
panel is assumed to have native backlight support.
The panel may use an OF graph binding for the association
to the display, or it may be a direct child node of the
display.
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
items:
- enum:
- motorola,droid4-panel # Panel from Motorola Droid4 phone
- nokia,himalaya # Panel from Nokia N950 phone
- tpo,taal # Panel from OMAP4 SDP board
- const: panel-dsi-cm # Generic DSI command mode panel compatible fallback
reg:
maxItems: 1
description: DSI virtual channel
vddi-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 vddi-supply property specifies the supply powering the panel as a
phandle to a regulator.
vpnl-supply:
description:
When the display panel needs a second power supply, this property can be
used in addition to vddi-supply. Both supplies will be enabled at the
same time before the panel is being accessed.
width-mm: true
height-mm: true
label: true
rotation: true
panel-timing: true
port: true
reset-gpios: true
te-gpios: true
backlight: true
additionalProperties: false
required:
- compatible
- reg
examples:
- |
#include <dt-bindings/gpio/gpio.h>
dsi-controller {
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "tpo,taal", "panel-dsi-cm";
reg = <0>;
reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
};
};
...

ファイルの表示

@@ -33,6 +33,8 @@ properties:
- auo,b080uan01
# Boe Corporation 8.0" WUXGA TFT LCD panel
- boe,tv080wum-nl0
# Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
- innolux,p079zca
# Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel
- kingdisplay,kd097d04
# LG ACX467AKM-7 4.95" 1080×1920 LCD Panel

ファイルの表示

@@ -81,6 +81,10 @@ properties:
- boe,nv140fhmn49
# CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
- cdtech,s043wq26h-ct7
# CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel
- cdtech,s070pws19hp-fc21
# CDTech(H.K.) Electronics Limited 7" WVGA (800x480) TFT LCD Panel
- cdtech,s070swv29hg-dc44
# CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
- cdtech,s070wv95-ct16
# Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
@@ -157,6 +161,8 @@ properties:
- innolux,zj070na-01p
# Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
- koe,tx14d24vm1bpa
# Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel
- koe,tx26d202vm0bwa
# Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
- koe,tx31d200vm0baa
# Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel
@@ -245,6 +251,8 @@ properties:
- starry,kr122ea0sra
# Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel
- tianma,tm070jdhg30
# Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel
- tianma,tm070jvhg33
# Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
- tianma,tm070rvhg71
# Toshiba 8.9" WXGA (1280x768) TFT LCD panel

ファイルの表示

@@ -1,23 +0,0 @@
Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel
Required properties:
- compatible: should be "rocktech,jh057n00900"
- 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:
&mipi_dsi {
panel@0 {
compatible = "rocktech,jh057n00900";
reg = <0>;
backlight = <&backlight>;
reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
vcc-supply = <&reg_2v8_p>;
iovcc-supply = <&reg_1v8_p>;
};
};

ファイルの表示

@@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
maintainers:
- Ondrej Jirman <megi@xff.cz>
description: |
Rocktech JH057N00900 is a 720x1440 TFT LCD panel
connected using a MIPI-DSI video interface.
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
enum:
# Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
- rocktech,jh057n00900
# Xingbangda XBD599 5.99" 720x1440 TFT LCD panel
- xingbangda,xbd599
port: true
reg:
maxItems: 1
description: DSI virtual channel
vcc-supply:
description: Panel power supply
iovcc-supply:
description: I/O voltage supply
reset-gpios:
description: GPIO used for the reset pin
maxItems: 1
backlight:
description: Backlight used by the panel
$ref: "/schemas/types.yaml#/definitions/phandle"
required:
- compatible
- reg
- vcc-supply
- iovcc-supply
- reset-gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
dsi {
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "rocktech,jh057n00900";
reg = <0>;
vcc-supply = <&reg_2v8_p>;
iovcc-supply = <&reg_1v8_p>;
reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>;
backlight = <&backlight>;
};
};
...

ファイルの表示

@@ -1,56 +0,0 @@
Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
Required properties:
- compatible: "samsung,s6e8aa0"
- reg: the virtual channel number of a DSI peripheral
- vdd3-supply: core voltage supply
- vci-supply: voltage supply for analog circuits
- reset-gpios: a GPIO spec for the reset pin
- display-timings: timings for the connected panel as described by [1]
Optional properties:
- power-on-delay: delay after turning regulators on [ms]
- reset-delay: delay after reset sequence [ms]
- init-delay: delay after initialization sequence [ms]
- panel-width-mm: physical panel width [mm]
- panel-height-mm: physical panel height [mm]
- flip-horizontal: boolean to flip image horizontally
- flip-vertical: boolean to flip image vertically
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/display/panel/display-timing.txt
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
panel {
compatible = "samsung,s6e8aa0";
reg = <0>;
vdd3-supply = <&vcclcd_reg>;
vci-supply = <&vlcd_reg>;
reset-gpios = <&gpy4 5 0>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
panel-width-mm = <58>;
panel-height-mm = <103>;
flip-horizontal;
flip-vertical;
display-timings {
timing0: timing-0 {
clock-frequency = <57153600>;
hactive = <720>;
vactive = <1280>;
hfront-porch = <5>;
hback-porch = <5>;
hsync-len = <5>;
vfront-porch = <13>;
vback-porch = <1>;
vsync-len = <2>;
};
};
};

ファイルの表示

@@ -0,0 +1,100 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/samsung,s6e8aa0.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
maintainers:
- Andrzej Hajda <a.hajda@samsung.com>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: samsung,s6e8aa0
reg: true
reset-gpios: true
display-timings: true
vdd3-supply:
description: core voltage supply
vci-supply:
description: voltage supply for analog circuits
power-on-delay:
description: delay after turning regulators on [ms]
$ref: /schemas/types.yaml#/definitions/uint32
reset-delay:
description: delay after reset sequence [ms]
$ref: /schemas/types.yaml#/definitions/uint32
init-delay:
description: delay after initialization sequence [ms]
panel-width-mm:
description: physical panel width [mm]
panel-height-mm:
description: physical panel height [mm]
flip-horizontal:
description: boolean to flip image horizontally
type: boolean
flip-vertical:
description: boolean to flip image vertically
type: boolean
required:
- compatible
- reg
- vdd3-supply
- vci-supply
- reset-gpios
- display-timings
additionalProperties: false
examples:
- |
dsi {
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "samsung,s6e8aa0";
reg = <0>;
vdd3-supply = <&vcclcd_reg>;
vci-supply = <&vlcd_reg>;
reset-gpios = <&gpy4 5 0>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
panel-width-mm = <58>;
panel-height-mm = <103>;
flip-horizontal;
flip-vertical;
display-timings {
timing0: timing-0 {
clock-frequency = <57153600>;
hactive = <720>;
vactive = <1280>;
hfront-porch = <5>;
hback-porch = <5>;
hsync-len = <5>;
vfront-porch = <13>;
vback-porch = <1>;
vsync-len = <2>;
};
};
};
};
...

ファイルの表示

@@ -1,49 +0,0 @@
Sharp Microelectronics 10.1" WQXGA TFT LCD panel
This panel requires a dual-channel DSI host to operate. It supports two modes:
- left-right: each channel drives the left or right half of the screen
- even-odd: each channel drives the even or odd lines of the screen
Each of the DSI channels controls a separate DSI peripheral. The peripheral
driven by the first link (DSI-LINK1), left or even, is considered the primary
peripheral and controls the device. The 'link2' property contains a phandle
to the peripheral driven by the second link (DSI-LINK2, right or odd).
Note that in video mode the DSI-LINK1 interface always provides the left/even
pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it
is possible to program either link to drive the left/even or right/odd pixels
but for the sake of consistency this binding assumes that the same assignment
is chosen as for video mode.
Required properties:
- compatible: should be "sharp,lq101r1sx01"
- reg: DSI virtual channel of the peripheral
Required properties (for DSI-LINK1 only):
- link2: phandle to the DSI peripheral on the secondary link. Note that the
presence of this property marks the containing node as DSI-LINK1.
- power-supply: phandle of the regulator that provides the supply voltage
Optional properties (for DSI-LINK1 only):
- backlight: phandle of the backlight device attached to the panel
Example:
dsi@54300000 {
panel: panel@0 {
compatible = "sharp,lq101r1sx01";
reg = <0>;
link2 = <&secondary>;
power-supply = <...>;
backlight = <...>;
};
};
dsi@54400000 {
secondary: panel@0 {
compatible = "sharp,lq101r1sx01";
reg = <0>;
};
};

ファイルの表示

@@ -0,0 +1,87 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/sharp,lq101r1sx01.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sharp Microelectronics 10.1" WQXGA TFT LCD panel
maintainers:
- Thierry Reding <treding@nvidia.com>
description: |
This panel requires a dual-channel DSI host to operate. It supports two modes:
- left-right: each channel drives the left or right half of the screen
- even-odd: each channel drives the even or odd lines of the screen
Each of the DSI channels controls a separate DSI peripheral. The peripheral
driven by the first link (DSI-LINK1), left or even, is considered the primary
peripheral and controls the device. The 'link2' property contains a phandle
to the peripheral driven by the second link (DSI-LINK2, right or odd).
Note that in video mode the DSI-LINK1 interface always provides the left/even
pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it
is possible to program either link to drive the left/even or right/odd pixels
but for the sake of consistency this binding assumes that the same assignment
is chosen as for video mode.
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: sharp,lq101r1sx01
reg: true
power-supply: true
backlight: true
link2:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
phandle to the DSI peripheral on the secondary link. Note that the
presence of this property marks the containing node as DSI-LINK1
required:
- compatible
- reg
if:
required:
- link2
then:
required:
- power-supply
additionalProperties: false
examples:
- |
dsi0: dsi@fd922800 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0xfd922800 0x200>;
panel: panel@0 {
compatible = "sharp,lq101r1sx01";
reg = <0>;
link2 = <&secondary>;
power-supply = <&power>;
backlight = <&backlight>;
};
};
dsi1: dsi@fd922a00 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0xfd922a00 0x200>;
secondary: panel@0 {
compatible = "sharp,lq101r1sx01";
reg = <0>;
};
};
...

ファイルの表示

@@ -152,28 +152,28 @@ additionalProperties: false
examples:
- |
aliases {
display0 = &lcdc0;
};
/ {
compatible = "foo";
model = "foo";
#address-cells = <1>;
#size-cells = <1>;
chosen {
#address-cells = <1>;
#size-cells = <1>;
stdout-path = "display0";
framebuffer0: framebuffer@1d385000 {
compatible = "allwinner,simple-framebuffer", "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
reg = <0x1d385000 3840000>;
width = <1600>;
height = <1200>;
stride = <3200>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
lcd-supply = <&reg_dc1sw>;
display = <&lcdc0>;
};
chosen {
#address-cells = <1>;
#size-cells = <1>;
framebuffer0: framebuffer@1d385000 {
compatible = "allwinner,simple-framebuffer", "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
reg = <0x1d385000 3840000>;
width = <1600>;
height = <1200>;
stride = <3200>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
lcd-supply = <&reg_dc1sw>;
display = <&lcdc0>;
};
};
};
lcdc0: lcdc { };
...

ファイルの表示

@@ -0,0 +1,174 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/xlnx/xlnx,zynqmp-dpsub.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx ZynqMP DisplayPort Subsystem
description: |
The DisplayPort subsystem of Xilinx ZynqMP (Zynq UltraScale+ MPSoC)
implements the display and audio pipelines based on the DisplayPort v1.2
standard. The subsystem includes multiple functional blocks as below:
+------------------------------------------------------------+
+--------+ | +----------------+ +-----------+ |
| DPDMA | --->| | --> | Video | Video +-------------+ |
| 4x vid | | | | | Rendering | -+--> | | | +------+
| 2x aud | | | Audio/Video | --> | Pipeline | | | DisplayPort |---> | PHY0 |
+--------+ | | Buffer Manager | +-----------+ | | Source | | +------+
| | and STC | +-----------+ | | Controller | | +------+
Live Video --->| | --> | Audio | Audio | |---> | PHY1 |
| | | | Mixer | --+-> | | | +------+
Live Audio --->| | --> | | || +-------------+ |
| +----------------+ +-----------+ || |
+---------------------------------------||-------------------+
vv
Blended Video and
Mixed Audio to PL
The Buffer Manager interacts with external interface such as DMA engines or
live audio/video streams from the programmable logic. The Video Rendering
Pipeline blends the video and graphics layers and performs colorspace
conversion. The Audio Mixer mixes the incoming audio streams. The DisplayPort
Source Controller handles the DisplayPort protocol and connects to external
PHYs.
The subsystem supports 2 video and 2 audio streams, and various pixel formats
and depths up to 4K@30 resolution.
Please refer to "Zynq UltraScale+ Device Technical Reference Manual"
(https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf)
for more details.
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
properties:
compatible:
const: xlnx,zynqmp-dpsub-1.7
reg:
maxItems: 4
reg-names:
items:
- const: dp
- const: blend
- const: av_buf
- const: aud
interrupts:
maxItems: 1
clocks:
description:
The APB clock and at least one video clock are mandatory, the audio clock
is optional.
minItems: 2
maxItems: 4
items:
- description: dp_apb_clk is the APB clock
- description: dp_aud_clk is the Audio clock
- description:
dp_vtc_pixel_clk_in is the non-live video clock (from Processing
System)
- description:
dp_live_video_in_clk is the live video clock (from Programmable
Logic)
clock-names:
oneOf:
- minItems: 2
maxItems: 3
items:
- const: dp_apb_clk
- enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
- enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
- minItems: 3
maxItems: 4
items:
- const: dp_apb_clk
- const: dp_aud_clk
- enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
- enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ]
power-domains:
maxItems: 1
resets:
maxItems: 1
dmas:
maxItems: 4
items:
- description: Video layer, plane 0 (RGB or luma)
- description: Video layer, plane 1 (U/V or U)
- description: Video layer, plane 2 (V)
- description: Graphics layer
dma-names:
items:
- const: vid0
- const: vid1
- const: vid2
- const: gfx0
phys:
description: PHYs for the DP data lanes
minItems: 1
maxItems: 2
phy-names:
minItems: 1
maxItems: 2
items:
- const: dp-phy0
- const: dp-phy1
required:
- compatible
- reg
- reg-names
- interrupts
- clocks
- clock-names
- power-domains
- resets
- dmas
- dma-names
- phys
- phy-names
additionalProperties: false
examples:
- |
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/reset/xlnx-zynqmp-resets.h>
display@fd4a0000 {
compatible = "xlnx,zynqmp-dpsub-1.7";
reg = <0x0 0xfd4a0000 0x0 0x1000>,
<0x0 0xfd4aa000 0x0 0x1000>,
<0x0 0xfd4ab000 0x0 0x1000>,
<0x0 0xfd4ac000 0x0 0x1000>;
reg-names = "dp", "blend", "av_buf", "aud";
interrupts = <0 119 4>;
interrupt-parent = <&gic>;
clock-names = "dp_apb_clk", "dp_aud_clk", "dp_live_video_in_clk";
clocks = <&dp_aclk>, <&clkc 17>, <&si570_1>;
power-domains = <&pd_dp>;
resets = <&reset ZYNQMP_RESET_DP>;
dma-names = "vid0", "vid1", "vid2", "gfx0";
dmas = <&xlnx_dpdma 0>,
<&xlnx_dpdma 1>,
<&xlnx_dpdma 2>,
<&xlnx_dpdma 3>;
phys = <&psgtr 1 PHY_TYPE_DP 0 3 27000000>,
<&psgtr 0 PHY_TYPE_DP 1 3 27000000>;
phy-names = "dp-phy0", "dp-phy1";
};
...

ファイルの表示

@@ -0,0 +1,68 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/xilinx/xlnx,zynqmp-dpdma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Xilinx ZynqMP DisplayPort DMA Controller Device Tree Bindings
description: |
These bindings describe the DMA engine included in the Xilinx ZynqMP
DisplayPort Subsystem. The DMA engine supports up to 6 DMA channels (3
channels for a video stream, 1 channel for a graphics stream, and 2 channels
for an audio stream).
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
allOf:
- $ref: "../dma-controller.yaml#"
properties:
"#dma-cells":
const: 1
description: |
The cell is the DMA channel ID (see dt-bindings/dma/xlnx-zynqmp-dpdma.h
for a list of channel IDs).
compatible:
const: xlnx,zynqmp-dpdma
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
description: The AXI clock
maxItems: 1
clock-names:
const: axi_clk
required:
- "#dma-cells"
- compatible
- reg
- interrupts
- clocks
- clock-names
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
dma: dma-controller@fd4c0000 {
compatible = "xlnx,zynqmp-dpdma";
reg = <0x0 0xfd4c0000 0x0 0x1000>;
interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&gic>;
clocks = <&dpdma_clk>;
clock-names = "axi_clk";
#dma-cells = <1>;
};
...

ファイルの表示

@@ -1167,6 +1167,8 @@ patternProperties:
description: Xiaomi Technology Co., Ltd.
"^xillybus,.*":
description: Xillybus Ltd.
"^xingbangda,.*":
description: Shenzhen Xingbangda Display Technology Co., Ltd
"^xinpeng,.*":
description: Shenzhen Xinpeng Technology Co., Ltd
"^xlnx,.*":

ファイルの表示

@@ -100,11 +100,11 @@ CPU Access to DMA Buffer Objects
.. kernel-doc:: drivers/dma-buf/dma-buf.c
:doc: cpu access
Fence Poll Support
~~~~~~~~~~~~~~~~~~
Implicit Fence Poll Support
~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/dma-buf/dma-buf.c
:doc: fence polling
:doc: implicit fence polling
Kernel Functions and Structures Reference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -133,6 +133,18 @@ DMA Fences
.. kernel-doc:: drivers/dma-buf/dma-fence.c
:doc: DMA fences overview
DMA Fence Cross-Driver Contract
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/dma-buf/dma-fence.c
:doc: fence cross-driver contract
DMA Fence Signalling Annotations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. kernel-doc:: drivers/dma-buf/dma-fence.c
:doc: fence signalling annotation
DMA Fences Functions Reference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -166,3 +178,73 @@ DMA Fence uABI/Sync File
.. kernel-doc:: include/linux/sync_file.h
:internal:
Indefinite DMA Fences
~~~~~~~~~~~~~~~~~~~~
At various times &dma_fence with an indefinite time until dma_fence_wait()
finishes have been proposed. Examples include:
* Future fences, used in HWC1 to signal when a buffer isn't used by the display
any longer, and created with the screen update that makes the buffer visible.
The time this fence completes is entirely under userspace's control.
* Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet
been set. Used to asynchronously delay command submission.
* Userspace fences or gpu futexes, fine-grained locking within a command buffer
that userspace uses for synchronization across engines or with the CPU, which
are then imported as a DMA fence for integration into existing winsys
protocols.
* Long-running compute command buffers, while still using traditional end of
batch DMA fences for memory management instead of context preemption DMA
fences which get reattached when the compute job is rescheduled.
Common to all these schemes is that userspace controls the dependencies of these
fences and controls when they fire. Mixing indefinite fences with normal
in-kernel DMA fences does not work, even when a fallback timeout is included to
protect against malicious userspace:
* Only the kernel knows about all DMA fence dependencies, userspace is not aware
of dependencies injected due to memory management or scheduler decisions.
* Only userspace knows about all dependencies in indefinite fences and when
exactly they will complete, the kernel has no visibility.
Furthermore the kernel has to be able to hold up userspace command submission
for memory management needs, which means we must support indefinite fences being
dependent upon DMA fences. If the kernel also support indefinite fences in the
kernel like a DMA fence, like any of the above proposal would, there is the
potential for deadlocks.
.. kernel-render:: DOT
:alt: Indefinite Fencing Dependency Cycle
:caption: Indefinite Fencing Dependency Cycle
digraph "Fencing Cycle" {
node [shape=box bgcolor=grey style=filled]
kernel [label="Kernel DMA Fences"]
userspace [label="userspace controlled fences"]
kernel -> userspace [label="memory management"]
userspace -> kernel [label="Future fence, fence proxy, ..."]
{ rank=same; kernel userspace }
}
This means that the kernel might accidentally create deadlocks
through memory management dependencies which userspace is unaware of, which
randomly hangs workloads until the timeout kicks in. Workloads, which from
userspace's perspective, do not contain a deadlock. In such a mixed fencing
architecture there is no single entity with knowledge of all dependencies.
Thefore preventing such deadlocks from within the kernel is not possible.
The only solution to avoid dependencies loops is by not allowing indefinite
fences in the kernel. This means:
* No future fences, proxy fences or userspace fences imported as DMA fences,
with or without a timeout.
* No DMA fences that signal end of batchbuffer for command submission where
userspace is allowed to use userspace fencing or long running compute
workloads. This also means no implicit fencing for shared buffers in these
cases.

ファイルの表示

@@ -86,7 +86,9 @@ The details of these operations are:
- interleaved_dma: This is common to Slave as well as M2M clients. For slave
address of devices' fifo could be already known to the driver.
Various types of operations could be expressed by setting
appropriate values to the 'dma_interleaved_template' members.
appropriate values to the 'dma_interleaved_template' members. Cyclic
interleaved DMA transfers are also possible if supported by the channel by
setting the DMA_PREP_REPEAT transfer flag.
A non-NULL return of this transfer API represents a "descriptor" for
the given transaction.

ファイルの表示

@@ -239,6 +239,27 @@ Currently, the types available are:
want to transfer a portion of uncompressed data directly to the
display to print it
- DMA_REPEAT
- The device supports repeated transfers. A repeated transfer, indicated by
the DMA_PREP_REPEAT transfer flag, is similar to a cyclic transfer in that
it gets automatically repeated when it ends, but can additionally be
replaced by the client.
- This feature is limited to interleaved transfers, this flag should thus not
be set if the DMA_INTERLEAVE flag isn't set. This limitation is based on
the current needs of DMA clients, support for additional transfer types
should be added in the future if and when the need arises.
- DMA_LOAD_EOT
- The device supports replacing repeated transfers at end of transfer (EOT)
by queuing a new transfer with the DMA_PREP_LOAD_EOT flag set.
- Support for replacing a currently running transfer at another point (such
as end of burst instead of end of transfer) will be added in the future
based on DMA clients needs, if and when the need arises.
These various types will also affect how the source and destination
addresses change over time.
@@ -531,6 +552,34 @@ DMA_CTRL_REUSE
writes for which the descriptor should be in different format from
normal data descriptors.
- DMA_PREP_REPEAT
- If set, the transfer will be automatically repeated when it ends until a
new transfer is queued on the same channel with the DMA_PREP_LOAD_EOT flag.
If the next transfer to be queued on the channel does not have the
DMA_PREP_LOAD_EOT flag set, the current transfer will be repeated until the
client terminates all transfers.
- This flag is only supported if the channel reports the DMA_REPEAT
capability.
- DMA_PREP_LOAD_EOT
- If set, the transfer will replace the transfer currently being executed at
the end of the transfer.
- This is the default behaviour for non-repeated transfers, specifying
DMA_PREP_LOAD_EOT for non-repeated transfers will thus make no difference.
- When using repeated transfers, DMA clients will usually need to set the
DMA_PREP_LOAD_EOT flag on all transfers, otherwise the channel will keep
repeating the last repeated transfer and ignore the new transfers being
queued. Failure to set DMA_PREP_LOAD_EOT will appear as if the channel was
stuck on the previous transfer.
- This flag is only supported if the channel reports the DMA_LOAD_EOT
capability.
General Design Notes
====================

ファイルの表示

@@ -127,7 +127,7 @@ At least on the EP9315 there is a silicon bug which causes bit 27 of
the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is
an unofficial errata for this bug at::
http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2
https://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2
By default the EP93xx framebuffer driver checks if the allocated physical
address has bit 27 set. If it does, then the memory is freed and an

ファイルの表示

@@ -411,15 +411,3 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
SHMEM GEM Helper Reference
==========================
.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
:doc: overview
.. kernel-doc:: include/drm/drm_gem_shmem_helper.h
:internal:
.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
:export:

ファイルの表示

@@ -460,6 +460,12 @@ HDMI Specific Connector Properties
.. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: HDMI connector properties
Standard CRTC Properties
------------------------
.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
:doc: standard CRTC properties
Plane Composition Properties
----------------------------
@@ -537,3 +543,18 @@ Vertical Blanking and Interrupt Handling Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_vblank.c
:export:
Vertical Blank Work
===================
.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c
:doc: vblank works
Vertical Blank Work Functions Reference
---------------------------------------
.. kernel-doc:: include/drm/drm_vblank_work.h
:internal:
.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c
:export:

ファイルの表示

@@ -179,10 +179,7 @@ GEM Objects Lifetime
All GEM objects are reference-counted by the GEM core. References can be
acquired and release by calling drm_gem_object_get() and drm_gem_object_put()
respectively. The caller must hold the :c:type:`struct drm_device <drm_device>`
struct_mutex lock when calling drm_gem_object_get(). As a convenience, GEM
provides drm_gem_object_put_unlocked() functions that can be called without
holding the lock.
respectively.
When the last reference to a GEM object is released the GEM core calls
the :c:type:`struct drm_driver <drm_driver>` gem_free_object_unlocked
@@ -373,6 +370,18 @@ GEM CMA Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
:export:
GEM SHMEM Helper Function Reference
-----------------------------------
.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
:doc: overview
.. kernel-doc:: include/drm/drm_gem_shmem_helper.h
:internal:
.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
:export:
GEM VRAM Helper Functions Reference
-----------------------------------

ファイルの表示

@@ -157,8 +157,8 @@ private lock. The tricky part is the BO free functions, since those can't
reliably take that lock any more. Instead state needs to be protected with
suitable subordinate locks or some cleanup work pushed to a worker thread. For
performance-critical drivers it might also be better to go with a more
fine-grained per-buffer object and per-context lockings scheme. Currently only the
``msm`` driver still use ``struct_mutex``.
fine-grained per-buffer object and per-context lockings scheme. Currently only
the ``msm`` and `i915` drivers use ``struct_mutex``.
Contact: Daniel Vetter, respective driver maintainers
@@ -305,7 +305,7 @@ acquire context. Replace the boilerplate code surrounding
drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END() instead.
This should also be done for all places where drm_modest_lock_all() is still
This should also be done for all places where drm_modeset_lock_all() is still
used.
As a reference, take a look at the conversions already completed in drm core.
@@ -327,26 +327,6 @@ Contact: Laurent Pinchart, Daniel Vetter
Level: Intermediate (mostly because it is a huge tasks without good partial
milestones, not technically itself that challenging)
Convert direct mode.vrefresh accesses to use drm_mode_vrefresh()
----------------------------------------------------------------
drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it
is risky and has been known to cause div-by-zero bugs. Fortunately, drm core
has helper which will use mode.vrefresh if it's !0 and will calculate it from
the timings when it's 0.
Use simple search/replace, or (more fun) cocci to replace instances of direct
vrefresh access with a call to the helper. Check out
https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for
inspiration.
Once all instances of vrefresh have been converted, remove vrefresh from
drm_display_mode to avoid future use.
Contact: Sean Paul
Level: Starter
connector register/unregister fixes
-----------------------------------
@@ -392,6 +372,38 @@ Contact: Laurent Pinchart, respective driver maintainers
Level: Intermediate
Consolidate custom driver modeset properties
--------------------------------------------
Before atomic modeset took place, many drivers where creating their own
properties. Among other things, atomic brought the requirement that custom,
driver specific properties should not be used.
For this task, we aim to introduce core helpers or reuse the existing ones
if available:
A quick, unconfirmed, examples list.
Introduce core helpers:
- audio (amdgpu, intel, gma500, radeon)
- brightness, contrast, etc (armada, nouveau) - overlay only (?)
- broadcast rgb (gma500, intel)
- colorkey (armada, nouveau, rcar) - overlay only (?)
- dither (amdgpu, nouveau, radeon) - varies across drivers
- underscan family (amdgpu, radeon, nouveau)
Already in core:
- colorspace (sti)
- tv format names, enhancements (gma500, intel)
- tv overscan, margins, etc. (gma500, intel)
- zorder (omapdrm) - same as zpos (?)
Contact: Emil Velikov, respective driver maintainers
Level: Intermediate
Core refactorings
=================

ファイルの表示

@@ -185,7 +185,7 @@ enhancing the kernel code to adapt as a kernel module and also did the
implementation of the user space side [3]. Now (2009) Tiago Vignatti and Dave
Airlie finally put this work in shape and queued to Jesse Barnes' PCI tree.
0) http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347
1) http://lists.freedesktop.org/archives/xorg/2005-March/006663.html
2) http://lists.freedesktop.org/archives/xorg/2005-March/006745.html
3) http://lists.freedesktop.org/archives/xorg/2007-October/029507.html
0) https://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347
1) https://lists.freedesktop.org/archives/xorg/2005-March/006663.html
2) https://lists.freedesktop.org/archives/xorg/2005-March/006745.html
3) https://lists.freedesktop.org/archives/xorg/2007-October/029507.html