1. Patchew
  2. linux
  3. View series

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

Simon Wright posted 1 patch 4 days, 14 hours ago 
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
[PATCH v2] drm/bridge: dw-hdmi-qp: compute audio CTS from N when not in TMDS table
Posted by Simon Wright 4 days, 14 hours ago 
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 <simon@symple.nz>
Closes: https://lore.kernel.org/linux-rockchip/ME3P282MB21960D9D68BFF520316BDFCEA83E2@ME3P282MB2196.AUSP282.PROD.OUTLOOK.COM/
Suggested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Simon Wright <simon@symple.nz>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Simon Wright <simon@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
Re: [PATCH v2] drm/bridge: dw-hdmi-qp: compute audio CTS from N when not in TMDS table
Posted by Jonas Karlman 4 days, 14 hours ago 
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 <simon@symple.nz>
> Closes: https://lore.kernel.org/linux-rockchip/ME3P282MB21960D9D68BFF520316BDFCEA83E2@ME3P282MB2196.AUSP282.PROD.OUTLOOK.COM/
> Suggested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> Tested-by: Simon Wright <simon@symple.nz>
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Simon Wright <simon@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
Re: [PATCH v2] drm/bridge: dw-hdmi-qp: compute audio CTS from N when not in TMDS table
Posted by Simon Wright 3 days, 16 hours ago 
On 20/05/2026 9:38 pm, Jonas Karlman wrote:
> Could this function instead be converted to use the helper
> drm_hdmi_acr_get_n_cts() to lookup/calculate the n and cts value?

Done in v3:

https://lore.kernel.org/linux-rockchip/86fcf349-0a7a-4618-9001-612371b0f71b@symple.nz/

Re-tested on the LG G3 OLED (the original reporting sink) at
148.5 / 185.625 / 297 / 594 MHz; audio plays at all four.  v3
also drops ~200 lines of open-coded N/CTS tables and search
functions that the helper makes redundant.

Simon

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.