[BUG][MTL] DSP firmware boot -110 on resume — only when HDMI is connected AND audio streams via the internal analog path during system suspend (regression)

[edyfox]

Describe the bug

On a ThinkPad T14s Gen 5 (Meteor Lake, sof-audio-pci-intel-mtl, PCI 0000:00:1f.3), the DSP fails to boot firmware with -110 (ETIMEDOUT) on resume from system suspend (S2idle), leaving audio permanently dead until a full reboot. Module reload, PCI remove/rescan, and driver unbind/rebind do not recover it — only a power-cycle does.

The trigger is very specific and fully reproducible: it requires an active playback stream on the internal analog path while an HDMI/DP display is connected at the moment of suspend.

Reproduction — requires ALL THREE conditions simultaneously

1. An external display is connected via HDMI/DP (HDMI codec present in topology).
2. Audio is actively streaming through the internal analog codec (in my case a background fluidsynth keeps the analog PCM open continuously).
3. The system enters suspend (S2idle).

→ On resume, the DSP wedges with -110.

It is NOT reproducible if any one condition is removed (each verified):

HDMI connected	Active stream path	Suspend	Result
Yes	Analog	Yes	WEDGE (-110)
No	Analog	Yes	OK
Yes	HDMI	Yes	OK
Yes	Analog	No	OK

The monitor model is irrelevant — reproduced with two different external monitors in two locations. Only the presence of a connected HDMI sink matters. This points to a cross-codec suspend/resume ordering issue: resuming the active analog path fails only when an idle-but-present HDMI codec also exists in the topology.

Regression

This worked correctly a few months ago — suspending with the same fluidsynth setup did not break audio. It has regressed since. (Happy to help bisect kernel / firmware versions to narrow the window.)

dmesg on the failed resume / forced re-probe

sof-audio-pci-intel-mtl 0000:00:1f.3: Loaded firmware library: ADSPFW, version: 2.12.0.1
sof-audio-pci-intel-mtl 0000:00:1f.3: timeout waiting for purge IPC done
sof-audio-pci-intel-mtl 0000:00:1f.3: ------------[ DSP dump start ]------------
sof-audio-pci-intel-mtl 0000:00:1f.3: Boot iteration failed: 3/3
sof-audio-pci-intel-mtl 0000:00:1f.3: fw_state: SOF_FW_BOOT_IN_PROGRESS (3)
sof-audio-pci-intel-mtl 0000:00:1f.3: 0xd000001c: module: ROM_EXT, state: REMOVE_ACCESS_CONTROL, not running
sof-audio-pci-intel-mtl 0000:00:1f.3: error code: 0x2328 (unknown)
sof-audio-pci-intel-mtl 0000:00:1f.3: ------------[ DSP dump end ]------------
sof-audio-pci-intel-mtl 0000:00:1f.3: error: dsp init failed after 3 attempts with err: -110
sof-audio-pci-intel-mtl 0000:00:1f.3: Failed to start DSP
sof-audio-pci-intel-mtl 0000:00:1f.3: error: failed to boot DSP firmware -110
sof-audio-pci-intel-mtl 0000:00:1f.3: error: sof_probe_work failed err: -110

Note: the failure is at the boot ROM stage (ROM_EXT / REMOVE_ACCESS_CONTROL), before firmware runs — so no PCI/driver/PM-level recovery works; only a full power cycle resets the DSP.

Environment

• Hardware: Lenovo ThinkPad T14s Gen 5 (21LS0041SG), BIOS N46ET24W (1.14)
• SoC / audio: Intel Meteor Lake, sof-hda-dsp, PCI 0000:00:1f.3
• Kernel: 7.0.12+deb14.1-amd64 (Debian forky/sid)
• SOF firmware: firmware-sof-signed 2025.01-1; loaded ADSPFW 2.12.0.1; sof-mtl.ri, IPC4
• Topology: sof-ipc4-tplg/sof-hda-generic-2ch.tplg
• alsa-ucm-conf: 1.2.16-1
• Userspace: PipeWire + WirePlumber
• Suspend type: S2idle (modern standby)

Possibly related

Same -110-on-suspend/resume IPC-timeout family: #1072, #2971, #4507, #4558 (different platforms/triggers, but similar resume failure signature).

Additional context

I can reliably reproduce on demand and am happy to collect sof-logger traces, test patches, or bisect. Workarounds in the meantime: disconnect HDMI before suspend, or keep the system on AC (no auto-suspend).

[lgirdwood]

@edyfox thanks, this is goood data. Btw do you have a full kernel log around the suspend and resume operations. Is it also possible to disable pipewire and wireplumber (and reboot so they are not running) and just do an aplay -Dhw: command. i.e. to rule in/out any interactions for userspace discovery around the HDMI connection event. Thanks !