dlan17/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge tag 'drm-next-2018-10-24' of git://anongit.freedesktop.org/drm/drm

Browse Source 
Pull drm updates from Dave Airlie:
 "This is going to rebuild more than drm as it adds a new helper to
  list.h for doing bulk updates. Seemed like a reasonable addition to
  me.

  Otherwise the usual merge window stuff lots of i915 and amdgpu, not so
  much nouveau, and piles of everything else.

  Core:
   - Adds a new list.h helper for doing bulk list updates for TTM.
   - Don't leak fb address in smem_start to userspace (comes with EXPORT
     workaround for people using mali out of tree hacks)
   - udmabuf device to turn memfd regions into dma-buf
   - Per-plane blend mode property
   - ref/unref replacements with get/put
   - fbdev conflicting framebuffers code cleaned up
   - host-endian format variants
   - panel orientation quirk for Acer One 10

  bridge:
   - TI SN65DSI86 chip support

  vkms:
   - GEM support.
   - Cursor support

  amdgpu:
   - Merge amdkfd and amdgpu into one module
   - CEC over DP AUX support
   - Picasso APU support + VCN dynamic powergating
   - Raven2 APU support
   - Vega20 enablement + kfd support
   - ACP powergating improvements
   - ABGR/XBGR display support
   - VCN jpeg support
   - xGMI support
   - DC i2c/aux cleanup
   - Ycbcr 4:2:0 support
   - GPUVM improvements
   - Powerplay and powerplay endian fixes
   - Display underflow fixes

  vmwgfx:
   - Move vmwgfx specific TTM code to vmwgfx
   - Split out vmwgfx buffer/resource validation code
   - Atomic operation rework

  bochs:
   - use more helpers
   - format/byteorder improvements

  qxl:
   - use more helpers

  i915:
   - GGTT coherency getparam
   - Turn off resource streamer API
   - More Icelake enablement + DMC firmware
   - Full PPGTT for Ivybridge, Haswell and Valleyview
   - DDB distribution based on resolution
   - Limited range DP display support

  nouveau:
   - CEC over DP AUX support
   - Initial HDMI 2.0 support

  virtio-gpu:
   - vmap support for PRIME objects

  tegra:
   - Initial Tegra194 support
   - DMA/IOMMU integration fixes

  msm:
   - a6xx perf improvements + clock prefix
   - GPU preemption optimisations
   - a6xx devfreq support
   - cursor support

  rockchip:
   - PX30 support
   - rgb output interface support

  mediatek:
   - HDMI output support on mt2701 and mt7623

  rcar-du:
   - Interlaced modes on Gen3
   - LVDS on R8A77980
   - D3 and E3 SoC support

  hisilicon:
   - misc fixes

  mxsfb:
   - runtime pm support

  sun4i:
   - R40 TCON support
   - Allwinner A64 support
   - R40 HDMI support

  omapdrm:
   - Driver rework changing display pipeline ordering to use common code
   - DMM memory barrier and irq fixes
   - Errata workarounds

  exynos:
   - out-bridge support for LVDS bridge driver
   - Samsung 16x16 tiled format support
   - Plane alpha and pixel blend mode support

  tilcdc:
   - suspend/resume update

  mali-dp:
   - misc updates"

* tag 'drm-next-2018-10-24' of git://anongit.freedesktop.org/drm/drm: (1382 commits)
  firmware/dmc/icl: Add missing MODULE_FIRMWARE() for Icelake.
  drm/i915/icl: Fix signal_levels
  drm/i915/icl: Fix DDI/TC port clk_off bits
  drm/i915/icl: create function to identify combophy port
  drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
  drm/i915: Large page offsets for pread/pwrite
  drm/i915/selftests: Disable shrinker across mmap-exhaustion
  drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode
  drm/i915: Fix intel_dp_mst_best_encoder()
  drm/i915: Skip vcpi allocation for MSTB ports that are gone
  drm/i915: Don't unset intel_connector->mst_port
  drm/i915: Only reset seqno if actually idle
  drm/i915: Use the correct crtc when sanitizing plane mapping
  drm/i915: Restore vblank interrupts earlier
  drm/i915: Check fb stride against plane max stride
  drm/amdgpu/vcn:Fix uninitialized symbol error
  drm: panel-orientation-quirks: Add quirk for Acer One 10 (S1003)
  drm/amd/amdgpu: Fix debugfs error handling
  drm/amdgpu: Update gc_9_0 golden settings.
  drm/amd/powerplay: update PPtable with DC BTC and Tvr SocLimit fields
  ...
This commit is contained in:
Linus Torvalds
2018-10-28 17:49:53 -07:00
parent 746bb4ed6d f2bfc71aee
commit 53b3b6bbfd
893 changed files with 107887 additions and 25792 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
+23
View File
@@ -15,6 +15,13 @@ Required children nodes:
to external devices using the OF graph reprensentation (see ../graph.txt).
At least one port node is required.
Optional properties in grandchild nodes:
Any endpoint grandchild node may specify a desired video interface
according to ../../media/video-interfaces.txt, specifically
- bus-width: recognized values are <12>, <16>, <18> and <24>, and
override any output mode selection heuristic, forcing "rgb444",
"rgb565", "rgb666" and "rgb888" respectively.
Example:
hlcdc: hlcdc@f0030000 {
@@ -50,3 +57,19 @@ Example:
#pwm-cells = <3>;
};
};
Example 2: With a video interface override to force rgb565; as above
but with these changes/additions:
&hlcdc {
hlcdc-display-controller {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
port@0 {
hlcdc_panel_output: endpoint@0 {
bus-width = <16>;
};
};
};
};
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+7 -1
View File
@@ -22,7 +22,13 @@ among others.
Required properties:
- compatible: Must be "lvds-encoder"
- compatible: Must be one or more of the following
- "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
- "lvds-encoder" for a generic LVDS encoder device
When compatible with the generic version, nodes must list the
device-specific version corresponding to the device first
followed by the generic version.
Required nodes:
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
+13 -1
View File
@@ -14,10 +14,22 @@ Required properties:
- "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
- "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
- "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders
- "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders
- "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders
- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders
- reg: Base address and length for the memory-mapped registers
- clocks: A phandle + clock-specifier pair for the functional clock
- clocks: A list of phandles + clock-specifier pairs, one for each entry in
the clock-names property.
- clock-names: Name of the clocks. This property is model-dependent.
- The functional clock, which mandatory for all models, shall be listed
first, and shall be named "fck".
- On R8A77990 and R8A77995, the LVDS encoder can use the EXTAL or
DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must be
named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN
numerical index.
- When the clocks property only contains the functional clock, the
clock-names property may be omitted.
- resets: A phandle + reset specifier for the module reset
Required nodes:
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
+87
View File
@@ -0,0 +1,87 @@
SN65DSI86 DSI to eDP bridge chip
--------------------------------
This is the binding for Texas Instruments SN65DSI86 bridge.
http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
Required properties:
- compatible: Must be "ti,sn65dsi86"
- reg: i2c address of the chip, 0x2d as per datasheet
- enable-gpios: gpio specification for bridge_en pin (active high)
- vccio-supply: A 1.8V supply that powers up the digital IOs.
- vpll-supply: A 1.8V supply that powers up the displayport PLL.
- vcca-supply: A 1.2V supply that powers up the analog circuits.
- vcc-supply: A 1.2V supply that powers up the digital core.
Optional properties:
- interrupts-extended: Specifier for the SN65DSI86 interrupt line.
- gpio-controller: Marks the device has a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../../gpio/gpio.txt for more information.
- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
the cell formats.
- clock-names: should be "refclk"
- clocks: Specification for input reference clock. The reference
clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
- data-lanes: See ../../media/video-interface.txt
- lane-polarities: See ../../media/video-interface.txt
- suspend-gpios: specification for GPIO1 pin on bridge (active low)
Required nodes:
This device has two video ports. Their connections are modelled using the
OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for DSI input
- Video port 1 for eDP output
Example
-------
edp-bridge@2d {
compatible = "ti,sn65dsi86";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x2d>;
enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>;
interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>;
vccio-supply = <&pm8916_l17>;
vcca-supply = <&pm8916_l6>;
vpll-supply = <&pm8916_l17>;
vcc-supply = <&pm8916_l6>;
clock-names = "refclk";
clocks = <&input_refclk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
edp_bridge_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
port@1 {
reg = <1>;
edp_bridge_out: endpoint {
data-lanes = <2 1 3 0>;
lane-polarities = <0 1 0 1>;
remote-endpoint = <&edp_panel_in>;
};
};
};
}
Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
+35
View File
@@ -0,0 +1,35 @@
TC358764 MIPI-DSI to LVDS panel bridge
Required properties:
- compatible: "toshiba,tc358764"
- reg: the virtual channel number of a DSI peripheral
- vddc-supply: core voltage supply, 1.2V
- vddio-supply: I/O voltage supply, 1.8V or 3.3V
- vddlvds-supply: LVDS1/2 voltage supply, 3.3V
- reset-gpios: a GPIO spec for the reset pin
The device node can contain following 'port' child nodes,
according to the OF graph bindings defined in [1]:
0: DSI Input, not required, if the bridge is DSI controlled
1: LVDS Output, mandatory
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
bridge@0 {
reg = <0>;
compatible = "toshiba,tc358764";
vddc-supply = <&vcc_1v2_reg>;
vddio-supply = <&vcc_1v8_reg>;
vddlvds-supply = <&vcc_3v3_reg>;
reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
lvds_ep: endpoint {
remote-endpoint = <&panel_ep>;
};
};
};
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
+6 -19
View File
@@ -21,6 +21,9 @@ Required properties:
- samsung,pll-clock-frequency: specifies frequency of the oscillator clock
- #address-cells, #size-cells: should be set respectively to <1> and <0>
according to DSI host bindings (see MIPI DSI bindings [1])
- samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst
mode
- samsung,esc-clock-frequency: specifies DSI frequency in escape mode
Optional properties:
- power-domains: a phandle to DSIM power domain node
@@ -29,25 +32,9 @@ Child nodes:
Should contain DSI peripheral nodes (see MIPI DSI bindings [1]).
Video interfaces:
Device node can contain video interface port nodes according to [2].
The following are properties specific to those nodes:
port node inbound:
- reg: (required) must be 0.
port node outbound:
- reg: (required) must be 1.
endpoint node connected from mic node (reg = 0):
- remote-endpoint: specifies the endpoint in mic node. This node is required
for Exynos5433 mipi dsi. So mic can access to panel node
throughout this dsi node.
endpoint node connected to panel node (reg = 1):
- remote-endpoint: specifies the endpoint in panel node. This node is
required in all kinds of exynos mipi dsi to represent
the connection between mipi dsi and panel.
- samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst
mode
- samsung,esc-clock-frequency: specifies DSI frequency in escape mode
Device node can contain following video interface port nodes according to [2]:
0: RGB input,
1: DSI output
[1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+145 -8
View File
@@ -16,7 +16,7 @@ The following assumes that only a single peripheral is connected to a DSI
host. Experience shows that this is true for the large majority of setups.
DSI host
--------
========
In addition to the standard properties and those defined by the parent bus of
a DSI host, the following properties apply to a node representing a DSI host.
@@ -29,12 +29,24 @@ Required properties:
- #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
DSI peripheral
--------------
Optional properties:
- clock-master: boolean. Should be enabled if the host is being used in
conjunction with another DSI host to drive the same peripheral. Hardware
supporting such a configuration generally requires the data on both the busses
to be driven by the same clock. Only the DSI host instance controlling this
clock should contain this property.
Peripherals are represented as child nodes of the DSI host's node. Properties
described here apply to all DSI peripherals, but individual bindings may want
to define additional, device-specific properties.
DSI peripheral
==============
Peripherals with DSI as control bus, or no control bus
------------------------------------------------------
Peripherals with the DSI bus as the primary control bus, or peripherals with
no control bus but use the DSI bus to transmit pixel data are represented
as child nodes of the DSI host's node. Properties described here apply to all
DSI peripherals, but individual bindings may want to define additional,
device-specific properties.
Required properties:
- reg: The virtual channel number of a DSI peripheral. Must be in the range
@@ -49,9 +61,37 @@ case two alternative representations can be chosen:
property is the number of the first virtual channel and the second cell is
the number of consecutive virtual channels.
Example
-------
Peripherals with a different control bus
----------------------------------------
There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
primary control bus, but are also connected to a DSI bus (mostly for the data
path). Connections between such peripherals and a DSI host can be represented
using the graph bindings [1], [2].
Peripherals that support dual channel DSI
-----------------------------------------
Peripherals with higher bandwidth requirements can be connected to 2 DSI
busses. Each DSI bus/channel drives some portion of the pixel data (generally
left/right half of each line of the display, or even/odd lines of the display).
The graph bindings should be used to represent the multiple DSI busses that are
connected to this peripheral. Each DSI host's output endpoint can be linked to
an input endpoint of the DSI peripheral.
[1] Documentation/devicetree/bindings/graph.txt
[2] Documentation/devicetree/bindings/media/video-interfaces.txt
Examples
========
- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
with different virtual channel configurations.
- (4) is an example of a peripheral on a I2C control bus connected to a
DSI host using of-graph bindings.
- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
which uses I2C as its primary control bus.
1)
dsi-host {
...
@@ -67,6 +107,7 @@ Example
...
};
2)
dsi-host {
...
@@ -82,6 +123,7 @@ Example
...
};
3)
dsi-host {
...
@@ -96,3 +138,98 @@ Example
...
};
4)
i2c-host {
...
dsi-bridge@35 {
compatible = "...";
reg = <0x35>;
ports {
...
port {
bridge_mipi_in: endpoint {
remote-endpoint = <&host_mipi_out>;
};
};
};
};
};
dsi-host {
...
ports {
...
port {
host_mipi_out: endpoint {
remote-endpoint = <&bridge_mipi_in>;
};
};
};
};
5)
i2c-host {
dsi-bridge@35 {
compatible = "...";
reg = <0x35>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dsi0_in: endpoint {
remote-endpoint = <&dsi0_out>;
};
};
port@1 {
reg = <1>;
dsi1_in: endpoint {
remote-endpoint = <&dsi1_out>;
};
};
};
};
};
dsi0-host {
...
/*
* this DSI instance drives the clock for both the host
* controllers
*/
clock-master;
ports {
...
port {
dsi0_out: endpoint {
remote-endpoint = <&dsi0_in>;
};
};
};
};
dsi1-host {
...
ports {
...
port {
dsi1_out: endpoint {
remote-endpoint = <&dsi1_in>;
};
};
};
};
Documentation/devicetree/bindings/display/renesas,du.txt
+4
View File
@@ -15,6 +15,8 @@ Required Properties:
- "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
- "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
- "renesas,du-r8a77990" for R8A77990 (R-Car E3) compatible DU
- "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
- reg: the memory-mapped I/O registers base address and length
@@ -61,6 +63,8 @@ corresponding to each DU output.
R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 -
R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - -
R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - -
R8A77990 (R-Car E3) DPAD 0 LVDS 0 LVDS 1 -
R8A77995 (R-Car D3) DPAD 0 LVDS 0 LVDS 1 -
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+3
View File
@@ -8,6 +8,9 @@ Required properties:
- compatible: value should be one of the following
"rockchip,rk3036-vop";
"rockchip,rk3126-vop";
"rockchip,px30-vop-lit";
"rockchip,px30-vop-big";
"rockchip,rk3188-vop";
"rockchip,rk3288-vop";
"rockchip,rk3368-vop";
"rockchip,rk3366-vop";
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+14 -2
View File
@@ -78,6 +78,7 @@ Required properties:
- compatible: value must be one of:
* "allwinner,sun8i-a83t-dw-hdmi"
* "allwinner,sun50i-a64-dw-hdmi", "allwinner,sun8i-a83t-dw-hdmi"
- reg: base address and size of memory-mapped region
- reg-io-width: See dw_hdmi.txt. Shall be 1.
- interrupts: HDMI interrupt number
@@ -96,6 +97,9 @@ Required properties:
first port should be the input endpoint. The second should be the
output, usually to an HDMI connector.
Optional properties:
- hvcc-supply: the VCC power supply of the controller
DWC HDMI PHY
------------
@@ -103,6 +107,7 @@ Required properties:
- compatible: value must be one of:
* allwinner,sun8i-a83t-hdmi-phy
* allwinner,sun8i-h3-hdmi-phy
* allwinner,sun8i-r40-hdmi-phy
* allwinner,sun50i-a64-hdmi-phy
- reg: base address and size of memory-mapped region
- clocks: phandles to the clocks feeding the HDMI PHY
@@ -112,9 +117,9 @@ Required properties:
- resets: phandle to the reset controller driving the PHY
- reset-names: must be "phy"
H3 and A64 HDMI PHY require additional clocks:
H3, A64 and R40 HDMI PHY require additional clocks:
- pll-0: parent of phy clock
- pll-1: second possible phy clock parent (A64 only)
- pll-1: second possible phy clock parent (A64/R40 only)
TV Encoder
----------
@@ -151,6 +156,8 @@ Required properties:
* allwinner,sun8i-v3s-tcon
* allwinner,sun9i-a80-tcon-lcd
* allwinner,sun9i-a80-tcon-tv
* "allwinner,sun50i-a64-tcon-lcd", "allwinner,sun8i-a83t-tcon-lcd"
* "allwinner,sun50i-a64-tcon-tv", "allwinner,sun8i-a83t-tcon-tv"
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
- clocks: phandles to the clocks feeding the TCON.
@@ -369,7 +376,11 @@ Required properties:
* allwinner,sun8i-a83t-de2-mixer-0
* allwinner,sun8i-a83t-de2-mixer-1
* allwinner,sun8i-h3-de2-mixer-0
* allwinner,sun8i-r40-de2-mixer-0
* allwinner,sun8i-r40-de2-mixer-1
* allwinner,sun8i-v3s-de2-mixer
* allwinner,sun50i-a64-de2-mixer-0
* allwinner,sun50i-a64-de2-mixer-1
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the mixer
* bus: the mixer interface clock
@@ -403,6 +414,7 @@ Required properties:
* allwinner,sun8i-r40-display-engine
* allwinner,sun8i-v3s-display-engine
* allwinner,sun9i-a80-display-engine
* allwinner,sun50i-a64-display-engine
- allwinner,pipelines: list of phandle to the display engine
frontends (DE 1.0) or mixers (DE 2.0) available.
Documentation/gpu/drivers.rst
+1
View File
@@ -13,6 +13,7 @@ GPU Driver Documentation
tve200
v3d
vc4
vkms
bridge/dw-hdmi
xen-front
Documentation/gpu/drm-kms.rst
+15 -3
View File
@@ -287,8 +287,14 @@ Atomic Mode Setting Function Reference
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
:export:
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
:internal:
Atomic Mode Setting IOCTL and UAPI Functions
--------------------------------------------
.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
:doc: overview
.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
:export:
CRTC Abstraction
================
@@ -323,6 +329,12 @@ Frame Buffer Functions Reference
DRM Format Handling
===================
.. kernel-doc:: include/uapi/drm/drm_fourcc.h
:doc: overview
Format Functions Reference
--------------------------
.. kernel-doc:: include/drm/drm_fourcc.h
:internal:
@@ -560,7 +572,7 @@ Tile Group Property
Explicit Fencing Properties
---------------------------
.. kernel-doc:: drivers/gpu/drm/drm_atomic.c
.. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
:doc: explicit fencing properties
Existing KMS Properties
Documentation/gpu/drm-mm.rst
+3 -3
View File
@@ -297,7 +297,7 @@ made up of several fields, the more interesting ones being:
struct vm_operations_struct {
void (*open)(struct vm_area_struct * area);
void (*close)(struct vm_area_struct * area);
int (*fault)(struct vm_fault *vmf);
vm_fault_t (*fault)(struct vm_fault *vmf);
};
@@ -505,7 +505,7 @@ GPU Scheduler
Overview
--------
.. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler.c
.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
:doc: Overview
Scheduler Function References
@@ -514,5 +514,5 @@ Scheduler Function References
.. kernel-doc:: include/drm/gpu_scheduler.h
:internal:
.. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler.c
.. kernel-doc:: drivers/gpu/drm/scheduler/sched_main.c
:export:
Documentation/gpu/todo.rst
+15 -56
View File
@@ -127,7 +127,8 @@ interfaces to fix these issues:
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.
Except for some driver code this is done.
Except for some driver code this is done. This task should be finished by
adding WARN_ON(!drm_drv_uses_atomic_modeset) in drm_modeset_lock_all().
* 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
@@ -137,13 +138,6 @@ interfaces to fix these issues:
``_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.
This was almost done, but new drivers added a few more cases again.
Contact: Daniel Vetter
Get rid of dev->struct_mutex from GEM drivers
@@ -164,9 +158,8 @@ private lock. The tricky part is the BO free functions, since those can't
reliably take that lock any more. Instead state needs to be protected with
suitable subordinate locks or some cleanup work pushed to a worker thread. For
performance-critical drivers it might also be better to go with a more
fine-grained per-buffer object and per-context lockings scheme. Currently the
following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and
``udl``.
fine-grained per-buffer object and per-context lockings scheme. Currently only the
``msm`` driver still use ``struct_mutex``.
Contact: Daniel Vetter, respective driver maintainers
@@ -190,7 +183,8 @@ Convert drivers to use simple modeset suspend/resume
Most drivers (except i915 and nouveau) that use
drm_atomic_helper_suspend/resume() can probably be converted to use
drm_mode_config_helper_suspend/resume().
drm_mode_config_helper_suspend/resume(). Also there's still open-coded version
of the atomic suspend/resume code in older atomic modeset drivers.
Contact: Maintainer of the driver you plan to convert
@@ -246,20 +240,10 @@ Core refactorings
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.
The DRM subsystem originally had only one huge global header, ``drmP.h``. This
is now split up, but many source files still include it. The remaining part of
the cleanup work here is to replace any ``#include <drm/drmP.h>`` by only the
headers needed (and fixing up any missing pre-declarations in the headers).
In the end no .c file should need to include ``drmP.h`` anymore.
@@ -278,26 +262,6 @@ 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
------------------------
@@ -396,17 +360,12 @@ 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
Extend virtual test driver (VKMS)
---------------------------------
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.
See the documentation of :ref:`VKMS <vkms>` for more details. This is an ideal
internship task, since it only requires a virtual machine and can be sized to
fit the available time.
Contact: Daniel Vetter
Documentation/gpu/vkms.rst
+24
View File
@@ -0,0 +1,24 @@
.. _vkms:
==========================================
drm/vkms Virtual Kernel Modesetting
==========================================
.. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
:doc: vkms (Virtual Kernel Modesetting)
TODO
====
CRC API
-------
- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
- Use the alpha value to blend vaddr_src with vaddr_dst instead of
overwriting it in ``blend()``.
- Add igt test to check cleared alpha value for XRGB plane format.
- Add igt test to check extreme alpha values i.e. fully opaque and fully
transparent (intermediate values are affected by hw-specific rounding modes).
Documentation/ioctl/ioctl-number.txt
+1
View File
@@ -272,6 +272,7 @@ Code Seq#(hex) Include File Comments
't' 90-91 linux/toshiba.h toshiba and toshiba_acpi SMM
'u' 00-1F linux/smb_fs.h gone
'u' 20-3F linux/uvcvideo.h USB video class host driver
'u' 40-4f linux/udmabuf.h userspace dma-buf misc device
'v' 00-1F linux/ext2_fs.h conflict!
'v' 00-1F linux/fs.h conflict!
'v' 00-0F linux/sonypi.h conflict!