mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-28 10:41:38 -04:00
main drm pull request for 4.12 kernel
-----BEGIN PGP SIGNATURE----- iQIcBAABAgAGBQJZCTzvAAoJEAx081l5xIa+9kcQAJsQiija4/7QGx6IzakOMqjx WulJ3zYG/cU/HLwCBcuWRDF6wAj+7iWNeLCPmolHwEazcI8tQVdgMlWtbdMbDh8U ckzD3FBXsEVfIfab+u6tyoUkm3l/VDhMXbjkUK7NTo/+dkRqe5LuFfZPCGN09jft Y+5salkRXzDhXPSFsqmjfzhx1v7PTgf0a5HUenKWEWOv+sJQaW4/iPvcDSIcg5qR l9WjAqro1NpFYhUodnh6DkLeledL1U5whdtp/yvrUAck8y+WP/jwGYmQ7pZ0UkQm f0M3kV6K67ox9eqN++jsGX5o8sB1qF01Uh95kBAnyzYzsw4ZlMCx6pV7PDX+J88M UBNMEqX10hrLkNJA9lGjPWx+/6fudcwg9anKvTRO3Uyx7MbYoJAgjzAM+yBqqtV0 8Otxa4Bw0V2pmUD+0lqJDERRvE77VCXkLb8SaI5lQo0MHpQqT2cZA+GD+B+rZHO6 Ie5LDFY87vM2GG1IECufG+xOa3v6sn2FfQ1ouu1KNGKOAMBKcQCQyQx3kGVuNW2i HDACVXALJgXdRlVLm4jydOCZdRoguX7AWmRjtdwxgaO+lBcGfLhkXdjLQ7Ho+29p 32ArJfkZPfA53vMB6lHxAfbtrs1q2RzyVnPHj/KqeJnGZbABKTsF2HQ5BQc4Xq/J mqXoz6Oubdvk4Pwyx7Ne =UxFF -----END PGP SIGNATURE----- Merge tag 'drm-for-v4.12' of git://people.freedesktop.org/~airlied/linux Pull drm u pdates from Dave Airlie: "This is the main drm pull request for v4.12. Apart from two fixes pulls, everything should have been in drm-next for at least 2 weeks. The biggest thing in here is AMD released the public headers for their upcoming VEGA GPUs. These as always are quite a sizeable chunk of header files. They've also added initial non-display support for those GPUs, though they aren't available in production yet. Otherwise it's pretty much normal. New bridge drivers: - megachips-stdpxxxx-ge-b850v3-fw LVDS->DP++ - generic LVDS bridge support. Core: - Displayport link train failure reporting to userspace - debugfs interface cleaned up - subsystem TODO in kerneldoc now - Extended fbdev support (flipping and vblank wait) - drm_platform removed - EDP CRC support in helper - HF-VSDB SCDC support in EDID parser - Lots of code cleanups and header extraction - Thunderbolt external GPU awareness - Atomic helper improvements - Documentation improvements panel: - Sitronix and Samsung new panel support amdgpu: - Preliminary vega10 support - Multi-level page table support - GPU sensor support for userspace - PRT support for sparse buffers - SR-IOV improvements - Non-contig VRAM CPU mapping i915: - Atomic modesetting enabled by default on Gen5+ - LSPCON improvements - Atomic state handling for cdclk - GPU reset improvements - In-kernel unit tests - Geminilake improvements and color manager support - Designware i2c fixes - vblank evasion improvements - Hotplug safe connector iterators - GVT scheduler QoS support - GVT Kabylake support nouveau: - Acceleration support for Pascal (GP10x). - Rearchitecture of code handling proprietary signed firmware - Fix GTX 970 with odd MMU configuration - GP10B support - GP107 acceleration support vmwgfx: - Atomic modesetting support for vmwgfx omapdrm: - Support for render nodes - Refactor omapdss code - Fix some probe ordering issues - Fix too dark RGB565 rendering sunxi: - prelim rework for multiple pipes. mali-dp: - Color management support - Plane scaling - Power management improvements imx-drm: - Prefetch Resolve Engine/Gasket on i.MX6QP - Deferred plane disabling - Separate alpha support mediatek: - Mediatek SoC MT2701 support rcar-du: - Gen3 HDMI support msm: - 4k support for newer chips - OPP bindings for gpu - prep work for per-process pagetables vc4: - HDMI audio support - fixes qxl: - minor fixes. dw-hdmi: - PHY improvements - CSC fixes - Amlogic GX SoC support" * tag 'drm-for-v4.12' of git://people.freedesktop.org/~airlied/linux: (1778 commits) drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr() drm/nouveau/kms: Increase max retries in scanout position queries. drm/nouveau/bios/bitP: check that table is long enough for optional pointers drm/nouveau/fifo/nv40: no ctxsw for pre-nv44 mpeg engine drm: mali-dp: use div_u64 for expensive 64-bit divisions drm/i915: Confirm the request is still active before adding it to the await drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio drm/i915/selftests: Allocate inode/file dynamically drm/i915: Fix system hang with EI UP masked on Haswell drm/i915: checking for NULL instead of IS_ERR() in mock selftests drm/i915: Perform link quality check unconditionally during long pulse drm/i915: Fix use after free in lpe_audio_platdev_destroy() drm/i915: Use the right mapping_gfp_mask for final shmem allocation drm/i915: Make legacy cursor updates more unsynced drm/i915: Apply a cond_resched() to the saturated signaler drm/i915: Park the signaler before sleeping drm: mali-dp: Check the mclk rate and allow up/down scaling drm: mali-dp: Enable image enhancement when scaling drm: mali-dp: Add plane upscaling support ...
This commit is contained in:
Linus Torvalds
commit
2f34c1231b
1060 changed files with 456334 additions and 27130 deletions
|
|
@ -59,9 +59,9 @@
|
|||
/* Fixed header pattern */
|
||||
header: .byte 0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00
|
||||
|
||||
mfg_id: .word swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
|
||||
mfg_id: .hword swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3))
|
||||
|
||||
prod_code: .word 0
|
||||
prod_code: .hword 0
|
||||
|
||||
/* Serial number. 32 bits, little endian. */
|
||||
serial_number: .long SERIAL
|
||||
|
|
@ -177,7 +177,7 @@ std_vres: .byte (XY_RATIO<<6)+VFREQ-60
|
|||
|
||||
descriptor1:
|
||||
/* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */
|
||||
clock: .word CLOCK/10
|
||||
clock: .hword CLOCK/10
|
||||
|
||||
/* Horizontal active pixels 8 lsbits (0-4095) */
|
||||
x_act_lsb: .byte XPIX&0xff
|
||||
|
|
|
|||
|
|
@ -0,0 +1,111 @@
|
|||
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"
|
||||
- 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"
|
||||
|
||||
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
|
||||
|
||||
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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -34,6 +34,9 @@ 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"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
Parallel to LVDS Encoder
|
||||
------------------------
|
||||
|
||||
This binding supports the parallel to LVDS encoders that don't require any
|
||||
configuration.
|
||||
|
||||
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 binding targets devices compatible with the following
|
||||
specifications only.
|
||||
|
||||
[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)
|
||||
|
||||
Those devices have been marketed under the FPD-Link and FlatLink brand names
|
||||
among others.
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be "lvds-encoder"
|
||||
|
||||
Required nodes:
|
||||
|
||||
This device has two video ports. Their connections are modeled using the OF
|
||||
graph bindings specified in Documentation/devicetree/bindings/graph.txt.
|
||||
|
||||
- Video port 0 for parallel input
|
||||
- Video port 1 for LVDS output
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
lvds-encoder {
|
||||
compatible = "lvds-encoder";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
lvds_enc_in: endpoint {
|
||||
remote-endpoint = <&display_out_rgb>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
lvds_enc_out: endpoint {
|
||||
remote-endpoint = <&lvds_panel_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
Drivers for the second video output of the GE B850v3:
|
||||
STDP4028-ge-b850v3-fw bridges (LVDS-DP)
|
||||
STDP2690-ge-b850v3-fw bridges (DP-DP++)
|
||||
|
||||
The video processing pipeline on the second output on the GE B850v3:
|
||||
|
||||
Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
|
||||
|
||||
Each bridge has a dedicated flash containing firmware for supporting the custom
|
||||
design. The result is that, in this design, neither the STDP4028 nor the
|
||||
STDP2690 behave as the stock bridges would. The compatible strings include the
|
||||
suffix "-ge-b850v3-fw" to make it clear that the driver is for the bridges with
|
||||
the firmware specific for the GE B850v3.
|
||||
|
||||
The hardware do not provide control over the video processing pipeline, as the
|
||||
two bridges behaves as a single one. The only interfaces exposed by the
|
||||
hardware are EDID, HPD, and interrupts.
|
||||
|
||||
stdp4028-ge-b850v3-fw required properties:
|
||||
- compatible : "megachips,stdp4028-ge-b850v3-fw"
|
||||
- reg : I2C bus address
|
||||
- interrupt-parent : phandle of the interrupt controller that services
|
||||
interrupts to the device
|
||||
- interrupts : one interrupt should be described here, as in
|
||||
<0 IRQ_TYPE_LEVEL_HIGH>
|
||||
- ports : One input port(reg = <0>) and one output port(reg = <1>)
|
||||
|
||||
stdp2690-ge-b850v3-fw required properties:
|
||||
compatible : "megachips,stdp2690-ge-b850v3-fw"
|
||||
- reg : I2C bus address
|
||||
- ports : One input port(reg = <0>) and one output port(reg = <1>)
|
||||
|
||||
Example:
|
||||
|
||||
&mux2_i2c2 {
|
||||
status = "okay";
|
||||
clock-frequency = <100000>;
|
||||
|
||||
stdp4028@73 {
|
||||
compatible = "megachips,stdp4028-ge-b850v3-fw";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
reg = <0x73>;
|
||||
|
||||
interrupt-parent = <&gpio2>;
|
||||
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
stdp4028_in: endpoint {
|
||||
remote-endpoint = <&lvds0_out>;
|
||||
};
|
||||
};
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
stdp4028_out: endpoint {
|
||||
remote-endpoint = <&stdp2690_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
stdp2690@72 {
|
||||
compatible = "megachips,stdp2690-ge-b850v3-fw";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
reg = <0x72>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
stdp2690_in: endpoint {
|
||||
remote-endpoint = <&stdp4028_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
stdp2690_out: endpoint {
|
||||
/* Connector for external display */
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
Renesas Gen3 DWC HDMI TX Encoder
|
||||
================================
|
||||
|
||||
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
|
||||
with a companion PHY IP.
|
||||
|
||||
These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
|
||||
Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
|
||||
following device-specific properties.
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Shall contain one or more of
|
||||
- "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
|
||||
- "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 compatible HDMI TX
|
||||
|
||||
When compatible with generic versions, nodes must list the SoC-specific
|
||||
version corresponding to the platform first, followed by the
|
||||
family-specific version.
|
||||
|
||||
- reg: See dw_hdmi.txt.
|
||||
- interrupts: HDMI interrupt number
|
||||
- clocks: See dw_hdmi.txt.
|
||||
- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
|
||||
- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
|
||||
corresponding to the video input of the controller and one port numbered 1
|
||||
corresponding to its HDMI output. Each port shall have a single endpoint.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- power-domains: Shall reference the power domain that contains the DWC HDMI,
|
||||
if any.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
hdmi0: hdmi0@fead0000 {
|
||||
compatible = "renesas,r8a7795-dw-hdmi";
|
||||
reg = <0 0xfead0000 0 0x10000>;
|
||||
interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
|
||||
clock-names = "iahb", "isfr";
|
||||
power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
|
||||
status = "disabled";
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
dw_hdmi0_in: endpoint {
|
||||
remote-endpoint = <&du_out_hdmi0>;
|
||||
};
|
||||
};
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
rcar_dw_hdmi0_out: endpoint {
|
||||
remote-endpoint = <&hdmi0_con>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
hdmi0-out {
|
||||
compatible = "hdmi-connector";
|
||||
label = "HDMI0 OUT";
|
||||
type = "a";
|
||||
|
||||
port {
|
||||
hdmi0_con: endpoint {
|
||||
remote-endpoint = <&rcar_dw_hdmi0_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -21,13 +21,19 @@ Freescale i.MX IPUv3
|
|||
====================
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,<chip>-ipu"
|
||||
- compatible: Should be "fsl,<chip>-ipu" where <chip> is one of
|
||||
- imx51
|
||||
- imx53
|
||||
- imx6q
|
||||
- imx6qp
|
||||
- reg: should be register base and length as documented in the
|
||||
datasheet
|
||||
- interrupts: Should contain sync interrupt and error interrupt,
|
||||
in this order.
|
||||
- resets: phandle pointing to the system reset controller and
|
||||
reset line index, see reset/fsl,imx-src.txt for details
|
||||
Additional required properties for fsl,imx6qp-ipu:
|
||||
- fsl,prg: phandle to prg node associated with this IPU instance
|
||||
Optional properties:
|
||||
- port@[0-3]: Port nodes with endpoint definitions as defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
|
@ -53,6 +59,57 @@ ipu: ipu@18000000 {
|
|||
};
|
||||
};
|
||||
|
||||
Freescale i.MX PRE (Prefetch Resolve Engine)
|
||||
============================================
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "fsl,imx6qp-pre"
|
||||
- reg: should be register base and length as documented in the
|
||||
datasheet
|
||||
- clocks : phandle to the PRE axi clock input, as described
|
||||
in Documentation/devicetree/bindings/clock/clock-bindings.txt and
|
||||
Documentation/devicetree/bindings/clock/imx6q-clock.txt.
|
||||
- clock-names: should be "axi"
|
||||
- interrupts: should contain the PRE interrupt
|
||||
- fsl,iram: phandle pointing to the mmio-sram device node, that should be
|
||||
used for the PRE SRAM double buffer.
|
||||
|
||||
example:
|
||||
|
||||
pre@21c8000 {
|
||||
compatible = "fsl,imx6qp-pre";
|
||||
reg = <0x021c8000 0x1000>;
|
||||
interrupts = <GIC_SPI 90 IRQ_TYPE_EDGE_RISING>;
|
||||
clocks = <&clks IMX6QDL_CLK_PRE0>;
|
||||
clock-names = "axi";
|
||||
fsl,iram = <&ocram2>;
|
||||
};
|
||||
|
||||
Freescale i.MX PRG (Prefetch Resolve Gasket)
|
||||
============================================
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "fsl,imx6qp-prg"
|
||||
- reg: should be register base and length as documented in the
|
||||
datasheet
|
||||
- clocks : phandles to the PRG ipg and axi clock inputs, as described
|
||||
in Documentation/devicetree/bindings/clock/clock-bindings.txt and
|
||||
Documentation/devicetree/bindings/clock/imx6q-clock.txt.
|
||||
- clock-names: should be "ipg" and "axi"
|
||||
- fsl,pres: phandles to the PRE units attached to this PRG, with the fixed
|
||||
PRE as the first entry and the muxable PREs following.
|
||||
|
||||
example:
|
||||
|
||||
prg@21cc000 {
|
||||
compatible = "fsl,imx6qp-prg";
|
||||
reg = <0x021cc000 0x1000>;
|
||||
clocks = <&clks IMX6QDL_CLK_PRG0_APB>,
|
||||
<&clks IMX6QDL_CLK_PRG0_AXI>;
|
||||
clock-names = "ipg", "axi";
|
||||
fsl,pres = <&pre1>, <&pre2>, <&pre3>;
|
||||
};
|
||||
|
||||
Parallel display support
|
||||
========================
|
||||
|
||||
|
|
|
|||
|
|
@ -40,6 +40,7 @@ Required properties (all function blocks):
|
|||
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
|
||||
"mediatek,<chip>-disp-mutex" - display mutex
|
||||
"mediatek,<chip>-disp-od" - overdrive
|
||||
the supported chips are mt2701 and mt8173.
|
||||
- reg: Physical base address and length of the function block register space
|
||||
- interrupts: The interrupt signal from the function block (required, except for
|
||||
merge and split function blocks).
|
||||
|
|
@ -54,6 +55,7 @@ Required properties (DMA function blocks):
|
|||
"mediatek,<chip>-disp-ovl"
|
||||
"mediatek,<chip>-disp-rdma"
|
||||
"mediatek,<chip>-disp-wdma"
|
||||
the supported chips are mt2701 and mt8173.
|
||||
- larb: Should contain a phandle pointing to the local arbiter device as defined
|
||||
in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
|
||||
- iommus: Should point to the respective IOMMU block with master port as
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ channel output.
|
|||
|
||||
Required properties:
|
||||
- compatible: "mediatek,<chip>-dsi"
|
||||
the supported chips are mt2701 and mt8173.
|
||||
- reg: Physical base address and length of the controller's registers
|
||||
- interrupts: The interrupt signal from the function block.
|
||||
- clocks: device clocks
|
||||
|
|
@ -25,6 +26,7 @@ The MIPI TX configuration module controls the MIPI D-PHY.
|
|||
|
||||
Required properties:
|
||||
- compatible: "mediatek,<chip>-mipi-tx"
|
||||
the supported chips are mt2701 and mt8173.
|
||||
- reg: Physical base address and length of the controller's registers
|
||||
- clocks: PLL reference clock
|
||||
- clock-output-names: name of the output clock line to the DSI encoder
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "ampire,am-480272h3tmqw-t01h"
|
||||
|
||||
Optional properties:
|
||||
- power-supply: regulator to provide the supply voltage
|
||||
- enable-gpios: GPIO pin to enable or disable the panel
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
|
||||
Optional nodes:
|
||||
- Video port for RGB input.
|
||||
|
||||
Example:
|
||||
panel_rgb: panel-rgb {
|
||||
compatible = "ampire,am-480272h3tmqw-t01h";
|
||||
enable-gpios = <&gpioa 8 1>;
|
||||
port {
|
||||
panel_in_rgb: endpoint {
|
||||
remote-endpoint = <&controller_out_rgb>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
Mitsubishi AA204XD12 LVDS Display Panel
|
||||
=======================================
|
||||
|
||||
The AA104XD12 is a 10.4" XGA TFT-LCD display panel.
|
||||
|
||||
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
|
||||
with the following device-specific properties.
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
|
||||
order.
|
||||
- vcc-supply: Reference to the regulator powering the panel VCC pins.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel {
|
||||
compatible = "mitsubishi,aa104xd12", "panel-lvds";
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
|
||||
width-mm = <210>;
|
||||
height-mm = <158>;
|
||||
|
||||
data-mapping = "jeida-24";
|
||||
|
||||
panel-timing {
|
||||
/* 1024x768 @65Hz */
|
||||
clock-frequency = <65000000>;
|
||||
hactive = <1024>;
|
||||
vactive = <768>;
|
||||
hsync-len = <136>;
|
||||
hfront-porch = <20>;
|
||||
hback-porch = <160>;
|
||||
vfront-porch = <3>;
|
||||
vback-porch = <29>;
|
||||
vsync-len = <6>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
Mitsubishi AA121TD01 LVDS Display Panel
|
||||
=======================================
|
||||
|
||||
The AA121TD01 is a 12.1" WXGA TFT-LCD display panel.
|
||||
|
||||
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
|
||||
with the following device-specific properties.
|
||||
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
|
||||
order.
|
||||
- vcc-supply: Reference to the regulator powering the panel VCC pins.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
panel {
|
||||
compatible = "mitsubishi,aa121td01", "panel-lvds";
|
||||
vcc-supply = <&vcc_3v3>;
|
||||
|
||||
width-mm = <261>;
|
||||
height-mm = <163>;
|
||||
|
||||
data-mapping = "jeida-24";
|
||||
|
||||
panel-timing {
|
||||
/* 1280x800 @60Hz */
|
||||
clock-frequency = <71000000>;
|
||||
hactive = <1280>;
|
||||
vactive = <800>;
|
||||
hsync-len = <70>;
|
||||
hfront-porch = <20>;
|
||||
hback-porch = <70>;
|
||||
vsync-len = <5>;
|
||||
vfront-porch = <3>;
|
||||
vback-porch = <15>;
|
||||
};
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&lvds_encoder>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
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/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.
|
||||
|
||||
|
||||
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.
|
||||
|
|
@ -9,6 +9,7 @@ Optional properties:
|
|||
- enable-gpios: panel enable gpio
|
||||
- reset-gpios: GPIO to control the RESET pin
|
||||
- vcc-supply: phandle of regulator that will be used to enable power to the display
|
||||
- backlight: phandle of the backlight device
|
||||
|
||||
Required nodes:
|
||||
- "panel-timing" containing video timings
|
||||
|
|
@ -22,6 +23,8 @@ lcd0: display@0 {
|
|||
compatible = "samsung,lte430wq-f0c", "panel-dpi";
|
||||
label = "lcd";
|
||||
|
||||
backlight = <&backlight>;
|
||||
|
||||
port {
|
||||
lcd_in: endpoint {
|
||||
remote-endpoint = <&dpi_out>;
|
||||
|
|
|
|||
120
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
Normal file
120
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
Normal file
|
|
@ -0,0 +1,120 @@
|
|||
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.
|
||||
- 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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
|
||||
|
||||
Required properties:
|
||||
- compatible: "samsung,s6e3ha2"
|
||||
- reg: the virtual channel number of a DSI peripheral
|
||||
- vdd3-supply: I/O voltage supply
|
||||
- vci-supply: voltage supply for analog circuits
|
||||
- reset-gpios: a GPIO spec for the reset pin (active low)
|
||||
- enable-gpios: a GPIO spec for the panel enable pin (active high)
|
||||
|
||||
Optional properties:
|
||||
- te-gpios: a GPIO spec for the tearing effect synchronization signal
|
||||
gpio pin (active high)
|
||||
|
||||
Example:
|
||||
&dsi {
|
||||
...
|
||||
|
||||
panel@0 {
|
||||
compatible = "samsung,s6e3ha2";
|
||||
reg = <0>;
|
||||
vdd3-supply = <&ldo27_reg>;
|
||||
vci-supply = <&ldo28_reg>;
|
||||
reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
|
||||
enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
|
||||
te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
Sitronix ST7789V RGB panel with SPI control bus
|
||||
|
||||
Required properties:
|
||||
- compatible: "sitronix,st7789v"
|
||||
- reg: Chip select of the panel on the SPI bus
|
||||
- reset-gpios: a GPIO phandle for the reset pin
|
||||
- power-supply: phandle of the regulator that provides the supply voltage
|
||||
|
||||
Optional properties:
|
||||
- backlight: phandle to the backlight used
|
||||
|
||||
The generic bindings for the SPI slaves documented in [1] also applies
|
||||
|
||||
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:
|
||||
|
||||
panel@0 {
|
||||
compatible = "sitronix,st7789v";
|
||||
reg = <0>;
|
||||
reset-gpios = <&pio 6 11 GPIO_ACTIVE_LOW>;
|
||||
backlight = <&pwm_bl>;
|
||||
spi-max-frequency = <100000>;
|
||||
spi-cpol;
|
||||
spi-cpha;
|
||||
|
||||
port {
|
||||
panel_input: endpoint {
|
||||
remote-endpoint = <&tcon0_out_panel>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "winstar,wf35ltiacd"
|
||||
- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
||||
Example:
|
||||
backlight: backlight {
|
||||
compatible = "pwm-backlight";
|
||||
pwms = <&hlcdc_pwm 0 50000 PWM_POLARITY_INVERTED>;
|
||||
brightness-levels = <0 31 63 95 127 159 191 223 255>;
|
||||
default-brightness-level = <191>;
|
||||
power-supply = <&bl_reg>;
|
||||
};
|
||||
|
||||
bl_reg: backlight_regulator {
|
||||
compatible = "regulator-fixed";
|
||||
regulator-name = "backlight-power-supply";
|
||||
regulator-min-microvolt = <5000000>;
|
||||
regulator-max-microvolt = <5000000>;
|
||||
};
|
||||
|
||||
panel: panel {
|
||||
compatible = "winstar,wf35ltiacd", "simple-panel";
|
||||
backlight = <&backlight>;
|
||||
power-supply = <&panel_reg>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
panel_input: endpoint {
|
||||
remote-endpoint = <&hlcdc_panel_output>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
panel_reg: panel_regulator {
|
||||
compatible = "regulator-fixed";
|
||||
regulator-name = "panel-power-supply";
|
||||
regulator-min-microvolt = <3300000>;
|
||||
regulator-max-microvolt = <3300000>;
|
||||
};
|
||||
|
|
@ -36,6 +36,9 @@ Required Properties:
|
|||
When supplied they must be named "dclkin.x" with "x" being the input
|
||||
clock numerical index.
|
||||
|
||||
- vsps: A list of phandles to the VSP nodes that handle the memory
|
||||
interfaces for the DU channels.
|
||||
|
||||
Required nodes:
|
||||
|
||||
The connections to the DU output video ports are modeled using the OF graph
|
||||
|
|
|
|||
|
|
@ -5,16 +5,24 @@ Required properties:
|
|||
- #address-cells: Should be <1>.
|
||||
- #size-cells: Should be <0>.
|
||||
- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
|
||||
"rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi".
|
||||
- reg: Represent the physical address range of the controller.
|
||||
- interrupts: Represent the controller's interrupt to the CPU(s).
|
||||
- clocks, clock-names: Phandles to the controller's pll reference
|
||||
clock(ref) and APB clock(pclk), as described in [1].
|
||||
clock(ref) and APB clock(pclk). For RK3399, a phy config clock
|
||||
(phy_cfg) and a grf clock(grf) are required. As described in [1].
|
||||
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
|
||||
- ports: contain a port node with endpoint definitions as defined in [2].
|
||||
For vopb,set the reg = <0> and set the reg = <1> for vopl.
|
||||
|
||||
Optional properties:
|
||||
- power-domains: a phandle to mipi dsi power domain node.
|
||||
- resets: list of phandle + reset specifier pairs, as described in [3].
|
||||
- reset-names: string reset name, must be "apb".
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
[3] Documentation/devicetree/bindings/reset/reset.txt
|
||||
|
||||
Example:
|
||||
mipi_dsi: mipi@ff960000 {
|
||||
|
|
@ -25,6 +33,8 @@ Example:
|
|||
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>;
|
||||
clock-names = "ref", "pclk";
|
||||
resets = <&cru SRST_MIPIDSI0>;
|
||||
reset-names = "apb";
|
||||
rockchip,grf = <&grf>;
|
||||
status = "okay";
|
||||
|
||||
|
|
|
|||
|
|
@ -179,6 +179,7 @@ maxim Maxim Integrated Products
|
|||
mcube mCube
|
||||
meas Measurement Specialties
|
||||
mediatek MediaTek Inc.
|
||||
megachips MegaChips
|
||||
melexis Melexis N.V.
|
||||
melfas MELFAS Inc.
|
||||
memsic MEMSIC Inc.
|
||||
|
|
@ -337,6 +338,7 @@ wd Western Digital Corp.
|
|||
wetek WeTek Electronics, limited.
|
||||
wexler Wexler
|
||||
winbond Winbond Electronics corp.
|
||||
winstar Winstar Display Corp.
|
||||
wlf Wolfson Microelectronics
|
||||
wm Wondermedia Technologies, Inc.
|
||||
x-powers X-Powers
|
||||
|
|
|
|||
15
Documentation/gpu/bridge/dw-hdmi.rst
Normal file
15
Documentation/gpu/bridge/dw-hdmi.rst
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
=======================================================
|
||||
drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller
|
||||
=======================================================
|
||||
|
||||
Synopsys DesignWare HDMI Controller
|
||||
===================================
|
||||
|
||||
This section covers everything related to the Synopsys DesignWare HDMI
|
||||
Controller implemented as a DRM bridge.
|
||||
|
||||
Supported Input Formats and Encodings
|
||||
-------------------------------------
|
||||
|
||||
.. kernel-doc:: include/drm/bridge/dw_hdmi.h
|
||||
:doc: Supported input formats and encodings
|
||||
|
|
@ -140,12 +140,12 @@ Device Instance and Driver Handling
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_drv.c
|
||||
:doc: driver instance overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_drv.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_drv.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_drv.c
|
||||
:export:
|
||||
|
||||
Driver Load
|
||||
-----------
|
||||
|
||||
|
|
@ -240,120 +240,21 @@ drivers.
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_pci.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_platform.c
|
||||
:export:
|
||||
|
||||
Open/Close, File Operations and IOCTLs
|
||||
======================================
|
||||
|
||||
Open and Close
|
||||
--------------
|
||||
|
||||
Open and close handlers. None of those methods are mandatory::
|
||||
|
||||
int (*firstopen) (struct drm_device *);
|
||||
void (*lastclose) (struct drm_device *);
|
||||
int (*open) (struct drm_device *, struct drm_file *);
|
||||
void (*preclose) (struct drm_device *, struct drm_file *);
|
||||
void (*postclose) (struct drm_device *, struct drm_file *);
|
||||
|
||||
The firstopen method is called by the DRM core for legacy UMS (User Mode
|
||||
Setting) drivers only when an application opens a device that has no
|
||||
other opened file handle. UMS drivers can implement it to acquire device
|
||||
resources. KMS drivers can't use the method and must acquire resources
|
||||
in the load method instead.
|
||||
|
||||
Similarly the lastclose method is called when the last application
|
||||
holding a file handle opened on the device closes it, for both UMS and
|
||||
KMS drivers. Additionally, the method is also called at module unload
|
||||
time or, for hot-pluggable devices, when the device is unplugged. The
|
||||
firstopen and lastclose calls can thus be unbalanced.
|
||||
|
||||
The open method is called every time the device is opened by an
|
||||
application. Drivers can allocate per-file private data in this method
|
||||
and store them in the struct :c:type:`struct drm_file
|
||||
<drm_file>` driver_priv field. Note that the open method is
|
||||
called before firstopen.
|
||||
|
||||
The close operation is split into preclose and postclose methods.
|
||||
Drivers must stop and cleanup all per-file operations in the preclose
|
||||
method. For instance pending vertical blanking and page flip events must
|
||||
be cancelled. No per-file operation is allowed on the file handle after
|
||||
returning from the preclose method.
|
||||
|
||||
Finally the postclose method is called as the last step of the close
|
||||
operation, right before calling the lastclose method if no other open
|
||||
file handle exists for the device. Drivers that have allocated per-file
|
||||
private data in the open method should free it here.
|
||||
|
||||
The lastclose method should restore CRTC and plane properties to default
|
||||
value, so that a subsequent open of the device will not inherit state
|
||||
from the previous user. It can also be used to execute delayed power
|
||||
switching state changes, e.g. in conjunction with the :ref:`vga_switcheroo`
|
||||
infrastructure. Beyond that KMS drivers should not do any
|
||||
further cleanup. Only legacy UMS drivers might need to clean up device
|
||||
state so that the vga console or an independent fbdev driver could take
|
||||
over.
|
||||
|
||||
File Operations
|
||||
---------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_fops.c
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_file.c
|
||||
:doc: file operations
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_fops.c
|
||||
.. kernel-doc:: include/drm/drm_file.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_file.c
|
||||
:export:
|
||||
|
||||
IOCTLs
|
||||
------
|
||||
|
||||
struct drm_ioctl_desc \*ioctls; int num_ioctls;
|
||||
Driver-specific ioctls descriptors table.
|
||||
|
||||
Driver-specific ioctls numbers start at DRM_COMMAND_BASE. The ioctls
|
||||
descriptors table is indexed by the ioctl number offset from the base
|
||||
value. Drivers can use the DRM_IOCTL_DEF_DRV() macro to initialize
|
||||
the table entries.
|
||||
|
||||
::
|
||||
|
||||
DRM_IOCTL_DEF_DRV(ioctl, func, flags)
|
||||
|
||||
``ioctl`` is the ioctl name. Drivers must define the DRM_##ioctl and
|
||||
DRM_IOCTL_##ioctl macros to the ioctl number offset from
|
||||
DRM_COMMAND_BASE and the ioctl number respectively. The first macro is
|
||||
private to the device while the second must be exposed to userspace in a
|
||||
public header.
|
||||
|
||||
``func`` is a pointer to the ioctl handler function compatible with the
|
||||
``drm_ioctl_t`` type.
|
||||
|
||||
::
|
||||
|
||||
typedef int drm_ioctl_t(struct drm_device *dev, void *data,
|
||||
struct drm_file *file_priv);
|
||||
|
||||
``flags`` is a bitmask combination of the following values. It restricts
|
||||
how the ioctl is allowed to be called.
|
||||
|
||||
- DRM_AUTH - Only authenticated callers allowed
|
||||
|
||||
- DRM_MASTER - The ioctl can only be called on the master file handle
|
||||
|
||||
- DRM_ROOT_ONLY - Only callers with the SYSADMIN capability allowed
|
||||
|
||||
- DRM_CONTROL_ALLOW - The ioctl can only be called on a control
|
||||
device
|
||||
|
||||
- DRM_UNLOCKED - The ioctl handler will be called without locking the
|
||||
DRM global mutex. This is the enforced default for kms drivers (i.e.
|
||||
using the DRIVER_MODESET flag) and hence shouldn't be used any more
|
||||
for new drivers.
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
|
||||
:export:
|
||||
|
||||
|
||||
Misc Utilities
|
||||
==============
|
||||
|
||||
|
|
|
|||
|
|
@ -37,10 +37,12 @@ Modeset Helper Reference for Common Vtables
|
|||
===========================================
|
||||
|
||||
.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
|
||||
:internal:
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
|
||||
:doc: overview
|
||||
:internal:
|
||||
|
||||
.. _drm_atomic_helper:
|
||||
|
||||
Atomic Modeset Helper Functions Reference
|
||||
=========================================
|
||||
|
|
@ -84,27 +86,27 @@ Legacy CRTC/Modeset Helper Functions Reference
|
|||
Simple KMS Helper Reference
|
||||
===========================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: include/drm/drm_simple_kms_helper.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c
|
||||
:doc: overview
|
||||
|
||||
fbdev Helper Functions Reference
|
||||
================================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
|
||||
:doc: fbdev helpers
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_fb_helper.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c
|
||||
:export:
|
||||
|
||||
Framebuffer CMA Helper Functions Reference
|
||||
==========================================
|
||||
|
||||
|
|
@ -114,6 +116,8 @@ Framebuffer CMA Helper Functions Reference
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_fb_cma_helper.c
|
||||
:export:
|
||||
|
||||
.. _drm_bridges:
|
||||
|
||||
Bridges
|
||||
=======
|
||||
|
||||
|
|
@ -139,18 +143,20 @@ Bridge Helper Reference
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
|
||||
:export:
|
||||
|
||||
.. _drm_panel_helper:
|
||||
|
||||
Panel Helper Reference
|
||||
======================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_panel.c
|
||||
:doc: drm panel
|
||||
|
||||
.. kernel-doc:: include/drm/drm_panel.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_panel.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_panel.c
|
||||
:doc: drm panel
|
||||
|
||||
Display Port Helper Functions Reference
|
||||
=======================================
|
||||
|
||||
|
|
@ -217,6 +223,18 @@ EDID Helper Functions Reference
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_edid.c
|
||||
:export:
|
||||
|
||||
SCDC Helper Functions Reference
|
||||
===============================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
|
||||
:doc: scdc helpers
|
||||
|
||||
.. kernel-doc:: include/drm/drm_scdc_helper.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
|
||||
:export:
|
||||
|
||||
Rectangle Utilities Reference
|
||||
=============================
|
||||
|
||||
|
|
|
|||
|
|
@ -15,35 +15,271 @@ be setup by initializing the following fields.
|
|||
- struct drm_mode_config_funcs \*funcs;
|
||||
Mode setting functions.
|
||||
|
||||
Mode Configuration
|
||||
Overview
|
||||
========
|
||||
|
||||
.. kernel-render:: DOT
|
||||
:alt: KMS Display Pipeline
|
||||
:caption: KMS Display Pipeline Overview
|
||||
|
||||
digraph "KMS" {
|
||||
node [shape=box]
|
||||
|
||||
subgraph cluster_static {
|
||||
style=dashed
|
||||
label="Static Objects"
|
||||
|
||||
node [bgcolor=grey style=filled]
|
||||
"drm_plane A" -> "drm_crtc"
|
||||
"drm_plane B" -> "drm_crtc"
|
||||
"drm_crtc" -> "drm_encoder A"
|
||||
"drm_crtc" -> "drm_encoder B"
|
||||
}
|
||||
|
||||
subgraph cluster_user_created {
|
||||
style=dashed
|
||||
label="Userspace-Created"
|
||||
|
||||
node [shape=oval]
|
||||
"drm_framebuffer 1" -> "drm_plane A"
|
||||
"drm_framebuffer 2" -> "drm_plane B"
|
||||
}
|
||||
|
||||
subgraph cluster_connector {
|
||||
style=dashed
|
||||
label="Hotpluggable"
|
||||
|
||||
"drm_encoder A" -> "drm_connector A"
|
||||
"drm_encoder B" -> "drm_connector B"
|
||||
}
|
||||
}
|
||||
|
||||
The basic object structure KMS presents to userspace is fairly simple.
|
||||
Framebuffers (represented by :c:type:`struct drm_framebuffer <drm_framebuffer>`,
|
||||
see `Frame Buffer Abstraction`_) feed into planes. One or more (or even no)
|
||||
planes feed their pixel data into a CRTC (represented by :c:type:`struct
|
||||
drm_crtc <drm_crtc>`, see `CRTC Abstraction`_) for blending. The precise
|
||||
blending step is explained in more detail in `Plane Composition Properties`_ and
|
||||
related chapters.
|
||||
|
||||
For the output routing the first step is encoders (represented by
|
||||
:c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those
|
||||
are really just internal artifacts of the helper libraries used to implement KMS
|
||||
drivers. Besides that they make it unecessarily more complicated for userspace
|
||||
to figure out which connections between a CRTC and a connector are possible, and
|
||||
what kind of cloning is supported, they serve no purpose in the userspace API.
|
||||
Unfortunately encoders have been exposed to userspace, hence can't remove them
|
||||
at this point. Futhermore the exposed restrictions are often wrongly set by
|
||||
drivers, and in many cases not powerful enough to express the real restrictions.
|
||||
A CRTC can be connected to multiple encoders, and for an active CRTC there must
|
||||
be at least one encoder.
|
||||
|
||||
The final, and real, endpoint in the display chain is the connector (represented
|
||||
by :c:type:`struct drm_connector <drm_connector>`, see `Connector
|
||||
Abstraction`_). Connectors can have different possible encoders, but the kernel
|
||||
driver selects which encoder to use for each connector. The use case is DVI,
|
||||
which could switch between an analog and a digital encoder. Encoders can also
|
||||
drive multiple different connectors. There is exactly one active connector for
|
||||
every active encoder.
|
||||
|
||||
Internally the output pipeline is a bit more complex and matches today's
|
||||
hardware more closely:
|
||||
|
||||
.. kernel-render:: DOT
|
||||
:alt: KMS Output Pipeline
|
||||
:caption: KMS Output Pipeline
|
||||
|
||||
digraph "Output Pipeline" {
|
||||
node [shape=box]
|
||||
|
||||
subgraph {
|
||||
"drm_crtc" [bgcolor=grey style=filled]
|
||||
}
|
||||
|
||||
subgraph cluster_internal {
|
||||
style=dashed
|
||||
label="Internal Pipeline"
|
||||
{
|
||||
node [bgcolor=grey style=filled]
|
||||
"drm_encoder A";
|
||||
"drm_encoder B";
|
||||
"drm_encoder C";
|
||||
}
|
||||
|
||||
{
|
||||
node [bgcolor=grey style=filled]
|
||||
"drm_encoder B" -> "drm_bridge B"
|
||||
"drm_encoder C" -> "drm_bridge C1"
|
||||
"drm_bridge C1" -> "drm_bridge C2";
|
||||
}
|
||||
}
|
||||
|
||||
"drm_crtc" -> "drm_encoder A"
|
||||
"drm_crtc" -> "drm_encoder B"
|
||||
"drm_crtc" -> "drm_encoder C"
|
||||
|
||||
|
||||
subgraph cluster_output {
|
||||
style=dashed
|
||||
label="Outputs"
|
||||
|
||||
"drm_encoder A" -> "drm_connector A";
|
||||
"drm_bridge B" -> "drm_connector B";
|
||||
"drm_bridge C2" -> "drm_connector C";
|
||||
|
||||
"drm_panel"
|
||||
}
|
||||
}
|
||||
|
||||
Internally two additional helper objects come into play. First, to be able to
|
||||
share code for encoders (sometimes on the same SoC, sometimes off-chip) one or
|
||||
more :ref:`drm_bridges` (represented by :c:type:`struct drm_bridge
|
||||
<drm_bridge>`) can be linked to an encoder. This link is static and cannot be
|
||||
changed, which means the cross-bar (if there is any) needs to be mapped between
|
||||
the CRTC and any encoders. Often for drivers with bridges there's no code left
|
||||
at the encoder level. Atomic drivers can leave out all the encoder callbacks to
|
||||
essentially only leave a dummy routing object behind, which is needed for
|
||||
backwards compatibility since encoders are exposed to userspace.
|
||||
|
||||
The second object is for panels, represented by :c:type:`struct drm_panel
|
||||
<drm_panel>`, see :ref:`drm_panel_helper`. Panels do not have a fixed binding
|
||||
point, but are generally linked to the driver private structure that embeds
|
||||
:c:type:`struct drm_connector <drm_connector>`.
|
||||
|
||||
Note that currently the bridge chaining and interactions with connectors and
|
||||
panels are still in-flux and not really fully sorted out yet.
|
||||
|
||||
KMS Core Structures and Functions
|
||||
=================================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_mode_config.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c
|
||||
:export:
|
||||
|
||||
Modeset Base Object Abstraction
|
||||
===============================
|
||||
|
||||
.. kernel-render:: DOT
|
||||
:alt: Mode Objects and Properties
|
||||
:caption: Mode Objects and Properties
|
||||
|
||||
digraph {
|
||||
node [shape=box]
|
||||
|
||||
"drm_property A" -> "drm_mode_object A"
|
||||
"drm_property A" -> "drm_mode_object B"
|
||||
"drm_property B" -> "drm_mode_object A"
|
||||
}
|
||||
|
||||
The base structure for all KMS objects is :c:type:`struct drm_mode_object
|
||||
<drm_mode_object>`. One of the base services it provides is tracking properties,
|
||||
which are especially important for the atomic IOCTL (see `Atomic Mode
|
||||
Setting`_). The somewhat surprising part here is that properties are not
|
||||
directly instantiated on each object, but free-standing mode objects themselves,
|
||||
represented by :c:type:`struct drm_property <drm_property>`, which only specify
|
||||
the type and value range of a property. Any given property can be attached
|
||||
multiple times to different objects using :c:func:`drm_object_attach_property()
|
||||
<drm_object_attach_property>`.
|
||||
|
||||
.. kernel-doc:: include/drm/drm_mode_object.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
|
||||
:export:
|
||||
|
||||
Atomic Mode Setting Function Reference
|
||||
======================================
|
||||
Atomic Mode Setting
|
||||
===================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
|
||||
:export:
|
||||
|
||||
.. kernel-render:: DOT
|
||||
:alt: Mode Objects and Properties
|
||||
:caption: Mode Objects and Properties
|
||||
|
||||
digraph {
|
||||
node [shape=box]
|
||||
|
||||
subgraph cluster_state {
|
||||
style=dashed
|
||||
label="Free-standing state"
|
||||
|
||||
"drm_atomic_state" -> "duplicated drm_plane_state A"
|
||||
"drm_atomic_state" -> "duplicated drm_plane_state B"
|
||||
"drm_atomic_state" -> "duplicated drm_crtc_state"
|
||||
"drm_atomic_state" -> "duplicated drm_connector_state"
|
||||
"drm_atomic_state" -> "duplicated driver private state"
|
||||
}
|
||||
|
||||
subgraph cluster_current {
|
||||
style=dashed
|
||||
label="Current state"
|
||||
|
||||
"drm_device" -> "drm_plane A"
|
||||
"drm_device" -> "drm_plane B"
|
||||
"drm_device" -> "drm_crtc"
|
||||
"drm_device" -> "drm_connector"
|
||||
"drm_device" -> "driver private object"
|
||||
|
||||
"drm_plane A" -> "drm_plane_state A"
|
||||
"drm_plane B" -> "drm_plane_state B"
|
||||
"drm_crtc" -> "drm_crtc_state"
|
||||
"drm_connector" -> "drm_connector_state"
|
||||
"driver private object" -> "driver private state"
|
||||
}
|
||||
|
||||
"drm_atomic_state" -> "drm_device" [label="atomic_commit"]
|
||||
"duplicated drm_plane_state A" -> "drm_device"[style=invis]
|
||||
}
|
||||
|
||||
Atomic provides transactional modeset (including planes) updates, but a
|
||||
bit differently from the usual transactional approach of try-commit and
|
||||
rollback:
|
||||
|
||||
- Firstly, no hardware changes are allowed when the commit would fail. This
|
||||
allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows
|
||||
userspace to explore whether certain configurations would work or not.
|
||||
|
||||
- This would still allow setting and rollback of just the software state,
|
||||
simplifying conversion of existing drivers. But auditing drivers for
|
||||
correctness of the atomic_check code becomes really hard with that: Rolling
|
||||
back changes in data structures all over the place is hard to get right.
|
||||
|
||||
- Lastly, for backwards compatibility and to support all use-cases, atomic
|
||||
updates need to be incremental and be able to execute in parallel. Hardware
|
||||
doesn't always allow it, but where possible plane updates on different CRTCs
|
||||
should not interfere, and not get stalled due to output routing changing on
|
||||
different CRTCs.
|
||||
|
||||
Taken all together there's two consequences for the atomic design:
|
||||
|
||||
- The overall state is split up into per-object state structures:
|
||||
:c:type:`struct drm_plane_state <drm_plane_state>` for planes, :c:type:`struct
|
||||
drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct
|
||||
drm_connector_state <drm_connector_state>` for connectors. These are the only
|
||||
objects with userspace-visible and settable state. For internal state drivers
|
||||
can subclass these structures through embeddeding, or add entirely new state
|
||||
structures for their globally shared hardware functions.
|
||||
|
||||
- An atomic update is assembled and validated as an entirely free-standing pile
|
||||
of structures within the :c:type:`drm_atomic_state <drm_atomic_state>`
|
||||
container. Again drivers can subclass that container for their own state
|
||||
structure tracking needs. Only when a state is committed is it applied to the
|
||||
driver and modeset objects. This way rolling back an update boils down to
|
||||
releasing memory and unreferencing objects like framebuffers.
|
||||
|
||||
Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
|
||||
coverage of specific topics.
|
||||
|
||||
Atomic Mode Setting Function Reference
|
||||
--------------------------------------
|
||||
|
||||
.. kernel-doc:: include/drm/drm_atomic.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
|
||||
:export:
|
||||
|
||||
CRTC Abstraction
|
||||
================
|
||||
|
||||
|
|
@ -68,12 +304,12 @@ Frame Buffer Abstraction
|
|||
Frame Buffer Functions Reference
|
||||
--------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_framebuffer.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c
|
||||
:export:
|
||||
|
||||
DRM Format Handling
|
||||
===================
|
||||
|
||||
|
|
@ -376,8 +612,8 @@ operation handler.
|
|||
Vertical Blanking and Interrupt Handling Functions Reference
|
||||
------------------------------------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_irq.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_irq.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_irq.c
|
||||
:export:
|
||||
|
|
|
|||
|
|
@ -183,14 +183,12 @@ GEM Objects Lifetime
|
|||
--------------------
|
||||
|
||||
All GEM objects are reference-counted by the GEM core. References can be
|
||||
acquired and release by :c:func:`calling
|
||||
drm_gem_object_reference()` and
|
||||
:c:func:`drm_gem_object_unreference()` respectively. The caller
|
||||
must hold the :c:type:`struct drm_device <drm_device>`
|
||||
struct_mutex lock when calling
|
||||
:c:func:`drm_gem_object_reference()`. As a convenience, GEM
|
||||
provides :c:func:`drm_gem_object_unreference_unlocked()`
|
||||
functions that can be called without holding the lock.
|
||||
acquired and release by :c:func:`calling drm_gem_object_get()` and
|
||||
:c:func:`drm_gem_object_put()` respectively. The caller must hold the
|
||||
:c:type:`struct drm_device <drm_device>` struct_mutex lock when calling
|
||||
:c:func:`drm_gem_object_get()`. As a convenience, GEM provides
|
||||
:c:func:`drm_gem_object_put_unlocked()` functions that can be called without
|
||||
holding the lock.
|
||||
|
||||
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
|
||||
|
|
@ -367,36 +365,36 @@ from the client in libdrm.
|
|||
GEM Function Reference
|
||||
----------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_gem.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_gem.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_gem.c
|
||||
:export:
|
||||
|
||||
GEM CMA Helper Functions Reference
|
||||
----------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
|
||||
:doc: cma helpers
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_gem_cma_helper.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c
|
||||
:export:
|
||||
|
||||
VMA Offset Manager
|
||||
==================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
|
||||
:doc: vma offset manager
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_vma_manager.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
|
||||
:export:
|
||||
|
||||
PRIME Buffer Sharing
|
||||
====================
|
||||
|
||||
|
|
@ -451,6 +449,9 @@ PRIME Helper Functions
|
|||
PRIME Function References
|
||||
-------------------------
|
||||
|
||||
.. kernel-doc:: include/drm/drm_prime.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_prime.c
|
||||
:export:
|
||||
|
||||
|
|
@ -472,12 +473,12 @@ LRU Scan/Eviction Support
|
|||
DRM MM Range Allocator Function References
|
||||
------------------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mm.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: include/drm/drm_mm.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_mm.c
|
||||
:export:
|
||||
|
||||
DRM Cache Handling
|
||||
==================
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,8 @@ libdrm Device Lookup
|
|||
:doc: getunique and setversion story
|
||||
|
||||
|
||||
.. _drm_primary_node:
|
||||
|
||||
Primary Nodes, DRM Master and Authentication
|
||||
============================================
|
||||
|
||||
|
|
@ -103,6 +105,8 @@ is already rather painful for the DRM subsystem, with multiple different uAPIs
|
|||
for the same thing co-existing. If we add a few more complete mistakes into the
|
||||
mix every year it would be entirely unmanageable.
|
||||
|
||||
.. _drm_render_node:
|
||||
|
||||
Render nodes
|
||||
============
|
||||
|
||||
|
|
@ -156,6 +160,20 @@ other hand, a driver requires shared state between clients which is
|
|||
visible to user-space and accessible beyond open-file boundaries, they
|
||||
cannot support render nodes.
|
||||
|
||||
IOCTL Support on Device Nodes
|
||||
=============================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
|
||||
:doc: driver specific ioctls
|
||||
|
||||
.. kernel-doc:: include/drm/drm_ioctl.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_ioc32.c
|
||||
:export:
|
||||
|
||||
Testing and validation
|
||||
======================
|
||||
|
|
@ -203,6 +221,28 @@ Display CRC Support
|
|||
.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
|
||||
:doc: CRC ABI
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
|
||||
:export:
|
||||
|
||||
Debugfs Support
|
||||
---------------
|
||||
|
||||
.. kernel-doc:: include/drm/drm_debugfs.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_debugfs.c
|
||||
:export:
|
||||
|
||||
Sysfs Support
|
||||
=============
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
|
||||
:doc: overview
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/drm_sysfs.c
|
||||
:export:
|
||||
|
||||
|
||||
VBlank event handling
|
||||
=====================
|
||||
|
||||
|
|
|
|||
|
|
@ -222,6 +222,15 @@ Video BIOS Table (VBT)
|
|||
.. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h
|
||||
:internal:
|
||||
|
||||
Display clocks
|
||||
--------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/intel_cdclk.c
|
||||
:doc: CDCLK / RAWCLK
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/i915/intel_cdclk.c
|
||||
:internal:
|
||||
|
||||
Display PLLs
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -11,9 +11,13 @@ Linux GPU Driver Developer's Guide
|
|||
drm-kms-helpers
|
||||
drm-uapi
|
||||
i915
|
||||
meson
|
||||
tinydrm
|
||||
vc4
|
||||
vga-switcheroo
|
||||
vgaarbiter
|
||||
bridge/dw-hdmi
|
||||
todo
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
|
|
|||
|
|
@ -50,3 +50,38 @@ names are "Notes" with information for dangerous or tricky corner cases,
|
|||
and "FIXME" where the interface could be cleaned up.
|
||||
|
||||
Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`.
|
||||
|
||||
Getting Started
|
||||
===============
|
||||
|
||||
Developers interested in helping out with the DRM subsystem are very welcome.
|
||||
Often people will resort to sending in patches for various issues reported by
|
||||
checkpatch or sparse. We welcome such contributions.
|
||||
|
||||
Anyone looking to kick it up a notch can find a list of janitorial tasks on
|
||||
the :ref:`TODO list <todo>`.
|
||||
|
||||
Contribution Process
|
||||
====================
|
||||
|
||||
Mostly the DRM subsystem works like any other kernel subsystem, see :ref:`the
|
||||
main process guidelines and documentation <process_index>` for how things work.
|
||||
Here we just document some of the specialities of the GPU subsystem.
|
||||
|
||||
Feature Merge Deadlines
|
||||
-----------------------
|
||||
|
||||
All feature work must be in the linux-next tree by the -rc6 release of the
|
||||
current release cycle, otherwise they must be postponed and can't reach the next
|
||||
merge window. All patches must have landed in the drm-next tree by latest -rc7,
|
||||
but if your branch is not in linux-next then this must have happened by -rc6
|
||||
already.
|
||||
|
||||
After that point only bugfixes (like after the upstream merge window has closed
|
||||
with the -rc1 release) are allowed. No new platform enabling or new drivers are
|
||||
allowed.
|
||||
|
||||
This means that there's a blackout-period of about one month where feature work
|
||||
can't be merged. The recommended way to deal with that is having a -next tree
|
||||
that's always open, but making sure to not feed it into linux-next during the
|
||||
blackout period. As an example, drm-misc works like that.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,5 @@
|
|||
Owner Module/Drivers,Group,Property Name,Type,Property Values,Object attached,Description/Restrictions
|
||||
,,“scaling mode”,ENUM,"{ ""None"", ""Full"", ""Center"", ""Full aspect"" }",Connector,"Supported by: amdgpu, gma500, i915, nouveau and radeon."
|
||||
,Connector,“EDID”,BLOB | IMMUTABLE,0,Connector,Contains id of edid blob ptr object.
|
||||
,,“DPMS”,ENUM,"{ “On”, “Standby”, “Suspend”, “Off” }",Connector,Contains DPMS operation mode value.
|
||||
,,“PATH”,BLOB | IMMUTABLE,0,Connector,Contains topology path to a connector.
|
||||
,,“TILE”,BLOB | IMMUTABLE,0,Connector,Contains tiling information for a connector.
|
||||
,,“CRTC_ID”,OBJECT,DRM_MODE_OBJECT_CRTC,Connector,CRTC that connector is attached to (atomic)
|
||||
,DVI-I,“subconnector”,ENUM,"{ “Unknown”, “DVI-D”, “DVI-A” }",Connector,TBD
|
||||
,,“select subconnector”,ENUM,"{ “Automatic”, “DVI-D”, “DVI-A” }",Connector,TBD
|
||||
,TV,“subconnector”,ENUM,"{ ""Unknown"", ""Composite"", ""SVIDEO"", ""Component"", ""SCART"" }",Connector,TBD
|
||||
|
|
|
|||
|
61
Documentation/gpu/meson.rst
Normal file
61
Documentation/gpu/meson.rst
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
=============================================
|
||||
drm/meson AmLogic Meson Video Processing Unit
|
||||
=============================================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/meson/meson_drv.c
|
||||
:doc: Video Processing Unit
|
||||
|
||||
Video Processing Unit
|
||||
=====================
|
||||
|
||||
The Amlogic Meson Display controller is composed of several components
|
||||
that are going to be documented below:
|
||||
|
||||
.. code::
|
||||
|
||||
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 |-------|______|----|____________| |________________| | |
|
||||
___|__________________________________________________________|_______________|
|
||||
|
||||
Video Input Unit
|
||||
================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/meson/meson_viu.c
|
||||
:doc: Video Input Unit
|
||||
|
||||
Video Post Processing
|
||||
=====================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/meson/meson_vpp.c
|
||||
:doc: Video Post Processing
|
||||
|
||||
Video Encoder
|
||||
=============
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/meson/meson_venc.c
|
||||
:doc: Video Encoder
|
||||
|
||||
Video Canvas Management
|
||||
=======================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/meson/meson_canvas.c
|
||||
:doc: Canvas
|
||||
|
||||
Video Clocks
|
||||
============
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/meson/meson_vclk.c
|
||||
:doc: Video Clocks
|
||||
|
||||
HDMI Video Output
|
||||
=================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/meson/meson_dw_hdmi.c
|
||||
:doc: HDMI Output
|
||||
407
Documentation/gpu/todo.rst
Normal file
407
Documentation/gpu/todo.rst
Normal file
|
|
@ -0,0 +1,407 @@
|
|||
.. _todo:
|
||||
|
||||
=========
|
||||
TODO list
|
||||
=========
|
||||
|
||||
This section contains a list of smaller janitorial tasks in the kernel DRM
|
||||
graphics subsystem useful as newbie projects. Or for slow rainy days.
|
||||
|
||||
Subsystem-wide refactorings
|
||||
===========================
|
||||
|
||||
De-midlayer drivers
|
||||
-------------------
|
||||
|
||||
With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required
|
||||
to have a ``drm_bus`` structure set up. Drivers can directly set up the
|
||||
``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
|
||||
and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
|
||||
``->unload`` callbacks and open-code the load/unload sequence properly, using
|
||||
the new two-stage ``drm_device`` setup/teardown.
|
||||
|
||||
Once all existing drivers are converted we can also remove those bus support
|
||||
files for USB and platform devices.
|
||||
|
||||
All you need is a GPU for a non-converted driver (currently almost all of
|
||||
them, but also all the virtual ones used by KVM, so everyone qualifies).
|
||||
|
||||
Contact: Daniel Vetter, Thierry Reding, respective driver maintainers
|
||||
|
||||
Switch from reference/unreference to get/put
|
||||
--------------------------------------------
|
||||
|
||||
For some reason DRM core uses ``reference``/``unreference`` suffixes for
|
||||
refcounting functions, but kernel uses ``get``/``put`` (e.g.
|
||||
``kref_get``/``put()``). It would be good to switch over for consistency, and
|
||||
it's shorter. Needs to be done in 3 steps for each pair of functions:
|
||||
|
||||
* Create new ``get``/``put`` functions, define the old names as compatibility
|
||||
wrappers
|
||||
* Switch over each file/driver using a cocci-generated spatch.
|
||||
* Once all users of the old names are gone, remove them.
|
||||
|
||||
This way drivers/patches in the progress of getting merged won't break.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Convert existing KMS drivers to atomic modesetting
|
||||
--------------------------------------------------
|
||||
|
||||
3.19 has the atomic modeset interfaces and helpers, so drivers can now be
|
||||
converted over. Modern compositors like Wayland or Surfaceflinger on Android
|
||||
really want an atomic modeset interface, so this is all about the bright
|
||||
future.
|
||||
|
||||
There is a conversion guide for atomic and all you need is a GPU for a
|
||||
non-converted driver (again virtual HW drivers for KVM are still all
|
||||
suitable).
|
||||
|
||||
As part of this drivers also need to convert to universal plane (which means
|
||||
exposing primary & cursor as proper plane objects). But that's much easier to
|
||||
do by directly using the new atomic helper driver callbacks.
|
||||
|
||||
Contact: Daniel Vetter, respective driver maintainers
|
||||
|
||||
Clean up the clipped coordination confusion around planes
|
||||
---------------------------------------------------------
|
||||
|
||||
We have a helper to get this right with drm_plane_helper_check_update(), but
|
||||
it's not consistently used. This should be fixed, preferrably in the atomic
|
||||
helpers (and drivers then moved over to clipped coordinates). Probably the
|
||||
helper should also be moved from drm_plane_helper.c to the atomic helpers, to
|
||||
avoid confusion - the other helpers in that file are all deprecated legacy
|
||||
helpers.
|
||||
|
||||
Contact: Ville Syrjälä, Daniel Vetter, driver maintainers
|
||||
|
||||
Implement deferred fbdev setup in the helper
|
||||
--------------------------------------------
|
||||
|
||||
Many (especially embedded drivers) want to delay fbdev setup until there's a
|
||||
real screen plugged in. This is to avoid the dreaded fallback to the low-res
|
||||
fbdev default. Many drivers have a hacked-up (and often broken) version of this,
|
||||
better to do it once in the shared helpers. Thierry has a patch series, but that
|
||||
one needs to be rebased and final polish applied.
|
||||
|
||||
Contact: Thierry Reding, Daniel Vetter, driver maintainers
|
||||
|
||||
Convert early atomic drivers to async commit helpers
|
||||
----------------------------------------------------
|
||||
|
||||
For the first year the atomic modeset helpers didn't support asynchronous /
|
||||
nonblocking commits, and every driver had to hand-roll them. This is fixed
|
||||
now, but there's still a pile of existing drivers that easily could be
|
||||
converted over to the new infrastructure.
|
||||
|
||||
One issue with the helpers is that they require that drivers handle completion
|
||||
events for atomic commits correctly. But fixing these bugs is good anyway.
|
||||
|
||||
Contact: Daniel Vetter, respective driver maintainers
|
||||
|
||||
Better manual-upload support for atomic
|
||||
---------------------------------------
|
||||
|
||||
This would be especially useful for tinydrm:
|
||||
|
||||
- Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the
|
||||
crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
|
||||
__drm_atomic_helper_crtc_duplicate_state().
|
||||
|
||||
- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm_
|
||||
prefix ofc and using drm_fb_. drm_framebuffer.c makes sense since this
|
||||
is a function useful to implement the fb->dirty function.
|
||||
|
||||
- Create a new drm_fb_dirty function which does essentially what e.g.
|
||||
mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as the
|
||||
template. But instead of doing a simple full-screen plane update, this new
|
||||
helper also sets crtc_state->dirty_clip to the right coordinates. And of
|
||||
course it needs to check whether the fb is actually active (and maybe where),
|
||||
so there's some book-keeping involved. There's also some good fun involved in
|
||||
scaling things appropriately. For that case we might simply give up and
|
||||
declare the entire area covered by the plane as dirty.
|
||||
|
||||
Contact: Noralf Trønnes, Daniel Vetter
|
||||
|
||||
Fallout from atomic KMS
|
||||
-----------------------
|
||||
|
||||
``drm_atomic_helper.c`` provides a batch of functions which implement legacy
|
||||
IOCTLs on top of the new atomic driver interface. Which is really nice for
|
||||
gradual conversion of drivers, but unfortunately the semantic mismatches are
|
||||
a bit too severe. So there's some follow-up work to adjust the function
|
||||
interfaces to fix these issues:
|
||||
|
||||
* atomic needs the lock acquire context. At the moment that's passed around
|
||||
implicitly with some horrible hacks, and it's also allocate with
|
||||
``GFP_NOFAIL`` behind the scenes. All legacy paths need to start allocating
|
||||
the acquire context explicitly on stack and then also pass it down into
|
||||
drivers explicitly so that the legacy-on-atomic functions can use them.
|
||||
|
||||
* A bunch of the vtable hooks are now in the wrong place: DRM has a split
|
||||
between core vfunc tables (named ``drm_foo_funcs``), which are used to
|
||||
implement the userspace ABI. And then there's the optional hooks for the
|
||||
helper libraries (name ``drm_foo_helper_funcs``), which are purely for
|
||||
internal use. Some of these hooks should be move from ``_funcs`` to
|
||||
``_helper_funcs`` since they are not part of the core ABI. There's a
|
||||
``FIXME`` comment in the kerneldoc for each such case in ``drm_crtc.h``.
|
||||
|
||||
* There's a new helper ``drm_atomic_helper_best_encoder()`` which could be
|
||||
used by all atomic drivers which don't select the encoder for a given
|
||||
connector at runtime. That's almost all of them, and would allow us to get
|
||||
rid of a lot of ``best_encoder`` boilerplate in drivers.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Get rid of dev->struct_mutex from GEM drivers
|
||||
---------------------------------------------
|
||||
|
||||
``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested
|
||||
everything. Nowadays in modern drivers the only bit where it's mandatory is
|
||||
serializing GEM buffer object destruction. Which unfortunately means drivers
|
||||
have to keep track of that lock and either call ``unreference`` or
|
||||
``unreference_locked`` depending upon context.
|
||||
|
||||
Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8,
|
||||
and there's a ``gem_free_object_unlocked`` callback for any drivers which are
|
||||
entirely ``struct_mutex`` free.
|
||||
|
||||
For drivers that need ``struct_mutex`` it should be replaced with a driver-
|
||||
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 the
|
||||
following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and
|
||||
``udl``.
|
||||
|
||||
Contact: Daniel Vetter, respective driver maintainers
|
||||
|
||||
Switch to drm_connector_list_iter for any connector_list walking
|
||||
----------------------------------------------------------------
|
||||
|
||||
Connectors can be hotplugged, and we now have a special list of helpers to walk
|
||||
the connector_list in a race-free fashion, without incurring deadlocks on
|
||||
mutexes and other fun stuff.
|
||||
|
||||
Unfortunately most drivers are not converted yet. At least all those supporting
|
||||
DP MST hotplug should be converted, since for those drivers the difference
|
||||
matters. See drm_for_each_connector_iter() vs. drm_for_each_connector().
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Core refactorings
|
||||
=================
|
||||
|
||||
Use new IDR deletion interface to clean up drm_gem_handle_delete()
|
||||
------------------------------------------------------------------
|
||||
|
||||
See the "This is gross" comment -- apparently the IDR system now can return an
|
||||
error code instead of oopsing.
|
||||
|
||||
Clean up the DRM header mess
|
||||
----------------------------
|
||||
|
||||
Currently the DRM subsystem has only one global header, ``drmP.h``. This is
|
||||
used both for functions exported to helper libraries and drivers and functions
|
||||
only used internally in the ``drm.ko`` module. The goal would be to move all
|
||||
header declarations not needed outside of ``drm.ko`` into
|
||||
``drivers/gpu/drm/drm_*_internal.h`` header files. ``EXPORT_SYMBOL`` also
|
||||
needs to be dropped for these functions.
|
||||
|
||||
This would nicely tie in with the below task to create kerneldoc after the API
|
||||
is cleaned up. Or with the "hide legacy cruft better" task.
|
||||
|
||||
Note that this is well in progress, but ``drmP.h`` is still huge. The updated
|
||||
plan is to switch to per-file driver API headers, which will also structure
|
||||
the kerneldoc better. This should also allow more fine-grained ``#include``
|
||||
directives.
|
||||
|
||||
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 DocBook.
|
||||
|
||||
See https://dri.freedesktop.org/docs/drm/ for what's there already.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Hide legacy cruft better
|
||||
------------------------
|
||||
|
||||
Way back DRM supported only drivers which shadow-attached to PCI devices with
|
||||
userspace or fbdev drivers setting up outputs. Modern DRM drivers take charge
|
||||
of the entire device, you can spot them with the DRIVER_MODESET flag.
|
||||
|
||||
Unfortunately there's still large piles of legacy code around which needs to
|
||||
be hidden so that driver writers don't accidentally end up using it. And to
|
||||
prevent security issues in those legacy IOCTLs from being exploited on modern
|
||||
drivers. This has multiple possible subtasks:
|
||||
|
||||
* Extract support code for legacy features into a ``drm-legacy.ko`` kernel
|
||||
module and compile it only when one of the legacy drivers is enabled.
|
||||
|
||||
This is mostly done, the only thing left is to split up ``drm_irq.c`` into
|
||||
legacy cruft and the parts needed by modern KMS drivers.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Make panic handling work
|
||||
------------------------
|
||||
|
||||
This is a really varied tasks with lots of little bits and pieces:
|
||||
|
||||
* The panic path can't be tested currently, leading to constant breaking. The
|
||||
main issue here is that panics can be triggered from hardirq contexts and
|
||||
hence all panic related callback can run in hardirq context. It would be
|
||||
awesome if we could test at least the fbdev helper code and driver code by
|
||||
e.g. trigger calls through drm debugfs files. hardirq context could be
|
||||
achieved by using an IPI to the local processor.
|
||||
|
||||
* There's a massive confusion of different panic handlers. DRM fbdev emulation
|
||||
helpers have one, but on top of that the fbcon code itself also has one. We
|
||||
need to make sure that they stop fighting over each another.
|
||||
|
||||
* ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and
|
||||
isn't a full solution for panic paths. We need to make sure that it only
|
||||
returns true if there's a panic going on for real, and fix up all the
|
||||
fallout.
|
||||
|
||||
* The panic handler must never sleep, which also means it can't ever
|
||||
``mutex_lock()``. Also it can't grab any other lock unconditionally, not
|
||||
even spinlocks (because NMI and hardirq can panic too). We need to either
|
||||
make sure to not call such paths, or trylock everything. Really tricky.
|
||||
|
||||
* For the above locking troubles reasons it's pretty much impossible to
|
||||
attempt a synchronous modeset from panic handlers. The only thing we could
|
||||
try to achive is an atomic ``set_base`` of the primary plane, and hope that
|
||||
it shows up. Everything else probably needs to be delayed to some worker or
|
||||
something else which happens later on. Otherwise it just kills the box
|
||||
harder, prevent the panic from going out on e.g. netconsole.
|
||||
|
||||
* There's also proposal for a simplied DRM console instead of the full-blown
|
||||
fbcon and DRM fbdev emulation. Any kind of panic handling tricks should
|
||||
obviously work for both console, in case we ever get kmslog merged.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Clean up the debugfs support
|
||||
----------------------------
|
||||
|
||||
There's a bunch of issues with it:
|
||||
|
||||
- The drm_info_list ->show() function doesn't even bother to cast to the drm
|
||||
structure for you. This is lazy.
|
||||
|
||||
- We probably want to have some support for debugfs files on crtc/connectors and
|
||||
maybe other kms objects directly in core. There's even drm_print support in
|
||||
the funcs for these objects to dump kms state, so it's all there. And then the
|
||||
->show() functions should obviously give you a pointer to the right object.
|
||||
|
||||
- The drm_info_list stuff is centered on drm_minor instead of drm_device. For
|
||||
anything we want to print drm_device (or maybe drm_file) is the right thing.
|
||||
|
||||
- The drm_driver->debugfs_init hooks we have is just an artifact of the old
|
||||
midlayered load sequence. DRM debugfs should work more like sysfs, where you
|
||||
can create properties/files for an object anytime you want, and the core
|
||||
takes care of publishing/unpuplishing all the files at register/unregister
|
||||
time. Drivers shouldn't need to worry about these technicalities, and fixing
|
||||
this (together with the drm_minor->drm_device move) would allow us to remove
|
||||
debugfs_init.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Better Testing
|
||||
==============
|
||||
|
||||
Enable trinity for DRM
|
||||
----------------------
|
||||
|
||||
And fix up the fallout. Should be really interesting ...
|
||||
|
||||
Make KMS tests in i-g-t generic
|
||||
-------------------------------
|
||||
|
||||
The i915 driver team maintains an extensive testsuite for the i915 DRM driver,
|
||||
including tons of testcases for corner-cases in the modesetting API. It would
|
||||
be awesome if those tests (at least the ones not relying on Intel-specific GEM
|
||||
features) could be made to run on any KMS driver.
|
||||
|
||||
Basic work to run i-g-t tests on non-i915 is done, what's now missing is mass-
|
||||
converting things over. For modeset tests we also first need a bit of
|
||||
infrastructure to use dumb buffers for untiled buffers, to be able to run all
|
||||
the non-i915 specific modeset tests.
|
||||
|
||||
Contact: Daniel Vetter
|
||||
|
||||
Create a virtual KMS driver for testing (vkms)
|
||||
----------------------------------------------
|
||||
|
||||
With all the latest helpers it should be fairly simple to create a virtual KMS
|
||||
driver useful for testing, or for running X or similar on headless machines
|
||||
(to be able to still use the GPU). This would be similar to vgem, but aimed at
|
||||
the modeset side.
|
||||
|
||||
Once the basics are there there's tons of possibilities to extend it.
|
||||
|
||||
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.
|
||||
|
||||
- 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.
|
||||
|
||||
- tinydrm_lastclose could be drm_fb_helper_lastclose. Only thing we need
|
||||
for that is to store the drm_fb_helper pointer somewhere in
|
||||
drm_device->mode_config. And then we could roll that out to all the
|
||||
drivers.
|
||||
|
||||
- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma
|
||||
helpers, as a _vmapped variant (since not every driver needs the vmap).
|
||||
And tinydrm_gem_cma_free_object could the be merged into
|
||||
drm_gem_cma_free_object().
|
||||
|
||||
- tinydrm_fb_create we could move into drm_simple_pipe, only need to add
|
||||
the fb_create hook to drm_simple_pipe_funcs, which would again simplify a
|
||||
bunch of things (since it gives you a one-stop vfunc for simple drivers).
|
||||
|
||||
- Quick aside: The unregister devm stuff is kinda getting the lifetimes of
|
||||
a drm_device wrong. Doesn't matter, since everyone else gets it wrong
|
||||
too :-)
|
||||
|
||||
- With the fbdev pointer in dev->mode_config we could also make
|
||||
suspend/resume helpers entirely generic, at least if we add a
|
||||
dev->mode_config.suspend_state. We could even provide a generic pm_ops
|
||||
structure with those.
|
||||
|
||||
- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above.
|
||||
|
||||
Contact: Noralf Trønnes, Daniel Vetter
|
||||
|
||||
Outside DRM
|
||||
===========
|
||||
89
Documentation/gpu/vc4.rst
Normal file
89
Documentation/gpu/vc4.rst
Normal file
|
|
@ -0,0 +1,89 @@
|
|||
=====================================
|
||||
drm/vc4 Broadcom VC4 Graphics Driver
|
||||
=====================================
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_drv.c
|
||||
:doc: Broadcom VC4 Graphics Driver
|
||||
|
||||
Display Hardware Handling
|
||||
=========================
|
||||
|
||||
This section covers everything related to the display hardware including
|
||||
the mode setting infrastructure, plane, sprite and cursor handling and
|
||||
display, output probing and related topics.
|
||||
|
||||
Pixel Valve (DRM CRTC)
|
||||
----------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_crtc.c
|
||||
:doc: VC4 CRTC module
|
||||
|
||||
HVS
|
||||
---
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_hvs.c
|
||||
:doc: VC4 HVS module.
|
||||
|
||||
HVS planes
|
||||
----------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_plane.c
|
||||
:doc: VC4 plane module
|
||||
|
||||
HDMI encoder
|
||||
------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_hdmi.c
|
||||
:doc: VC4 Falcon HDMI module
|
||||
|
||||
DSI encoder
|
||||
-----------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_dsi.c
|
||||
:doc: VC4 DSI0/DSI1 module
|
||||
|
||||
DPI encoder
|
||||
-----------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_dpi.c
|
||||
:doc: VC4 DPI module
|
||||
|
||||
VEC (Composite TV out) encoder
|
||||
------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_vec.c
|
||||
:doc: VC4 SDTV module
|
||||
|
||||
Memory Management and 3D Command Submission
|
||||
===========================================
|
||||
|
||||
This section covers the GEM implementation in the vc4 driver.
|
||||
|
||||
GPU buffer object (BO) management
|
||||
---------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_bo.c
|
||||
:doc: VC4 GEM BO management support
|
||||
|
||||
V3D binner command list (BCL) validation
|
||||
----------------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_validate.c
|
||||
:doc: Command list validator for VC4.
|
||||
|
||||
V3D render command list (RCL) generation
|
||||
----------------------------------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_render_cl.c
|
||||
:doc: Render command list generation
|
||||
|
||||
Shader validator for VC4
|
||||
---------------------------
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_validate_shaders.c
|
||||
:doc: Shader validator for VC4.
|
||||
|
||||
V3D Interrupts
|
||||
--------------
|
||||
|
||||
.. kernel-doc:: drivers/gpu/drm/vc4/vc4_irq.c
|
||||
:doc: Interrupt management for the V3D engine
|
||||
|
|
@ -1258,6 +1258,319 @@ The following tables list existing packed RGB formats.
|
|||
- b\ :sub:`2`
|
||||
- b\ :sub:`1`
|
||||
- b\ :sub:`0`
|
||||
* .. _MEDIA-BUS-FMT-RGB101010-1X30:
|
||||
|
||||
- MEDIA_BUS_FMT_RGB101010_1X30
|
||||
- 0x1018
|
||||
-
|
||||
- 0
|
||||
- 0
|
||||
- r\ :sub:`9`
|
||||
- r\ :sub:`8`
|
||||
- r\ :sub:`7`
|
||||
- r\ :sub:`6`
|
||||
- r\ :sub:`5`
|
||||
- r\ :sub:`4`
|
||||
- r\ :sub:`3`
|
||||
- r\ :sub:`2`
|
||||
- r\ :sub:`1`
|
||||
- r\ :sub:`0`
|
||||
- g\ :sub:`9`
|
||||
- g\ :sub:`8`
|
||||
- g\ :sub:`7`
|
||||
- g\ :sub:`6`
|
||||
- g\ :sub:`5`
|
||||
- g\ :sub:`4`
|
||||
- g\ :sub:`3`
|
||||
- g\ :sub:`2`
|
||||
- g\ :sub:`1`
|
||||
- g\ :sub:`0`
|
||||
- b\ :sub:`9`
|
||||
- b\ :sub:`8`
|
||||
- b\ :sub:`7`
|
||||
- b\ :sub:`6`
|
||||
- b\ :sub:`5`
|
||||
- b\ :sub:`4`
|
||||
- b\ :sub:`3`
|
||||
- b\ :sub:`2`
|
||||
- b\ :sub:`1`
|
||||
- b\ :sub:`0`
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\endgroup
|
||||
|
||||
|
||||
The following table list existing packed 36bit wide RGB formats.
|
||||
|
||||
.. tabularcolumns:: |p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
|
||||
|
||||
.. _v4l2-mbus-pixelcode-rgb-36:
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begingroup
|
||||
\tiny
|
||||
\setlength{\tabcolsep}{2pt}
|
||||
|
||||
.. flat-table:: 36bit RGB formats
|
||||
:header-rows: 2
|
||||
:stub-columns: 0
|
||||
:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
|
||||
|
||||
* - Identifier
|
||||
- Code
|
||||
-
|
||||
- :cspan:`35` Data organization
|
||||
* -
|
||||
-
|
||||
- Bit
|
||||
- 35
|
||||
- 34
|
||||
- 33
|
||||
- 32
|
||||
- 31
|
||||
- 30
|
||||
- 29
|
||||
- 28
|
||||
- 27
|
||||
- 26
|
||||
- 25
|
||||
- 24
|
||||
- 23
|
||||
- 22
|
||||
- 21
|
||||
- 20
|
||||
- 19
|
||||
- 18
|
||||
- 17
|
||||
- 16
|
||||
- 15
|
||||
- 14
|
||||
- 13
|
||||
- 12
|
||||
- 11
|
||||
- 10
|
||||
- 9
|
||||
- 8
|
||||
- 7
|
||||
- 6
|
||||
- 5
|
||||
- 4
|
||||
- 3
|
||||
- 2
|
||||
- 1
|
||||
- 0
|
||||
* .. _MEDIA-BUS-FMT-RGB121212-1X36:
|
||||
|
||||
- MEDIA_BUS_FMT_RGB121212_1X36
|
||||
- 0x1019
|
||||
-
|
||||
- r\ :sub:`11`
|
||||
- r\ :sub:`10`
|
||||
- r\ :sub:`9`
|
||||
- r\ :sub:`8`
|
||||
- r\ :sub:`7`
|
||||
- r\ :sub:`6`
|
||||
- r\ :sub:`5`
|
||||
- r\ :sub:`4`
|
||||
- r\ :sub:`3`
|
||||
- r\ :sub:`2`
|
||||
- r\ :sub:`1`
|
||||
- r\ :sub:`0`
|
||||
- g\ :sub:`11`
|
||||
- g\ :sub:`10`
|
||||
- g\ :sub:`9`
|
||||
- g\ :sub:`8`
|
||||
- g\ :sub:`7`
|
||||
- g\ :sub:`6`
|
||||
- g\ :sub:`5`
|
||||
- g\ :sub:`4`
|
||||
- g\ :sub:`3`
|
||||
- g\ :sub:`2`
|
||||
- g\ :sub:`1`
|
||||
- g\ :sub:`0`
|
||||
- b\ :sub:`11`
|
||||
- b\ :sub:`10`
|
||||
- b\ :sub:`9`
|
||||
- b\ :sub:`8`
|
||||
- b\ :sub:`7`
|
||||
- b\ :sub:`6`
|
||||
- b\ :sub:`5`
|
||||
- b\ :sub:`4`
|
||||
- b\ :sub:`3`
|
||||
- b\ :sub:`2`
|
||||
- b\ :sub:`1`
|
||||
- b\ :sub:`0`
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\endgroup
|
||||
|
||||
|
||||
The following table list existing packed 48bit wide RGB formats.
|
||||
|
||||
.. tabularcolumns:: |p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
|
||||
|
||||
.. _v4l2-mbus-pixelcode-rgb-48:
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begingroup
|
||||
\tiny
|
||||
\setlength{\tabcolsep}{2pt}
|
||||
|
||||
.. flat-table:: 48bit RGB formats
|
||||
:header-rows: 3
|
||||
:stub-columns: 0
|
||||
:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
|
||||
|
||||
* - Identifier
|
||||
- Code
|
||||
-
|
||||
- :cspan:`31` Data organization
|
||||
* -
|
||||
-
|
||||
- Bit
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- 47
|
||||
- 46
|
||||
- 45
|
||||
- 44
|
||||
- 43
|
||||
- 42
|
||||
- 41
|
||||
- 40
|
||||
- 39
|
||||
- 38
|
||||
- 37
|
||||
- 36
|
||||
- 35
|
||||
- 34
|
||||
- 33
|
||||
- 32
|
||||
* -
|
||||
-
|
||||
-
|
||||
- 31
|
||||
- 30
|
||||
- 29
|
||||
- 28
|
||||
- 27
|
||||
- 26
|
||||
- 25
|
||||
- 24
|
||||
- 23
|
||||
- 22
|
||||
- 21
|
||||
- 20
|
||||
- 19
|
||||
- 18
|
||||
- 17
|
||||
- 16
|
||||
- 15
|
||||
- 14
|
||||
- 13
|
||||
- 12
|
||||
- 11
|
||||
- 10
|
||||
- 9
|
||||
- 8
|
||||
- 7
|
||||
- 6
|
||||
- 5
|
||||
- 4
|
||||
- 3
|
||||
- 2
|
||||
- 1
|
||||
- 0
|
||||
* .. _MEDIA-BUS-FMT-RGB161616-1X48:
|
||||
|
||||
- MEDIA_BUS_FMT_RGB161616_1X48
|
||||
- 0x101a
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- r\ :sub:`15`
|
||||
- r\ :sub:`14`
|
||||
- r\ :sub:`13`
|
||||
- r\ :sub:`12`
|
||||
- r\ :sub:`11`
|
||||
- r\ :sub:`10`
|
||||
- r\ :sub:`9`
|
||||
- r\ :sub:`8`
|
||||
- r\ :sub:`7`
|
||||
- r\ :sub:`6`
|
||||
- r\ :sub:`5`
|
||||
- r\ :sub:`4`
|
||||
- r\ :sub:`3`
|
||||
- r\ :sub:`2`
|
||||
- r\ :sub:`1`
|
||||
- r\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
- g\ :sub:`15`
|
||||
- g\ :sub:`14`
|
||||
- g\ :sub:`13`
|
||||
- g\ :sub:`12`
|
||||
- g\ :sub:`11`
|
||||
- g\ :sub:`10`
|
||||
- g\ :sub:`9`
|
||||
- g\ :sub:`8`
|
||||
- g\ :sub:`7`
|
||||
- g\ :sub:`6`
|
||||
- g\ :sub:`5`
|
||||
- g\ :sub:`4`
|
||||
- g\ :sub:`3`
|
||||
- g\ :sub:`2`
|
||||
- g\ :sub:`1`
|
||||
- g\ :sub:`0`
|
||||
- b\ :sub:`15`
|
||||
- b\ :sub:`14`
|
||||
- b\ :sub:`13`
|
||||
- b\ :sub:`12`
|
||||
- b\ :sub:`11`
|
||||
- b\ :sub:`10`
|
||||
- b\ :sub:`9`
|
||||
- b\ :sub:`8`
|
||||
- b\ :sub:`7`
|
||||
- b\ :sub:`6`
|
||||
- b\ :sub:`5`
|
||||
- b\ :sub:`4`
|
||||
- b\ :sub:`3`
|
||||
- b\ :sub:`2`
|
||||
- b\ :sub:`1`
|
||||
- b\ :sub:`0`
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
|
|
@ -2344,7 +2657,8 @@ The format code is made of the following information.
|
|||
|
||||
- The number of bus samples per pixel. Pixels that are wider than the
|
||||
bus width must be transferred in multiple samples. Common values are
|
||||
1, 1.5 (encoded as 1_5) and 2.
|
||||
0.5 (encoded as 0_5; in this case two pixels are transferred per bus
|
||||
sample), 1, 1.5 (encoded as 1_5) and 2.
|
||||
|
||||
- The bus width. When the bus width is larger than the number of bits
|
||||
per pixel component, several components are packed in a single bus
|
||||
|
|
@ -5962,6 +6276,78 @@ the following codes.
|
|||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
* .. _MEDIA-BUS-FMT-UYYVYY8-0-5X24:
|
||||
|
||||
- MEDIA_BUS_FMT_UYYVYY8_0_5X24
|
||||
- 0x2026
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- u\ :sub:`7`
|
||||
- u\ :sub:`6`
|
||||
- u\ :sub:`5`
|
||||
- u\ :sub:`4`
|
||||
- u\ :sub:`3`
|
||||
- u\ :sub:`2`
|
||||
- u\ :sub:`1`
|
||||
- u\ :sub:`0`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- v\ :sub:`7`
|
||||
- v\ :sub:`6`
|
||||
- v\ :sub:`5`
|
||||
- v\ :sub:`4`
|
||||
- v\ :sub:`3`
|
||||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* .. _MEDIA-BUS-FMT-UYVY12-1X24:
|
||||
|
||||
- MEDIA_BUS_FMT_UYVY12_1X24
|
||||
|
|
@ -6287,6 +6673,78 @@ the following codes.
|
|||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
* .. _MEDIA-BUS-FMT-UYYVYY10-0-5X30:
|
||||
|
||||
- MEDIA_BUS_FMT_UYYVYY10_0_5X30
|
||||
- 0x2027
|
||||
-
|
||||
-
|
||||
-
|
||||
- u\ :sub:`9`
|
||||
- u\ :sub:`8`
|
||||
- u\ :sub:`7`
|
||||
- u\ :sub:`6`
|
||||
- u\ :sub:`5`
|
||||
- u\ :sub:`4`
|
||||
- u\ :sub:`3`
|
||||
- u\ :sub:`2`
|
||||
- u\ :sub:`1`
|
||||
- u\ :sub:`0`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- v\ :sub:`9`
|
||||
- v\ :sub:`8`
|
||||
- v\ :sub:`7`
|
||||
- v\ :sub:`6`
|
||||
- v\ :sub:`5`
|
||||
- v\ :sub:`4`
|
||||
- v\ :sub:`3`
|
||||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* .. _MEDIA-BUS-FMT-AYUV8-1X32:
|
||||
|
||||
- MEDIA_BUS_FMT_AYUV8_1X32
|
||||
|
|
@ -6326,6 +6784,506 @@ the following codes.
|
|||
- v\ :sub:`0`
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\endgroup
|
||||
|
||||
|
||||
The following table list existing packed 36bit wide YUV formats.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begingroup
|
||||
\tiny
|
||||
\setlength{\tabcolsep}{2pt}
|
||||
|
||||
.. tabularcolumns:: |p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
|
||||
|
||||
.. _v4l2-mbus-pixelcode-yuv8-36bit:
|
||||
|
||||
.. flat-table:: 36bit YUV Formats
|
||||
:header-rows: 2
|
||||
:stub-columns: 0
|
||||
:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
|
||||
|
||||
* - Identifier
|
||||
- Code
|
||||
-
|
||||
- :cspan:`35` Data organization
|
||||
* -
|
||||
-
|
||||
- Bit
|
||||
- 35
|
||||
- 34
|
||||
- 33
|
||||
- 32
|
||||
- 31
|
||||
- 30
|
||||
- 29
|
||||
- 28
|
||||
- 27
|
||||
- 26
|
||||
- 25
|
||||
- 24
|
||||
- 23
|
||||
- 22
|
||||
- 21
|
||||
- 10
|
||||
- 19
|
||||
- 18
|
||||
- 17
|
||||
- 16
|
||||
- 15
|
||||
- 14
|
||||
- 13
|
||||
- 12
|
||||
- 11
|
||||
- 10
|
||||
- 9
|
||||
- 8
|
||||
- 7
|
||||
- 6
|
||||
- 5
|
||||
- 4
|
||||
- 3
|
||||
- 2
|
||||
- 1
|
||||
- 0
|
||||
* .. _MEDIA-BUS-FMT-UYYVYY12-0-5X36:
|
||||
|
||||
- MEDIA_BUS_FMT_UYYVYY12_0_5X36
|
||||
- 0x2028
|
||||
-
|
||||
- u\ :sub:`11`
|
||||
- u\ :sub:`10`
|
||||
- u\ :sub:`9`
|
||||
- u\ :sub:`8`
|
||||
- u\ :sub:`7`
|
||||
- u\ :sub:`6`
|
||||
- u\ :sub:`5`
|
||||
- u\ :sub:`4`
|
||||
- u\ :sub:`3`
|
||||
- u\ :sub:`2`
|
||||
- u\ :sub:`1`
|
||||
- u\ :sub:`0`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
- v\ :sub:`11`
|
||||
- v\ :sub:`10`
|
||||
- v\ :sub:`9`
|
||||
- v\ :sub:`8`
|
||||
- v\ :sub:`7`
|
||||
- v\ :sub:`6`
|
||||
- v\ :sub:`5`
|
||||
- v\ :sub:`4`
|
||||
- v\ :sub:`3`
|
||||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* .. _MEDIA-BUS-FMT-YUV12-1X36:
|
||||
|
||||
- MEDIA_BUS_FMT_YUV12_1X36
|
||||
- 0x2029
|
||||
-
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- u\ :sub:`11`
|
||||
- u\ :sub:`10`
|
||||
- u\ :sub:`9`
|
||||
- u\ :sub:`8`
|
||||
- u\ :sub:`7`
|
||||
- u\ :sub:`6`
|
||||
- u\ :sub:`5`
|
||||
- u\ :sub:`4`
|
||||
- u\ :sub:`3`
|
||||
- u\ :sub:`2`
|
||||
- u\ :sub:`1`
|
||||
- u\ :sub:`0`
|
||||
- v\ :sub:`11`
|
||||
- v\ :sub:`10`
|
||||
- v\ :sub:`9`
|
||||
- v\ :sub:`8`
|
||||
- v\ :sub:`7`
|
||||
- v\ :sub:`6`
|
||||
- v\ :sub:`5`
|
||||
- v\ :sub:`4`
|
||||
- v\ :sub:`3`
|
||||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\endgroup
|
||||
|
||||
|
||||
The following table list existing packed 48bit wide YUV formats.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\begingroup
|
||||
\tiny
|
||||
\setlength{\tabcolsep}{2pt}
|
||||
|
||||
.. tabularcolumns:: |p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|
|
||||
|
||||
.. _v4l2-mbus-pixelcode-yuv8-48bit:
|
||||
|
||||
.. flat-table:: 48bit YUV Formats
|
||||
:header-rows: 3
|
||||
:stub-columns: 0
|
||||
:widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
|
||||
|
||||
* - Identifier
|
||||
- Code
|
||||
-
|
||||
- :cspan:`31` Data organization
|
||||
* -
|
||||
-
|
||||
- Bit
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- 47
|
||||
- 46
|
||||
- 45
|
||||
- 44
|
||||
- 43
|
||||
- 42
|
||||
- 41
|
||||
- 40
|
||||
- 39
|
||||
- 38
|
||||
- 37
|
||||
- 36
|
||||
- 35
|
||||
- 34
|
||||
- 33
|
||||
- 32
|
||||
* -
|
||||
-
|
||||
-
|
||||
- 31
|
||||
- 30
|
||||
- 29
|
||||
- 28
|
||||
- 27
|
||||
- 26
|
||||
- 25
|
||||
- 24
|
||||
- 23
|
||||
- 22
|
||||
- 21
|
||||
- 10
|
||||
- 19
|
||||
- 18
|
||||
- 17
|
||||
- 16
|
||||
- 15
|
||||
- 14
|
||||
- 13
|
||||
- 12
|
||||
- 11
|
||||
- 10
|
||||
- 9
|
||||
- 8
|
||||
- 7
|
||||
- 6
|
||||
- 5
|
||||
- 4
|
||||
- 3
|
||||
- 2
|
||||
- 1
|
||||
- 0
|
||||
* .. _MEDIA-BUS-FMT-YUV16-1X48:
|
||||
|
||||
- MEDIA_BUS_FMT_YUV16_1X48
|
||||
- 0x202a
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- y\ :sub:`15`
|
||||
- y\ :sub:`14`
|
||||
- y\ :sub:`13`
|
||||
- y\ :sub:`12`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
- u\ :sub:`15`
|
||||
- u\ :sub:`14`
|
||||
- u\ :sub:`13`
|
||||
- u\ :sub:`12`
|
||||
- u\ :sub:`11`
|
||||
- u\ :sub:`10`
|
||||
- u\ :sub:`9`
|
||||
- u\ :sub:`8`
|
||||
- u\ :sub:`7`
|
||||
- u\ :sub:`6`
|
||||
- u\ :sub:`5`
|
||||
- u\ :sub:`4`
|
||||
- u\ :sub:`3`
|
||||
- u\ :sub:`2`
|
||||
- u\ :sub:`1`
|
||||
- u\ :sub:`0`
|
||||
- v\ :sub:`15`
|
||||
- v\ :sub:`14`
|
||||
- v\ :sub:`13`
|
||||
- v\ :sub:`12`
|
||||
- v\ :sub:`11`
|
||||
- v\ :sub:`10`
|
||||
- v\ :sub:`9`
|
||||
- v\ :sub:`8`
|
||||
- v\ :sub:`7`
|
||||
- v\ :sub:`6`
|
||||
- v\ :sub:`5`
|
||||
- v\ :sub:`4`
|
||||
- v\ :sub:`3`
|
||||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
* .. _MEDIA-BUS-FMT-UYYVYY16-0-5X48:
|
||||
|
||||
- MEDIA_BUS_FMT_UYYVYY16_0_5X48
|
||||
- 0x202b
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- u\ :sub:`15`
|
||||
- u\ :sub:`14`
|
||||
- u\ :sub:`13`
|
||||
- u\ :sub:`12`
|
||||
- u\ :sub:`11`
|
||||
- u\ :sub:`10`
|
||||
- u\ :sub:`9`
|
||||
- u\ :sub:`8`
|
||||
- u\ :sub:`7`
|
||||
- u\ :sub:`6`
|
||||
- u\ :sub:`5`
|
||||
- u\ :sub:`4`
|
||||
- u\ :sub:`3`
|
||||
- u\ :sub:`2`
|
||||
- u\ :sub:`1`
|
||||
- u\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
- y\ :sub:`15`
|
||||
- y\ :sub:`14`
|
||||
- y\ :sub:`13`
|
||||
- y\ :sub:`12`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`15`
|
||||
- y\ :sub:`14`
|
||||
- y\ :sub:`13`
|
||||
- y\ :sub:`12`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
-
|
||||
- v\ :sub:`15`
|
||||
- v\ :sub:`14`
|
||||
- v\ :sub:`13`
|
||||
- v\ :sub:`12`
|
||||
- v\ :sub:`11`
|
||||
- v\ :sub:`10`
|
||||
- v\ :sub:`9`
|
||||
- v\ :sub:`8`
|
||||
- v\ :sub:`7`
|
||||
- v\ :sub:`6`
|
||||
- v\ :sub:`5`
|
||||
- v\ :sub:`4`
|
||||
- v\ :sub:`3`
|
||||
- v\ :sub:`2`
|
||||
- v\ :sub:`1`
|
||||
- v\ :sub:`0`
|
||||
* -
|
||||
-
|
||||
-
|
||||
- y\ :sub:`15`
|
||||
- y\ :sub:`14`
|
||||
- y\ :sub:`13`
|
||||
- y\ :sub:`12`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`9`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
- y\ :sub:`15`
|
||||
- y\ :sub:`14`
|
||||
- y\ :sub:`13`
|
||||
- y\ :sub:`12`
|
||||
- y\ :sub:`11`
|
||||
- y\ :sub:`10`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`8`
|
||||
- y\ :sub:`7`
|
||||
- y\ :sub:`6`
|
||||
- y\ :sub:`5`
|
||||
- y\ :sub:`4`
|
||||
- y\ :sub:`3`
|
||||
- y\ :sub:`2`
|
||||
- y\ :sub:`1`
|
||||
- y\ :sub:`0`
|
||||
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\endgroup
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@
|
|||
\renewcommand\thesection*
|
||||
\renewcommand\thesubsection*
|
||||
|
||||
.. _process_index:
|
||||
|
||||
Working with the kernel development community
|
||||
=============================================
|
||||
|
|
|
|||
Loading…
Reference in a new issue