https://bugzilla.kernel.org/show_bug.cgi?id=203439
Bug ID: 203439
Summary: amdgpu: [REG 4.20 -> 5.0] Brightness minimum level is
too high
Product: Drivers
Version: 2.5
Kernel Version: 5.0
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: spaz16(a)wp.pl
Regression: No
I have Huawei Matebook D 14 with AMD Ryzen 2500U.
Since kernel 5.0.x the minimum brightness level is too high. It is not possible
to dim the display as much as on previous kernel version. Kernel 4.20 also
allows to disable the backlight on level 0.
Value of "0" in "/sys/class/backlight/amdgpu_bl0/brightness" currently doesn't
disable backlight as in previous version. Value of "1" means the screen is dim,
but not as much as in kernel 4.20. Sometimes the screen is still too bright
even on level 0 in kernel 5.0.
Since commit 206bbafe00dcacccf40e6f09e624329ec124201b I can see the define:
> #define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 12
Maybe it should be defined to "0" to restore the old behavior? (I haven't
tested yet)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=85421
Bug ID: 85421
Summary: radeon stalled, GPU lockup, reset and failed on
resume; crashed by firefox.
Product: Drivers
Version: 2.5
Kernel Version: 3.16.3
Hardware: x86-64
OS: Linux
Tree: Fedora
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-dri(a)kernel-bugs.osdl.org
Reporter: htl10(a)users.sourceforge.net
Regression: No
Created attachment 152191
--> https://bugzilla.kernel.org/attachment.cgi?id=152191&action=edit
/var/log/messages from radeon 0000:00:01.0: ring 0 stalled to reboot.
I was away from the computer when the radeon dri driver crashed; I left a fair
number of firefox windows on/tab, some of them may have videos (from BBC news
web site) and animated gifs from another web site on; but it crashed about 5-10
minutes after I was away and I was aware of it because the laptop blipped.
# lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Mullins [Radeon R3 Graphics]
some excerpt from the attached logs are:
...
[ 8770.250116] radeon 0000:00:01.0: ring 0 stalled for more than 10012msec
[ 8770.250128] radeon 0000:00:01.0: GPU lockup (waiting for 0x0000000000056034
last fence id 0x0000000000056031 on ring 0)
[ 8770.298635] radeon 0000:00:01.0: Saved 14196 dwords of commands on ring 0.
[ 8770.298663] radeon 0000:00:01.0: GPU softreset: 0x0000000C
...
[ 8770.313299] radeon 0000:00:01.0: GPU reset succeeded, trying to resume
...
[ 8770.339724] [drm] ring test on 0 succeeded in 3 usecs
[ 8770.518568] [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed
(scratch(0x3010C)=0xCAFEDEAD)
[ 8770.752885] [drm:cik_sdma_ring_test] *ERROR* radeon: ring 3 test failed
(0xCAFEDEAD)
[ 8770.752892] [drm:cik_resume] *ERROR* cik startup failed on resume
[ 8780.753181] radeon 0000:00:01.0: ring 0 stalled for more than 10001msec
[ 8780.753193] radeon 0000:00:01.0: GPU lockup (waiting for 0x00000000000560f7
last fence id 0x0000000000056031 on ring 0)
[ 8780.753199] [drm:cik_ib_test] *ERROR* radeon: fence wait failed (-35).
[ 8780.753209] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-35).
[ 8780.753215] radeon 0000:00:01.0: ib ring test failed (-35).
[ 8780.762131] radeon 0000:00:01.0: GPU softreset: 0x0000000C
...
The kernel is a largely fedora 3.16.3-200 one grabbed from the koji srpm but
with the additional patch from
https://bugzilla.kernel.org/show_bug.cgi?id=71051#c8
drv ati 7.4.0 , mesa 10.2.8, glamor from git 347ef4 .
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=107381
Bug ID: 107381
Summary: radeon VCE init error (-110) -- AMD/Intel Mars Hybrid
Graphics
Product: Drivers
Version: 2.5
Kernel Version: 4.3
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: schmod(a)gmail.com
Regression: No
Created attachment 192261
--> https://bugzilla.kernel.org/attachment.cgi?id=192261&action=edit
dmesg output
Since upgrading to Ubuntu 15.10, I have encountered graphics performance
issues, and have occasionally experienced lockups during boot.
I have encountered this issue on kernel 4.2.0 and 4.3.0, and it seems to have
affected users on other distributions as well:
https://bugs.launchpad.net/fedora/+source/linux/+bug/1512848https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803087https://bugzilla.redhat.com/show_bug.cgi?id=1262649
Notably, this issue seems to primarily impact users with The ATI "Mars"
chipset, on machines that have an Intel/AMD hybrid graphics hardware
configuration.
This shows up in dmesg (full log attached, because there's a fair amount of
seemingly-useful context):
[ 4.917369] radeon 0000:01:00.0: VCE init error (-110).
Some other context from my PC:
$ xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x6a cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 5
associated providers: 2 name:Intel
Provider 1: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0
associated providers: 2 name:radeon
Provider 2: id: 0x41 cap: 0x6, Sink Output, Source Offload crtcs: 2 outputs: 0
associated providers: 2 name:radeon
$ lspci -k (trimmed to omit likely-irrelevant devices)
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller
(rev 09)
Subsystem: Samsung Electronics Co Ltd Device c0e6
Kernel driver in use: ivb_uncore
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor
PCI Express Root Port (rev 09)
Kernel driver in use: pcieport
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
DeviceName: Onboard IGD
Subsystem: Samsung Electronics Co Ltd Device c0e6
Kernel driver in use: i915
01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars [Radeon
HD 8670A/8670M/8750M] (rev ff)
Kernel driver in use: radeon
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=51381
Summary: [drm:atom_op_jump] *ERROR* atombios stuck in loop for
more than 5secs aborting, when disabled via
vgaswitcheroo
Product: Drivers
Version: 2.5
Kernel Version: Linux version 3.6.9-1-ARCH (tobias@T-POWA-LX) (gcc
version 4.7.2 (GCC) ) #1 SMP PREEMPT Tue Dec 4
08:04:10 CET 2012
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org
ReportedBy: a(a)anrd.net
Regression: Yes
Created an attachment (id=88591)
--> (https://bugzilla.kernel.org/attachment.cgi?id=88591)
journald log
After updating from 3.6.6 to 3.6.9 my laptop with Intel graphics and ATI HD
5650 will not resume from suspend. I use vgaswitcheroo to disable the ATI card
at boot. On resume the computer almost hangs (I can press power button and wait
5 minutes for a proper shutdown, but no other interaction is possible). It logs
a lot of messages saying:
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing D098 (len 72,
WS 0, PS 0) @ 0xD0C7
Steps to reproduce:
echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch
[suspend and resume]
Actual results:
Almost freeze.
Expected results:
Resume and work as normal.
Log is attached, but if you need anything else just ask.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=200695
Bug ID: 200695
Summary: Blank screen on RX 580 with amdgpu.dc=1 enabled (no
displays detected)
Product: Drivers
Version: 2.5
Kernel Version: 4.18.0-rc7
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: claude(a)mathr.co.uk
Regression: No
Created attachment 277633
--> https://bugzilla.kernel.org/attachment.cgi?id=277633&action=edit
dmesg after boot with amdgpu.dc=1 amdgpu.dc_log=1 drm.debug=6
When amdgpu.dc=1 is initialized at boot, the console goes blank as it thinks
all displays are disconnected. Xorg is not able to enable the display either.
With amdgpu.dc=0 all is fine. Tried with various (mostly Debian) kernels from
4.16 through 4.18~rc4, all have the issue. I built a 4.18~rc7 from kernel.org
to rule out Debian patches being the issue and will provide logs.
--
You are receiving this mail because:
You are watching the assignee of the bug.
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
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.
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.
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
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.