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

["CK Hu (胡俊光)" <ck.hu@mediatek.com>]

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
>