From: wangdicheng <wangdicheng@kylinos.cn>

The DRM HDMI audio helper framework notifies the audio codec about
physical connection changes via drm_connector_hdmi_audio_plugged_notify(),
but has no mechanism to notify when the CRTC state changes while the
connector remains physically connected.

This is a real problem on platforms with DP/HDMI audio. When a CRTC is
disabled while the sink remains connected (e.g. user switches to
"internal display only" mode but still wants audio from the external
monitor), the audio path silently breaks because:

1. The video stream is disabled, so there are no blanking intervals
   for audio Secondary Data Packets (SDP) to be transported.

2. The audio codec still believes the jack is present because
   plugged_notify() was not called (the connector is still physically
   connected).

3. Userspace (PulseAudio/PipeWire) continues routing audio to the
   external display, but no sound is actually output.

Without a framework-level notification, vendors who need to support
"audio output to external display while CRTC is inactive" are forced
to scatter condition checks across CRTC disable, encoder disable,
suspend, and resume paths. This pattern is fragile: any change in
the display pipeline can break the audio path, and the same condition
("connector connected but CRTC inactive, and audio is in use") must
be duplicated in multiple locations.

The root cause is architectural: the audio codec has no visibility
into CRTC state changes, so there is no clean way to implement
policies like:

- Mute audio output when CRTC is disabled (instead of silent breakage)
- Keep the video stream alive for audio transport
- Switch to DP Audio Only mode (hardware-supported on some platforms,
  e.g. Intel TRANS_DP_AUDIO_ONLY, but never used in i915 driver)

The HDA HDMI silent stream / KAE mechanism partially addresses this on
Intel platforms, but it operates only on the audio codec side and does
not coordinate with the DRM side. It also cannot work on platforms
without HDA codec support (e.g. ASoC-based designs).

Add an optional callback crtc_state_change() to
drm_connector_hdmi_audio_funcs, and a corresponding notification
function drm_connector_hdmi_audio_crtc_notify(). DRM drivers should
call this when the CRTC state changes on a connector with audio
capability, allowing audio codec implementations to react to display
pipeline state changes rather than only physical connection changes.

This provides a framework-level mechanism to implement "audio without
active display" policies cleanly, instead of scattering condition
checks across the display pipeline.

Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
---
 .../gpu/drm/display/drm_hdmi_audio_helper.c   | 23 +++++++++++++++++++
 include/drm/display/drm_hdmi_audio_helper.h   |  2 ++
 include/drm/drm_connector.h                   | 16 +++++++++++++
 3 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_hdmi_audio_helper.c b/drivers/gpu/drm/display/drm_hdmi_audio_helper.c
index 7d78b02c1446..3437be6ee989 100644
--- a/drivers/gpu/drm/display/drm_hdmi_audio_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_audio_helper.c
@@ -128,6 +128,29 @@ void drm_connector_hdmi_audio_plugged_notify(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_hdmi_audio_plugged_notify);
 
+/**
+ * drm_connector_hdmi_audio_crtc_notify - Notify the audio codec of CRTC state change
+ * @connector: A pointer to the connector
+ * @crtc_active: true if the CRTC is now active, false if disabled
+ *
+ * Notify the HDMI audio codec that the CRTC state has changed on this
+ * connector. This should be called by DRM drivers when a CRTC is
+ * enabled or disabled on a connector that has audio capability, even
+ * if the connector remains physically connected.
+ *
+ * Unlike drm_connector_hdmi_audio_plugged_notify() which signals
+ * physical connection changes, this function signals display pipeline
+ * state changes that affect the audio transport path.
+ */
+void drm_connector_hdmi_audio_crtc_notify(struct drm_connector *connector,
+					  bool crtc_active)
+{
+	if (connector->hdmi_audio.funcs->crtc_state_change)
+		connector->hdmi_audio.funcs->crtc_state_change(connector,
+							       crtc_active);
+}
+EXPORT_SYMBOL(drm_connector_hdmi_audio_crtc_notify);
+
 static const struct hdmi_codec_ops drm_connector_hdmi_audio_ops = {
 	.audio_startup = drm_connector_hdmi_audio_startup,
 	.prepare = drm_connector_hdmi_audio_prepare,
diff --git a/include/drm/display/drm_hdmi_audio_helper.h b/include/drm/display/drm_hdmi_audio_helper.h
index 44d910bdc72d..6b6672ae73cf 100644
--- a/include/drm/display/drm_hdmi_audio_helper.h
+++ b/include/drm/display/drm_hdmi_audio_helper.h
@@ -19,5 +19,7 @@ int drm_connector_hdmi_audio_init(struct drm_connector *connector,
 				  int sound_dai_port);
 void drm_connector_hdmi_audio_plugged_notify(struct drm_connector *connector,
 					     bool plugged);
+void drm_connector_hdmi_audio_crtc_notify(struct drm_connector *connector,
+					  bool crtc_active);
 
 #endif
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f83f28cae207..54aa15d0ef45 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1256,6 +1256,22 @@ struct drm_connector_hdmi_audio_funcs {
 	 */
 	int (*mute_stream)(struct drm_connector *connector,
 			   bool enable, int direction);
+
+	/**
+	 * @crtc_state_change:
+	 *
+	 * Notify the audio codec that the CRTC state has changed on this
+	 * connector. Called when a CRTC is enabled or disabled while the
+	 * connector remains physically connected. This is important for
+	 * DP/HDMI audio because audio transport depends on the video
+	 * stream's blanking intervals. The @crtc_state_change callback
+	 * is optional.
+	 *
+	 * @connector: the connector whose CRTC state changed
+	 * @crtc_active: true if the CRTC is now active, false if disabled
+	 */
+	void (*crtc_state_change)(struct drm_connector *connector,
+				  bool crtc_active);
 };
 
 void drm_connector_cec_phys_addr_invalidate(struct drm_connector *connector);
-- 
2.25.1

Hi,

On Wed, May 27, 2026 at 04:53:29PM +0800, wangdich9700@163.com wrote:
> From: wangdicheng <wangdicheng@kylinos.cn>
> 
> The DRM HDMI audio helper framework notifies the audio codec about
> physical connection changes via drm_connector_hdmi_audio_plugged_notify(),
> but has no mechanism to notify when the CRTC state changes while the
> connector remains physically connected.
> 
> This is a real problem on platforms with DP/HDMI audio. When a CRTC is
> disabled while the sink remains connected (e.g. user switches to
> "internal display only" mode but still wants audio from the external
> monitor), the audio path silently breaks because:
> 
> 1. The video stream is disabled, so there are no blanking intervals
>    for audio Secondary Data Packets (SDP) to be transported.
> 
> 2. The audio codec still believes the jack is present because
>    plugged_notify() was not called (the connector is still physically
>    connected).
> 
> 3. Userspace (PulseAudio/PipeWire) continues routing audio to the
>    external display, but no sound is actually output.
> 
> Without a framework-level notification, vendors who need to support
> "audio output to external display while CRTC is inactive" are forced
> to scatter condition checks across CRTC disable, encoder disable,
> suspend, and resume paths. This pattern is fragile: any change in
> the display pipeline can break the audio path, and the same condition
> ("connector connected but CRTC inactive, and audio is in use") must
> be duplicated in multiple locations.
> 
> The root cause is architectural: the audio codec has no visibility
> into CRTC state changes, so there is no clean way to implement
> policies like:
> 
> - Mute audio output when CRTC is disabled (instead of silent breakage)
> - Keep the video stream alive for audio transport
> - Switch to DP Audio Only mode (hardware-supported on some platforms,
>   e.g. Intel TRANS_DP_AUDIO_ONLY, but never used in i915 driver)
> 
> The HDA HDMI silent stream / KAE mechanism partially addresses this on
> Intel platforms, but it operates only on the audio codec side and does
> not coordinate with the DRM side. It also cannot work on platforms
> without HDA codec support (e.g. ASoC-based designs).
> 
> Add an optional callback crtc_state_change() to
> drm_connector_hdmi_audio_funcs, and a corresponding notification
> function drm_connector_hdmi_audio_crtc_notify(). DRM drivers should
> call this when the CRTC state changes on a connector with audio
> capability, allowing audio codec implementations to react to display
> pipeline state changes rather than only physical connection changes.
> 
> This provides a framework-level mechanism to implement "audio without
> active display" policies cleanly, instead of scattering condition
> checks across the display pipeline.
> 
> Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>

I'm not saying this is right or wrong, but I'd like to see what it looks
like from a driver point of view before merging anything in the
framework.

Maxime

Hi Maxime,

Thank you for the feedback. You're right - showing the driver usage is
important to validate the API design before merging framework changes.

I'm preparing follow-up patches to demonstrate how this would be used
in practice. Here's the plan:

1. DRM driver side: Show where to call drm_connector_hdmi_audio_crtc_notify()
   in the CRTC enable/disable paths (using i915 as an example)

2. Audio codec side: Show how an audio codec driver would implement the
   crtc_state_change callback (using HDA HDMI as an example)

I'll send these as a small series (framework patch + driver usage examples)
for your review. The examples will show:

- How i915 would notify audio when a CRTC is disabled while the connector
  remains physically connected (e.g., user switches to "internal display only")
- How the HDA HDMI codec would handle this notification to prevent silent
  audio breakage

Would you prefer I send the full series now, or would you like to see the
example patches first for API design review?

Best regards,
Wang Dicheng

On Fri, Jun 05, 2026 at 02:09:46PM +0800, wangdich9700@163.com wrote:
> Hi Maxime,
> 
> Thank you for the feedback. You're right - showing the driver usage is
> important to validate the API design before merging framework changes.
> 
> I'm preparing follow-up patches to demonstrate how this would be used
> in practice. Here's the plan:
> 
> 1. DRM driver side: Show where to call drm_connector_hdmi_audio_crtc_notify()
>    in the CRTC enable/disable paths (using i915 as an example)

i915 doesn't use the audio helpers, so I'm not sure what good that would do.

That being said, that patch and answer sure looks AI generated, and you
have to disclose that in your commit log.

Maxime