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: …
[View More]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.
[View Less]
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]
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]
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]
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
…
[View More]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.
[View Less]