https://bugzilla.kernel.org/show_bug.cgi?id=197327
Bug ID: 197327
Summary: radeon 0000:01:00.0: failed VCE resume (-110).
Product: Drivers
Version: 2.5
Kernel Version: 4.13.8
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
…
[View More]Reporter: mad_sam(a)bk.ru
Regression: No
Created attachment 260297
--> https://bugzilla.kernel.org/attachment.cgi?id=260297&action=edit
dmesg log
Have some trouble on my laptop with Radeon HD 8550G + Radeon HD 8750M
I have error message radeon 0000:01:00.0: failed VCE resume (-110) in boot
time, and i think my discrette card Radeon HD 8750M possibly not work (3D with
DRI_PRIME=1 gives a worse or the same FPS than without it)
--
You are receiving this mail because:
You are watching the assignee of the bug.
[View Less]
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
…
[View More]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.
[View Less]
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(…
[View More]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.
[View Less]
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: …
[View More]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.
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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)…
[View More]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.
[View Less]
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
…
[View More]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.
[View Less]
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 …
[View More]/ 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
[View Less]
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)
…
[View More]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.
[View Less]