drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks
Simon Wright
Simon at symple.nz
Thu May 7 03:39:30 PDT 2026
Hi Cristian,
Thanks for the pointer. Quick test results before writing back.
Test rig: NanoPi R76S (RK3576) on Armbian-edge mainline 7.0.1, LG G3
OLED sink (the same strict HDMI 2.1 sink that surfaced the original
audio bug). Stack: hdptx-clk-fixes v1 + frl-enable-gpios v2 patch 3/13
+ SCDC v5 patch 5 (hand-ported to v7.0; `.detect` kept instead of
`.detect_ctx` so the OOT module loads against unpatched vmlinux).
Tested-by for hdptx-clk-fixes v1: dmesg shows phy_configure /
phy_power_on / atomic_enable consistent at rate=185625000 bpc=10 with
no recalc drift -- exactly what the cover letter promises. Happy to
add the trailer to the v1 cover and any individual patch.
That said, audio still mutes at high-bpc / high-TMDS rates on the
LG G3 even with your series applied:
1080p60 8-bit (148.5 MHz): audio plays -- already worked
1080p60 10-bit (185.625 MHz): muted -- original bug regime
4K at 60 8-bit (594.0 MHz): muted -- production cast path
The "muted" rates are precisely those not in `common_tmds_cts_table[]`.
For those, `dw_hdmi_qp_find_cts()` returns 0, the override path is
skipped, and the QP IP falls back to its auto-CTS measurement -- which
the LG G3 cross-check rejects. The BSP-derived dw-hdmi-qp.c
(develop-6.6) carries an in-source comment attributing this to the
auto-circuit measuring at half the actual TMDS rate; I haven't read
that register out myself to confirm the specific value, so I can only
report that empirically the override path with explicit CTS works on
the LG G3 and the bare auto path doesn't.
The fix is to compute CTS from N when the table misses, and feed it
through the standard override path. Six lines + comment in
`dw_hdmi_qp_set_sample_rate()`, between find_cts() and set_cts_n():
/*
* When no CTS table entry exists for the given TMDS rate, compute
* CTS from N rather than relying on the IP's auto-measure path,
* which mis-measures on this controller at high TMDS rates and
* produces incorrect ACR timing on strict HDMI 2.1 sinks.
* Computed CTS = (TMDS * N) / (128 * Fs) per HDMI spec.
*/
if (!cts && n) {
u64 computed = (u64)tmds_char_rate * n;
do_div(computed, 128ULL * sample_rate);
cts = (unsigned int)computed;
}
With this on top of your series, all three regimes above play audio
cleanly -- including the 1080p 10-bit case from my original bug
report and the 4K at 60 path on our production cast rig.
That makes my earlier rate-block patch
(linux-rockchip 2026-May/070673) redundant -- I'm happy to withdraw
it on its thread once you've decided where the CTS-from-N fix should
land.
Two questions:
1. Where would you like the CTS-from-N fix? Its own small thread, a
trailer on hdptx-clk-fixes, or folded into the SCDC series --
whichever fits your workflow.
2. The kernel 7.0 announcement flagged controller-side FRL as "not
yet landed". Is that still on Collabora's roadmap, or open for me
to send a develop-6.6-derived prototype as RFC once I've ported it
to mainline? Happy to wait if you have a series in flight.
Reproducer for the audio fix is the stack above plus a small libdrm
helper to hold the mode against fbcon (modetest releases DRM master
on exit). I can share the helper if useful.
Sige5/Sige7 DTS follow-ups to your frl-enable-gpios v2 series are in
draft against the schematics; both boards are on order so I'll
validate on my own hardware before sending. I'll start a separate
thread on the v2 series for those rather than burying them here.
Thanks again -- the pointer saved a lot of parallel debug time, and
the controller-side gap was small once pinned down.
Regards,
Simon
Symple Solutions, Dunedin, New Zealand
________________________________________
From: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
Sent: Wednesday, 6 May 2026 8:01 am
To: Simon Wright <Simon at symple.nz>; linux-rockchip at lists.infradead.org <linux-rockchip at lists.infradead.org>
Cc: dri-devel at lists.freedesktop.org <dri-devel at lists.freedesktop.org>; kernel at collabora.com <kernel at collabora.com>
Subject: Re: drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks
Hi Simon,
Thanks for the detailed bug report!
I submitted a while ago a patch series [1] providing clock fixes (among others)
to samsung-hdptx PHY driver, but sadly it hasn't been merged yet.
I think this should also address your audio issue, hence please give it a try
and let me know how it goes.
Regards,
Cristian
[1] https://lore.kernel.org/all/20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com/
On 5/5/26 11:18 AM, Simon Wright wrote:
> [Resent in plain text — first attempt was rejected by the list's HTML filter.]
>
> Hi,
>
> I have tracked down a bug in dw-hdmi-qp that silences audio on strict
> HDMI 2.1 sinks (tested: LG G3 OLED) when booting with HDMI seamless
> handoff from U-Boot. HDMI 2.0 sinks are unaffected. The root cause is
> a mismatch between the AVI InfoFrame colour depth and the ACR embedded
> CTS value.
>
> Hardware tested:
> Source: ArmSoM Sige5 (Rockchip RK3576)
> Armbian-edge kernel 7.0.2 (Linux mainline v7.0 plus
> Armbian board-enable patches; not a BSP kernel)
> Failing sink: LG G3 OLED 4K (HDMI 2.1, strict embedded-CTS mode)
> Passing sink: Various HDMI 2.0 TVs (self-measuring CTS, unaffected)
>
> The bug is structural and is expected to affect RK3588 under the same
> boot sequence.
>
>
> Root cause
> ----------
>
> When the system boots with seamless handoff active, U-Boot has configured
> the PHY for 8-bit 1080p60 (TMDS = 148,500,000 Hz). The DRM connector
> state, negotiated from EDID, selects 10-bit deep colour (TMDS =
> 185,625,000 Hz). In dw_hdmi_qp_bridge_atomic_enable():
>
> hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
>
> This stores 185,625,000. The PHY ops->init() is called but the PHY is
> already running at 148,500,000 from U-Boot and is not reconfigured.
>
> The result is an inconsistency between what the sink is told over HDMI
> and what the wire actually carries:
>
> AVI InfoFrame: declares 10-bit deep colour at the connector-state
> TMDS rate (185.625 MHz)
> ACR embedded CTS: driver uses hdmi->tmds_char_rate = 185,625,000 Hz
> to compute CTS via dw_hdmi_qp_set_sample_rate(),
> producing CTS = 185,625 (internally consistent
> with the AVI declaration)
> Wire TMDS clock: PHY untouched from U-Boot, still running at
> 148,500,000 Hz (8-bit)
>
> The dmesg signature (full pr_err output, lower in this report) confirms
> both AVI and ACR are computed from the nominal 185.625 MHz value:
> "tmds=185625000 ... cts=185625".
>
> A standard HDMI 2.0 sink does not cross-check AVI against the wire TMDS
> in any way that matters for audio, so the mismatch is harmless. A strict
> HDMI 2.1 sink (LG G3) measures the wire TMDS and verifies it matches the
> AVI declaration; with declared 185.625 MHz vs measured 148.5 MHz, the
> check fails and audio is muted, permanently, until the next mode set.
>
> The N/CTS values themselves are correct CEA-861 ratios. At a wire TMDS
> of 148.5 MHz with N=6144, CTS=148,500 yields f_audio = 48 kHz; at a
> wire TMDS of 185.625 MHz with N=6144, CTS=185,625 also yields f_audio
> = 48 kHz. The driver picks one TMDS, computes a self-consistent N/CTS
> pair, and embeds it. The bug is solely that the TMDS the driver picks
> (connector-state nominal) differs from the TMDS on the wire (PHY
> actual).
>
>
> Dmesg diagnostic signature
> --------------------------
>
> Failing (seamless handoff, DRM selects 10-bit 1080p from EDID):
>
> dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
> tmds_candidate=185625000 is_hdmi=1
> DW_HDMI_QP set_sample_rate: tmds=185625000 sr=48000 n=6144 cts=185625
> [audio silent on LG G3]
>
> Working (8-bit mode forced, see workaround below):
>
> dwhdmiqp-rockchip 27da0000.hdmi: atomic_enable: \
> tmds_candidate=148500000 is_hdmi=1
> DW_HDMI_QP set_sample_rate: tmds=148500000 sr=48000 n=6144 cts=148500
> [audio working on LG G3]
>
> The difference is entirely in which tmds_char_rate bridge_atomic_enable()
> receives. If the PHY and DRM state agree (both 148.5 MHz), audio works
> because what the AVI declares matches what the wire carries. If they
> disagree (DRM: 185.625 MHz, PHY: 148.5 MHz), the AVI declares 185.625
> but the wire carries 148.5, and any sink that cross-checks the wire
> TMDS against the declared rate (e.g. LG G3 OLED) mutes audio.
>
>
> Confirmed workaround
> --------------------
>
> In dw_hdmi_qp_bridge_tmds_char_rate_valid(), reject 185,625,000 Hz:
>
> if (rate == 185625000)
> return MODE_CLOCK_HIGH;
>
> This forces DRM to select 8-bit mode (148,500,000 Hz). bridge_atomic_enable()
> then stores the correct tmds_char_rate, the AVI InfoFrame declares 8-bit,
> the ACR CTS is computed correctly, and the LG G3 produces audio.
>
> Note: 185,625,000 Hz (1080p at 60 10-bit) is only selected via EDID
> negotiation during seamless handoff. A genuine modeset at that rate would
> correctly reconfigure the PHY and the AVI/ACR inconsistency would not
> arise. Blocking this rate in tmds_char_rate_valid() therefore has no
> correct-use-case cost on RK3576 with the current BSP. 4K at 60Hz (594 MHz)
> is unaffected and continues to work correctly, including audio.
>
>
> Proposed proper fix
> -------------------
>
> The fundamental issue is that bridge_atomic_enable() accepts
> conn_state->hdmi.tmds_char_rate without verifying it against the PHY's
> actual output frequency.
>
> Option A (no display disruption):
>
> The HDPTX PHY PLL is already registered as a clock provider. On
> RK3576, rk3576.dtsi gives the hdptxphy node #clock-cells = <0>;
> VOP2 consumes it as "pll_hdmiphy0". If the bridge driver adds a
> new clk pointer (e.g. hdmi->tmds_clk) populated via
> devm_clk_get_optional() at probe and queries clk_get_rate()
> in bridge_atomic_enable(), it can detect the seamless-handoff
> mismatch and use the actual rate:
>
> /* hdmi->tmds_clk added in struct dw_hdmi_qp; populated at
> * probe via devm_clk_get_optional(dev, "tmds") or similar */
> actual_rate = hdmi->tmds_clk ? clk_get_rate(hdmi->tmds_clk) : 0;
> if (actual_rate && actual_rate != conn_state->hdmi.tmds_char_rate) {
> dev_warn(hdmi->dev,
> "seamless handoff: PHY at %lu Hz, DRM selected %llu Hz; "
> "using actual PHY rate for audio\n",
> actual_rate, conn_state->hdmi.tmds_char_rate);
> hdmi->tmds_char_rate = actual_rate;
> } else {
> hdmi->tmds_char_rate = conn_state->hdmi.tmds_char_rate;
> }
>
> This corrects the ACR CTS and AVI InfoFrame without touching the
> PHY configuration or causing a display blank.
>
> Option B (correct but causes brief blank):
>
> If the driver detects a mismatch, call phy.ops->init() to bring
> the PHY into agreement with the DRM-negotiated state. All
> parameters become consistent at the cost of a single mode change
> on first enable after seamless handoff. This is arguably the more
> correct approach if the intent is to honour what the EDID reports.
>
> Option A is preferred for a seamless user experience. Option B is
> preferable if the seamless-handoff-inherited U-Boot mode is not
> otherwise suitable for production use.
>
>
> Relation to Collabora's HDMI 2.0 patch series
> ----------------------------------------------
>
> The "Add HDMI 2.0 support to DW HDMI QP TX" series (v3, January 2026)
> addresses high-TMDS-clock-ratio and scrambling. It does not appear to
> address the seamless-handoff tmds_char_rate mismatch described here.
> If a revision of that series reads PHY state at probe time it may
> incidentally close this gap, but that is not a stated goal. Reviewers
> may wish to verify the seamless-handoff path is exercised in testing.
>
>
> Summary
> -------
>
> Bug: bridge_atomic_enable() takes EDID-negotiated
> tmds_char_rate (185,625,000) while PHY runs at U-Boot
> rate (148,500,000); the AVI InfoFrame and the ACR CTS
> both reflect the connector-state nominal value, but
> the wire TMDS clock disagrees with what AVI declares
> Symptom: audio silent on any HDMI 2.1 sink that cross-checks
> wire TMDS against the AVI declaration; HDMI 2.0 sinks
> unaffected (no such cross-check)
> Scope: RK3576 confirmed; RK3588 structurally identical
> Not a bug: N/CTS table, IEC60958 channel status, ARC, ALSA path
> Workaround: reject 185,625,000 Hz in tmds_char_rate_valid() so
> DRM picks 8-bit 1080p (148,500,000 Hz) which matches
> the actual PHY rate
> Fix: compare conn_state->hdmi.tmds_char_rate against actual
> PHY clock at bridge_atomic_enable() and use the
> measured rate when they disagree (Option A) or
> reconfigure the PHY (Option B)
>
> I am happy to test patches on Sige5 + LG G3.
>
> Regards,
> Simon
> Symple Solutions, Dunedin, New Zealand
More information about the Linux-rockchip
mailing list