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

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/