dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[v3 0/2] drm: Add support for backlight control of eDP panel on ti-sn65dsi86 bridge
by Rajeev Nandan 25 May '21

25 May '21

The backlight level of an eDP panel can be controlled through the AUX channel using DPCD registers of the panel. The capability for the Source device to adjust backlight characteristics within the panel, using the Sink device DPCD registers is indicated by the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE bit in the EDP_GENERAL_CAPABILITY_1 register (DPCD Address 701h, bit0). In this configuration, the eDP TCON receives the backlight level information from the host, through the AUX channel. Anderson's patch series [1] exposed the DDC bus from ti-sn65dsi86 bridge, that gives an option to move the backlight control out of the bridge and to create a separate backlight driver. Changes in v2: - Created a new DisplayPort aux backlight driver and moved the code from drm_dp_aux_backlight.c (v1) to the new driver. - Removed the changes done in ti-sn65dsi86 bridge. (Rob Herring) Changes in v3: - Add missing ';' to fix module compilation (kernel test bot) [1] https://lore.kernel.org/dri-devel/20210416223950.3586967-1-dianders@chromiu… Rajeev Nandan (2): dt-bindings: backlight: add DisplayPort aux backlight backlight: Add DisplayPort aux backlight driver .../bindings/leds/backlight/dp-aux-backlight.yaml | 49 +++++ drivers/video/backlight/Kconfig | 7 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/dp_aux_backlight.c | 245 +++++++++++++++++++++ 4 files changed, 302 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml create mode 100644 drivers/video/backlight/dp_aux_backlight.c -- 2.7.4

7 15

[PATCH] drm/meson: fix shutdown crash when component not probed
by Neil Armstrong 25 May '21

25 May '21

When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... pc : meson_drv_shutdown+0x24/0x50 lr : platform_drv_shutdown+0x20/0x30 ... Call trace: meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x30 device_shutdown+0x158/0x360 kernel_restart_prepare+0x38/0x48 kernel_restart+0x18/0x68 __do_sys_reboot+0x224/0x250 __arm64_sys_reboot+0x24/0x30 ... Simply check if the priv struct has been allocated before using it. Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function") Reported-by: Stefan Agner <stefan(a)agner.ch> Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- drivers/gpu/drm/meson/meson_drv.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/meson/meson_drv.c b/drivers/gpu/drm/meson/meson_drv.c index 453d8b4c5763..07fcd12dca16 100644 --- a/drivers/gpu/drm/meson/meson_drv.c +++ b/drivers/gpu/drm/meson/meson_drv.c @@ -485,11 +485,12 @@ static int meson_probe_remote(struct platform_device *pdev, static void meson_drv_shutdown(struct platform_device *pdev) { struct meson_drm *priv = dev_get_drvdata(&pdev->dev); - struct drm_device *drm = priv->drm; - DRM_DEBUG_DRIVER("\n"); - drm_kms_helper_poll_fini(drm); - drm_atomic_helper_shutdown(drm); + if (!priv) + return; + + drm_kms_helper_poll_fini(priv->drm); + drm_atomic_helper_shutdown(priv->drm); } static int meson_drv_probe(struct platform_device *pdev) -- 2.25.1

2 4

[PATCHv2 0/5] Support for GE B1x5v2 and B1x5Pv2
by Sebastian Reichel 24 May '21

24 May '21

Hi, This series adds support for another General Electric patient monitor series (similar to existing Bx50v3), which is based on i.MX6DL using Congatec's QMX6 module. The module uses an I2C RTC to provide the i.MX6 32768 Hz clock, so it's important to keep it enabled. Not doing so results in incorrect timings of watchdog and i.MX6 RTC. The bootloader enables the watchdog, so disabling the clock results in system reboot. [0] The second patch is required for B155v2, which uses a 1366x768 G156XTN01 panel. The 1366 width is not supported by the display pipeline and result in boot hanging without the patch. [1] Patches 3+4 are updating DT bindings for the new board compatible values. Patch 5 adds the board files. Changes since PATCHv1: * https://lore.kernel.org/lkml/20210222171247.97609-1-sebastian.reichel@colla… * drop patch 5 (applied) * instead of using 'protected-clocks' in RTC node, add fixed-clock node as suggested by Saravana Kannan * rebased to current master (68a32ba14177) Thanks, [0] There has been a discussion for the problem on the mailinglists last year. The discussion died off, when I told people their ideas don't work. I hope using protected-clocks is fine for this usecase. https://lore.kernel.org/linux-clk/20191108170135.9053-1-sebastian.reichel@c… [1] I've sent this before as a separate patch in September, but nobody seemed to care. This adds full context for the problem. https://lore.kernel.org/dri-devel/20200910162831.321556-1-sebastian.reichel… -- Sebastian Sebastian Reichel (5): rtc: m41t80: add support for fixed clock drm/imx: Add 8 pixel alignment fix dt-bindings: vendor-prefixes: add congatec dt-bindings: arm: fsl: add GE B1x5pv2 boards ARM: dts: imx6: Add GE B1x5v2 .../devicetree/bindings/arm/fsl.yaml | 11 + .../devicetree/bindings/rtc/rtc-m41t80.txt | 9 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 5 + arch/arm/boot/dts/imx6dl-b105pv2.dts | 35 + arch/arm/boot/dts/imx6dl-b105v2.dts | 35 + arch/arm/boot/dts/imx6dl-b125pv2.dts | 33 + arch/arm/boot/dts/imx6dl-b125v2.dts | 33 + arch/arm/boot/dts/imx6dl-b155v2.dts | 36 + arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 ++++++++++++ arch/arm/boot/dts/imx6dl-b1x5v2.dtsi | 61 ++ arch/arm/boot/dts/imx6dl-qmx6.dtsi | 624 ++++++++++++++++++ drivers/gpu/drm/imx/imx-drm-core.c | 19 +- drivers/gpu/drm/imx/imx-ldb.c | 5 + drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +- drivers/gpu/drm/imx/ipuv3-plane.c | 19 +- drivers/gpu/ipu-v3/ipu-dc.c | 5 + drivers/gpu/ipu-v3/ipu-di.c | 7 + drivers/rtc/rtc-m41t80.c | 12 + 19 files changed, 1390 insertions(+), 6 deletions(-) create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi -- 2.30.2

6 12

[Bug 208573] New: Black screen on boot if two displays plugged in with NAVI 10
by bugzilla-daemon＠bugzilla.kernel.org 24 May '21

24 May '21

https://bugzilla.kernel.org/show_bug.cgi?id=208573 Bug ID: 208573 Summary: Black screen on boot if two displays plugged in with NAVI 10 Product: Drivers Version: 2.5 Kernel Version: 5.7.8-6-MANJARO Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: thomas.langkamp(a)medicalschool-hamburg.de Regression: No With Radeon R9 Fury X and 2 4k displays @60hz, one LG TV@HDMI, one iiyama@DP => everything fine With new Radeon 5700 from Asus => black screen after grub menu and after some time the gpu-fans spin up a bit and the mainboard debug LED starts flashing. Then reset-button is the only option. With new Radeon 5700 XT from Gigabyte => same So I can already rule out a hardware fault. What helps: - Starting a recovery boot entry in grub - OR disconecting one display before reboot Both 5700 cards work always fine with only one display connected. If I connect the second display later, when I am already on desktop environment - also everything works. Other things I tried - changing to 30 hz then reboot - kernels from 5.4 onwards - different ports on the gpu - DP to HDMI-adapter sudo dmesg | grep amdgpu [sudo] Passwort für tom: [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.7-x86_64 root=UUID=74886ca0-4a71-4692-aa0c-b2a539ec6b48 rw quiet loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3 amdgpu.ppfeaturemask=0xfffd7fff resume=LABEL=swap libahci.ignore_sss=1 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.7-x86_64 root=UUID=74886ca0-4a71-4692-aa0c-b2a539ec6b48 rw quiet loglevel=3 rd.systemd.show_status=auto rd.udev.log_priority=3 amdgpu.ppfeaturemask=0xfffd7fff resume=LABEL=swap libahci.ignore_sss=1 [ 2.597324] [drm] amdgpu kernel modesetting enabled. [ 2.597526] fb0: switching to amdgpudrmfb from EFI VGA [ 2.597631] amdgpu 0000:0d:00.0: vgaarb: deactivate vga console [ 2.597664] amdgpu 0000:0d:00.0: enabling device (0006 -> 0007) [ 2.615476] amdgpu 0000:0d:00.0: VRAM: 8176M 0x0000008000000000 - 0x00000081FEFFFFFF (8176M used) [ 2.615477] amdgpu 0000:0d:00.0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF [ 2.615580] [drm] amdgpu: 8176M of VRAM memory ready [ 2.615583] [drm] amdgpu: 8176M of GTT memory ready. [ 3.433349] amdgpu 0000:0d:00.0: RAS: optional ras ta ucode is not available [ 3.528083] snd_hda_intel 0000:0d:00.1: bound 0000:0d:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) [ 3.628396] fbcon: amdgpudrmfb (fb0) is primary device [ 3.739398] amdgpu 0000:0d:00.0: fb0: amdgpudrmfb frame buffer device [ 3.783482] amdgpu 0000:0d:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0 [ 3.783485] amdgpu 0000:0d:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0 [ 3.783487] amdgpu 0000:0d:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0 [ 3.783489] amdgpu 0000:0d:00.0: ring comp_1.2.0 uses VM inv eng 5 on hub 0 [ 3.783491] amdgpu 0000:0d:00.0: ring comp_1.3.0 uses VM inv eng 6 on hub 0 [ 3.783492] amdgpu 0000:0d:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0 [ 3.783494] amdgpu 0000:0d:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0 [ 3.783496] amdgpu 0000:0d:00.0: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [ 3.783498] amdgpu 0000:0d:00.0: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [ 3.783499] amdgpu 0000:0d:00.0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0 [ 3.783501] amdgpu 0000:0d:00.0: ring sdma0 uses VM inv eng 12 on hub 0 [ 3.783503] amdgpu 0000:0d:00.0: ring sdma1 uses VM inv eng 13 on hub 0 [ 3.783505] amdgpu 0000:0d:00.0: ring vcn_dec uses VM inv eng 0 on hub 1 [ 3.783506] amdgpu 0000:0d:00.0: ring vcn_enc0 uses VM inv eng 1 on hub 1 [ 3.783508] amdgpu 0000:0d:00.0: ring vcn_enc1 uses VM inv eng 4 on hub 1 [ 3.783510] amdgpu 0000:0d:00.0: ring jpeg_dec uses VM inv eng 5 on hub 1 [ 3.784426] [drm] Initialized amdgpu 3.37.0 20150101 for 0000:0d:00.0 on minor 0 [ 2050.217010] amdgpu 0000:0d:00.0: RAS: optional ras ta ucode is not available [ 2050.416499] [drm:dpcd_set_source_specific_data [amdgpu]] *ERROR* Error in DP aux read transaction, not writing source specific data [ 2050.925049] [drm:retrieve_link_cap [amdgpu]] *ERROR* retrieve_link_cap: Read dpcd data failed. [ 2050.934845] amdgpu 0000:0d:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0 [ 2050.934846] amdgpu 0000:0d:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0 [ 2050.934846] amdgpu 0000:0d:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0 [ 2050.934847] amdgpu 0000:0d:00.0: ring comp_1.2.0 uses VM inv eng 5 on hub 0 [ 2050.934847] amdgpu 0000:0d:00.0: ring comp_1.3.0 uses VM inv eng 6 on hub 0 [ 2050.934848] amdgpu 0000:0d:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0 [ 2050.934849] amdgpu 0000:0d:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0 [ 2050.934849] amdgpu 0000:0d:00.0: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [ 2050.934850] amdgpu 0000:0d:00.0: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [ 2050.934850] amdgpu 0000:0d:00.0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0 [ 2050.934851] amdgpu 0000:0d:00.0: ring sdma0 uses VM inv eng 12 on hub 0 [ 2050.934851] amdgpu 0000:0d:00.0: ring sdma1 uses VM inv eng 13 on hub 0 [ 2050.934852] amdgpu 0000:0d:00.0: ring vcn_dec uses VM inv eng 0 on hub 1 [ 2050.934852] amdgpu 0000:0d:00.0: ring vcn_enc0 uses VM inv eng 1 on hub 1 [ 2050.934853] amdgpu 0000:0d:00.0: ring vcn_enc1 uses VM inv eng 4 on hub 1 [ 2050.934853] amdgpu 0000:0d:00.0: ring jpeg_dec uses VM inv eng 5 on hub 1 lspci -v 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Root Complex Subsystem: ASRock Incorporation Device 1450 Flags: fast devsel 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge Flags: fast devsel 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 25 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: fcf00000-fcffffff [size=1M] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 26 Bus: primary=00, secondary=02, subordinate=0a, sec-latency=0 I/O behind bridge: 0000f000-0000ffff [size=4K] Memory behind bridge: fcc00000-fcdfffff [size=2M] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge Flags: fast devsel 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge Flags: fast devsel 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 27 Bus: primary=00, secondary=0b, subordinate=0d, sec-latency=0 I/O behind bridge: 0000e000-0000efff [size=4K] Memory behind bridge: fca00000-fcbfffff [size=2M] Prefetchable memory behind bridge: 00000000e0000000-00000000f01fffff [size=258M] Capabilities: <access denied> Kernel driver in use: pcieport 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge Flags: fast devsel 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge Flags: fast devsel 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 28 Bus: primary=00, secondary=0e, subordinate=0e, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: fc700000-fc9fffff [size=3M] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge Flags: fast devsel 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 30 Bus: primary=00, secondary=0f, subordinate=0f, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: fce00000-fcefffff [size=1M] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 59) Subsystem: ASRock Incorporation Device 790b Flags: 66MHz, medium devsel Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4, sp5100_tco 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) Subsystem: ASRock Incorporation Device 790e Flags: bus master, 66MHz, medium devsel, latency 0 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 0 Flags: fast devsel 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 1 Flags: fast devsel 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 2 Flags: fast devsel 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 3 Flags: fast devsel Kernel driver in use: k10temp Kernel modules: k10temp 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 4 Flags: fast devsel 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 5 Flags: fast devsel 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 6 Flags: fast devsel 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 7 Flags: fast devsel 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 (prog-if 02 [NVM Express]) Subsystem: Samsung Electronics Co Ltd Device a801 Flags: bus master, fast devsel, latency 0, IRQ 45, NUMA node 0 Memory at fcf00000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: nvme 02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43d0 (rev 01) (prog-if 30 [XHCI]) Subsystem: ASRock Incorporation Device 43d0 Flags: bus master, fast devsel, latency 0, IRQ 29 Memory at fcda0000 (64-bit, non-prefetchable) [size=32K] Capabilities: <access denied> Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 02:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller (rev 01) (prog-if 01 [AHCI 1.0]) Subsystem: ASRock Incorporation Device 43c8 Flags: bus master, fast devsel, latency 0, IRQ 47 Memory at fcd80000 (32-bit, non-prefetchable) [size=128K] Expansion ROM at fcd00000 [disabled] [size=512K] Capabilities: <access denied> Kernel driver in use: ahci 02:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Bridge (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 32 Bus: primary=02, secondary=03, subordinate=0a, sec-latency=0 I/O behind bridge: 0000f000-0000ffff [size=4K] Memory behind bridge: fcc00000-fccfffff [size=1M] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 03:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 33 Bus: primary=03, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: [disabled] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 03:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 35 Bus: primary=03, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: 0000f000-0000ffff [size=4K] Memory behind bridge: fcc00000-fccfffff [size=1M] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 03:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 36 Bus: primary=03, secondary=06, subordinate=06, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: [disabled] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 03:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 38 Bus: primary=03, secondary=07, subordinate=07, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: [disabled] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 03:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 39 Bus: primary=03, secondary=08, subordinate=08, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: [disabled] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 03:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 40 Bus: primary=03, secondary=09, subordinate=09, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: [disabled] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 03:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 41 Bus: primary=03, secondary=0a, subordinate=0a, sec-latency=0 I/O behind bridge: [disabled] Memory behind bridge: [disabled] Prefetchable memory behind bridge: [disabled] Capabilities: <access denied> Kernel driver in use: pcieport 05:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) Subsystem: ASRock Incorporation Device 1539 Flags: bus master, fast devsel, latency 0, IRQ 34 Memory at fcc00000 (32-bit, non-prefetchable) [size=128K] I/O ports at f000 [size=32] Memory at fcc20000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: igb Kernel modules: igb 0b:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev c1) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at fcb00000 (32-bit, non-prefetchable) [size=16K] Bus: primary=0b, secondary=0c, subordinate=0d, sec-latency=0 I/O behind bridge: 0000e000-0000efff [size=4K] Memory behind bridge: fca00000-fcafffff [size=1M] Prefetchable memory behind bridge: 00000000e0000000-00000000f01fffff [size=258M] Capabilities: <access denied> Kernel driver in use: pcieport 0c:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 44 Bus: primary=0c, secondary=0d, subordinate=0d, sec-latency=0 I/O behind bridge: 0000e000-0000efff [size=4K] Memory behind bridge: fca00000-fcafffff [size=1M] Prefetchable memory behind bridge: 00000000e0000000-00000000f01fffff [size=258M] Capabilities: <access denied> Kernel driver in use: pcieport 0d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (rev c1) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device 2316 Flags: bus master, fast devsel, latency 0, IRQ 111 Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f0000000 (64-bit, prefetchable) [size=2M] I/O ports at e000 [size=256] Memory at fca00000 (32-bit, non-prefetchable) [size=512K] Expansion ROM at fca80000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: amdgpu Kernel modules: amdgpu 0d:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 HDMI Audio Flags: bus master, fast devsel, latency 0, IRQ 110 Memory at fcaa0000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 0e:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function Subsystem: Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function Flags: fast devsel Capabilities: <access denied> 0e:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor Subsystem: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor Flags: bus master, fast devsel, latency 0, IRQ 99 Memory at fc800000 (32-bit, non-prefetchable) [size=1M] Memory at fc900000 (32-bit, non-prefetchable) [size=8K] Capabilities: <access denied> Kernel driver in use: ccp Kernel modules: ccp 0e:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Zeppelin USB 3.0 Host controller (prog-if 30 [XHCI]) Subsystem: ASRock Incorporation Device 7914 Flags: bus master, fast devsel, latency 0, IRQ 90 Memory at fc700000 (64-bit, non-prefetchable) [size=1M] Capabilities: <access denied> Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 0f:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Renoir PCIe Dummy Function Subsystem: Advanced Micro Devices, Inc. [AMD] Zeppelin/Renoir PCIe Dummy Function Flags: fast devsel Capabilities: <access denied> 0f:00.2 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) (prog-if 01 [AHCI 1.0]) Subsystem: ASRock Incorporation Device 7901 Flags: bus master, fast devsel, latency 0, IRQ 49 Memory at fce08000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: ahci 0f:00.3 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller Subsystem: ASRock Incorporation Device 2220 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at fce00000 (32-bit, non-prefetchable) [size=32K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel -- You are receiving this mail because: You are watching the assignee of the bug.

1 15

[PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
by John Stultz 21 May '21

21 May '21

Hey All, So just wanted to send my last revision of my patch series of performance optimizations to the dma-buf system heap. This series reworks the system heap to use sgtables, and then consolidates the pagelist method from the heap-helpers into the CMA heap. After which the heap-helpers logic is removed (as it is unused). I'd still like to find a better way to avoid some of the logic duplication in implementing the entire dma_buf_ops handlers per heap. But unfortunately that code is tied somewhat to how the buffer's memory is tracked. As more heaps show up I think we'll have a better idea how to best share code, so for now I think this is ok. After this, the series introduces an optimization that Ørjan Eide implemented for ION that avoids calling sync on attachments that don't have a mapping. Next, an optimization to use larger order pages for the system heap. This change brings us closer to the current performance of the ION allocation code (though there still is a gap due to ION using a mix of deferred-freeing and page pools, I'll be looking at integrating those eventually). Finally, a reworked version of my uncached system heap implementation I was submitting a few weeks back. Since it duplicated a lot of the now reworked system heap code, I realized it would be much simpler to add the functionality to the system_heap implementation itself. While not improving the core allocation performance, the uncached heap allocations do result in *much* improved performance on HiKey960 as it avoids a lot of flushing and invalidating buffers that the cpu doesn't touch often. Feedback on these would be great! thanks -john New in v5: * Added a comment explaining why the order sizes are chosen as they are Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Liam Mark <lmark(a)codeaurora.org> Cc: Laura Abbott <labbott(a)kernel.org> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: Hridya Valsaraju <hridya(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Daniel Mentz <danielmentz(a)google.com> Cc: Chris Goldsworthy <cgoldswo(a)codeaurora.org> Cc: Ørjan Eide <orjan.eide(a)arm.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Cc: Ezequiel Garcia <ezequiel(a)collabora.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: James Jones <jajones(a)nvidia.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org John Stultz (7): dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists dma-buf: heaps: Move heap-helper logic into the cma_heap implementation dma-buf: heaps: Remove heap-helpers code dma-buf: heaps: Skip sync if not mapped dma-buf: system_heap: Allocate higher order pages if available dma-buf: dma-heap: Keep track of the heap device struct dma-buf: system_heap: Add a system-uncached heap re-using the system heap drivers/dma-buf/dma-heap.c | 33 +- drivers/dma-buf/heaps/Makefile | 1 - drivers/dma-buf/heaps/cma_heap.c | 324 +++++++++++++++--- drivers/dma-buf/heaps/heap-helpers.c | 270 --------------- drivers/dma-buf/heaps/heap-helpers.h | 53 --- drivers/dma-buf/heaps/system_heap.c | 494 ++++++++++++++++++++++++--- include/linux/dma-heap.h | 9 + 7 files changed, 753 insertions(+), 431 deletions(-) delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h -- 2.17.1

5 18

[PATCH v8 0/8] Add support for SVM atomics in Nouveau
by Alistair Popple 21 May '21

21 May '21

This is the eighth version of a series to add support to Nouveau for atomic memory operations on OpenCL shared virtual memory (SVM) regions. The main change for this version is a simplification of device exclusive entry handling. Instead of copying entries for copy-on-write mappings during fork they are removed instead. This is safer because there could be unique corner cases when copying, particularly for pinned pages which should follow the same logic as copy_present_page(). Removing entries avoids this possiblity by treating them as normal ptes. Exclusive device access is implemented by adding a new swap entry type (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry. The main difference is that on fault the original entry is immediately restored by the fault handler instead of waiting. Restoring the entry triggers calls to MMU notifers which allows a device driver to revoke the atomic access permission from the GPU prior to the CPU finalising the entry. Patches 1 & 2 refactor existing migration and device private entry functions. Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated functionality into separate functions - try_to_migrate_one() and try_to_munlock_one(). These should not change any functionality, but any help testing would be much appreciated as I have not been able to test every usage of try_to_unmap_one(). Patch 5 contains the bulk of the implementation for device exclusive memory. Patch 6 contains some additions to the HMM selftests to ensure everything works as expected. Patch 7 is a cleanup for the Nouveau SVM implementation. Patch 8 contains the implementation of atomic access for the Nouveau driver. This has been tested using the latest upstream Mesa userspace with a simple OpenCL test program which checks the results of atomic GPU operations on a SVM buffer whilst also writing to the same buffer from the CPU. Alistair Popple (8): mm: Remove special swap entry functions mm/swapops: Rework swap entry manipulation code mm/rmap: Split try_to_munlock from try_to_unmap mm/rmap: Split migration into its own function mm: Device exclusive memory access mm: Selftests for exclusive device memory nouveau/svm: Refactor nouveau_range_fault nouveau/svm: Implement atomic SVM access Documentation/vm/hmm.rst | 19 +- Documentation/vm/unevictable-lru.rst | 33 +- arch/s390/mm/pgtable.c | 2 +- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + drivers/gpu/drm/nouveau/nouveau_svm.c | 156 ++++- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 6 + fs/proc/task_mmu.c | 23 +- include/linux/mmu_notifier.h | 26 +- include/linux/rmap.h | 11 +- include/linux/swap.h | 8 +- include/linux/swapops.h | 123 ++-- lib/test_hmm.c | 126 +++- lib/test_hmm_uapi.h | 2 + mm/debug_vm_pgtable.c | 12 +- mm/hmm.c | 12 +- mm/huge_memory.c | 45 +- mm/hugetlb.c | 10 +- mm/memcontrol.c | 2 +- mm/memory.c | 196 +++++- mm/migrate.c | 51 +- mm/mlock.c | 10 +- mm/mprotect.c | 18 +- mm/page_vma_mapped.c | 15 +- mm/rmap.c | 612 +++++++++++++++--- tools/testing/selftests/vm/hmm-tests.c | 158 +++++ 26 files changed, 1366 insertions(+), 312 deletions(-) -- 2.20.1

6 41

[PATCH v6 1/3] gpu: drm: separate panel orientation property creating and value setting
by Hsin-Yi Wang 20 May '21

20 May '21

drm_dev_register() sets connector->registration_state to DRM_CONNECTOR_REGISTERED and dev->registered to true. If drm_connector_set_panel_orientation() is first called after drm_dev_register(), it will fail several checks and results in following warning. Add a function to create panel orientation property and set default value to UNKNOWN, so drivers can call this function to init the property earlier , and let the panel set the real value later. [ 4.480976] ------------[ cut here ]------------ [ 4.485603] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xb4/0xbc <snip> [ 4.609772] Call trace: [ 4.612208] __drm_mode_object_add+0xb4/0xbc [ 4.616466] drm_mode_object_add+0x20/0x2c [ 4.620552] drm_property_create+0xdc/0x174 [ 4.624723] drm_property_create_enum+0x34/0x98 [ 4.629241] drm_connector_set_panel_orientation+0x64/0xa0 [ 4.634716] boe_panel_get_modes+0x88/0xd8 [ 4.638802] drm_panel_get_modes+0x2c/0x48 [ 4.642887] panel_bridge_get_modes+0x1c/0x28 [ 4.647233] drm_bridge_connector_get_modes+0xa0/0xd4 [ 4.652273] drm_helper_probe_single_connector_modes+0x218/0x700 [ 4.658266] drm_mode_getconnector+0x1b4/0x45c [ 4.662699] drm_ioctl_kernel+0xac/0x128 [ 4.666611] drm_ioctl+0x268/0x410 [ 4.670002] drm_compat_ioctl+0xdc/0xf0 [ 4.673829] __arm64_compat_sys_ioctl+0xc8/0x100 [ 4.678436] el0_svc_common+0xf4/0x1c0 [ 4.682174] do_el0_svc_compat+0x28/0x3c [ 4.686088] el0_svc_compat+0x10/0x1c [ 4.689738] el0_sync_compat_handler+0xa8/0xcc [ 4.694171] el0_sync_compat+0x178/0x180 [ 4.698082] ---[ end trace b4f2db9d9c88610b ]--- [ 4.702721] ------------[ cut here ]------------ [ 4.707329] WARNING: CPU: 5 PID: 369 at drivers/gpu/drm/drm_mode_object.c:243 drm_object_attach_property+0x48/0xb8 <snip> [ 4.833830] Call trace: [ 4.836266] drm_object_attach_property+0x48/0xb8 [ 4.840958] drm_connector_set_panel_orientation+0x84/0xa0 [ 4.846432] boe_panel_get_modes+0x88/0xd8 [ 4.850516] drm_panel_get_modes+0x2c/0x48 [ 4.854600] panel_bridge_get_modes+0x1c/0x28 [ 4.858946] drm_bridge_connector_get_modes+0xa0/0xd4 [ 4.863984] drm_helper_probe_single_connector_modes+0x218/0x700 [ 4.869978] drm_mode_getconnector+0x1b4/0x45c [ 4.874410] drm_ioctl_kernel+0xac/0x128 [ 4.878320] drm_ioctl+0x268/0x410 [ 4.881711] drm_compat_ioctl+0xdc/0xf0 [ 4.885536] __arm64_compat_sys_ioctl+0xc8/0x100 [ 4.890142] el0_svc_common+0xf4/0x1c0 [ 4.893879] do_el0_svc_compat+0x28/0x3c [ 4.897791] el0_svc_compat+0x10/0x1c [ 4.901441] el0_sync_compat_handler+0xa8/0xcc [ 4.905873] el0_sync_compat+0x178/0x180 [ 4.909783] ---[ end trace b4f2db9d9c88610c ]--- Signed-off-by: Hsin-Yi Wang <hsinyi(a)chromium.org> --- v6, v5: don't create property in set_panel_orientation. v4, v3: create property in dsi driver and set value in panel. v2: create property in connector init https://patchwork.kernel.org/project/linux-mediatek/patch/20210426051848.26… v1: set panel orientation in dsi driver https://patchwork.kernel.org/project/linux-mediatek/patch/20210409045314.34… --- drivers/gpu/drm/drm_connector.c | 58 ++++++++++++++++++------- drivers/gpu/drm/i915/display/icl_dsi.c | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 1 + drivers/gpu/drm/i915/display/vlv_dsi.c | 1 + include/drm/drm_connector.h | 2 + 5 files changed, 47 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 7631f76e7f34..7189baaabf41 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -1210,7 +1210,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel * coordinates, so if userspace rotates the picture to adjust for * the orientation it must also apply the same transformation to the - * touchscreen input coordinates. This property is initialized by calling + * touchscreen input coordinates. This property value is set by calling * drm_connector_set_panel_orientation() or * drm_connector_set_panel_orientation_with_quirk() * @@ -2173,8 +2173,8 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property); * @connector: connector for which to set the panel-orientation property. * @panel_orientation: drm_panel_orientation value to set * - * This function sets the connector's panel_orientation and attaches - * a "panel orientation" property to the connector. + * This function sets the connector's panel_orientation value. If the property + * doesn't exist, it will return an error. * * Calling this function on a connector where the panel_orientation has * already been set is a no-op (e.g. the orientation has been overridden with @@ -2205,19 +2205,11 @@ int drm_connector_set_panel_orientation( info->panel_orientation = panel_orientation; prop = dev->mode_config.panel_orientation_property; - if (!prop) { - prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, - "panel orientation", - drm_panel_orientation_enum_list, - ARRAY_SIZE(drm_panel_orientation_enum_list)); - if (!prop) - return -ENOMEM; - - dev->mode_config.panel_orientation_property = prop; - } + if (WARN_ON(!prop)) + return -EINVAL; - drm_object_attach_property(&connector->base, prop, - info->panel_orientation); + drm_object_property_set_value(&connector->base, prop, + info->panel_orientation); return 0; } EXPORT_SYMBOL(drm_connector_set_panel_orientation); @@ -2225,7 +2217,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation); /** * drm_connector_set_panel_orientation_with_quirk - * set the connector's panel_orientation after checking for quirks - * @connector: connector for which to init the panel-orientation property. + * @connector: connector for which to set the panel-orientation property. * @panel_orientation: drm_panel_orientation value to set * @width: width in pixels of the panel, used for panel quirk detection * @height: height in pixels of the panel, used for panel quirk detection @@ -2252,6 +2244,40 @@ int drm_connector_set_panel_orientation_with_quirk( } EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk); +/** + * drm_connector_init_panel_orientation_property - + * create the connector's panel orientation property + * + * This function attaches a "panel orientation" property to the connector + * and initializes its value to DRM_MODE_PANEL_ORIENTATION_UNKNOWN. + * + * The value of the property can be set by drm_connector_set_panel_orientation() + * or drm_connector_set_panel_orientation_with_quirk() later. + * + * Returns: + * Zero on success, negative errno on failure. + */ +int drm_connector_init_panel_orientation_property( + struct drm_connector *connector) +{ + struct drm_device *dev = connector->dev; + struct drm_property *prop; + + prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE, + "panel orientation", + drm_panel_orientation_enum_list, + ARRAY_SIZE(drm_panel_orientation_enum_list)); + if (!prop) + return -ENOMEM; + + dev->mode_config.panel_orientation_property = prop; + drm_object_attach_property(&connector->base, prop, + DRM_MODE_PANEL_ORIENTATION_UNKNOWN); + + return 0; +} +EXPORT_SYMBOL(drm_connector_init_panel_orientation_property); + int drm_connector_set_obj_prop(struct drm_mode_object *obj, struct drm_property *property, uint64_t value) diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index 9282978060b0..5ac4538e4283 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -1903,6 +1903,7 @@ static void icl_dsi_add_properties(struct intel_connector *connector) connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT; + drm_connector_init_panel_orientation_property(&connector->base); drm_connector_set_panel_orientation_with_quirk(&connector->base, intel_dsi_get_panel_orientation(connector), connector->panel.fixed_mode->hdisplay, diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index a5231ac3443a..f1d664e5abb2 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -5263,6 +5263,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp, intel_panel_setup_backlight(connector, pipe); if (fixed_mode) { + drm_connector_init_panel_orientation_property(connector); drm_connector_set_panel_orientation_with_quirk(connector, dev_priv->vbt.orientation, fixed_mode->hdisplay, fixed_mode->vdisplay); diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c index 9bee99fe5495..853855482af1 100644 --- a/drivers/gpu/drm/i915/display/vlv_dsi.c +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c @@ -1632,6 +1632,7 @@ static void vlv_dsi_add_properties(struct intel_connector *connector) connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT; + drm_connector_init_panel_orientation_property(&connector->base); drm_connector_set_panel_orientation_with_quirk( &connector->base, intel_dsi_get_panel_orientation(connector), diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index 1922b278ffad..4396c1c4a5db 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -1696,6 +1696,8 @@ int drm_connector_set_panel_orientation_with_quirk( struct drm_connector *connector, enum drm_panel_orientation panel_orientation, int width, int height); +int drm_connector_init_panel_orientation_property( + struct drm_connector *connector); int drm_connector_attach_max_bpc_property(struct drm_connector *connector, int min, int max); -- 2.31.1.498.g6c1eba8ee3d-goog

3 5

[PATCH v3 0/2] Document drm_mode_get_plane
by Leandro Ribeiro 20 May '21

20 May '21

v2: possible_crtcs field is a bitmask, not a pointer. Suggested by Ville Syrjälä <ville.syrjala(a)linux.intel.com> v3: document how userspace should find out CRTC index. Also, document that field 'gamma_size' represents the number of entries in the lookup table. Suggested by Pekka Paalanen <ppaalanen(a)gmail.com> and Daniel Vetter <daniel(a)ffwll.ch> Leandro Ribeiro (2): drm/doc: document how userspace should find out CRTC index drm/doc: document drm_mode_get_plane Documentation/gpu/drm-uapi.rst | 14 ++++++++++++++ drivers/gpu/drm/drm_debugfs_crc.c | 9 +++++---- include/uapi/drm/drm.h | 3 ++- include/uapi/drm/drm_mode.h | 22 ++++++++++++++++++++++ 4 files changed, 43 insertions(+), 5 deletions(-) -- 2.31.1

2 9

[RFC PATCH 0/3] A drm_plane API to support HDR planes
by Harry Wentland 19 May '21

19 May '21

## Introduction We are looking to enable HDR support for a couple of single-plane and multi-plane scenarios. To do this effectively we recommend new interfaces to drm_plane. Below I'll give a bit of background on HDR and why we propose these interfaces. ## Defining a pixel's luminance Currently the luminance space of pixels in a framebuffer/plane presented to the display is not well defined. It's usually assumed to be in a 2.2 or 2.4 gamma space and has no mapping to an absolute luminance value but is interpreted in relative terms. Luminance can be measured and described in absolute terms as candela per meter squared, or cd/m2, or nits. Even though a pixel value can be mapped to luminance in a linear fashion to do so without losing a lot of detail requires 16-bpc color depth. The reason for this is that human perception can distinguish roughly between a 0.5-1% luminance delta. A linear representation is suboptimal, wasting precision in the highlights and losing precision in the shadows. A gamma curve is a decent approximation to a human's perception of luminance, but the PQ (perceptual quantizer) function [1] improves on it. It also defines the luminance values in absolute terms, with the highest value being 10,000 nits and the lowest 0.0005 nits. Using a content that's defined in PQ space we can approximate the real world in a much better way. Here are some examples of real-life objects and their approximate luminance values: | Object | Luminance in nits | | ----------------- | ----------------- | | Sun | 1.6 million | | Fluorescent light | 10,000 | | Highlights | 1,000 - sunlight | | White Objects | 250 - 1,000 | | Typical objects | 1 - 250 | | Shadows | 0.01 - 1 | | Ultra Blacks | 0 - 0.0005 | ## Describing the luminance space **We propose a new drm_plane property to describe the Eletro-Optical Transfer Function (EOTF) with which its framebuffer was composed.** Examples of EOTF are: | EOTF | Description | | --------- |:------------------------------------------------------------------------- | | Gamma 2.2 | a simple 2.2 gamma | | sRGB | 2.4 gamma with small initial linear section | | PQ 2084 | SMPTE ST 2084; used for HDR video and allows for up to 10,000 nit support | | Linear | Linear relationship between pixel value and luminance value | ## Mastering Luminances Now we are able to use the PQ 2084 EOTF to define the luminance of pixels in absolute terms. Unfortunately we're again presented with physical limitations of the display technologies on the market today. Here are a few examples of luminance ranges of displays. | Display | Luminance range in nits | | ------------------------ | ----------------------- | | Typical PC display | 0.3 - 200 | | Excellent LCD HDTV | 0.3 - 400 | | HDR LCD w/ local dimming | 0.05 - 1,500 | Since no display can currently show the full 0.0005 to 10,000 nits luminance range the display will need to tonemap the HDR content, i.e to fit the content within a display's capabilities. To assist with tonemapping HDR content is usually accompanied with a metadata that describes (among other things) the minimum and maximum mastering luminance, i.e. the maximum and minimum luminance of the display that was used to master the HDR content. The HDR metadata is currently defined on the drm_connector via the hdr_output_metadata blob property. It might be useful to define per-plane hdr metadata, as different planes might have been mastered differently. ## SDR Luminance Since SDR covers a smaller luminance range than HDR, an SDR plane might look dark when blended with HDR content. Since the max HDR luminance can be quite variable (200-1,500 nits on actual displays) it is best to make the SDR maximum luminance value configurable. **We propose a drm_plane property to specfy the desired maximum luminance of the SDR plane in nits.** This allows us to map the SDR content predictably into HDR's absolute luminance space. ## Let There Be Color So far we've only talked about luminance, ignoring colors altogether. Just like in the luminance space, traditionally the color space of display outputs has not been well defined. Similar to how an EOTF defines a mapping of pixel data to an absolute luminance value, the color space maps color information for each pixel onto the CIE 1931 chromaticity space. This can be thought of as a mapping to an absolute, real-life, color value. A color space is defined by its primaries and white point. The primaries and white point are expressed as coordinates in the CIE 1931 color space. Think of the red primary as the reddest red that can be displayed within the color space. Same for green and blue. Examples of color spaces are: | Color Space | Description | | ----------- | ------------------------------------------ | | BT 601 | similar to BT 709 | | BT 709 | used by sRGB content; ~53% of BT 2020 | | DCI-P3 | used by most HDR displays; ~72% of BT 2020 | | BT 2020 | standard for most HDR content | The color space is defined in DRM for YCbCr planes via the color_encoding property of the drm_plane. **We propose to add definitions for the RGB variants of the BT color spaces.** ## Color Primaries and White Point Just like displays can currently not represent the entire 0.0005 - 10,000 nits HDR range of the PQ 2084 EOTF, they are currently not capable of representing the entire BT.2020 color Gamut. For this reason video content will often specify the color primaries and white point used to master the video, in order to allow displays to be able to map the image as best as possible onto the display's gamut. ## Displays and Tonemapping External displays are able to do their own tone and color mapping, based on the mastering luminance, color primaries, and white space defined in the HDR metadata. Internal panels (which are currently few and far between) usually don't include the complex HW to do tone and color mapping on their own and will require the display driver to perform appropriate mapping. ## Pixel Formats The pixel formats, such as ARGB8888, ARGB2101010, P010, or FP16 are unrelated to color space and EOTF definitions. HDR pixels can be formatted in different ways but in order to not lose precision HDR content requires at least 10 bpc precision. For this reason ARGB2101010, P010, and FP16 are the obvious candidates for HDR. ARGB2101010 and P010 have the advantage of requiring only half the bandwidth as FP16, while FP16 has the advantage of enough precision to operate in a linear space, i.e. without EOTF. ## Proposed use-cases Although the userspace side of this work is still in the early stages it is clear that we will want to support the following two use-cases: **One XRGB2101010 HDR Plane:** A single, composited plane of HDR content. The use-case is a video player on a desktop with the compositor owning the composition of SDR and HDR content. The content shall be PQ BT.2020 formatted. The drm_connector's hdr_output_metadata shall be set. **One ARGB8888 SDR Plane + One P010 HDR Plane:** A normal 8bpc desktop plane, with a P010 HDR video plane underlayed. The HDR plane shall be PQ BT.2020 formatted. The desktop plane shall specify an SDR boost value. The drm_connector's hdr_output_metadata shall be set. **One XRGB8888 SDR Plane - HDR output:** In order to support a smooth transition we recommend an OS that supports HDR output to provide the hdr_output_metadata on the drm_connector to configure the output for HDR, even when the content is only SDR. This will allow for a smooth transition between SDR-only and HDR content. In this use-case the SDR max luminance value should be provided on the drm_plane. In DCN we will de-PQ or de-Gamma all input in order to blend in linear space. For SDR content we will also apply any desired boost before blending. After blending we will then re-apply the PQ EOTF and do RGB to YCbCr conversion if needed. ## Summary of proposed interface changes per drm_plane: - new RGB color space definitions, mirroring the existing YUV color space definitions - new transfer function property - new SDR maximum white level property ## References [1] https://en.wikipedia.org/wiki/High-dynamic-range_video#Perceptual_Quantizer ## Further Reading https://gitlab.freedesktop.org/swick/wayland-protocols/-/blob/color/unstabl… http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP309.pdf https://app.spectracal.com/Documents/White%20Papers/HDR_Demystified.pdf Bhawanpreet Lakha (3): drm/color: Add RGB Color encodings drm/color: Add Color transfer functions for HDR/SDR drm/color: Add sdr boost property .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +- .../gpu/drm/arm/display/komeda/komeda_plane.c | 4 +- drivers/gpu/drm/arm/malidp_planes.c | 4 +- drivers/gpu/drm/armada/armada_overlay.c | 4 +- drivers/gpu/drm/drm_atomic_uapi.c | 8 ++ drivers/gpu/drm/drm_color_mgmt.c | 84 +++++++++++++++++-- drivers/gpu/drm/i915/display/intel_sprite.c | 4 +- .../drm/i915/display/skl_universal_plane.c | 4 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 4 +- drivers/gpu/drm/omapdrm/omap_plane.c | 4 +- drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 4 +- drivers/gpu/drm/tidss/tidss_plane.c | 6 +- include/drm/drm_color_mgmt.h | 25 +++++- include/drm/drm_plane.h | 30 +++++++ 14 files changed, 173 insertions(+), 16 deletions(-) -- 2.31.0

7 27

[PATCH 1/4] drm/panel: seperate panel power control from panel prepare/unprepare
by Jitao Shi 19 May '21

19 May '21

Some dsi panels require the dsi lanes keeping low before panel power on. So seperate the panel power control and the communication with panel. And put the power control in drm_panel_prepare_power and drm_panel_unprepare_power. Put the communication with panel in drm_panel_prepare and drm_panel_unprepare. Signed-off-by: Jitao Shi <jitao.shi(a)mediatek.com> --- drivers/gpu/drm/bridge/panel.c | 17 +++++++++++++++ drivers/gpu/drm/drm_panel.c | 38 ++++++++++++++++++++++++++++++++++ include/drm/drm_bridge.h | 2 ++ include/drm/drm_panel.h | 17 +++++++++++++++ 4 files changed, 74 insertions(+) diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c index 0ddc37551194..a19c96e710fc 100644 --- a/drivers/gpu/drm/bridge/panel.c +++ b/drivers/gpu/drm/bridge/panel.c @@ -125,6 +125,23 @@ static int panel_bridge_get_modes(struct drm_bridge *bridge, return drm_panel_get_modes(panel_bridge->panel, connector); } +int panel_bridge_prepare_power(struct drm_bridge *bridge) +{ + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge); + + return drm_panel_prepare_power(panel_bridge->panel); +} +EXPORT_SYMBOL(panel_bridge_prepare_power); + +int panel_bridge_unprepare_power(struct drm_bridge *bridge) +{ + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge); + + return drm_panel_unprepare_power(panel_bridge->panel); +} +EXPORT_SYMBOL(panel_bridge_unprepare_power); + + static const struct drm_bridge_funcs panel_bridge_bridge_funcs = { .attach = panel_bridge_attach, .detach = panel_bridge_detach, diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c index f634371c717a..7bb5185db17d 100644 --- a/drivers/gpu/drm/drm_panel.c +++ b/drivers/gpu/drm/drm_panel.c @@ -115,6 +115,24 @@ int drm_panel_prepare(struct drm_panel *panel) } EXPORT_SYMBOL(drm_panel_prepare); +/** + * drm_panel_prepare_power - power on a panel's power + * @panel: DRM panel + * + * Calling this function will enable power and deassert any reset signals to + * the panel. + * + * Return: 0 on success or a negative error code on failure. + */ +int drm_panel_prepare_power(struct drm_panel *panel) +{ + if (panel && panel->funcs && panel->funcs->prepare_power) + return panel->funcs->prepare_power(panel); + + return panel ? -ENOSYS : -EINVAL; +} +EXPORT_SYMBOL(drm_panel_prepare_power); + /** * drm_panel_unprepare - power off a panel * @panel: DRM panel @@ -138,6 +156,26 @@ int drm_panel_unprepare(struct drm_panel *panel) } EXPORT_SYMBOL(drm_panel_unprepare); +/** + * drm_panel_unprepare_power - power off a panel + * @panel: DRM panel + * + * Calling this function will completely power off a panel (assert the panel's + * reset, turn off power supplies, ...). After this function has completed, it + * is usually no longer possible to communicate with the panel until another + * call to drm_panel_prepare_power and drm_panel_prepare(). + * + * Return: 0 on success or a negative error code on failure. + */ +int drm_panel_unprepare_power(struct drm_panel *panel) +{ + if (panel && panel->funcs && panel->funcs->unprepare_power) + return panel->funcs->unprepare_power(panel); + + return panel ? -ENOSYS : -EINVAL; +} +EXPORT_SYMBOL(drm_panel_unprepare_power); + /** * drm_panel_enable - enable a panel * @panel: DRM panel diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index 2195daa289d2..cc94c9da47d8 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -892,6 +892,8 @@ struct drm_bridge *devm_drm_panel_bridge_add_typed(struct device *dev, struct drm_panel *panel, u32 connector_type); struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge); +int panel_bridge_prepare_power(struct drm_bridge *bridge); +int panel_bridge_unprepare_power(struct drm_bridge *bridge); #endif #endif diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h index 33605c3f0eba..48e83712ad44 100644 --- a/include/drm/drm_panel.h +++ b/include/drm/drm_panel.h @@ -68,6 +68,13 @@ enum drm_panel_orientation; * functionality to enable/disable backlight. */ struct drm_panel_funcs { + /** + * @prepare_power: + * + * Turn on panel power. + */ + int (*prepare_power)(struct drm_panel *panel); + /** * @prepare: * @@ -115,6 +122,13 @@ struct drm_panel_funcs { int (*get_modes)(struct drm_panel *panel, struct drm_connector *connector); + /** + * @unprepare_power: + * + * Turn off panel_power. + */ + int (*unprepare_power)(struct drm_panel *panel); + /** * @get_timings: * @@ -180,6 +194,9 @@ void drm_panel_init(struct drm_panel *panel, struct device *dev, void drm_panel_add(struct drm_panel *panel); void drm_panel_remove(struct drm_panel *panel); +int drm_panel_prepare_power(struct drm_panel *panel); +int drm_panel_unprepare_power(struct drm_panel *panel); + int drm_panel_prepare(struct drm_panel *panel); int drm_panel_unprepare(struct drm_panel *panel); -- 2.25.1

2 7

← Newer
1
...
11
12
13
14
15
16
17
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021