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 <[email protected]> > Closes: > https://lore.kernel.org/linux-rockchip/me3p282mb21960d9d68bff520316bdfcea8...@me3p282mb2196.ausp282.prod.outlook.com/ > Suggested-by: Cristian Ciocaltea <[email protected]> > Suggested-by: Jonas Karlman <[email protected]> > Tested-by: Simon Wright <[email protected]>
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 <[email protected]> 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 <[email protected]> Tested-by: Cristian Ciocaltea <[email protected]> Regards, Cristian
