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