Skip to content

Commit

Permalink
Merge tag 'drm-misc-next-2021-04-01' of git://anongit.freedesktop.org…
Browse files Browse the repository at this point in the history
…/drm/drm-misc into drm-next

drm-misc-next for 5.13:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - mst: Improve topology logging
  - edid: Rework and improvements for displayid

Driver Changes:
  - anx7625: Regulators support
  - bridge: Support for the Chipone ICN6211, Lontium LT8912B
  - lt9611: Fix 4k panels handling

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401110552.2b3yetlgsjtlotcn@gilmour
  • Loading branch information
Dave Airlie committed Apr 7, 2021
2 parents fb457e0 + 6c74498 commit 1539f71
Show file tree
Hide file tree
Showing 90 changed files with 4,724 additions and 577 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,15 @@ properties:
description: used for reset chip control, RESET_N pin B7.
maxItems: 1

vdd10-supply:
description: Regulator that provides the supply 1.0V power.

vdd18-supply:
description: Regulator that provides the supply 1.8V power.

vdd33-supply:
description: Regulator that provides the supply 3.3V power.

ports:
$ref: /schemas/graph.yaml#/properties/ports

Expand All @@ -55,6 +64,9 @@ properties:
required:
- compatible
- reg
- vdd10-supply
- vdd18-supply
- vdd33-supply
- ports

additionalProperties: false
Expand All @@ -72,6 +84,9 @@ examples:
reg = <0x58>;
enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
vdd10-supply = <&pp1000_mipibrdg>;
vdd18-supply = <&pp1800_mipibrdg>;
vdd33-supply = <&pp3300_mipibrdg>;
ports {
#address-cells = <1>;
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/chipone,icn6211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Chipone ICN6211 MIPI-DSI to RGB Converter bridge

maintainers:
- Jagan Teki <jagan@amarulasolutions.com>

description: |
ICN6211 is MIPI-DSI to RGB Converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input and
produce RGB565, RGB666, RGB888 output format.
properties:
compatible:
enum:
- chipone,icn6211

reg:
maxItems: 1
description: virtual channel number of a DSI peripheral

enable-gpios:
description: Bridge EN pin, chip is reset when EN is low.

vdd1-supply:
description: A 1.8V/2.5V/3.3V supply that power the MIPI RX.

vdd2-supply:
description: A 1.8V/2.5V/3.3V supply that power the PLL.

vdd3-supply:
description: A 1.8V/2.5V/3.3V supply that power the RGB output.

ports:
$ref: /schemas/graph.yaml#/properties/ports

properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
Video port for MIPI DSI input

port@1:
$ref: /schemas/graph.yaml#/properties/port
description:
Video port for MIPI DPI output (panel or connector).

required:
- port@0
- port@1

required:
- compatible
- reg
- enable-gpios
- ports

additionalProperties: false

examples:
- |
#include <dt-bindings/gpio/gpio.h>
dsi {
#address-cells = <1>;
#size-cells = <0>;
bridge@0 {
compatible = "chipone,icn6211";
reg = <0>;
enable-gpios = <&r_pio 0 5 GPIO_ACTIVE_HIGH>; /* LCD-RST: PL5 */
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
bridge_in_dsi: endpoint {
remote-endpoint = <&dsi_out_bridge>;
};
};
port@1 {
reg = <1>;
bridge_out_panel: endpoint {
remote-endpoint = <&panel_out_bridge>;
};
};
};
};
};
102 changes: 102 additions & 0 deletions Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912b.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Lontium LT8912B MIPI to HDMI Bridge

maintainers:
- Adrien Grassein <adrien.grassein@gmail.com>

description: |
The LT8912B is a bridge device which convert DSI to HDMI
properties:
compatible:
enum:
- lontium,lt8912b

reg:
maxItems: 1

reset-gpios:
maxItems: 1
description: GPIO connected to active high RESET pin.

ports:
$ref: /schemas/graph.yaml#/properties/ports

properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description:
Primary MIPI port for MIPI input

properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false

properties:
data-lanes: true

required:
- data-lanes

port@1:
$ref: /schemas/graph.yaml#/properties/port
description: |
HDMI port, should be connected to a node compatible with the
hdmi-connector binding.
required:
- port@0
- port@1

required:
- compatible
- reg
- reset-gpios
- ports

additionalProperties: false

examples:
- |
#include <dt-bindings/gpio/gpio.h>
i2c4 {
#address-cells = <1>;
#size-cells = <0>;
hdmi-bridge@48 {
compatible = "lontium,lt8912b";
reg = <0x48>;
reset-gpios = <&max7323 0 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
hdmi_out_in: endpoint {
data-lanes = <0 1 2 3>;
remote-endpoint = <&mipi_dsi_out>;
};
};
port@1 {
reg = <1>;
endpoint {
remote-endpoint = <&hdmi_in>;
};
};
};
};
};
...
Original file line number Diff line number Diff line change
Expand Up @@ -161,6 +161,8 @@ properties:
# Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
- innolux,g121x1-l03
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bca-ea1
# Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
- innolux,n116bge
# InnoLux 13.3" FHD (1920x1080) eDP TFT LCD panel
- innolux,n125hce-gn1
Expand Down
76 changes: 76 additions & 0 deletions Documentation/driver-api/dma-buf.rst
Original file line number Diff line number Diff line change
Expand Up @@ -257,3 +257,79 @@ fences in the kernel. This means:
userspace is allowed to use userspace fencing or long running compute
workloads. This also means no implicit fencing for shared buffers in these
cases.

Recoverable Hardware Page Faults Implications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Modern hardware supports recoverable page faults, which has a lot of
implications for DMA fences.

First, a pending page fault obviously holds up the work that's running on the
accelerator and a memory allocation is usually required to resolve the fault.
But memory allocations are not allowed to gate completion of DMA fences, which
means any workload using recoverable page faults cannot use DMA fences for
synchronization. Synchronization fences controlled by userspace must be used
instead.

On GPUs this poses a problem, because current desktop compositor protocols on
Linux rely on DMA fences, which means without an entirely new userspace stack
built on top of userspace fences, they cannot benefit from recoverable page
faults. Specifically this means implicit synchronization will not be possible.
The exception is when page faults are only used as migration hints and never to
on-demand fill a memory request. For now this means recoverable page
faults on GPUs are limited to pure compute workloads.

Furthermore GPUs usually have shared resources between the 3D rendering and
compute side, like compute units or command submission engines. If both a 3D
job with a DMA fence and a compute workload using recoverable page faults are
pending they could deadlock:

- The 3D workload might need to wait for the compute job to finish and release
hardware resources first.

- The compute workload might be stuck in a page fault, because the memory
allocation is waiting for the DMA fence of the 3D workload to complete.

There are a few options to prevent this problem, one of which drivers need to
ensure:

- Compute workloads can always be preempted, even when a page fault is pending
and not yet repaired. Not all hardware supports this.

- DMA fence workloads and workloads which need page fault handling have
independent hardware resources to guarantee forward progress. This could be
achieved through e.g. through dedicated engines and minimal compute unit
reservations for DMA fence workloads.

- The reservation approach could be further refined by only reserving the
hardware resources for DMA fence workloads when they are in-flight. This must
cover the time from when the DMA fence is visible to other threads up to
moment when fence is completed through dma_fence_signal().

- As a last resort, if the hardware provides no useful reservation mechanics,
all workloads must be flushed from the GPU when switching between jobs
requiring DMA fences or jobs requiring page fault handling: This means all DMA
fences must complete before a compute job with page fault handling can be
inserted into the scheduler queue. And vice versa, before a DMA fence can be
made visible anywhere in the system, all compute workloads must be preempted
to guarantee all pending GPU page faults are flushed.

- Only a fairly theoretical option would be to untangle these dependencies when
allocating memory to repair hardware page faults, either through separate
memory blocks or runtime tracking of the full dependency graph of all DMA
fences. This results very wide impact on the kernel, since resolving the page
on the CPU side can itself involve a page fault. It is much more feasible and
robust to limit the impact of handling hardware page faults to the specific
driver.

Note that workloads that run on independent hardware like copy engines or other
GPUs do not have any impact. This allows us to keep using DMA fences internally
in the kernel even for resolving hardware page faults, e.g. by using copy
engines to clear or copy memory needed to resolve the page fault.

In some ways this page fault problem is a special case of the `Infinite DMA
Fences` discussions: Infinite fences from compute workloads are allowed to
depend on DMA fences, but not the other way around. And not even the page fault
problem is new, because some other CPU thread in userspace might
hit a page fault which holds up a userspace fence - supporting page faults on
GPUs doesn't anything fundamentally new.
2 changes: 1 addition & 1 deletion Documentation/gpu/todo.rst
Original file line number Diff line number Diff line change
Expand Up @@ -677,7 +677,7 @@ Outside DRM
Convert fbdev drivers to DRM
----------------------------

There are plenty of fbdev drivers for older hardware. Some hwardware has
There are plenty of fbdev drivers for older hardware. Some hardware has
become obsolete, but some still provides good(-enough) framebuffers. The
drivers that are still useful should be converted to DRM and afterwards
removed from fbdev.
Expand Down
21 changes: 21 additions & 0 deletions MAINTAINERS
Original file line number Diff line number Diff line change
Expand Up @@ -5568,6 +5568,12 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
F: drivers/gpu/drm/panel/panel-boe-himax8279d.c

DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTER BRIDGE
M: Jagan Teki <jagan@amarulasolutions.com>
S: Maintained
F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
F: drivers/gpu/drm/bridge/chipone-icn6211.c

DRM DRIVER FOR FARADAY TVE200 TV ENCODER
M: Linus Walleij <linus.walleij@linaro.org>
S: Maintained
Expand All @@ -5586,6 +5592,14 @@ S: Maintained
F: Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml
F: drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c

DRM DRIVER FOR GENERIC USB DISPLAY
M: Noralf Trønnes <noralf@tronnes.org>
S: Maintained
W: https://github.com/notro/gud/wiki
T: git git://anongit.freedesktop.org/drm/drm-misc
F: drivers/gpu/drm/gud/
F: include/drm/gud.h

DRM DRIVER FOR GRAIN MEDIA GM12U320 PROJECTORS
M: Hans de Goede <hdegoede@redhat.com>
S: Maintained
Expand Down Expand Up @@ -5894,6 +5908,7 @@ F: drivers/gpu/drm/atmel-hlcdc/
DRM DRIVERS FOR BRIDGE CHIPS
M: Andrzej Hajda <a.hajda@samsung.com>
M: Neil Armstrong <narmstrong@baylibre.com>
M: Robert Foss <robert.foss@linaro.org>
R: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
R: Jonas Karlman <jonas@kwiboo.se>
R: Jernej Skrabec <jernej.skrabec@siol.net>
Expand Down Expand Up @@ -10460,6 +10475,12 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
F: drivers/hid/hid-lg-g15.c

LONTIUM LT8912B MIPI TO HDMI BRIDGE
M: Adrien Grassein <adrien.grassein@gmail.com>
S: Maintained
F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
F: drivers/gpu/drm/bridge/lontium-lt8912b.c

LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash <sathya.prakash@broadcom.com>
M: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Expand Down
2 changes: 2 additions & 0 deletions drivers/gpu/drm/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -384,6 +384,8 @@ source "drivers/gpu/drm/tidss/Kconfig"

source "drivers/gpu/drm/xlnx/Kconfig"

source "drivers/gpu/drm/gud/Kconfig"

# Keep legacy drivers last

menuconfig DRM_LEGACY
Expand Down
Loading

0 comments on commit 1539f71

Please sign in to comment.