dri-devel December 2019

dri-devel@lists.freedesktop.org

315 participants
807 discussions

[Bug 204241] New: amdgpu fails to resume from suspend
by bugzilla-daemon＠bugzilla.kernel.org 08 Feb '21

08 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=204241 Bug ID: 204241 Summary: amdgpu fails to resume from suspend Product: Drivers Version: 2.5 Kernel Version: 5.2.1-arch1-1-ARCH Hardware: Intel 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: kitaev(a)gmail.com Regression: No Created attachment 283863 --> https://bugzilla.kernel.org/attachment.cgi?id=283863&action=edit dmesg Computer fails to resume from suspend. >From the logs it looks like AMDGPU fails to resume. -- You are receiving this mail because: You are watching the assignee of the bug.

1 77

[Bug 202043] New: amdgpu: Vega 56 SCLK drops to 700 Mhz when undervolting
by bugzilla-daemon＠bugzilla.kernel.org 08 Feb '21

08 Feb '21

https://bugzilla.kernel.org/show_bug.cgi?id=202043 Bug ID: 202043 Summary: amdgpu: Vega 56 SCLK drops to 700 Mhz when undervolting Product: Drivers Version: 2.5 Kernel Version: 4.19.8, 4.20.0-rc6 Hardware: All 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: antifermion(a)protonmail.com Regression: No When undervolting my Sapphire Pulse Vega 56 by just 1mV, SCLK immediately drops down to 700 Mhz and pstate 1-2 under load (`gputest /test=fur /width=1920 /height=1080`). Script to undervolt: ``` echo "s 7 1630 1199" > /sys/class/drm/card0/device/pp_od_clk_voltage echo "c" > /sys/class/drm/card0/device/pp_od_clk_voltage ``` Stock voltage would be 1200 on the Vega 64 Bios. The same behavior can be observed with the stock Vega 56 Bios. Undervolting the memory by 1mV results in similar behavior. Overvolting by 1mV has no discernable effect. `echo r > pp_od_clk_voltage` does not work to go back to the normal behavior. Instead, I need to use `echo "s 7 1630 1200" > pp_od_clk_voltage` as above. Without undervolting, SCLK is around 1330 Mhz, which matches the behavior on Windows, where undervolting by around 150 mV is no problem and increases clock. With an increased power limit of 300W, the clocks increase to around 1100 Mhz while the card uses the full 300W. It even maxes that limit with a significant underclock/undervolt which would pull around 200W on Windows. I tested with current Manjaro (4.19.8-2-MANJARO), as well as Kubuntu 18.10 with stock (4.18) and 4.20 from https://github.com/M-Bab/linux-kernel-amdgpu-binaries. -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

[Bug 205675] New: Display locks up. AMDGPU timeout
by bugzilla-daemon＠bugzilla.kernel.org 03 Jan '21

03 Jan '21

https://bugzilla.kernel.org/show_bug.cgi?id=205675 Bug ID: 205675 Summary: Display locks up. AMDGPU timeout Product: Drivers Version: 2.5 Kernel Version: 5.4.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: freddyreimer(a)comcast.net Regression: No Created attachment 286079 --> https://bugzilla.kernel.org/attachment.cgi?id=286079&action=edit dmesg tail from immediately after a lockup I have been encountering issues the AMDGPU driver completely failing when loading games. When loading into a game and after making one click or moving the mouse, the display will completely freeze. Can't tab out or go to a TTY at all. I can SSH into the box and do stuff, such as getting the attached dmesg tail, but even killing the process doesn't unfreeze the display, which has the still image of the game. Only rebooting unlocks it. Basically it just seems to timeout and then can't recover, and this happens all the time on certain games, but inconsistent as to what environment it happens. Some lock it up on Xorg but work fine on Wayland. Some work fine on Wayland but break on Xorg. Some never work at all. My Graphics card is a Navi10, RX5700. I'm on the 5.4 kernel, but this was happening on 5.3 as well. -- You are receiving this mail because: You are watching the assignee of the bug.

1 45

[PATCH v5 00/19] R-Car DU display writeback support
by Laurent Pinchart 16 Dec '20

16 Dec '20

Hello everybody, This patch series implements display writeback support for the R-Car Gen3 platforms in the VSP1 and DU drivers. Patches 01/19 to 11/19 prepare the VSP1 driver for writeback support with all the necessary plumbing, including extensions of the API between the VSP1 and DU drivers. Compared to v4 the major change is the move from V4L2 to DRM writeback connectors for the userspace API. This has caused a few issues with writeback support to be uncovered, and they are addressed by patches 12/19 to 14/19. Patch 15/19 is an unrelated drive-by fix. Patches 16/19 to 18/19 then perform refactoring of the DU driver, to finally add writeback support in patch 19/19. The writeback pixel format is restricted to RGB, due to the VSP1 outputting RGB to the display and lacking a separate colour space conversion unit for writeback. The resolution can be freely picked by will result in cropping or composing, not scaling. Writeback requests are queued to the hardware on page flip (atomic flush), and complete at the next vblank. This means that a queued writeback buffer will not be processed until the next page flip, but once it starts being written to by the VSP, it will complete at the next vblank regardless of whether another page flip occurs at that time. The code is based on a merge of the media master branch, the drm-next branch and the R-Car DT next branch. For convenience patches can be found at git://linuxtv.org/pinchartl/media.git v4l2/vsp1/writeback Kieran Bingham (1): Revert "[media] v4l: vsp1: Supply frames to the DU continuously" Laurent Pinchart (18): media: vsp1: wpf: Fix partition configuration for display pipelines media: vsp1: Replace leftover occurrence of fragment with body media: vsp1: Fix addresses of display-related registers for VSP-DL media: vsp1: Refactor vsp1_video_complete_buffer() for later reuse media: vsp1: Replace the display list internal flag with a flags field media: vsp1: dl: Support one-shot entries in the display list media: vsp1: wpf: Add writeback support media: vsp1: drm: Split RPF format setting to separate function media: vsp1: drm: Extend frame completion API to the DU driver media: vsp1: drm: Implement writeback support drm: writeback: Cleanup job ownership handling when queuing job drm: writeback: Fix leak of writeback job drm: writeback: Add job prepare and cleanup operations drm/msm: Remove prototypes for non-existing functions drm: rcar-du: Fix rcar_du_crtc structure documentation drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions drm: rcar-du: Add writeback support for R-Car Gen3 drivers/gpu/drm/arm/malidp_mw.c | 3 +- drivers/gpu/drm/drm_atomic_helper.c | 11 ++ drivers/gpu/drm/drm_atomic_state_helper.c | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 31 +-- drivers/gpu/drm/drm_writeback.c | 71 ++++++- drivers/gpu/drm/msm/msm_drv.h | 2 - drivers/gpu/drm/rcar-du/Kconfig | 4 + drivers/gpu/drm/rcar-du/Makefile | 3 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 9 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 37 ++++ drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 121 ++++++------ drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 17 ++ drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 203 ++++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_writeback.h | 39 ++++ drivers/gpu/drm/vc4/vc4_txp.c | 2 +- drivers/media/platform/vsp1/vsp1_dl.c | 127 ++++++++++-- drivers/media/platform/vsp1/vsp1_dl.h | 8 +- drivers/media/platform/vsp1/vsp1_drm.c | 92 ++++++--- drivers/media/platform/vsp1/vsp1_drm.h | 2 +- drivers/media/platform/vsp1/vsp1_drv.c | 15 ++ drivers/media/platform/vsp1/vsp1_pipe.c | 5 + drivers/media/platform/vsp1/vsp1_pipe.h | 1 + drivers/media/platform/vsp1/vsp1_regs.h | 6 +- drivers/media/platform/vsp1/vsp1_rwpf.h | 2 + drivers/media/platform/vsp1/vsp1_video.c | 49 +++-- drivers/media/platform/vsp1/vsp1_wpf.c | 68 +++++-- include/drm/drm_modeset_helper_vtables.h | 7 + include/drm/drm_writeback.h | 30 ++- include/media/vsp1.h | 19 +- 30 files changed, 790 insertions(+), 199 deletions(-) create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.h -- Regards, Laurent Pinchart

6 64

[PATCH] drm/bridge: thc63lvd1024: Fix regulator_get_optional() misuse
by Mark Brown 15 Dec '20

15 Dec '20

The thc63lvd1024 driver requests a supply using regulator_get_optional() but both the name of the supply and the usage pattern suggest that it is being used for the main power for the device and is not at all optional for the device for function, there is no handling at all for absent supplies. Such regulators should use the vanilla regulator_get() interface, it will ensure that even if a supply is not described in the system integration one will be provided in software. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c b/drivers/gpu/drm/bridge/thc63lvd1024.c index 3d74129b2995..ffca28ccc2c4 100644 --- a/drivers/gpu/drm/bridge/thc63lvd1024.c +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c @@ -200,7 +200,7 @@ static int thc63_probe(struct platform_device *pdev) thc63->dev = &pdev->dev; platform_set_drvdata(pdev, thc63); - thc63->vcc = devm_regulator_get_optional(thc63->dev, "vcc"); + thc63->vcc = devm_regulator_get(thc63->dev, "vcc"); if (IS_ERR(thc63->vcc)) { if (PTR_ERR(thc63->vcc) == -EPROBE_DEFER) return -EPROBE_DEFER; -- 2.20.1

2 1

[Bug 205147] New: Unable to shut down - radeon_drv.c - radeon_suspend_kms()
by bugzilla-daemon＠bugzilla.kernel.org 15 Dec '20

15 Dec '20

https://bugzilla.kernel.org/show_bug.cgi?id=205147 Bug ID: 205147 Summary: Unable to shut down - radeon_drv.c - radeon_suspend_kms() Product: Drivers Version: 2.5 Kernel Version: 5.3.5 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: rherbert(a)sympatico.ca Regression: No >From the 5.3.5 changelog: drm/radeon: Fix EEH during kexec [ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ] During kexec some adapters hit an EEH since they are not properly shut down in the radeon_pci_shutdown() function. Adding radeon_suspend_kms() fixes this issue. This commit creates a problem where I can't shut down or restart my system without pressing the Rest button. The problem is solved by commenting out the call to radeon_suspend_kms() in radeon_pci_shutdown. The gpu hardware is an ATI Radeon HD5770 in a PCI-E slot on an Intel DG41RQ MB. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

[Bug 201139] New: amdgpu: [drm] enabling link 1 failed: 15 (vega)
by bugzilla-daemon＠bugzilla.kernel.org 12 Dec '20

12 Dec '20

https://bugzilla.kernel.org/show_bug.cgi?id=201139 Bug ID: 201139 Summary: amdgpu: [drm] enabling link 1 failed: 15 (vega) Product: Drivers Version: 2.5 Kernel Version: 4.19-rc3 Hardware: All 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: mezin.alexander(a)gmail.com Regression: No My setup: - RX Vega 64 - Arch Linux - GNOME 3.28.3 on Xorg 1.20.1 - modesetting Xorg driver - LG 27UD69P and Dell P2415Q I have "screen blanking" enabled in Gnome. Sometimes (very rarely) one display (Dell, connected to 2nd DisplayPort) doesn't wake up correctly. It turns on, shows only black screen, then quickly shows "no signal" message. In kernel log I see: [39215.008773] [drm] enabling link 1 failed: 15 If I manually turn the display off and on, it starts to work. Can't tell if it is a regression (hardly it is) because on 4.18 and earlier screen blanking just makes the driver hang: https://bugzilla.kernel.org/show_bug.cgi?id=200531 I've never seen a similar issue on Windows on the same machine. If I'm not mistaken, I've seen the same issue with Gnome on Wayland too (but I'm not sure). -- You are receiving this mail because: You are watching the assignee of the bug.

1 14

[PATCH 0/7] Adding a proper workaround for fixing RTD3 issues with Nouveau
by Karol Herbst 10 Dec '20

10 Dec '20

First three patches are removing ACPI workarounds which should have never landed. The last four are adding a workaround to nouveau which seem to help quite a lot with the RTD3 issues with Nouveau, so let's discuss and get wider testing of those and see if there is any fallout or laptops where the issues don't get fixed. Karol Herbst (7): Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output" Revert "ACPI / OSI: Add OEM _OSI string to enable NVidia HDMI audio" Revert "ACPI / OSI: Add OEM _OSI strings to disable NVidia RTD3" drm/nouveau/pci: enable pcie link changes for pascal drm/nouveau/pci: add nvkm_pcie_get_speed drm/nouveau/pci: save the boot pcie link speed and restore it on fini drm/nouveau: abort runtime suspend if we hit an error drivers/acpi/osi.c | 24 ---------- .../drm/nouveau/include/nvkm/core/device.h | 2 + .../gpu/drm/nouveau/include/nvkm/subdev/pci.h | 9 ++-- drivers/gpu/drm/nouveau/nouveau_drm.c | 6 +++ .../gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- .../gpu/drm/nouveau/nvkm/subdev/pci/base.c | 9 +++- .../gpu/drm/nouveau/nvkm/subdev/pci/gk104.c | 8 ++-- .../gpu/drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++++ .../gpu/drm/nouveau/nvkm/subdev/pci/pcie.c | 46 +++++++++++++++++-- .../gpu/drm/nouveau/nvkm/subdev/pci/priv.h | 7 +++ 10 files changed, 84 insertions(+), 39 deletions(-) -- 2.21.0

10 40

[Bug 94061] New: [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
by bugzilla-daemon＠bugzilla.kernel.org 03 Dec '20

03 Dec '20

https://bugzilla.kernel.org/show_bug.cgi?id=94061 Bug ID: 94061 Summary: [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst Product: Drivers Version: 2.5 Kernel Version: 3.14.x ... 3.19. Hardware: All 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: abcdmail(a)freenet.de Regression: No With all kernel versions >= 3.14 (I didn't test versions below), radeon / dpm consumes about 6 W more compared to catalyst in idle mode (X-server 1.15 / 1.16) with Kaveri graphics (AMD A10-7800 Radeon R7). Idle mode: Xorg runs (KDE 4.11.x), screen saver off, static screen, load: 0.0 If the screen is turned off by X, the power consumption finally reaches the same level as with catalyst. It's raising immediately again at the moment the screen is switched on again by X. Seams the lowest rate is never reached as long as even a static screen has to be drawn - but it should! -- You are receiving this mail because: You are watching the assignee of the bug.

1 12

[Bug 78111] New: APU turbo core boost not working when radeon.dpm=1
by bugzilla-daemon＠bugzilla.kernel.org 03 Dec '20

03 Dec '20

https://bugzilla.kernel.org/show_bug.cgi?id=78111 Bug ID: 78111 Summary: APU turbo core boost not working when radeon.dpm=1 Product: Drivers Version: 2.5 Kernel Version: 3.14.6 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: bgz.marko(a)gmail.com Regression: No I am testing with A6-1450 APU on Arch Linux. If I pass radeon.dpm=1 parameter at boot and start a single core workload then turbostat will report max frequency of about 1000 MHz: Core CPU Avg_MHz Bzy_MHz TSC_MHz time - - 262 998 998 5** 0 0 12 998 998 5** 1 1 998 998 998 2 2 16 998 998 3 3 21 998 998 "cpupower frequency-info" reports that boost state support is supported, but not active: boost state support: Supported: yes Active: no However, when dynamic power management is disabled (radeon.dpm=0), turbostat reports higher frequencies for single core load, up to 1300 Mhz: Core CPU Avg_MHz Bzy_MHz TSC_MHz time - - 320 1214 998 5** 0 0 9 1226 998 5** 1 1 13 1194 998 2 2 41 1143 998 3 3 1216 1216 998 "cpupower frequency-info" confirms that boost is now active. boost state support: Supported: yes Active: yes -- You are receiving this mail because: You are watching the assignee of the bug.

1 14

← Newer
1
2
3
4
5
6
7
...
81
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2019