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

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

[Frank Zhang]

The following panic was observed during system reboot:

Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 6 UID: 1000 PID: 2348 Comm: pipewire ... 7.0.5+ #4 PREEMPT(full)
Call trace:
 ...
 regmap_update_bits_base+0x70/0xa8
 dw_hdmi_qp_bridge_clear_audio_infoframe+0x3c/0x58 [dw_hdmi_qp]
 drm_bridge_connector_clear_audio_infoframe+0x2c/0x48 [drm_display_helper]
 ...
 dw_hdmi_qp_audio_disable+0x28/0xa8 [dw_hdmi_qp]
 drm_bridge_connector_audio_shutdown+0x38/0x68 [drm_display_helper]
 drm_connector_hdmi_audio_shutdown+0x28/0x40 [drm_display_helper]
 hdmi_codec_shutdown+0x60/0x90 [snd_soc_hdmi_codec]
 ...
 snd_pcm_release_substream+0xcc/0x120 [snd_pcm]
 snd_pcm_release+0x4c/0xc0 [snd_pcm]
 ...

The crash occurs when HDMI audio callbacks access registers after DRM
atomic framework disabled the PHY.

The root cause is a race condition exists between ALSA and DRM atomic
framework. During a modeset disable sequence, the DRM path disables the
PHY, while ALSA may still execute HDMI audio callbacks such as
audio_shutdown(), leading to accessing registers while the PHY is down
and eventually a kernel panic.

Fix this by introducing a mutex lock and PHY enabled state to serialize
PHY state transitions and HDMI audio callbacks. This ensures that HDMI
audio callbacks can only access registers while the PHY is enabled.

Fixes: fd0141d1a8a2 ("drm/bridge: synopsys: Add audio support for dw-hdmi-qp")
Cc: stable@vger.kernel.org
Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>

---
Changes in v2:
- Move drm_atomic_helper_connector_hdmi_clear_audio_infoframe() inside
  the if (hdmi->tmds_char_rate) of dw_hdmi_qp_audio_disable().
- Link to v1: https://lore.kernel.org/all/20260416093150.13853-1-rmxpzlb@gmail.com/

Changes in v3:
- Add a tmds_char_rate guard in clear_audio_infoframe path.
- Decouple write_audio_infoframe from clear_audio_infoframe.
- Balance the PKTSCHED_AMD_TX_EN bit enable/disable.
- Link to v2: https://lore.kernel.org/all/20260418101936.7731-1-rmxpzlb@gmail.com/

Changes in v4:
- Update panic stack on 7.0.5
- Link to v3: https://lore.kernel.org/all/20260423081514.15444-1-rmxpzlb@gmail.com/

Changes in v5:
- Reuse the origin dw_hdmi_qp_bridge_clear_audio_infoframe and add
  tmds_char_rate guard in new callback function.
- Link to v4: https://lore.kernel.org/all/20260512103153.8861-1-rmxpzlb@gmail.com/

Changes in v6:
- Add mutex and state to serialize HDMI audio callbacks with the PHY enable/disable
- Link to v5: https://lore.kernel.org/all/20260908070220.41574-1-rmxpzlb@gmail.com/

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
index 1c214a8e6dc2..a4789050a09e 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
@@ -159,6 +159,8 @@ struct dw_hdmi_qp {
 	struct {
 		const struct dw_hdmi_qp_phy_ops *ops;
 		void *data;
+		struct mutex lock;
+		bool enabled;
 	} phy;
 
 	unsigned long ref_clk_rate;
@@ -467,6 +469,10 @@ static int dw_hdmi_qp_audio_enable(struct drm_bridge *bridge,
 {
 	struct dw_hdmi_qp *hdmi = dw_hdmi_qp_from_bridge(bridge);
 
+	guard(mutex)(&hdmi->phy.lock);
+	if (!hdmi->phy.enabled)
+		return -EOPNOTSUPP;
+
 	if (hdmi->tmds_char_rate)
 		dw_hdmi_qp_mod(hdmi, 0, AVP_DATAPATH_PACKET_AUDIO_SWDISABLE, GLOBAL_SWDISABLE);
 
@@ -480,13 +486,23 @@ static int dw_hdmi_qp_audio_prepare(struct drm_bridge *bridge,
 {
 	struct dw_hdmi_qp *hdmi = dw_hdmi_qp_from_bridge(bridge);
 	bool ref2stream = false;
+	int ret = 0;
 
-	if (!hdmi->tmds_char_rate)
-		return -ENODEV;
+	mutex_lock(&hdmi->phy.lock);
+	if (!hdmi->phy.enabled) {
+		ret = -EOPNOTSUPP;
+		goto err_res;
+	}
+
+	if (!hdmi->tmds_char_rate) {
+		ret = -ENODEV;
+		goto err_res;
+	}
 
 	if (fmt->bit_clk_provider | fmt->frame_clk_provider) {
 		dev_err(hdmi->dev, "unsupported clock settings\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto err_res;
 	}
 
 	if (fmt->bit_fmt == SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE)
@@ -495,9 +511,13 @@ static int dw_hdmi_qp_audio_prepare(struct drm_bridge *bridge,
 	dw_hdmi_qp_set_audio_interface(hdmi, fmt, hparms);
 	dw_hdmi_qp_set_sample_rate(hdmi, hdmi->tmds_char_rate, hparms->sample_rate);
 	dw_hdmi_qp_set_channel_status(hdmi, hparms->iec.status, ref2stream);
-	drm_atomic_helper_connector_hdmi_update_audio_infoframe(connector, &hparms->cea);
+	mutex_unlock(&hdmi->phy.lock);
 
-	return 0;
+	return drm_atomic_helper_connector_hdmi_update_audio_infoframe(connector, &hparms->cea);
+
+err_res:
+	mutex_unlock(&hdmi->phy.lock);
+	return ret;
 }
 
 static void dw_hdmi_qp_audio_disable_regs(struct dw_hdmi_qp *hdmi)
@@ -526,6 +546,10 @@ static void dw_hdmi_qp_audio_disable(struct drm_bridge *bridge,
 
 	drm_atomic_helper_connector_hdmi_clear_audio_infoframe(connector);
 
+	guard(mutex)(&hdmi->phy.lock);
+	if (!hdmi->phy.enabled)
+		return;
+
 	if (hdmi->tmds_char_rate)
 		dw_hdmi_qp_audio_disable_regs(hdmi);
 }
@@ -754,6 +778,7 @@ static void dw_hdmi_qp_bridge_atomic_enable(struct drm_bridge *bridge,
 	struct drm_connector_state *conn_state;
 	struct drm_connector *connector;
 	unsigned int op_mode;
+	int ret;
 
 	connector = drm_atomic_get_new_connector_for_encoder(state, bridge->encoder);
 	if (WARN_ON(!connector))
@@ -763,6 +788,7 @@ static void dw_hdmi_qp_bridge_atomic_enable(struct drm_bridge *bridge,
 	if (WARN_ON(!conn_state))
 		return;
 
+	mutex_lock(&hdmi->phy.lock);
 	if (connector->display_info.is_hdmi) {
 		dev_dbg(hdmi->dev, "%s mode=HDMI %s rate=%llu bpc=%u\n", __func__,
 			drm_hdmi_connector_get_output_format_name(conn_state->hdmi.output_format),
@@ -774,10 +800,19 @@ static void dw_hdmi_qp_bridge_atomic_enable(struct drm_bridge *bridge,
 		op_mode = OPMODE_DVI;
 	}
 
-	hdmi->phy.ops->init(hdmi, hdmi->phy.data);
+	ret = hdmi->phy.ops->init(hdmi, hdmi->phy.data);
+	if (unlikely(ret)) {
+		dev_err(hdmi->dev, "failed to initialize PHY: %d\n", ret);
+		hdmi->phy.enabled = false;
+		hdmi->tmds_char_rate = 0;
+		mutex_unlock(&hdmi->phy.lock);
+		return;
+	}
+	hdmi->phy.enabled = true;
 
 	dw_hdmi_qp_mod(hdmi, HDCP2_BYPASS, HDCP2_BYPASS, HDCP2LOGIC_CONFIG0);
 	dw_hdmi_qp_mod(hdmi, op_mode, OPMODE_DVI, LINK_CONFIG0);
+	mutex_unlock(&hdmi->phy.lock);
 
 	drm_atomic_helper_connector_hdmi_update_infoframes(connector, state);
 }
@@ -787,9 +822,10 @@ static void dw_hdmi_qp_bridge_atomic_disable(struct drm_bridge *bridge,
 {
 	struct dw_hdmi_qp *hdmi = bridge->driver_private;
 
+	guard(mutex)(&hdmi->phy.lock);
 	hdmi->tmds_char_rate = 0;
-
 	hdmi->phy.ops->disable(hdmi, hdmi->phy.data);
+	hdmi->phy.enabled = false;
 }
 
 static enum drm_connector_status
@@ -880,10 +916,8 @@ static int dw_hdmi_qp_bridge_clear_spd_infoframe(struct drm_bridge *bridge)
 	return 0;
 }
 
-static int dw_hdmi_qp_bridge_clear_audio_infoframe(struct drm_bridge *bridge)
+static int dw_hdmi_qp_clear_audio_infoframe_regs(struct dw_hdmi_qp *hdmi)
 {
-	struct dw_hdmi_qp *hdmi = bridge->driver_private;
-
 	dw_hdmi_qp_mod(hdmi, 0,
 		       PKTSCHED_ACR_TX_EN |
 		       PKTSCHED_AUDS_TX_EN |
@@ -893,6 +927,17 @@ static int dw_hdmi_qp_bridge_clear_audio_infoframe(struct drm_bridge *bridge)
 	return 0;
 }
 
+static int dw_hdmi_qp_bridge_clear_audio_infoframe(struct drm_bridge *bridge)
+{
+	struct dw_hdmi_qp *hdmi = bridge->driver_private;
+
+	guard(mutex)(&hdmi->phy.lock);
+	if (!hdmi->phy.enabled)
+		return 0;
+
+	return dw_hdmi_qp_clear_audio_infoframe_regs(hdmi);
+}
+
 static void dw_hdmi_qp_write_pkt(struct dw_hdmi_qp *hdmi, const u8 *buffer,
 				 size_t start, size_t len, unsigned int reg)
 {
@@ -987,7 +1032,11 @@ static int dw_hdmi_qp_bridge_write_audio_infoframe(struct drm_bridge *bridge,
 {
 	struct dw_hdmi_qp *hdmi = bridge->driver_private;
 
-	dw_hdmi_qp_bridge_clear_audio_infoframe(bridge);
+	guard(mutex)(&hdmi->phy.lock);
+	if (!hdmi->phy.enabled)
+		return -EOPNOTSUPP;
+
+	dw_hdmi_qp_clear_audio_infoframe_regs(hdmi);
 
 	/*
 	 * AUDI_CONTENTS0: { RSV, HB2, HB1, RSV }
@@ -1299,6 +1348,8 @@ struct dw_hdmi_qp *dw_hdmi_qp_bind(struct platform_device *pdev,
 
 	hdmi->phy.ops = plat_data->phy_ops;
 	hdmi->phy.data = plat_data->phy_data;
+	hdmi->phy.enabled = false;
+	mutex_init(&hdmi->phy.lock);
 
 	if (plat_data->ref_clk_rate) {
 		hdmi->ref_clk_rate = plat_data->ref_clk_rate;
-- 
2.55.0

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

[Igor Paunovic]

Hi Frank,

I tested v6 on an Orange Pi 5 Plus (RK3588): git am onto a
drm-misc-next based 7.3.0-rc2 tree with PROVE_LOCKING and
DEBUG_ATOMIC_SLEEP, HDMI output to a TV.

The reproducer I used on v5 (output off, then open and close the PCM)
now stops at the open: dw_hdmi_qp_audio_enable() returned -EOPNOTSUPP
three times out of three, nothing from ASoC or the bridge was logged,
and since the startup failed, the shutdown path never reached
clear_audio_infoframe().

So I also ran the sequence from your commit message: PCM opened with
the output on, output turned off by the compositor while the stream
runs, PCM closed after that. With function_graph on
dw_hdmi_qp_bridge_clear_audio_infoframe() and
dw_hdmi_qp_audio_enable(), the clear call after the disable takes and
drops phy.lock and returns 0 with no regmap access inside it; with the
output on, as a control, one regmap_update_bits_base() call shows up
inside it, under the lock.

There was no external abort, SError, lockdep report or might_sleep
splat in the whole run, including two output off/on cycles, and once
the output was back on a new stream played on the TV.

Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus (RK3588)

Not covered: I did not try to hit the window the lock is meant to
close (an atomic disable landing between the state check and a
register write), so that part rests on the code; and I did not check
Dmitry's condition from v2 [1] that a PHY off/on cycle clears the
audio registers.

v6 overlaps with Detlev's patch [2] (both return -EOPNOTSUPP from the
audio callbacks while the output is off), and [2] no longer applies on
top of v6. For the crash, v6 alone now covers both sequences from my
v5 note (open with the output already off, and the output going away
under an open PCM), so my remark there that both patches are needed
does not apply to v6.

An LLM assistant applied and built the patch, wrote the test scripts,
counted the traces and helped draft this mail; I ran the tests on the
board and did the listening myself.

[1] https://lore.kernel.org/all/urguajogb4zsz4jg3ef32hpyf2awxkywdtlk5ackdi2gjai4l7@vpjaf3sznkto/
[2] https://lore.kernel.org/all/20260519-fix-hdmi-audio-warnings-v1-1-9608966c993f@collabora.com/

Igor

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

[Frank Zhang]

On 9/17/26 00:09, Igor Paunovic wrote:
> Hi Frank,
> 
> I tested v6 on an Orange Pi 5 Plus (RK3588): git am onto a
> drm-misc-next based 7.3.0-rc2 tree with PROVE_LOCKING and
> DEBUG_ATOMIC_SLEEP, HDMI output to a TV.
> 
> The reproducer I used on v5 (output off, then open and close the PCM)
> now stops at the open: dw_hdmi_qp_audio_enable() returned -EOPNOTSUPP
> three times out of three, nothing from ASoC or the bridge was logged,
> and since the startup failed, the shutdown path never reached
> clear_audio_infoframe().
> 
> So I also ran the sequence from your commit message: PCM opened with
> the output on, output turned off by the compositor while the stream
> runs, PCM closed after that. With function_graph on
> dw_hdmi_qp_bridge_clear_audio_infoframe() and
> dw_hdmi_qp_audio_enable(), the clear call after the disable takes and
> drops phy.lock and returns 0 with no regmap access inside it; with the
> output on, as a control, one regmap_update_bits_base() call shows up
> inside it, under the lock.
> 
> There was no external abort, SError, lockdep report or might_sleep
> splat in the whole run, including two output off/on cycles, and once
> the output was back on a new stream played on the TV.
> 
> Tested-by: Igor Paunovic <royalnet026@gmail.com> # Orange Pi 5 Plus (RK3588)
> 
> Not covered: I did not try to hit the window the lock is meant to
> close (an atomic disable landing between the state check and a
> register write), so that part rests on the code; and I did not check
> Dmitry's condition from v2 [1] that a PHY off/on cycle clears the
> audio registers.
> 
> v6 overlaps with Detlev's patch [2] (both return -EOPNOTSUPP from the
> audio callbacks while the output is off), and [2] no longer applies on
> top of v6. For the crash, v6 alone now covers both sequences from my
> v5 note (open with the output already off, and the output going away
> under an open PCM), so my remark there that both patches are needed
> does not apply to v6.
> 
> An LLM assistant applied and built the patch, wrote the test scripts,
> counted the traces and helped draft this mail; I ran the tests on the
> board and did the listening myself.
> 
> [1] https://lore.kernel.org/all/urguajogb4zsz4jg3ef32hpyf2awxkywdtlk5ackdi2gjai4l7@vpjaf3sznkto/
> [2] https://lore.kernel.org/all/20260519-fix-hdmi-audio-warnings-v1-1-9608966c993f@collabora.com/
> 
> Igor

Hi Igor,

Thanks for your testing.

Best regards,
Frank

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

[Tim Surber]

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