[PATCH v2] drm/bridge: dw-hdmi-qp: compute audio CTS from N when not in TMDS table

[Simon Wright]

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 at 60 with 10-bit deep colour
(185.625 MHz, HDMI 1.4) is affected, as is 3840x2160 at 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 at 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 <simon at symple.nz>
Closes: https://lore.kernel.org/linux-rockchip/ME3P282MB21960D9D68BFF520316BDFCEA83E2@ME3P282MB2196.AUSP282.PROD.OUTLOOK.COM/
Suggested-by: Cristian Ciocaltea <cristian.ciocaltea at collabora.com>
Tested-by: Simon Wright <simon at symple.nz>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Simon Wright <simon at symple.nz>
---
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/92aa4191-2a2a-41e3-badb-c0a5b1fbb957@symple.nz/

 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