Re: SoundWire: amd: all peripherals stay UNATTACHED after s2idle resume (AMD ACP70, ASUS ProArt PX13 HN7306)

Hi Antoine,

I have the same machine (ASUS ProArt PX13 HN7306EAC, Ryzen AI MAX+ 395,
ACP rev 0x70, RT721 + 2x TAS2783 on link 1) and have been chasing this
since May [1], [2].

Good news: this is already fixed in mainline.

  5893013efabb ("ASoC: amd: ps: disable MSI on resume in ACP PCI driver")
  Vijendar Mukunda, in v7.2-rc4

> drivers/soundwire/amd_manager.c is byte-identical between v7.1.4 and
> v7.2-rc3, so I have not test-booted 7.2.

That is why you missed it - the fix is not in the SoundWire manager at
all, it is in sound/soc/amd/ps/pci-ps.c, and it landed in rc4, one week
after the rc3 you diffed against. BIOS/firmware re-enables MSI in the
ACP's PCI config space on system resume while snd_pci_ps only uses
legacy INTx. With stale MSI address/data, the device writes interrupts
to a bogus address: hence the IOMMU IO_PAGE_FAULT at 0xfffffffffffffffc
and, crucially, the slave status-change interrupt never being delivered.
No status-change interrupt, no enumeration - which is exactly why a full
ACP unbind/rebind does not help either: the re-init runs fine, the
interrupt just never arrives.

So the conditional clock-resume handshake you flagged is not the cause
here; that branch behaves the same before and after the fix.

Results on this hardware, on a v7.2-rc4 based kernel:

 - 14 s2idle cycles, all three peripherals Attached after every resume
   (previously: UNATTACHED after the first cycle, 100% of the time)
 - zero IO_PAGE_FAULT, zero "resume: initialization timed out",
   zero -110 from acpi_subsys_resume, suspend_stats fail=0
 - in 11 of those cycles the driver logged the smoking gun:

     snd_pci_ps 0000:c4:00.5: ACP: MSI unexpectedly enabled after resume
     (flags=0x00f1), disabling

   i.e. the BIOS really does re-enable MSI behind the driver's back.
 - confirmed with real deep S0i3, not just a shallow s2idle: cycles with
   amd_pmc residency of 51.4 s and 38 s (out of ~57 s / ~43 s of sleep)
   re-attach just as reliably. Worth stressing, because on this board
   'amdgpu.dcdebugmask=0xE10' (IPS off) silently keeps the platform out
   of S0i3 and then the bug does not reproduce at all.

Vijendar, Mark: the commit carries a Fixes: tag but no Cc: stable, and it
has not been picked up for 7.1.y (currently v7.1.5). Could it be queued
for stable? Everyone hitting this so far is on a distro kernel: Antoine
on Debian 7.1.4, Pasquale Fiorillo on 7.0.x/7.1.3 (bugzilla #221584 [2]),
and myself on 7.0/7.1. A backport would fix the machine for all of them
without a mainline rebuild.

Antoine: attach being fixed is necessary but not sufficient on this
board - with real S0i3 residency the speakers stayed silent here for two
further reasons (a stale regmap cache in tas2783-sdw, and the ACP
SoundWire DMA configuration not being reprogrammed on stream recovery).
I am replying to your firmware thread [3] with the details, so as not to
mix them up with this one.

Happy to test patches or provide register dumps - and thanks for the very
precise write-ups, they saved me a lot of cross-checking.

[1] https://lore.kernel.org/all/[email protected]/
[2] https://bugzilla.kernel.org/show_bug.cgi?id=221584
[3] https://lore.kernel.org/all/[email protected]/

Thanks,
Andrey