Hi,

On Tue, Sep 01, 2026 at 09:50:24PM +0300, Cristian Ciocaltea wrote:
> Enable HDMI 2.0 display modes (e.g. 4K@60Hz) on the Synopsys DW HDMI QP
> TX controller, as found in Rockchip RK3576 & RK3588 SoCs, by adding SCDC
> management for high TMDS clock ratio and scrambling.  Since SCDC state
> is lost on sink disconnects, the bridge driver needs to trigger a CRTC
> reset during connector detection.
> 
> To support this at the DRM infrastructure level, the series first
> introduces the HDMI version enum, then prepares for changing the
> signature of drmm_connector_hdmi_init(), i.e. dropping the vendor,
> product, supported_formats and max_bpc arguments, which are being moved
> into struct drm_connector_hdmi_funcs, by temporarily renaming the helper
> to drmm_connector_hdmi_ini2().  This lets the new signature be
> introduced under the original name while callers are converted
> incrementally.  Note the transitional name matches the original's length
> so continuation-line arguments stay aligned to the opening parenthesis,
> keeping the diff to the identifier itself and avoiding re-alignment
> churn.
> 
> Appending more HDMI-specific arguments to the init function would not
> scale well, hence the hdmi_funcs struct is extended with new fields:
> supported_hdmi_ver, supported_tmds_char_rate.  These are used to
> infer and/or limit the maximum TMDS character rate permitted for the
> connector.
> 
> Patches 6-11 build the connector and bridge scrambling infrastructure on
> top: the connector scrambler callbacks/flags, the scdc-helper
> additions (connector-prefixed debug macro and SCDC version helper), and
> the HDMI scrambling management helpers including SCDC source-version
> advertisement.
> 
> Patches 12-25 wires this up through the hdmi-state-helper and bridge
> connector layers: source TMDS rate validation, hotplug SCDC state sync
> and the scrambling requirement, new source-side scrambling bridge ops,
> the switch to a cached-status, atomic-aware .detect_ctx() connector
> helper, and finally hooking up the HDMI 2.0 scrambler callbacks.
> 
> The SCDC scrambling feature itself is implemented in the DW HDMI QP
> bridge driver, alongside i2c error-message rate limiting,
> .enable_hpd()/.disable_hpd() PHY ops and a dw_hdmi_qp_hpd_notify()
> helper (patches 26-30).
> 
> Patches 31-41 cover the Rockchip platform driver and HPD handling: bug
> fixes, minor cleanups, avoiding spurious HDP IRQ wakeups, masking the
> RK3576 HPD IRQ in io_init, implementing the .{enable|disable}_hpd() PHY
> ops, switching HPD reports to dw_hdmi_qp_hpd_notify() to restrict events
> to the affected connector, dropping the now-unused .setup_hpd() PHY op.
> 
> Patches 42-48 convert VC4 HDMI to the common infrastructure as a proof
> of reuse: adopting the shared TMDS char rate constants, switching to
> drm_hdmi_mode_needs_scrambling() and force_ctx(), proper -EDEADLK
> handling, and replacing the driver-local scrambling implementation with
> the common SCDC scrambling helpers.
> 
> Patches 50-57 advertise supported version for all HDMI
> connectors/bridges, except the MediaTek HDMI driver (for now), as it
> requires non-trivial changes: there's a core library shared between two
> drivers, one being HDMI 2.0 compliant.
> 
> Patches 58-67 add KUnit tests: HDMI caps-based init coverage and
> source-side scrambler validation for the connector, conversion of
> hdmi_state_helper to the new drmm_connector_hdmi_init() with
> max_tmds_char_rate validation, a new 4K@60Hz 600MHz TMDS EDID,
> source-side scrambling decision coverage, and conformity fixes for the
> existing 1080p+4K YUV420 200MHz and 4K RGB/YUV 340MHz test EDID blobs.
> 
> Patches 68-71 remove the now unused drmm_connector_hdmi_ini2() helper
> and redundant hdmi fields from connector structs: vendor, product,
> supported_formats and max_bpc.
> 
> Eventually patches 72-74 consolidate SPD InfoFrame handling of
> vendor/product.
> 
> This has been tested on the following boards:
> 
> * Radxa ROCK 5B (RK3588)
> * Radxa ROCK 4D (RK3576)
> * Raspberry Pi 5 Model B Rev 1.1 (BCM2712 D0)

This series is getting a bit insane. You have preliminary patches that
have been reviewed/acked already, you should merge them, and possibly
split the rest into preliminary series.

Maxime