PKTSCHED_ACR_TX_EN | PKTSCHED_AUDS_TX_EN |
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.0Hi 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
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
© 2016 - 2026 Red Hat, Inc.