drm/bridge: dw-hdmi-qp: seamless handoff sets wrong tmds_char_rate, breaking audio on strict HDMI 2.1 sinks

Thu May 7 22:53:45 PDT 2026

Hi Cristian,

Thanks for the pointers -- I should have checked rockchip-devel
before the previous reply. Three things to clean up:

* Sige5 in linux-next and Sige7 in rockchip-devel both match what I'd
  derived from the schematics -- dropping the DTS follow-ups I had
  drafted.

* Your FRL work in rockchip-devel supersedes the BSP-derived prototype
  I was going to port. Standing down on that; happy to Tested-by the
  series once it's posted.

* Acknowledged on the HDMI 1.4 vs 2.x framing.

Tested-by: Simon Wright <simon at symple.nz>

Heiko, Vinod -- any chance hdptx-clk-fixes v1 can be applied? It
cleanly addresses the high-bpc rate recalculation and uncommitted PHY
config issues on RK3576 hdptx, and Tested-by results on real hardware
(R76S + LG G3 OLED) match the cover letter.

Reproducer for the audio mute:

  1. mainline 7.0 + hdptx-clk-fixes v1 applied (or rockchip-devel HEAD
     -- same code path).
  2. Sink that doesn't tolerate incorrect ACR CTS values -- LG G3 OLED
     is the canonical case, LG C4 OLED behaves identically. More-
     permissive sinks play audio regardless and won't surface the bug.
  3. Set a mode whose tmds_char_rate is NOT in common_tmds_cts_table[].
     Affected rates we tested: 1920x1080 at 60 bpc=10 (185.625 MHz, the
     original-bug regime -- requires max_bpc=10 set on the connector
     property), 3840x2160 at 30 8-bit (297 MHz), and 3840x2160 at 60 8-bit
     (594 MHz).
  4. The mode must be held for the duration of the audio test --
     `modetest -s` releases DRM master on exit and fbcon reverts to
     an in-table mode, which would explain audio playing in your
     test path.
  5. speaker-test -D hw:0,0 -c 2 -t sine -f 440 -- mutes without the
     fix, plays with it.

I'll send the CTS-from-N change as a separate patch against
rockchip-devel, and withdraw the rate-block patch
(linux-rockchip 2026-May/070673) once it's accepted in some form.

Regards,
Simon
Symple Solutions, Dunedin, New Zealand

________________________________________
From: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
Sent: Friday, 8 May 2026 6:03 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,

On 5/7/26 1:39 PM, Simon Wright wrote:
> 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.

Please provide the trailer and maybe also a kind reminder for the maintainers to
get the series applied.. :-)

>
> 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.

Nice catch, will try to reproduce this on my end.

Regardless, the fix should be submitted as a separate patch, as it's not
(directly) related to any of the existing serieses posted on ML.
I.e. you mentioned "... mis-measures on this controller at high TMDS rates", but
the 1080p60 10-bit (185.625 MHz) use case falls under HDMI 1.4, hence the
problem doesn't seem to be limited to HDMI 2.x.

>
> Two questions:
>
> 1. Where would you like the CTS-from-N fix? Its own small thread,

Yep, dedicated submission, per the above.

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

Yes, I'm currently preparing a new revision of the HDMI 2.0 patchset, then I
will focus on the HDMI 2.1 FRL support. The latest version of these patches is
already available in our rockchip-devel branch, which contains all the
necessary dependencies:

 https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rockchip-devel?ref_type=heads

> , 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.

Yes, please detail the reproducer steps.  So far, I've only tried playing audio
using speaker-test while switching the modes via modetest and it works as
expected.

>
> 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.

That series has been applied and is available in linux-next since next-20260506.
It also handles the rk3576-armsom-sige5 board, do you need anything else for
this particular one?

Regards,
Cristian