Hi,
On a Picasso/Raven2 laptop, MCLK stays pinned at its highest level
(1200 MHz) after a Chromium-based browser (Brave) has used the GPU and
been closed. I could not find where the state is set or released from
the driver side, so I am asking whether this is known and what else I
should collect. I have the kernel tree and can test patches.
== System ==
Laptop: Huawei MateBook D14 (NBLK-WAX9X), Ryzen 5 3500U,
Picasso/Raven2 1002:15d8 rev c2
Distro: Fedora 44, Sway 1.11 on Wayland
Kernel: 7.2.13-200.fc44.x86_64 (Fedora kernel, at most 1-2 releases
behind the current stable; not tested on drm-next)
amdgpu 3.64.0, DCN 1.0, SMU10, VCN 1.0 (ENC 1.15 DEC 3 VEP 0 Rev 9)
Mesa 26.2.5, libva 2.23.0
Boot: amdgpu.noretry=0 amdgpu.ppfeaturemask=0xffffffff
amdgpu.gpu_recovery=1 amdgpu.vcnfw_log=1
amdgpu.dcdebugmask=0x10
Userspace: no daemon or tool writes to amdgpu sysfs.
== Symptom ==
Idle: pp_dpm_mclk shows "0: 667Mhz *".
After WebGL (WebGL Aquarium) or VA-API video (YouTube, VP9 1080p) in
Brave, and closing the tab or the whole browser, pp_dpm_mclk shows
"3: 1200Mhz *" indefinitely, with GPU load 0% and SCLK back at idle.
amdgpu_pm_info reports "VCN: Powered down". Battery drain is about
5 W higher, (which for my machine it makes about 1.5 hour at my daily usage).
- Persists across tab close, browser kill -9, all fds closed, VT switch.
- power_dpm_force_performance_level stays "auto" and
pp_power_profile_mode stays BOOTUP_DEFAULT throughout.
- While latched, writing "low" or manual MCLK levels does not move it.
After it is cleared, MCLK follows low/manual requests normally.
- Cleared by: amdgpu_gpu_recover (debugfs), or by playing a video in
Firefox (MCLK goes to 933 MHz during playback).
- Firefox itself does not trigger it.
== What triggers it ==
- WebGL alone in Brave latches it, with VCN powered down the whole
time. So this is not specific to a VCN decode teardown path.
A clean Brave without custom flags behaves the same.
- VA-API video decode in Brave latches it with VaapiVideoDecoder
confirmed active in media-internals, in each of these variants:
default flags, --use-angle=gl,
--disable-features=UseMultiPlaneFormatForHardwareVideo,
--disable-features=VaapiIgnoreDriverChecks
- mpv --hwdec=vaapi on the same file: MCLK is 933 MHz during playback.
== Kernel-side evidence ==
I attached bpftrace kprobes (with kstack) to smum_send_msg_to_smc and
smum_send_msg_to_smc_with_parameter and ran: Brave WebGL, Brave
YouTube, close (latched), Firefox WebGL, Firefox video (released),
then amdgpu_gpu_recover.
- Before the latch was first observed: 152 SMU messages, all either
GFXOFF enable/disable (smu10_gfx_off_control) or two VCN power
up/down pairs (smu10_powergate_vcn). No smu10_dpm_force_dpm_level,
no hard-min, active-display-count or deep-sleep messages.
- Between the latched read and the released read (Firefox): again only
GFXOFF toggles and two balanced VCN up/down pairs. Brave's video
session produces the same two pairs and does not release.
- A kprobe on rv1_update_clocks never fires during any browser
activity, only during gpu_recover.
- Each read of pp_dpm_sclk/pp_dpm_mclk issues an SMU query
(smu10_emit_clock_levels), so the reported value is live.
So neither setting nor releasing the state is visible on the SMU
mailbox through these wrappers. This would not show direct register or
table writes. I cannot tell whether the state lives in SMU firmware,
in the display/data fabric p-state handshake, or elsewhere.
== Questions ==
1. Is this a known issue on Raven/Picasso?
2. On SMU10, what other path can hold FCLK/MCLK high that does not go
through the mailbox (DCN hubbub watermarks, DF p-state, firmware
internal state)?
3. What should I trace next? amdgpu_dm_dtn_log returns EPERM here even
as root (probably lockdown); I can boot without Secure Boot if that
output would help.
Full trace logs and brave://media-internals output are available; I can
attach them if asked.
Thanks,
Ata
