Re: [REGRESSION] AMD HDMI/DP audio broken after suspend since commit 50e0bae34fa6

[Mario Limonciello <superm1@kernel.org>]

On 8/31/2025 5:12 AM, Przemysław Kopa wrote:
> Hello,
> 
> I'm running Radeon RX 9060 XT and since upgrading to the kernel 6.15 I'm
> facing an issue with audio via DisplayPort. After waking from S3 suspend
> (sometimes, but not always) audio doesn't work - pavucontrol shows that
> the output is disconnected and I don't get sound from my display. If I
> manually reselect the Digital/HDMI output in pavucontrol after resume,
> sound starts working again. Besides my main screen, GPU is also
> connected (via HDMI) to a TV set - I've found out that this issue occurs
> more often if the TV is on (not displaying output from GPU) when I put
> my PC to sleep and I turn the TV off before resuming PC.
> 
> The issue persists on the current mainline kernel (6.17-rc3).
> 
> I've bisected it and this is the commit that introduced the issue:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=50e0bae34fa6b8b18e13473ddf0bcdab6ab68310
> 
> I've also found a similar report on the alsa mailing list:
> https://lore.kernel.org/alsa-devel/1855350181c58300-webhooks-bot@alsa-project.org/
> 
> I'm running Arch Linux with pipewire and wireplumber. The following is
> an excerpt from the WirePlumber log after bad resume:
> 
> D spa.alsa [alsa-util.c:1996:pa_alsa_get_hdmi_eld]: ELD info empty (for device=7)
> I spa.alsa [alsa-acp-device.c:893:card_props_changed]: card properties changed
> D spa.alsa [acp.c:760:report_jack_state]: Jack 'HDMI/DP,pcm=7 Jack' is now unplugged
> I spa.alsa [alsa-acp-device.c:975:card_port_available]: card port hdmi-output-1 available yes -> no
> I spa.alsa [acp.c:702:profile_set_available]: Profile output:hdmi-stereo-extra1 available yes -> no
> I spa.alsa [alsa-acp-device.c:941:card_profile_available]: card profile output:hdmi-stereo-extra1 available yes -> no
> 
> Please let me know what additional information I might provide to
> pinpoint this issue.
> 
> Thanks,
> Przemysław Kopa
> 

Given it's not a 100% reproduce for you, how did you confirm this commit 
is causing the issue?  Some sort of sampling of X cycles at each bisect 
point?

Could you capture a dmesg log where /sys/power/pm_debug_messages is set 
both from a good case and from a bad case so we can compare?

The peculiar thing is this commit only changes the timing of some of the 
suspend sequence, and as part of the suspend sequence the GPU is reset 
anyway.  So during the resume sequence it shouldn't have mattered what 
happened the last time on suspend entry.

Thanks,