Re: [PATCH v6] drm/bridge: dw-hdmi-qp: serialize HDMI audio callbacks with PHY enable/disable

[Frank Zhang <rmxpzlb@gmail.com>]

On 11/11/26 05:55, Tim Surber wrote:
> Hi Frank,
> 
> On Tue, Sep 15, 2026 at 06:34:33PM +0800, Frank Zhang wrote:
>> The crash occurs when HDMI audio callbacks access registers after DRM
>> atomic framework disabled the PHY.
> 
> I reproduced this on a FriendlyElec CM3588 NAS (RK3588) and tested v6.
> The bug can be hit in more situations than the reboot case in the
> commit message. The details are below in case they help with the
> commit message or with the stable backport.
> 
> Setup:
> - rockchip for-next at c3baae5f1 (7.4.0-rc1), arm64 defconfig
> - HDMI TX/RX audio DT enablement for CM3588 on top (HDMI-IN series)
> - Debian forky, GNOME 50 / Mutter 50.5
> - HDMI0 TX looped back into the RK3588 HDMI RX, so playback on HDMI0
>    can be captured on the HDMI-IN card for a functional check
> - netconsole to capture oopses
> 
> Without the patch:
> 
> 1) Display off, then open/close the PCM
> 
>     Mutter switches the outputs off (CRTC fully disabled):
> 
>       busctl --user set-property org.gnome.Mutter.DisplayConfig \
>           /org/gnome/Mutter/DisplayConfig \
>           org.gnome.Mutter.DisplayConfig PowerSaveMode i 3
>       cat /sys/class/drm/card0-HDMI-A-1/enabled   # -> disabled
>       speaker-test -D hw:HDMI0 -c2 -r 48000 -t sine -F S16_LE -l 1
> 
>     hw_params fails with -ENODEV (prepare sees tmds_char_rate == 0).
>     The close that follows still reaches clear_audio_infoframe:
> 
>       Internal error: synchronous external abort: 0000000096000010 [#1] SMP
>       pc : regmap_mmio_read32le+0xc/0x24
>       Call trace:
>        regmap_mmio_read32le+0xc/0x24 (P)
>        _regmap_bus_reg_read+0x68/0xac
>        _regmap_read+0x60/0xd8
>        _regmap_update_bits+0xfc/0x14c
>        regmap_update_bits_base+0x54/0x80
>        dw_hdmi_qp_bridge_clear_audio_infoframe+0x30/0x40 [dw_hdmi_qp]
>        drm_bridge_connector_clear_audio_infoframe+0x20/0x40 [drm_display_helper]
>        clear_infoframe+0x50/0xf4 [drm_display_helper]
>        drm_atomic_helper_connector_hdmi_clear_audio_infoframe+0x64/0xcc [drm_display_helper]
>        dw_hdmi_qp_audio_disable+0x1c/0xa4 [dw_hdmi_qp]
>        drm_bridge_connector_audio_shutdown+0x28/0x4c [drm_display_helper]
>        drm_connector_hdmi_audio_shutdown+0x1c/0x30 [drm_display_helper]
>        hdmi_codec_shutdown+0x58/0x7c [snd_soc_hdmi_codec]
>        snd_soc_dai_shutdown+0x54/0x80 [snd_soc_core]
>        soc_pcm_clean.isra.0+0x5c/0x1e0 [snd_soc_core]
>        soc_pcm_close+0x34/0x60 [snd_soc_core]
>        snd_pcm_release_substream.part.0+0x88/0xe0 [snd_pcm]
>        snd_pcm_release+0x58/0xc8 [snd_pcm]
>        __fput+0xd0/0x300
>        ...
>       note: speaker-test[1576] exited with irqs disabled
>       note: speaker-test[1576] exited with preempt_count 1
> 
>     The task dies holding the ASoC PCM mutex. Afterwards the
>     close_delayed_work kworker stays in D state in
>     snd_soc_close_delayed_work(), so audio stays broken until reboot.
>     One of my runs ended in an SError panic instead of the
>     synchronous abort.
> 
> 2) Display turned off while a stream is running (the wider case)
> 
>     Start playback on hw:HDMI0 with the display on, switch the display
>     off through Mutter as above, keep playing, then stop the stream.
>     Playback keeps running normally (state RUNNING, hw_ptr advancing)
>     and nothing is reported to user space. When the stream is closed,
>     the board dies: SSH drops, nothing reaches netconsole, and it
>     reboots only through kernel.panic. I reproduced this twice.
> 
>     No application error is needed for this. Playing audio over HDMI
>     while the desktop blanks the screen, or while the sink is
>     unplugged, and then stopping playback is enough. I suspect this is
>     also what most users hit in practice, more than the reboot path.
> 
> 3) HDMI output never enabled (HDMI1, nothing connected)
> 
>     Opening and closing hw:HDMI1 repeatedly fails with -ENODEV and does
>     not crash. The same holds for WirePlumber probing HDMI0 at boot,
>     before the compositor enables it. The register accesses only fault
>     after the PHY has been initialised once and then disabled, which
>     matches your analysis.
> 
> With v6 applied:
> 
> - Case 1: the open now fails cleanly ("Playback open error: -95,
>    Operation not supported" from the new startup check). No abort,
>    and the system stays healthy.
> - Case 2: playback continues after the display goes off, and the
>    close completes cleanly. No hang.
> - Case 3: unchanged, -ENODEV, no crash.
> - Functional check: after re-enabling the display, a 440 Hz sine played
>    on HDMI0 is captured correctly on the HDMI-IN card through the
>    loopback, so the prepare/infoframe path still works.
> - Stress test: for 2 minutes, HDMI0 was toggled on and off 114 times
>    (atomic commits disabling/enabling the CRTC at random 0.1-0.9 s
>    intervals), racing about 2950 open/play/close cycles on hw:HDMI0
>    with random lifetimes. No oops, no hung tasks, nothing new in
>    dmesg (lockdep was not enabled).
> 
> It may be worth adding the "stream open while the output is disabled"
> case to the commit message. It is much easier to trigger than the
> reboot race and makes a stronger case for the stable backport.
> 
> Tested-by: Tim Surber <me@timsurber.de> # FriendlyElec CM3588 NAS (RK3588)
> 
> Thanks,
> Tim

Hi Tim,

Thank you for the thorough testing and suggestion. I'll update the 
commit message and send a new version as soon as possible.

Best regards,
Frank