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

[Tim Surber <me@timsurber.de>]

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