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

[Mario Limonciello <superm1@kernel.org>]

On 9/3/25 7:21 AM, Przemysław Kopa wrote:
> On 9/3/25 05:35, Mario Limonciello wrote:
> 
>> 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?
> 
> Yes, I've tried a couple of times to trigger this issue on each 
> bisection point (by doing suspend -> resume cycle), and if I wasn't able 
> to trigger it, I've assumed it's good and moved on. I think I got the 
> right commit in the end, since now I have two kernels that are a single 
> commit apart (50e0bae34fa6), and I am able to trigger the issue when 
> running kernel with 50e0bae34fa6 applied, but am not able to trigger it 
> when running kernel without 50e0bae34fa6 (and I tried a lot ;).
> 
>> 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?
> 
> I'm attaching two dmesg dumps, running 6.17-rc4, fresh boot with a 
> single suspend -> resume cycle within each file.
> 
> 'dmesg_dp_audio_good.txt' - sound is fine after resume
> 'dmesg_dp_audio_bad.txt' - no sound after resume

I compared the two of them.
There are different problems you have with USB during recovery in the 
bad, but I don't think that's relevant.
The only thing different from a display perspective is a slight 
difference to the timing.

Can you repeat once more with /sys/power/pm_debug_messages and 
/sys/power/pm_print_times set for good and bad?  I want to make sure the 
device suspend order is identical.

Also; does playing audio leading up to the suspend cycle influence 
anything (both on good and bad kernel)?