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

[Jonas Karlman]

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 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;
> +	}

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