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

[Igor Paunovic <royalnet026@gmail.com>]

Hi Simon,

First RK3588 report for this patch, with register-level before and
after, both HDMI controllers driven at once:

Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588 Orange Pi 5 Plus, both HDMI controllers

Base: drm-misc-next 47b823940e38 with the HDMI 2.0 scrambling
series v11 on top. The patch needs one trivial context resolution
there (v11 still carries the open-coded tables next to its new
scrambling defines); the result is your intent verbatim, -206/+3.

Before (table code): at TMDS 297 MHz / 48 kHz the controller ran
with AUDPKT_ACR_CONTROL1 = 0, CTS_OVR_EN clear - the auto-CTS
fallback your commit message describes. Audio still played here
because both my sinks are permissive.

After (this patch), read back from AUDPKT_ACR_CONTROL0/1 while
audio was playing:

  TMDS      sink                     N     CTS      spec CTS
  297 MHz   Sony (300 MHz max)     5120   247500    247500
  594 MHz   Samsung (HF-VSDB 2.0)  6144   594000    594000

Both values land exactly on the HDMI spec numbers, CTS_OVR_EN set,
and audio is audible on both sinks simultaneously. The 594 MHz row
runs on a scrambled HDMI 2.0 link (4K60 RGB), which I believe no
one had exercised with this patch yet. Note N at 594 MHz changes
from the old table's 10240 to the helper's spec value 6144 - no
audible difference on my sinks.

Igor