[PATCH 1/2] drm/mediatek: hdmi: pulse audio clocks on bridge enable

[PATCH 1/2] drm/mediatek: hdmi: pulse audio clocks on bridge enable

[Daniel Golle]

The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed the
HDMI TX internal audio measurement block which derives CTS values
for the ACR packets embedded in the TMDS stream. These clocks are
enabled once at driver probe time and then left untouched across
bridge atomic_enable / atomic_disable cycles.

On every observed stale-state event -- a blank/unblank cycle, or
a cold boot with the monitor off followed by a later hotplug --
the measurement block remains armed against the previous state
and fails to latch a valid CTS on the subsequent bridge enable.
Video recovers cleanly but the audio data islands never regain
lock and the HDMI sink sees no audio, even though the ASoC stack,
the AFE, and the HDMI TX audio packetizer are all programmed
correctly.

Debugging the issue of audio no longer working after vblank it was
found that an unbind+bind of the mediatek-drm-hdmi platform driver
recovers audio in all such scenarios without disturbing video.
The only audio-relevant side effect of that rebind is an off->on edge
on CLK_MM_HDMI_AUDIO / CLK_MM_HDMI_SPDIF via the probe path. Pulsing
those two clocks directly at the end of mtk_hdmi_bridge_atomic_enable
reproduces that recovery on every enable and doesn't hurt on the
first enable after boot.

Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 1ea2598547800..9050d7785f109 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1065,6 +1065,22 @@ static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
 	phy_power_on(hdmi->phy);
 	mtk_hdmi_send_infoframe(hdmi, &hdmi->mode);
 
+	/*
+	 * Pulse the HDMI TX audio clocks off/on on every bridge enable.
+	 * The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed
+	 * the HDMI TX internal audio measurement block that derives CTS
+	 * for the ACR packets embedded in the TMDS stream. Without an
+	 * off->on edge at bridge enable the block can stay armed against
+	 * stale state from a previous enable (e.g. after blank/unblank,
+	 * or after a monitor that was off at boot is plugged in later)
+	 * and fails to latch a valid CTS, leaving the audio path silent
+	 * even though video recovers. The pulse is what an unbind+bind
+	 * of the HDMI platform driver effectively does, and it recovers
+	 * audio in all observed stale-state scenarios.
+	 */
+	mtk_hdmi_clk_disable_audio(hdmi);
+	mtk_hdmi_clk_enable_audio(hdmi);
+
 	hdmi->enabled = true;
 }
 
-- 
2.53.0

[PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable

[Daniel Golle]

Notify hdmi-codec of the current sink plugged state from
mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
via mtk_hdmi_update_plugged_status(). This matches the pattern used
by dw-hdmi, which invokes handle_plugged_change() from the bridge
enable and disable paths so that ASoC jack state stays in sync with
the actual sink presence across atomic commit cycles, and not only
on CEC HPD transitions.

Userspace audio daemons (e.g. pipewire) rely on the jack state to
route streams, restore per-sink volume levels, and recover the last
used device after a reconnect. Without this, those transitions are
missed whenever the sink change is driven by a mode set rather than
by a bare HPD event.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 9050d7785f109..565bb72c9b63a 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1013,6 +1013,8 @@ static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
 	hdmi->curr_conn = NULL;
 
 	hdmi->enabled = false;
+
+	mtk_hdmi_update_plugged_status(hdmi);
 }
 
 static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
@@ -1082,6 +1084,8 @@ static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
 	mtk_hdmi_clk_enable_audio(hdmi);
 
 	hdmi->enabled = true;
+
+	mtk_hdmi_update_plugged_status(hdmi);
 }
 
 static const struct drm_bridge_funcs mtk_hdmi_bridge_funcs = {
-- 
2.53.0

Re: [PATCH 1/2] drm/mediatek: hdmi: pulse audio clocks on bridge enable

[Daniel Golle]

A kind reminder that this patch fixes HDMI audio on all v1 platforms.
The (now already merged[1]) driver for MT2701/MT7623N also depends on
it, as mentioned in the cover letter of that series[2].

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=4d9c6bbfed7d9a3224a66f3d135cdef21a430168
[2]: https://lore.kernel.org/all/cover.1776998727.git.daniel@makrotopia.org/

On Wed, Apr 15, 2026 at 04:04:08PM +0100, Daniel Golle wrote:
> The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed the
> HDMI TX internal audio measurement block which derives CTS values
> for the ACR packets embedded in the TMDS stream. These clocks are
> enabled once at driver probe time and then left untouched across
> bridge atomic_enable / atomic_disable cycles.
> 
> On every observed stale-state event -- a blank/unblank cycle, or
> a cold boot with the monitor off followed by a later hotplug --
> the measurement block remains armed against the previous state
> and fails to latch a valid CTS on the subsequent bridge enable.
> Video recovers cleanly but the audio data islands never regain
> lock and the HDMI sink sees no audio, even though the ASoC stack,
> the AFE, and the HDMI TX audio packetizer are all programmed
> correctly.
> 
> Debugging the issue of audio no longer working after vblank it was
> found that an unbind+bind of the mediatek-drm-hdmi platform driver
> recovers audio in all such scenarios without disturbing video.
> The only audio-relevant side effect of that rebind is an off->on edge
> on CLK_MM_HDMI_AUDIO / CLK_MM_HDMI_SPDIF via the probe path. Pulsing
> those two clocks directly at the end of mtk_hdmi_bridge_atomic_enable
> reproduces that recovery on every enable and doesn't hurt on the
> first enable after boot.
> 
> Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 1ea2598547800..9050d7785f109 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1065,6 +1065,22 @@ static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
>  	phy_power_on(hdmi->phy);
>  	mtk_hdmi_send_infoframe(hdmi, &hdmi->mode);
>  
> +	/*
> +	 * Pulse the HDMI TX audio clocks off/on on every bridge enable.
> +	 * The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed
> +	 * the HDMI TX internal audio measurement block that derives CTS
> +	 * for the ACR packets embedded in the TMDS stream. Without an
> +	 * off->on edge at bridge enable the block can stay armed against
> +	 * stale state from a previous enable (e.g. after blank/unblank,
> +	 * or after a monitor that was off at boot is plugged in later)
> +	 * and fails to latch a valid CTS, leaving the audio path silent
> +	 * even though video recovers. The pulse is what an unbind+bind
> +	 * of the HDMI platform driver effectively does, and it recovers
> +	 * audio in all observed stale-state scenarios.
> +	 */
> +	mtk_hdmi_clk_disable_audio(hdmi);
> +	mtk_hdmi_clk_enable_audio(hdmi);
> +
>  	hdmi->enabled = true;
>  }
>  
> -- 
> 2.53.0
> 

Re: [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable

[Dmitry Baryshkov]

On Wed, Apr 15, 2026 at 04:04:16PM +0100, Daniel Golle wrote:
> Notify hdmi-codec of the current sink plugged state from
> mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
> via mtk_hdmi_update_plugged_status(). This matches the pattern used
> by dw-hdmi, which invokes handle_plugged_change() from the bridge
> enable and disable paths so that ASoC jack state stays in sync with
> the actual sink presence across atomic commit cycles, and not only
> on CEC HPD transitions.
> 
> Userspace audio daemons (e.g. pipewire) rely on the jack state to
> route streams, restore per-sink volume levels, and recover the last
> used device after a reconnect. Without this, those transitions are
> missed whenever the sink change is driven by a mode set rather than
> by a bare HPD event.

I can only hope to see mtk_hdmi to migrate to DRM_BRIDGE_OP_HDMI and
DRM_BRIDGE_OP_HDMI_AUDIO...

I think the correct timing was discussed several times and the overall
conclusion was that the correct time is when the actual HDMI cable is
being plugged / unplugged. See the discussion around [1] and the
captured response of Mark Brown.

[1] https://lore.kernel.org/dri-devel/cwxmu5a37qaqerpaolohxw57nzerkvlumx4dsqwmqwx5t7xhxo@kq6j63hfydra/

> 
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 9050d7785f109..565bb72c9b63a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1013,6 +1013,8 @@ static void mtk_hdmi_bridge_atomic_disable(struct drm_bridge *bridge,
>  	hdmi->curr_conn = NULL;
>  
>  	hdmi->enabled = false;
> +
> +	mtk_hdmi_update_plugged_status(hdmi);
>  }
>  
>  static void mtk_hdmi_bridge_atomic_post_disable(struct drm_bridge *bridge,
> @@ -1082,6 +1084,8 @@ static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
>  	mtk_hdmi_clk_enable_audio(hdmi);
>  
>  	hdmi->enabled = true;
> +
> +	mtk_hdmi_update_plugged_status(hdmi);
>  }
>  
>  static const struct drm_bridge_funcs mtk_hdmi_bridge_funcs = {
> -- 
> 2.53.0

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable

[Daniel Golle]

On Thu, May 07, 2026 at 12:51:56PM +0300, Dmitry Baryshkov wrote:
> On Wed, Apr 15, 2026 at 04:04:16PM +0100, Daniel Golle wrote:
> > Notify hdmi-codec of the current sink plugged state from
> > mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
> > via mtk_hdmi_update_plugged_status(). This matches the pattern used
> > by dw-hdmi, which invokes handle_plugged_change() from the bridge
> > enable and disable paths so that ASoC jack state stays in sync with
> > the actual sink presence across atomic commit cycles, and not only
> > on CEC HPD transitions.
> > 
> > Userspace audio daemons (e.g. pipewire) rely on the jack state to
> > route streams, restore per-sink volume levels, and recover the last
> > used device after a reconnect. Without this, those transitions are
> > missed whenever the sink change is driven by a mode set rather than
> > by a bare HPD event.
> 
> I can only hope to see mtk_hdmi to migrate to DRM_BRIDGE_OP_HDMI and
> DRM_BRIDGE_OP_HDMI_AUDIO...
> 
> I think the correct timing was discussed several times and the overall
> conclusion was that the correct time is when the actual HDMI cable is
> being plugged / unplugged. See the discussion around [1] and the
> captured response of Mark Brown.

Thank you for bringing this to my attention. I'll follow up on it.
Meanwhile, can (independent) patch 1/2 already be merged, or at least
get reviewed?

Re: [PATCH 1/2] drm/mediatek: hdmi: pulse audio clocks on bridge enable

[CK Hu (胡俊光)]

On Wed, 2026-04-15 at 16:04 +0100, Daniel Golle wrote:
> External email : Please do not click links or open attachments until you have verified the sender or the content.
> 
> 
> The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed the
> HDMI TX internal audio measurement block which derives CTS values
> for the ACR packets embedded in the TMDS stream. These clocks are
> enabled once at driver probe time and then left untouched across
> bridge atomic_enable / atomic_disable cycles.
> 
> On every observed stale-state event -- a blank/unblank cycle, or
> a cold boot with the monitor off followed by a later hotplug --
> the measurement block remains armed against the previous state
> and fails to latch a valid CTS on the subsequent bridge enable.
> Video recovers cleanly but the audio data islands never regain
> lock and the HDMI sink sees no audio, even though the ASoC stack,
> the AFE, and the HDMI TX audio packetizer are all programmed
> correctly.
> 
> Debugging the issue of audio no longer working after vblank it was
> found that an unbind+bind of the mediatek-drm-hdmi platform driver
> recovers audio in all such scenarios without disturbing video.
> The only audio-relevant side effect of that rebind is an off->on edge
> on CLK_MM_HDMI_AUDIO / CLK_MM_HDMI_SPDIF via the probe path. Pulsing
> those two clocks directly at the end of mtk_hdmi_bridge_atomic_enable
> reproduces that recovery on every enable and doesn't hurt on the
> first enable after boot.
> 
> Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 1ea2598547800..9050d7785f109 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1065,6 +1065,22 @@ static void mtk_hdmi_bridge_atomic_enable(struct drm_bridge *bridge,
>         phy_power_on(hdmi->phy);
>         mtk_hdmi_send_infoframe(hdmi, &hdmi->mode);
> 
> +       /*
> +        * Pulse the HDMI TX audio clocks off/on on every bridge enable.
> +        * The CLK_MM_HDMI_AUDIO and CLK_MM_HDMI_SPDIF mmsys gates feed
> +        * the HDMI TX internal audio measurement block that derives CTS
> +        * for the ACR packets embedded in the TMDS stream. Without an
> +        * off->on edge at bridge enable the block can stay armed against
> +        * stale state from a previous enable (e.g. after blank/unblank,
> +        * or after a monitor that was off at boot is plugged in later)
> +        * and fails to latch a valid CTS, leaving the audio path silent
> +        * even though video recovers. The pulse is what an unbind+bind
> +        * of the HDMI platform driver effectively does, and it recovers
> +        * audio in all observed stale-state scenarios.
> +        */
> +       mtk_hdmi_clk_disable_audio(hdmi);
> +       mtk_hdmi_clk_enable_audio(hdmi);

Why not align audio clock on/off timing to video clock timing.
I mean, do not turn on audio clock when probe and turn on it in atomic enable and turn off it in atomic disable.
I think it's reasonable to align audio clock and video clock on/off timing.

Regards,
CK

> +
>         hdmi->enabled = true;
>  }
> 
> --
> 2.53.0
> 

Re: [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable

[Dmitry Baryshkov]

On Thu, May 07, 2026 at 02:32:45PM +0100, Daniel Golle wrote:
> On Thu, May 07, 2026 at 12:51:56PM +0300, Dmitry Baryshkov wrote:
> > On Wed, Apr 15, 2026 at 04:04:16PM +0100, Daniel Golle wrote:
> > > Notify hdmi-codec of the current sink plugged state from
> > > mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
> > > via mtk_hdmi_update_plugged_status(). This matches the pattern used
> > > by dw-hdmi, which invokes handle_plugged_change() from the bridge
> > > enable and disable paths so that ASoC jack state stays in sync with
> > > the actual sink presence across atomic commit cycles, and not only
> > > on CEC HPD transitions.
> > > 
> > > Userspace audio daemons (e.g. pipewire) rely on the jack state to
> > > route streams, restore per-sink volume levels, and recover the last
> > > used device after a reconnect. Without this, those transitions are
> > > missed whenever the sink change is driven by a mode set rather than
> > > by a bare HPD event.
> > 
> > I can only hope to see mtk_hdmi to migrate to DRM_BRIDGE_OP_HDMI and
> > DRM_BRIDGE_OP_HDMI_AUDIO...
> > 
> > I think the correct timing was discussed several times and the overall
> > conclusion was that the correct time is when the actual HDMI cable is
> > being plugged / unplugged. See the discussion around [1] and the
> > captured response of Mark Brown.
> 
> Thank you for bringing this to my attention. I'll follow up on it.
> Meanwhile, can (independent) patch 1/2 already be merged, or at least
> get reviewed?


The discussion that I pointed to suggests that the patch is incorrect.

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable

[Daniel Golle]

On Fri, May 08, 2026 at 02:29:29PM +0300, Dmitry Baryshkov wrote:
> On Thu, May 07, 2026 at 02:32:45PM +0100, Daniel Golle wrote:
> > On Thu, May 07, 2026 at 12:51:56PM +0300, Dmitry Baryshkov wrote:
> > > On Wed, Apr 15, 2026 at 04:04:16PM +0100, Daniel Golle wrote:
> > > > Notify hdmi-codec of the current sink plugged state from
> > > > mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
> > > > via mtk_hdmi_update_plugged_status(). This matches the pattern used
> > > > by dw-hdmi, which invokes handle_plugged_change() from the bridge
> > > > enable and disable paths so that ASoC jack state stays in sync with
> > > > the actual sink presence across atomic commit cycles, and not only
> > > > on CEC HPD transitions.
> > > > 
> > > > Userspace audio daemons (e.g. pipewire) rely on the jack state to
> > > > route streams, restore per-sink volume levels, and recover the last
> > > > used device after a reconnect. Without this, those transitions are
> > > > missed whenever the sink change is driven by a mode set rather than
> > > > by a bare HPD event.
> > > 
> > > I can only hope to see mtk_hdmi to migrate to DRM_BRIDGE_OP_HDMI and
> > > DRM_BRIDGE_OP_HDMI_AUDIO...
> > > 
> > > I think the correct timing was discussed several times and the overall
> > > conclusion was that the correct time is when the actual HDMI cable is
> > > being plugged / unplugged. See the discussion around [1] and the
> > > captured response of Mark Brown.
> > 
> > Thank you for bringing this to my attention. I'll follow up on it.
> > Meanwhile, can (independent) patch 1/2 already be merged, or at least
> > get reviewed?
> 
> 
> The discussion that I pointed to suggests that the patch is incorrect.

I understand that patch 2/2 is incorrect, but (the independent fix in)
patch 1/2 as well?

Re: [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable

[Dmitry Baryshkov]

On Fri, May 08, 2026 at 12:44:23PM +0100, Daniel Golle wrote:
> On Fri, May 08, 2026 at 02:29:29PM +0300, Dmitry Baryshkov wrote:
> > On Thu, May 07, 2026 at 02:32:45PM +0100, Daniel Golle wrote:
> > > On Thu, May 07, 2026 at 12:51:56PM +0300, Dmitry Baryshkov wrote:
> > > > On Wed, Apr 15, 2026 at 04:04:16PM +0100, Daniel Golle wrote:
> > > > > Notify hdmi-codec of the current sink plugged state from
> > > > > mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
> > > > > via mtk_hdmi_update_plugged_status(). This matches the pattern used
> > > > > by dw-hdmi, which invokes handle_plugged_change() from the bridge
> > > > > enable and disable paths so that ASoC jack state stays in sync with
> > > > > the actual sink presence across atomic commit cycles, and not only
> > > > > on CEC HPD transitions.
> > > > > 
> > > > > Userspace audio daemons (e.g. pipewire) rely on the jack state to
> > > > > route streams, restore per-sink volume levels, and recover the last
> > > > > used device after a reconnect. Without this, those transitions are
> > > > > missed whenever the sink change is driven by a mode set rather than
> > > > > by a bare HPD event.
> > > > 
> > > > I can only hope to see mtk_hdmi to migrate to DRM_BRIDGE_OP_HDMI and
> > > > DRM_BRIDGE_OP_HDMI_AUDIO...
> > > > 
> > > > I think the correct timing was discussed several times and the overall
> > > > conclusion was that the correct time is when the actual HDMI cable is
> > > > being plugged / unplugged. See the discussion around [1] and the
> > > > captured response of Mark Brown.
> > > 
> > > Thank you for bringing this to my attention. I'll follow up on it.
> > > Meanwhile, can (independent) patch 1/2 already be merged, or at least
> > > get reviewed?
> > 
> > 
> > The discussion that I pointed to suggests that the patch is incorrect.
> 
> I understand that patch 2/2 is incorrect, but (the independent fix in)
> patch 1/2 as well?

1/2 moves plugged updates to the atomic_enable() / atomic_disable(),
which is not correct according to the discussion I pointed to.

-- 
With best wishes
Dmitry

Re: [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable

[Daniel Golle]

On Fri, May 08, 2026 at 03:14:34PM +0300, Dmitry Baryshkov wrote:
> On Fri, May 08, 2026 at 12:44:23PM +0100, Daniel Golle wrote:
> > On Fri, May 08, 2026 at 02:29:29PM +0300, Dmitry Baryshkov wrote:
> > > On Thu, May 07, 2026 at 02:32:45PM +0100, Daniel Golle wrote:
> > > > On Thu, May 07, 2026 at 12:51:56PM +0300, Dmitry Baryshkov wrote:
> > > > > On Wed, Apr 15, 2026 at 04:04:16PM +0100, Daniel Golle wrote:
> > > > > > Notify hdmi-codec of the current sink plugged state from
> > > > > > mtk_hdmi_bridge_atomic_enable() and mtk_hdmi_bridge_atomic_disable()
> > > > > > via mtk_hdmi_update_plugged_status(). This matches the pattern used
> > > > > > by dw-hdmi, which invokes handle_plugged_change() from the bridge
> > > > > > enable and disable paths so that ASoC jack state stays in sync with
> > > > > > the actual sink presence across atomic commit cycles, and not only
> > > > > > on CEC HPD transitions.
> > > > > > 
> > > > > > Userspace audio daemons (e.g. pipewire) rely on the jack state to
> > > > > > route streams, restore per-sink volume levels, and recover the last
> > > > > > used device after a reconnect. Without this, those transitions are
> > > > > > missed whenever the sink change is driven by a mode set rather than
> > > > > > by a bare HPD event.
> > > > > 
> > > > > I can only hope to see mtk_hdmi to migrate to DRM_BRIDGE_OP_HDMI and
> > > > > DRM_BRIDGE_OP_HDMI_AUDIO...
> > > > > 
> > > > > I think the correct timing was discussed several times and the overall
> > > > > conclusion was that the correct time is when the actual HDMI cable is
> > > > > being plugged / unplugged. See the discussion around [1] and the
> > > > > captured response of Mark Brown.
> > > > 
> > > > Thank you for bringing this to my attention. I'll follow up on it.
> > > > Meanwhile, can (independent) patch 1/2 already be merged, or at least
> > > > get reviewed?
> > > 
> > > 
> > > The discussion that I pointed to suggests that the patch is incorrect.
> > 
> > I understand that patch 2/2 is incorrect, but (the independent fix in)
> > patch 1/2 as well?
> 
> 1/2 moves plugged updates to the atomic_enable() / atomic_disable(),
> which is not correct according to the discussion I pointed to.

So enabling/disabling the clk there as suggested by CK Hu[1] is not
acceptable?

[1]: https://lore.kernel.org/all/effea6b19a05460371c9f6b639c5e08ab0fe1111.camel@mediatek.com/