Re:Re: [PATCH] drm/connector: add CRTC state change callback to HDMI audio helpers

[wangdicheng <wangdich9700@163.com>]

[-- Attachment #1: Type: text/plain, Size: 4203 bytes --]

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












At 2026-06-04 21:22:39, "Maxime Ripard" <mripard@kernel.org> wrote:
>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

[-- Attachment #2: Type: text/html, Size: 5124 bytes --]