Re: [PATCH] drm/bridge: dw-hdmi-qp: Compute ACR CTS for unlisted TMDS rates

[Christian Hewitt]

> On 1 Sep 2026, at 6:28 pm, Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx> wrote:
> 
> Hi,
> 
> On Tue, Sep 01, 2026 at 11:25:41AM +0000, Christian Hewitt wrote:
>> common_tmds_cts_table[] holds only six TMDS character rates (25.175,
>> 25.2, 27, 54, 74.25 and 148.5 MHz), so dw_hdmi_qp_find_cts() returns 0
>> for everything else. dw_hdmi_qp_set_cts_n() then clears the CTS override
>> enable and programs a value of 0, leaving the sink with no CTS to
>> regenerate the audio clock from.
>> 
>> Any deep colour link falls into this gap: a 10 bpc RK3576 HDMI output
>> runs at 185625000 Hz (148.5 MHz * 1.25), which is absent from both
>> tables. N is computed dynamically and comes out correct at 6144, but
>> AUDPKT_ACR_CONTROL1 reads back as 0.
>> 
>> Give CTS the same dynamic fallback that N already has, using the formula
>> from the Audio chapter of the HDMI specification, and drop the -ENOENT
>> returned into an unsigned int for the unlisted sample rates.
>> 
>> Fixes: fd0141d1a8a2a ("drm/bridge: synopsys: Add audio support for dw-hdmi-qp")
>> Assisted-by: Claude:claude-opus-5
>> Signed-off-by: Christian Hewitt <christianshewitt@xxxxxxxxx>
>> ---
>> This was found after testing unrelated patches from DetlevC that rename
>> the RK audio cards to see the impact in Kodi. RK3588 had audio output,
>> while RK3576 did not. I'd not used an RK3576 board for a while so tasked
>> Claude to help triage the problem, and this was the finding. The problem
>> appears to have been exposed since Kodi reworked plane selection logic
>> and support for 10bpc planes; earlier Kodi/LibreELEC images were using
>> 8bpc planes thus avoiding the problem.
> 
> You are looking for this series:
> 
> https://lore.kernel.org/linux-rockchip/86fcf349-0a7a-4618-9001-612371b0f71b@xxxxxxxxx/

Ahh, I missed that. I have now tested that patch (and will reply
to it with a TB) so please ignore this patch. Thanks!

Christian