Re: [PATCH] drm/bridge: dw-hdmi-qp: Return -EOPNOTSUPP in HDMI audio functions

[Igor Paunovic]

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 <royalnet026@xxxxxxxxx> # 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/20260512103153.8861-1-rmxpzlb@xxxxxxxxx/
[2] https://lore.kernel.org/all/20260907153000.hdmiqp-audio-1-royalnet026@xxxxxxxxx/

Thanks,
Igor