Re: [PATCH v3] drm/bridge: dw-hdmi-qp: use drm_hdmi_acr_get_n_cts() helper for audio N/CTS

[Cristian Ciocaltea]

Hi Simon,

On 5/21/26 10:36 AM, Simon Wright wrote:
> dw_hdmi_qp_set_sample_rate() open-coded its own N and CTS lookup
> tables and search/compute helpers, but it lacked the out-of-table
> CTS fallback needed by strict HDMI sinks at TMDS rates not in the
> table.  The original LG G3 OLED audio mute (linux-rockchip 070633)
> was caused by dw_hdmi_qp_find_cts() returning 0 at 185.625 MHz,
> leaving AUDPKT_ACR_CTS_OVR_EN clear and falling back to the
> controller's internal CTS auto-measurement, which produces incorrect
> timing on the wire at out-of-table rates.
> 
> The shared drm_hdmi_acr_get_n_cts() helper in
> drivers/gpu/drm/display/drm_hdmi_helper.c already implements the
> correct behaviour: it has the HDMI 1.4b spec N/CTS tables, and for
> TMDS rates not in the table it computes CTS = (TMDS * N) / (128 * Fs)
> inline (the canonical HDMI spec formula).  It is already used by
> drivers/gpu/drm/msm/hdmi/hdmi_audio.c.
> 
> Convert dw_hdmi_qp_set_sample_rate() to call the helper.  This
> removes ~200 lines of open-coded tables and search functions
> (dw_hdmi_qp_find_n, _compute_n, _find_cts, _audio_math_diff,
> _match_tmds_n_table, common_tmds_n_table[], common_tmds_cts_table[])
> and fixes the strict-sink audio mute as a side effect of using the
> helper's complete N+CTS path.
> 
> Tested on R76S (RK3576) running Linux 7.0.1, against the LG G3 OLED
> (the sink that originally reported the mute in linux-rockchip
> 070633) at four TMDS rates spanning HDMI 1.4 and HDMI 2.0:
> 
>   TMDS         Mode              Audio with v3
>   148.5 MHz    1080p60   8-bit   plays
>   185.625 MHz  1080p60  10-bit   plays
>   297 MHz      1080p100  8-bit   plays
>   594 MHz      3840p60   8-bit   plays
> 
> Without this change, the LG G3 mutes audio at 185.625, 297, and
> 594 MHz (every rate outside dw-hdmi-qp's open-coded CTS table,
> which contained only 148.5 MHz and below).  With this change,
> drm_hdmi_acr_get_n_cts() supplies the correct CTS at every rate --
> table-canonical at 148.5 / 297 / 594 MHz, and computed via the
> HDMI 1.4b formula at 185.625 MHz.  The 148.5 MHz row is a
> regression check confirming the in-table path is unchanged.
> 
> The Kogan KALED43XU9210STA (a permissive HDMI 2.0 sink that plays
> audio at all rates with or without this change) was used as a
> no-regression control: audio plays at 594 MHz with v3 loaded.
> 
> The open-coded N table in dw-hdmi-qp included optimised N values
> for some TMDS rates that are not in the helper's table (e.g.
> various non-CEA rates between 28-162 MHz).  For those rates the
> helper's fallback returns N = 128 * Fs / 1000, which is the same
> value dw_hdmi_qp_compute_n() returned when no table optimisation
> was needed; no audio regression has been observed at the rates
> tested above.
> 
> Reported-by: Simon Wright <simon@xxxxxxxxx>
> Closes: https://lore.kernel.org/linux-rockchip/ME3P282MB21960D9D68BFF520316BDFCEA83E2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> Suggested-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx>
> Suggested-by: Jonas Karlman <jonas@xxxxxxxxx>
> Tested-by: Simon Wright <simon@xxxxxxxxx>

I think T-b can be dropped, as the commit description implies you've actually
tested this before submitting.

> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Simon Wright <simon@xxxxxxxxx>

The patch looks good to me. 

I'm unable to reproduce the reported issues, but I can confirm audio continues
to work as expected on my end.  

Feel free to include:

Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx>

Regards,
Cristian