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 <[email protected]> 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@60 bpc=10 (185.625 MHz, the original-bug regime -- requires max_bpc=10 set on the connector property), 3840x2160@30 8-bit (297 MHz), and 3840x2160@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 <[email protected]> Sent: Friday, 8 May 2026 6:03 am To: Simon Wright <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> 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@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
