Hi Cristian, > This has been tested on the following boards:
One more, with a sink pair your boards cannot cover: Tested-by: Igor Paunovic <[email protected]> # RK3588 Orange Pi 5 Plus, dual HDMI Setup: whole v11 on its stated base (drm-misc-next 47b823940e38), both SoC HDMI ports driven at once: a Samsung with HF-VSDB (max TMDS character rate 600 MHz, SCDC present) and a Sony limited to 300 MHz TMDS. 1) HDMI 2.0 path: the Samsung now offers and runs 3840x2160@60 RGB with a 594 MHz pixel clock (modetest-confirmed). Without the series the same port tops out at 4K@30. A stable picture at 594 MHz is only possible with scrambling and the 1/40 TMDS ratio active; it stayed stable across boot, mode changes and hotplug. 2) Non-2.0 fallback: the Sony keeps its 297 MHz 4K@30 modes. No regression. 3) The result I care most about: this Sony in standby keeps EDID/5V up but drops the link, and on my 7.2 stack that generates a storm of detect/modeset cycles - measured 119-194 per hour, enough to make the desktop stutter. On v11, twenty minutes of standby produced ZERO events, and wake restored both sinks by itself. Whatever share of that the cached-status detect and the SCDC-loss handling each take - thank you. 4) Hotplug on both ports: clean detach and reattach, no storms. 5) Audio on a dead link: this morning my 7.2 stack took an SError panic (regmap read in dw_hdmi_qp_bridge_clear_audio_infoframe when a PCM was closed on a link whose SCDC never came up - full UART trace available if useful). On v11 I could not reproduce the class: six open/close cycles against the standby sink plus one natural prepare-failure-then-close during replug all survived cleanly. Caveat: different base kernels, so this is not a clean A/B on the series alone. Scope: RGB output only (the YUV420 output series is separate), no USB-C DP on this base, VC4 side not exercised. Igor
