drm/rockchip: vop2: ACLK_VOP pinned at 500 MHz starves DP 4K120 on RK3588

[Igor Paunovic <royalnet026@gmail.com>]

Hello,

On RK3588 the VOP2 AXI clock is pinned to 500 MHz by device tree and
nothing in mainline ever raises it.  For DisplayPort at 3840x2160@120
that is not enough bandwidth, and the failure is not graceful: the
video port floods POST_BUF_EMPTY interrupts and the picture is
corrupted.

I mentioned this in passing when I sent a Tested-by for the dw-dp v11
series:
https://lore.kernel.org/all/20260808094138.7205-1-royalnet026@gmail.com/

The pin is explicit.  In arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
the cru node lists <&cru ACLK_VOP> in assigned-clocks with 500000000 in
the matching position of assigned-clock-rates.  It is a deliberate
assignment rather than a boot default, and it is identical in mainline
and in the Collabora rockchip-devel branch.

The rate request does propagate.  ACLK_VOP is registered as a gate with
flags 0 in clk-rk3588.c, but drivers/clk/rockchip/clk.c adds
CLK_SET_RATE_PARENT for every branch_gate, so a request on aclk_vop
travels up through aclk_vop_sub_src (a mux carrying the same flag) to
aclk_vop_root, which is a settable composite.

What I measured, on an Orange Pi 5 Plus driving a DP monitor over USB-C
Alt Mode at 3840x2160@120 (YCbCr 4:2:0, so dclk sits at 594 MHz), on
drm-misc-next of 2026-08-07 (dc2f9f7fed1a) plus the dw-dp v11 and usbdp
v13 series.  I built with CLOCK_ALLOW_WRITE_DEBUGFS and changed the
rate by writing aclk_vop_root's clk_rate in clock debugfs, one level
up, which has the same effect.  The mode was unchanged across all three
phases, so dclk stayed at 594 MHz and the AXI rate was the only thing
that moved:

  500 MHz:  vop2_isr reported ~594000 suppressed callbacks per 5 s,
            roughly 119k interrupts per second, all POST_BUF_EMPTY on
            the DP video port; picture unusable
  750 MHz:  no POST_BUF_EMPTY logged at all for 42 s, the whole phase;
            the picture became correct the moment the write landed
  500 MHz:  ~607000 suppressed callbacks per 5 s; broken again

Both transitions are immediate, and the timestamps line up with the
phases of my test script.

Everything I can drive up to 2560x1440@144 (about 586 MHz pixel clock)
stays clean at 500 MHz; 3840x2160@120 (1188 MHz) does not.  That
comparison comes from a mode sweep on my rockchip-devel based daily
kernel rather than from the run above, and my monitor offers nothing in
between, so I cannot bisect the threshold.

In mainline rockchip_drm_vop2.c there is no clk_set_rate() on the VOP
aclk at all; the only clk_set_rate() in the file is on vp->dclk.  To
reproduce: enable dp0 on an RK3588 board - it is disabled in the
mainline DTS, so this needs a board DT change - drive a DP monitor at
3840x2160@120, and watch dmesg or the vop interrupt count in
/proc/interrupts.

The only code I know of that raises the rate is a commit in the
Collabora rockchip-devel branch, "drm/rockchip: vop2: Scale ACLK rate
up for RK3588 FRL display modes" by Cristian Ciocaltea.  It defines a
750 MHz rate and calls clk_set_rate() from vop2_crtc_atomic_enable()
and _disable(), gated on vcstate->frl_enabled with a refcount over the
video ports.  I could not find it on lore, but I may well have missed
it.

If that is the intended shape of the fix, DisplayPort still would not
benefit: frl_enabled is set only by dw_hdmi_qp-rockchip.c, and neither
dw-dp.c nor dw_dp-rockchip.c mentions FRL at all, so the condition is
HDMI specific while the bandwidth problem is not.  It also explains
what I had been seeing since I enabled dp0 on this board last week:
4K120 over USB-C only worked while an HDMI output happened to be
running in FRL mode.

Raising the DT rate to 750 MHz unconditionally would be simpler, but it
would cost power on boards that never drive such a mode, which is
presumably the reason for making it dynamic.

Cristian, Heiko - hence my question: should the ACLK rate be derived
from the bandwidth the enabled video ports actually need, rather than
from an HDMI-specific link flag?  A per-video-port requirement combined
with max() across the active ports would cover DP and HDMI under one
rule and would not need a refcount.

I am happy to prepare a patch along those lines if that is the right
direction.

Igor Paunovic

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip