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

[Cristian Ciocaltea <cristian.ciocaltea@collabora.com>]

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

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip