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

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

[Antoine Monnet]

Hi,

On an ASUS ProArt PX13 (HN7306, Ryzen AI Max / "Strix Halo", ACP rev 
0x70), all
SoundWire peripherals on link 1 fail to re-attach after a single s2idle
suspend/resume cycle. Audio works after a cold boot and is permanently 
broken
after the first resume; only a reboot recovers it. No amount of driver-level
re-initialisation from userspace helps (details below).

Environment
-----------
Machine : ASUS ProArt PX13, HN7306 (Ryzen AI Max, "Strix Halo")
Distro : Debian 13 (trixie)
Kernel : 7.0.13+deb13-amd64 (Debian 7.0.13-1~bpo13+1) -- fails
7.1.4+deb14-amd64 (Debian 7.1.4-1, sid) -- fails identically
ACP : 0000:c4:00.5 Audio Coprocessor [1022:15e2] rev 0x70,
subsystem ASUSTeK [1043:1714], driver snd_pci_ps
Link 1 : 2x TAS2783 smart-amps (slaves 0x8 / 0xB) + rt721-sdca jack codec
sdw:0:1:0102:0000:01:8, sdw:0:1:0102:0000:01:b,
sdw:0:1:025d:0721:01
Card : 1 [amdsoundwire]: amd-soundwire -
ASUSTeKCOMPUTERINC.-ProArtPX13HN7306EAC-1.0-HN7306EAC

Symptom
-------
After "PM: suspend entry (s2idle)" / "PM: suspend exit":

rt721-sdca sdw:0:1:025d:0721:01: Initialization not complete, timed out
slave-tas2783 sdw:0:1:0102:0000:01:8: resume: initialization timed out
slave-tas2783 sdw:0:1:0102:0000:01:8: PM: dpm_run_callback():
acpi_subsys_resume returns -110
slave-tas2783 sdw:0:1:0102:0000:01:8: PM: failed to resume: error -110
slave-tas2783 sdw:0:1:0102:0000:01:b: resume: initialization timed out
slave-tas2783 sdw:0:1:0102:0000:01:b: PM: failed to resume: error -110

and subsequently, on any playback attempt:

rt721-sdca sdw:0:1:025d:0721:01: SDW_SCP_BUSCLOCK_SCALE register write 
failed
soundwire sdw-master-0-1: Program params failed: -61
SDW1-PIN1-PLAYBACK-SmartAmp: ASoC error (-61): at snd_soc_link_prepare()

All three peripherals report UNATTACHED indefinitely:

# for d in /sys/bus/soundwire/devices/sdw:*; do \
echo "$(basename $d) $(cat $d/status)"; done
sdw:0:1:0102:0000:01:8 UNATTACHED
sdw:0:1:0102:0000:01:b UNATTACHED
sdw:0:1:025d:0721:01 UNATTACHED

Why this is not a codec bug
---------------------------
Three *different* codec drivers (TI tas2783-sdw on two devices, and
rt721-sdca) fail identically, all timing out on
wait_for_completion_timeout(&slave->initialization_complete). The subsequent
bus-level register writes fail with -ENODATA, i.e. the peripherals are not
responding on the bus at all. This is below the codec drivers.

A full ACP re-probe does not recover it
---------------------------------------
Unbinding and re-binding the ACP PCI device forces a complete teardown and
fresh probe of the SoundWire managers:

# echo 0000:c4:00.5 > /sys/bus/pci/drivers/snd_pci_ps/unbind
# echo 0000:c4:00.5 > /sys/bus/pci/drivers/snd_pci_ps/bind

After this, amd_sdw_manager.0/.1 are re-bound (so 
amd_sdw_manager_probe() has
re-run amd_init_sdw_manager() / amd_enable_sdw_interrupts() /
amd_enable_sdw_manager() / amd_sdw_set_frameshape()), yet all three 
peripherals
remain UNATTACHED. Driver-level unbind/rebind of the individual codec 
devices
and a full codec module reload are equally ineffective. Only a cold reboot
restores audio.

Since a from-scratch probe performs a strict superset of what
amd_resume_runtime() does, no additional re-initialisation in the manager's
resume path can fix this — the peripherals appear to be left unpowered 
or held
in reset across s2idle, and nothing the kernel does re-powers them.

ACPI configuration (verified)
-----------------------------
 From this machine's ACPI tables (SSDT, mipi-sdw-link-1-subproperties / 
"SWM1",
the link the codecs are on):

amd-sdw-enable 1
amd-sdw-wakeup-enable 1 -> wake_en_mask = 1
amd-sdw-power-mode 2 -> AMD_SDW_POWER_OFF_MODE
amd-sdw-multi-lane-enable 1
mipi-sdw-clock-stop-mode0-supported 1
mipi-sdw-clock-stop-mode1-supported 0

So power_mode_mask = AMD_SDW_POWER_OFF_MODE, i.e. amd_suspend() runs
amd_sdw_clock_stop() + amd_deinit_sdw_manager() + D3, and 
amd_resume_runtime()
(also the system-resume callback via SET_SYSTEM_SLEEP_PM_OPS) takes the
POWER_OFF_MODE branch and does the full re-initialisation:
sdw_clear_slave_status(SDW_UNATTACH_REQUEST_MASTER_RESET),
amd_init_sdw_manager(), amd_enable_sdw_interrupts(), 
amd_enable_sdw_manager(),
amd_sdw_set_frameshape(), D0.

That re-init demonstrably runs and the peripherals still never attach, 
which is
consistent with the ACP unbind/rebind result above.

Still present in 7.1.4; unchanged in 7.2-rc3
--------------------------------------------
I retested on Debian's 7.1.4 (7.1.4+deb14-amd64). The failure is 
identical: all
three peripherals UNATTACHED after one s2idle cycle, rt721-sdca reporting
"Initialization not complete, timed out" and "PM: failed to resume: 
error -110".
(The TAS2783 devices are silent in the log there only because Debian 
does not
set CONFIG_SND_SOC_TAS2783_SDW, so no codec driver is bound to them; 
their bus
status is UNATTACHED all the same.)

Note this rules out one plausible candidate: 7.1 added 
amd_sdw_clk_init_ctrl()
(commit 2a267a841084, "soundwire: amd: add clock init control 
function"), which
programs ACP_SW_CLK_FREQUENCY_CTRL and is called from the POWER_OFF_MODE 
resume
branch — a register the 7.0.x driver never writes at all. That reprogramming
does not help here.

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

One further detail looks suspicious, though I have not confirmed it is the
cause: in the POWER_OFF_MODE branch of amd_resume_runtime(), the clock 
resume
handshake is conditional —

val = readl(amd_manager->mmio + ACP_SW_CLK_RESUME_CTRL);
if (val) {
val |= AMD_SDW_CLK_RESUME_REQ;
...poll for AMD_SDW_CLK_RESUME_DONE...
if (val & AMD_SDW_CLK_RESUME_DONE) {
writel(0, ...);
amd_manager->clk_stopped = false;
}
}

After amd_deinit_sdw_manager() and a D3 transition the register block 
may well
read back as 0, in which case AMD_SDW_CLK_RESUME_REQ is never issued and
amd_manager->clk_stopped stays true from suspend. Whether the peripherals
require that clock-resume handshake before they will re-attach is a 
question for
someone with the ACP70 programming documentation.

I am not sure whether the correct fix belongs in the manager driver, in ACP
platform power handling, or in this board's firmware; guidance welcome.

Reproduce
---------
1. Cold boot; confirm internal speakers play.
2. systemctl suspend (s2idle); wake.
3. All link-1 peripherals are UNATTACHED; playback fails with -61.
4. ACP unbind/bind, codec rebind, and codec module reload do not recover;
only a reboot does.

Happy to test patches, add debug prints, or dump registers on this hardware.

Thanks,

Antoine

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

[Pierre-Louis Bossart]

> One further detail looks suspicious, though I have not confirmed it is the
> cause: in the POWER_OFF_MODE branch of amd_resume_runtime(), the clock
> resume
> handshake is conditional —
> 
> val = readl(amd_manager->mmio + ACP_SW_CLK_RESUME_CTRL);
> if (val) {
> val |= AMD_SDW_CLK_RESUME_REQ;
> ...poll for AMD_SDW_CLK_RESUME_DONE...
> if (val & AMD_SDW_CLK_RESUME_DONE) {
> writel(0, ...);
> amd_manager->clk_stopped = false;
> }
> }
> 
> After amd_deinit_sdw_manager() and a D3 transition the register block
> may well
> read back as 0, in which case AMD_SDW_CLK_RESUME_REQ is never issued and
> amd_manager->clk_stopped stays true from suspend. Whether the peripherals
> require that clock-resume handshake before they will re-attach is a
> question for
> someone with the ACP70 programming documentation.

Even without the ACP70 documentation, if the clock line doesn't toggle
nothing will happen on the peripheral sides. That's a generic SoundWire
property, the peripherals can only look for a sync pattern on the data
line if there's a clock signal.

I don't have any specific info on this IP, in general such bugs result
from one of:
- manager IP not powered
- manager IO pins not configured for SoundWire operation
- clock not toggling
- reset sequence not applied

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

[Andrey Golovko]

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/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

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

[Mario Limonciello]

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