Hi Detlev, One more data point for this one, from an Orange Pi 5 Plus (RK3588).
Without the patch, every prepare on an HDMI PCM whose output is not lit (tmds_char_rate == 0: early in boot before the compositor enables the output, or with the output disabled in the compositor) logs hdmi-audio-codec hdmi-audio-codec.N.auto: ASoC error (-19): at snd_soc_dai_prepare() on i2s-hifi On two boots here with the link perfectly fine that was 115 and 114 lines, in two bursts each (60 and 55 prepares ~1 ms apart at 15.7 s and 28.1 s after boot on one, 60 and 54 at 14.8 s and 22.0 s on the other) - as far as I can tell PipeWire probing the cards from the greeter session before the compositor had lit the outputs. On the boot just before those two, where the sink had also failed SCDC, there were four of them and then the SError described in [2]. Disabling one output in the compositor and opening its PCM reproduces it on demand: exactly one line per prepare - and, on the close that follows, the abort in clear_audio_infoframe() described in [2]. With the patch applied (rebuilt dw_hdmi_qp module, same kernel), opening the PCM of an output disabled in the compositor now fails right away in hdmi_codec_startup() with EOPNOTSUPP - nothing from ASoC or the bridge in the kernel log, aplay says "Operation not supported" - and audio on the output that has a link works as before. Tested-by: Igor Paunovic <[email protected]> # Orange Pi 5 Plus One more reason I think this and Frank Zhang's patch [1] belong together: since the startup now fails, ASoC never marks the DAI as started, so for a PCM opened on a dead link the close never reaches hdmi_codec_shutdown() -> dw_hdmi_qp_audio_disable() -> clear_audio_infoframe(). That is the same class of bug as the SError we hit here on 02.09 (PCM closed after a failed prepare, register access with the PHY down -> SError, panic; full trace in [2]). I can't be certain this patch alone would have prevented that particular crash - a PCM that is already open when the output goes down still walks that path, which is what Frank's guard is for - so both still look needed to me. (I saw Cristian's question on v4 about open-coding the clear; either shape works for the crash I hit.) [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ Thanks, Igor
