dw_hdmi_qp_find_cts() returns 0 for any TMDS character rate not present in common_tmds_cts_table[], which terminates at 148.5 MHz. In that case dw_hdmi_qp_set_sample_rate() calls dw_hdmi_qp_set_cts_n() with cts == 0, which leaves AUDPKT_ACR_CTS_OVR_EN clear and falls back to the controller's internal CTS auto-measurement.
On at least the RK3576 hdptx integration, the auto-measure path produces incorrect ACR timing on the wire at TMDS rates above the table's coverage. Strict HDMI sinks that cross-check the ACR CTS against the AVI/GCP and the actual TMDS clock then mute audio. The issue is reproducible at any rate not present in the table, and is not specific to HDMI 2.x: 1920x1080@60 with 10-bit deep colour (185.625 MHz, HDMI 1.4) is affected, as is 3840x2160@60 8-bit (594 MHz, HDMI 2.0). The driver already has the symmetric machinery for the N-table-miss case: dw_hdmi_qp_compute_n() falls back to a dynamic search via dw_hdmi_qp_audio_math_diff() ((pixel_clk * n) / (128 * freq)) when no table entry matches. The CTS path lacks the equivalent fallback. Compute CTS inline in dw_hdmi_qp_set_sample_rate() from N per the HDMI spec (CTS = TMDS * N / (128 * Fs)) when find_cts() returns 0. The standard override path then supplies the correct value on the wire instead of falling through to auto-measure. The legacy DesignWare HDMI driver (drivers/gpu/drm/bridge/synopsys/ dw-hdmi.c, hdmi_set_clk_regenerator()) computes CTS from N via the same formula when AHB or GP audio is active, so the pattern is already established within the family. Tested on R76S (RK3576) on Armbian-edge mainline 7.0.1 with Cristian Ciocaltea's hdptx-clk-fixes v1 series applied, against four sinks at four TMDS rates spanning HDMI 1.4 and HDMI 2.0: TMDS Mode In table? G3 C4 TCL Kogan 148.5 MHz 1080p60 8-bit yes audio audio audio audio 185.625 MHz 1080p60 10-bit no audio audio audio audio 297 MHz 3840p30 8-bit no audio audio audio audio 594 MHz 3840p60 8-bit no audio N/A audio audio Without this fix, all four sinks mute audio at the rates marked "no" above. With the fix, audio plays cleanly. The 148.5 MHz row is a regression check confirming the in-table path is unchanged. The LG C4 OLED's CTA-861 SVDs do not advertise 3840x2160@60 over TMDS (it is signalled FRL-only in this model's EDID), so that specific case is untestable on the C4 over the TMDS path. The same audio-path code is exercised on the C4 at 297 MHz and behaves identically to the G3. More-permissive sinks (older HDMI 2.0 TVs tested informally) play audio at all rates with or without the fix because they do not strictly cross-check ACR CTS against the TMDS clock. Reported-by: Simon Wright <[email protected]> Closes: https://lore.kernel.org/linux-rockchip/me3p282mb21960d9d68bff520316bdfcea8...@me3p282mb2196.ausp282.prod.outlook.com/ Suggested-by: Cristian Ciocaltea <[email protected]> Tested-by: Simon Wright <[email protected]> Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Simon Wright <[email protected]> --- Changes in v2: - Resend after v1 was mailer-mangled and unapplyable (reported by Luca Ceresoli). - Body split into shorter paragraphs for readability per Luca's review. - Original LG G3 report (linux-rockchip 070633) moved from inline prose to a Closes: trailer paired with Reported-by:, per Documentation/process/submitting-patches.rst. - Add Assisted-by: trailer per Documentation/process/coding-assistants.rst. - No code or test-result changes. v1: https://lore.kernel.org/linux-rockchip/[email protected]/ drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c index 0dbb1274360..b7203787057 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c @@ -461,6 +461,23 @@ static void dw_hdmi_qp_set_sample_rate(struct dw_hdmi_qp *hdmi, unsigned long lo n = dw_hdmi_qp_find_n(hdmi, tmds_char_rate, sample_rate); cts = dw_hdmi_qp_find_cts(hdmi, tmds_char_rate, sample_rate); + /* + * When no CTS table entry exists for the given TMDS rate, compute + * CTS from N rather than letting the hardware auto-measure. The + * auto-CTS circuit produces incorrect audio timing at out-of-table + * rates (e.g. 185.625 MHz, 297 MHz, 594 MHz), causing strict HDMI + * sinks to mute audio. Computed CTS = (TMDS * N) / (128 * Fs) per + * HDMI spec; the standard override path then supplies it on the + * wire. Mirrors hdmi_set_clk_regenerator() in the legacy dw-hdmi + * driver. + */ + if (!cts && n) { + u64 computed = (u64)tmds_char_rate * n; + + do_div(computed, 128ULL * sample_rate); + cts = (unsigned int)computed; + } + dw_hdmi_qp_set_cts_n(hdmi, cts, n); } base-commit: c1079aebb4de218caa86c44f9a53700d1a582683 -- 2.53.0
