Hi Simon, On 5/20/2026 11:10 AM, Simon Wright wrote: > 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; > + }
Could this function instead be converted to use the helper drm_hdmi_acr_get_n_cts() to lookup/calculate the n and cts value? At first glance it looks to produce same/similar values as this driver tries to do open-coded. Regards, Jonas > + > dw_hdmi_qp_set_cts_n(hdmi, cts, n); > } > > > base-commit: c1079aebb4de218caa86c44f9a53700d1a582683
