From: Daniel Golle <daniel@makrotopia.org>
To: Chun-Kuang Hu <chunkuang.hu@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Junzhi Zhao <junzhi.zhao@mediatek.com>,
Jie Qiu <jie.qiu@mediatek.com>,
dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] drm/mediatek: hdmi: pulse audio clocks on bridge enable
Date: Wed, 15 Apr 2026 16:04:08 +0100 [thread overview]
Message-ID: <a3e22cbae528c9a38d854a586d1736b860998d41.1776265222.git.daniel@makrotopia.org> (raw)
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
next reply other threads:[~2026-04-15 15:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 15:04 Daniel Golle [this message]
2026-04-15 15:04 ` [PATCH 2/2] drm/mediatek: hdmi: report jack plugged state from bridge enable/disable Daniel Golle
2026-05-07 9:51 ` Dmitry Baryshkov
2026-05-07 13:32 ` Daniel Golle
2026-05-08 11:29 ` Dmitry Baryshkov
2026-05-08 11:44 ` Daniel Golle
2026-05-08 12:14 ` Dmitry Baryshkov
2026-05-08 12:19 ` Daniel Golle
2026-05-07 3:14 ` [PATCH 1/2] drm/mediatek: hdmi: pulse audio clocks on bridge enable Daniel Golle
2026-05-08 7:19 ` CK Hu (胡俊光)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3e22cbae528c9a38d854a586d1736b860998d41.1776265222.git.daniel@makrotopia.org \
--to=daniel@makrotopia.org \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jie.qiu@mediatek.com \
--cc=junzhi.zhao@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox