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 andbeen closed. I could
not find where the state is set or released fromthe driver side, so I am asking
whether this is known and what else Ishould 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 c2Distro: Fedora 44, Sway 1.11 on
WaylandKernel: 7.2.13-200.fc44.x86_64 (Fedora kernel, 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.0Boot: amdgpu.noretry=0
amdgpu.ppfeaturemask=0xffffffff amdgpu.gpu_recovery=1 amdgpu.vcnfw_log=1
amdgpu.dcdebugmask=0x10Userspace: no daemon or tool writes to amdgpu
sysfs.== Symptom ==Idle: pp_dpm_mclk shows "0: 667Mhz *".After WebGL (WebGL
Aquarium, sometimes this doesn't trigger?) orVA-API video (YouTube, VP9 1080p)
in Brave, and closing the tabor 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 formy
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
667 MHz -sometimes 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, even I run with temp user
directory with no flags, VA-API decoding ran and same issue continued.- mpv
--hwdec=vaapi on the same file: MCLK is 933 MHz during playback.== Kernel-side
==I attached bpftrace kprobes (with kstack) to smum_send_msg_to_smc
andsmum_send_msg_to_smc_with_parameter and ran: Brave WebGL, BraveYouTube,
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 SMUmailbox through these wrappers. This would not show direct register
ortable 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 canattach them if
asked.Thanks,Ata
