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

[Mario Limonciello <superm1@kernel.org>]

On 7/27/26 03:12, Andrey Golovko wrote:
> 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.

FWIW - anyone can send a stable patch.  If you or someone else has 
validated it works on 7.1.y (which I expect it works), feel free to send 
it out.

https://docs.kernel.org/process/stable-kernel-rules.html

> 
> 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/cab8c5d1-6930-4048-a8d3-720db9b3c0dd@amd.com/
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=221584
> [3] https://lore.kernel.org/all/c66ae00a-e878-4af0-a05a-272e9574eaa5@montane.tech/
> 
> Thanks,
> Andrey