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

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

[Igor Paunovic]

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

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

[Cristian Ciocaltea]

Hi Igor,

On 8/8/26 1:42 PM, Igor Paunovic wrote:
> 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.

I haven't submitted that yet; it's part of a work-in-progress FRL enablement
patchset that's currently blocked on the HDMI 2.0 support series [1], still
under review upstream.

> 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.

Yes.

> 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.

Unfortunately, deriving ACLK purely from bandwidth wouldn't suffice as a general
solution for HDMI. FRL and TMDS overlap for certain display modes, and hardware
may impose its own limits on max TMDS character rate and/or supported min/max
FRL bandwidth - so the same mode can map to different ACLK requirements
depending on which link type is used. 

Later, we might want to support user-prioritization of FRL over TMDS, even for
modes that TMDS could otherwise handle cleanly. Since FRL uses fixed rates
regardless of the active display mode, ACLK can't be reliably inferred from the
mode alone for HDMI.

DP may still follow a bandwidth-derived max() rule, though I haven't been
personally involved in the DP use-case. I recall Alexey (added to CC) mentioning
additional issues with PLL rates on RK3576, I think [2] is the most recent one. 

Cheers,
Cristian

[1] https://lore.kernel.org/all/20260731-dw-hdmi-qp-scramb-v10-0-294364b2cf15@collabora.com/
[2] https://lore.kernel.org/all/CAKTNdwFPhVrjb4iVpN19f0Nw+MA_BxXLOLs4V50fuyf+_rbEPg@mail.gmail.com

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

[Chaoyi Chen]

Hello Cristian, Igor,

On 8/10/2026 11:36 PM, Cristian Ciocaltea wrote:
> Hi Igor,
> 
> On 8/8/26 1:42 PM, Igor Paunovic wrote:
>> 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.
> 
> I haven't submitted that yet; it's part of a work-in-progress FRL enablement
> patchset that's currently blocked on the HDMI 2.0 support series [1], still
> under review upstream.
> 
>> 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.
> 
> Yes.
> 
>> 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.
> 
> Unfortunately, deriving ACLK purely from bandwidth wouldn't suffice as a general
> solution for HDMI. FRL and TMDS overlap for certain display modes, and hardware
> may impose its own limits on max TMDS character rate and/or supported min/max
> FRL bandwidth - so the same mode can map to different ACLK requirements
> depending on which link type is used. 
> 
> Later, we might want to support user-prioritization of FRL over TMDS, even for
> modes that TMDS could otherwise handle cleanly. Since FRL uses fixed rates
> regardless of the active display mode, ACLK can't be reliably inferred from the
> mode alone for HDMI.
> 
> DP may still follow a bandwidth-derived max() rule, though I haven't been
> personally involved in the DP use-case. I recall Alexey (added to CC) mentioning
> additional issues with PLL rates on RK3576, I think [2] is the most recent one.

In my opinion, POST BUF EMPTY has nothing to do with the display
interface actually being used, but rather relates to the plane you
are actually using.

For example, when using DP at 4K@120, we can perfectly well use a
lower ACLK with a smaller 1080P plane without encountering the POST
BUF EMPTY issue. Similarly, when using 4K@60, if multiple 4K ARGB
planes are displayed simultaneously, we may encounter the same issue 
as well.

> 
> Cheers,
> Cristian
> 
> [1] https://lore.kernel.org/all/20260731-dw-hdmi-qp-scramb-v10-0-294364b2cf15@collabora.com/
> [2] https://lore.kernel.org/all/CAKTNdwFPhVrjb4iVpN19f0Nw+MA_BxXLOLs4V50fuyf+_rbEPg@mail.gmail.com
> 
> 

-- 
Best, 
Chaoyi

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

[Igor Paunovic]

Hi Chaoyi, Cristian,

Chaoyi, your reading fits my own measurements better than mine did.

The link in that test was running YCbCr 4:2:0, so dclk sat at 594 MHz
for a 3840x2160@120 mode - the interface rate was the cheap part. What
was not cheap was what the video port had to compose: a single
full-screen 3840x2160 ARGB plane at 120 Hz. So the case I reported is
one where the interface was modest and the composition was not, which
is the direction you are pointing in. I framed it as a DisplayPort
problem because DisplayPort was the only thing I changed; that was the
wrong axis.

I should say what this bears on directly, because it is not
hypothetical for me. I have a patch here that I have not sent, which
replaces the frl_enabled condition with a threshold on the pixel clock:

  static bool vop2_needs_aclk_boost(struct drm_crtc_state *crtc_state)
  {
      return vcstate->frl_enabled ||
             crtc_state->adjusted_mode.crtc_clock > VOP2_HIGH_BW_PIXCLK_KHZ;
  }

with VOP2_HIGH_BW_PIXCLK_KHZ at 1000000, so that any video port needing
the bandwidth can ask for the higher rate. It also guards the refcount
on the way, since atomic_disable() runs for ports that were never
enabled and the counter is unsigned. It is written against the
rockchip-devel branch, on top of the commit Cristian mentions, and I
was holding it back until I had a threshold I could defend.

Your reply says the quantity I keyed it on is the wrong one, and I
cannot argue against that from my own data. The measurement the
threshold came from is that at 500 MHz a 2560x1440@144 mode stays clean
while 3840x2160@120 does not. But in both cases the port was composing
a single full-screen plane at the mode's own resolution, so mode and
composition moved together and the comparison cannot separate them. If
the rule belongs in terms of what the port composes, then the pixel
clock is at best a proxy that happens to fit the two points I have.

I would rather learn that before sending the patch than after. Two
things I can run here:

  - your first case: hold 3840x2160@120 on DP, leave ACLK at 500 MHz,
    and scan out a 1080p plane instead of the full-screen one. If that
    comes up clean, the pixel clock is not the variable and the patch
    as written is keyed on the wrong thing.

  - your second case: a modest mode with several 4K ARGB planes
    composed at once. I can drive that over HDMI, without the USB-C
    adapter in the path, so it is a cleaner test than the first.

Is there a form of the condition you would consider correct? What your
description suggests to me is something derived from the composed pixel
rate summed over a video port's enabled planes, with max() across the
active ports rather than a refcount - but you know what the hardware
actually stalls on, and I am inferring it from an interrupt counter.

Cristian, understood on HDMI. If FRL and TMDS can serve the same mode
at different fixed rates, the mode cannot determine the rate on its own
and a bandwidth rule cannot be the whole story there. That answers what
I asked. Whatever shape this ends up taking should keep working for the
FRL case you already handle rather than replace it.

One thing worth carrying across from the dw-dp v11 thread, since not
everyone on this Cc list is on that one. Heiko reported that on his 4K
display he gets no output at all at the stock rate, and some output
after raising ACLK_VOP to 750 MHz, although that output is garbled:

  https://lore.kernel.org/all/20767137.geO5KgaWL5@diego/

So the starvation reproduces on hardware other than mine, which until
now I could not tell apart from a fault in my adapter. The garbling at
750 MHz is not something I see here - the picture was correct the
moment the write landed and stayed correct - so that looks like a
separate problem, and I have replied to him on that thread rather than
fold it into this one.

Igor

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

[Chaoyi Chen]

Hi Igor,

On 8/12/2026 5:23 AM, Igor Paunovic wrote:
> Hi Chaoyi, Cristian,
> 
> Chaoyi, your reading fits my own measurements better than mine did.
> 
> The link in that test was running YCbCr 4:2:0, so dclk sat at 594 MHz
> for a 3840x2160@120 mode - the interface rate was the cheap part. What
> was not cheap was what the video port had to compose: a single
> full-screen 3840x2160 ARGB plane at 120 Hz. So the case I reported is
> one where the interface was modest and the composition was not, which
> is the direction you are pointing in. I framed it as a DisplayPort
> problem because DisplayPort was the only thing I changed; that was the
> wrong axis.
> 
> I should say what this bears on directly, because it is not
> hypothetical for me. I have a patch here that I have not sent, which
> replaces the frl_enabled condition with a threshold on the pixel clock:
> 
>   static bool vop2_needs_aclk_boost(struct drm_crtc_state *crtc_state)
>   {
>       return vcstate->frl_enabled ||
>              crtc_state->adjusted_mode.crtc_clock > VOP2_HIGH_BW_PIXCLK_KHZ;
>   }
> 
> with VOP2_HIGH_BW_PIXCLK_KHZ at 1000000, so that any video port needing
> the bandwidth can ask for the higher rate. It also guards the refcount
> on the way, since atomic_disable() runs for ports that were never
> enabled and the counter is unsigned. It is written against the
> rockchip-devel branch, on top of the commit Cristian mentions, and I
> was holding it back until I had a threshold I could defend.
> 
> Your reply says the quantity I keyed it on is the wrong one, and I
> cannot argue against that from my own data. The measurement the
> threshold came from is that at 500 MHz a 2560x1440@144 mode stays clean
> while 3840x2160@120 does not. But in both cases the port was composing
> a single full-screen plane at the mode's own resolution, so mode and
> composition moved together and the comparison cannot separate them. If
> the rule belongs in terms of what the port composes, then the pixel
> clock is at best a proxy that happens to fit the two points I have.
> 
> I would rather learn that before sending the patch than after. Two
> things I can run here:
> 
>   - your first case: hold 3840x2160@120 on DP, leave ACLK at 500 MHz,
>     and scan out a 1080p plane instead of the full-screen one. If that
>     comes up clean, the pixel clock is not the variable and the patch
>     as written is keyed on the wrong thing.
> 
>   - your second case: a modest mode with several 4K ARGB planes
>     composed at once. I can drive that over HDMI, without the USB-C
>     adapter in the path, so it is a cleaner test than the first.
> 
> Is there a form of the condition you would consider correct? What your
> description suggests to me is something derived from the composed pixel
> rate summed over a video port's enabled planes, with max() across the
> active ports rather than a refcount - but you know what the hardware
> actually stalls on, and I am inferring it from an interrupt counter.
> 

In fact, this is similar to what we do in the downstream kernel. 
The complete decision flow is as follows[0]:

if (vop_bw_info->plane_num_4k || crtc_num > 1 ||
	crtc->state->adjusted_mode.crtc_hdisplay > 2560 ||
	crtc->state->adjusted_mode.crtc_vdisplay > 2560 ||
	linedur_ns < 7500) {/* 4kp60 linedur_ns roughly equal to 7500 ns */
	
	/* set aclk to 750M */
	funcs->set_aclk(crtc, ROCKCHIP_VOP_ACLK_ADVANCED_MODE, vop_bw_info);
	priv->aclk_adjust_frame_num = 2;
}

I think the condition above should be equivalent to the
"linedur_ns < 7500" here :)

[0]: https://github.com/rockchip-linux/kernel/blob/develop-6.6/drivers/gpu/drm/rockchip/rockchip_drm_fb.c#L204


> Cristian, understood on HDMI. If FRL and TMDS can serve the same mode
> at different fixed rates, the mode cannot determine the rate on its own
> and a bandwidth rule cannot be the whole story there. That answers what
> I asked. Whatever shape this ends up taking should keep working for the
> FRL case you already handle rather than replace it.
> 
> One thing worth carrying across from the dw-dp v11 thread, since not
> everyone on this Cc list is on that one. Heiko reported that on his 4K
> display he gets no output at all at the stock rate, and some output
> after raising ACLK_VOP to 750 MHz, although that output is garbled:
> 
>   https://lore.kernel.org/all/20767137.geO5KgaWL5@diego/
> 
> So the starvation reproduces on hardware other than mine, which until
> now I could not tell apart from a fault in my adapter. The garbling at
> 750 MHz is not something I see here - the picture was correct the
> moment the write landed and stayed correct - so that looks like a
> separate problem, and I have replied to him on that thread rather than
> fold it into this one.
> 
> Igor
> 
> 

-- 
Best, 
Chaoyi

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

[Igor Paunovic]

Hi Chaoyi,

That is exactly what I was missing, thank you. Having the vendor's
decision flow meant I could stop guessing and go measure the case where
my rule and yours disagree. I have done that now, and the result is
worth more than my earlier argument was.

First, on equivalence: I do not think my threshold is equivalent to the
linedur_ns term - it is strictly narrower. With
linedur_ns = crtc_htotal * 1000000 / crtc_clock, and htotal 4400 for the
4K modes my panel offers:

  3840x2160@120  1188000 kHz   linedur_ns 3703
  3840x2160@60    594000 kHz   linedur_ns 7407
  2560x1440@144  ~586000 kHz   linedur_ns ~4600-4700

My VOP2_HIGH_BW_PIXCLK_KHZ of 1000000, at htotal 4400, is the same as
saying linedur_ns < 4400 - about 1.7x stricter than your 7500. So my
rule declines to boost in cases where yours boosts, and 3840x2160@60 is
one of them: your rule raises it on two counts (crtc_hdisplay > 2560 and
linedur_ns 7407 < 7500), mine does not raise it at all.

So I measured that case. I unplugged both HDMI cables, leaving the
DisplayPort output as the only display, and switched it between
3840x2160@120 and 3840x2160@60, reading aclk_vop and dclk_vop2 from
clk_summary at each point:

                        4K120 (YCbCr 4:2:0)      4K60
  dclk_vop2             594 MHz                  594 MHz
  aclk_vop              750 MHz                  500 MHz
  vop interrupts/s      120                      60
  POST_BUF_EMPTY        0                        0, over 60 s

The dclk is identical in the two states, because the 4K120 link runs
YCbCr 4:2:0 and the 4K60 link does not. The interface rate did not move
at all. What moved was what the video port composes - a full-screen 4K
ARGB plane at 120 Hz versus the same plane at 60 Hz - and the AXI clock.
That is the separation I told you I could not make from my earlier data,
where mode and composition moved together. The interrupt counts are one
vblank per frame in both states, so there is no starvation at either
point.

3840x2160@60 is therefore clean at ACLK 500 MHz with a full-screen 4K
plane. For that case the downstream rule boosts and does not need to.

Putting all four points I now have in terms of composed pixels per ACLK
cycle:

  3840x2160@120   995.3 Mpx/s   500 MHz   1.99   storms (116630 irq/s)
  3840x2160@120   995.3 Mpx/s   750 MHz   1.33   clean
  2560x1440@144   530.8 Mpx/s   500 MHz   1.06   clean
  3840x2160@60    497.7 Mpx/s   500 MHz   1.00   clean

The boundary sits between 1.33 and 1.99. That quantity does not depend
on the connector or on the pixel format, which is what I think you were
pointing me at, and it fits every point I have rather than the two I
started from.

The honest limit of this: all four are a single full-screen plane on a
single video port. They say nothing about plane_num_4k or crtc_num > 1,
which are exactly the terms my condition has no counterpart for. I am
not proposing to drop your terms - I am saying the two mode-derived ones
appear to carry margin for this shape of workload, and I would rather
ask than assume.

The other thing I had not appreciated is where the decision lives.
rockchip_drm_aclk_adjust() runs from atomic_commit_tail, so it is
re-evaluated on every commit with that commit's plane information, and
aclk_adjust_frame_num holds the boost for two more commits on the way
down. My unsent patch puts the decision in vop2_crtc_atomic_enable() and
_disable(), which only run on modeset. A condition that depends on what
the planes are composing cannot live there: a client swapping a 1080p
plane for a 4K one without a modeset would never be seen. So the
placement has to change, not just the condition.

Two things I would still rather learn than guess:

  - Is the two-commit hold on the way down a hardware requirement - the
    rate has to be up before the frame that needs it and stay up for a
    beat after - or is it belt and braces? It decides whether an
    upstream version needs the same hysteresis.

  - Are the mode-derived terms describing something the hardware stalls
    on, or are they a conservative stand-in for "this is probably a
    heavy scene"? My 4K60 and 1440p144 points only make sense to me
    under the second reading.

I will rewrite the patch along the lines of your flow rather than the
pixel-clock threshold, and move the decision to the commit path. For
what it is worth, the version I have been running locally since 7 August
has driven 3840x2160@120 HDR over DisplayPort with no HDMI output
present at all, which is the case the FRL-gated condition cannot serve;
it also drops the rate back to 500 MHz on modeset and restores it, so
the refcount side behaves.

Thanks again - this turned a guess into a measurement.

Igor

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

[Chaoyi Chen]

Hi Igor,

On 8/12/2026 4:38 PM, Igor Paunovic wrote:
> Hi Chaoyi,
> 
> That is exactly what I was missing, thank you. Having the vendor's
> decision flow meant I could stop guessing and go measure the case where
> my rule and yours disagree. I have done that now, and the result is
> worth more than my earlier argument was.
> 
> First, on equivalence: I do not think my threshold is equivalent to the
> linedur_ns term - it is strictly narrower. With
> linedur_ns = crtc_htotal * 1000000 / crtc_clock, and htotal 4400 for the
> 4K modes my panel offers:
> 
>   3840x2160@120  1188000 kHz   linedur_ns 3703
>   3840x2160@60    594000 kHz   linedur_ns 7407
>   2560x1440@144  ~586000 kHz   linedur_ns ~4600-4700
> 
> My VOP2_HIGH_BW_PIXCLK_KHZ of 1000000, at htotal 4400, is the same as
> saying linedur_ns < 4400 - about 1.7x stricter than your 7500. So my
> rule declines to boost in cases where yours boosts, and 3840x2160@60 is
> one of them: your rule raises it on two counts (crtc_hdisplay > 2560 and
> linedur_ns 7407 < 7500), mine does not raise it at all.
> 

Ah, that's close. What I want to say is that it has a direct
correlation with dclk and resolution.

> So I measured that case. I unplugged both HDMI cables, leaving the
> DisplayPort output as the only display, and switched it between
> 3840x2160@120 and 3840x2160@60, reading aclk_vop and dclk_vop2 from
> clk_summary at each point:
> 
>                         4K120 (YCbCr 4:2:0)      4K60
>   dclk_vop2             594 MHz                  594 MHz
>   aclk_vop              750 MHz                  500 MHz
>   vop interrupts/s      120                      60
>   POST_BUF_EMPTY        0                        0, over 60 s
> 
> The dclk is identical in the two states, because the 4K120 link runs
> YCbCr 4:2:0 and the 4K60 link does not. The interface rate did not move
> at all. What moved was what the video port composes - a full-screen 4K
> ARGB plane at 120 Hz versus the same plane at 60 Hz - and the AXI clock.
> That is the separation I told you I could not make from my earlier data,
> where mode and composition moved together. The interrupt counts are one
> vblank per frame in both states, so there is no starvation at either
> point.
> 
> 3840x2160@60 is therefore clean at ACLK 500 MHz with a full-screen 4K
> plane. For that case the downstream rule boosts and does not need to.
> 
> Putting all four points I now have in terms of composed pixels per ACLK
> cycle:
> 
>   3840x2160@120   995.3 Mpx/s   500 MHz   1.99   storms (116630 irq/s)
>   3840x2160@120   995.3 Mpx/s   750 MHz   1.33   clean
>   2560x1440@144   530.8 Mpx/s   500 MHz   1.06   clean
>   3840x2160@60    497.7 Mpx/s   500 MHz   1.00   clean
> 
> The boundary sits between 1.33 and 1.99. That quantity does not depend
> on the connector or on the pixel format, which is what I think you were
> pointing me at, and it fits every point I have rather than the two I
> started from.
> 
> The honest limit of this: all four are a single full-screen plane on a
> single video port. They say nothing about plane_num_4k or crtc_num > 1,
> which are exactly the terms my condition has no counterpart for. I am
> not proposing to drop your terms - I am saying the two mode-derived ones
> appear to carry margin for this shape of workload, and I would rather
> ask than assume.
> 
> The other thing I had not appreciated is where the decision lives.
> rockchip_drm_aclk_adjust() runs from atomic_commit_tail, so it is
> re-evaluated on every commit with that commit's plane information, and
> aclk_adjust_frame_num holds the boost for two more commits on the way
> down. My unsent patch puts the decision in vop2_crtc_atomic_enable() and
> _disable(), which only run on modeset. A condition that depends on what
> the planes are composing cannot live there: a client swapping a 1080p
> plane for a 4K one without a modeset would never be seen. So the
> placement has to change, not just the condition.
>

Yes, I think it depends on the strategy you adopt.

> Two things I would still rather learn than guess:
> 
>   - Is the two-commit hold on the way down a hardware requirement - the
>     rate has to be up before the frame that needs it and stay up for a
>     beat after - or is it belt and braces? It decides whether an
>     upstream version needs the same hysteresis.
>

I think this is a software strategy for debouncing.

>   - Are the mode-derived terms describing something the hardware stalls
>     on, or are they a conservative stand-in for "this is probably a
>     heavy scene"? My 4K60 and 1440p144 points only make sense to me
>     under the second reading.
>

I think it's both. You can think of the VOP internally as having a FIFO:
aclk is used to fill the FIFO, while dclk is used to consume from it. 
This problem occurs when the fill rate cannot keep up with the consumption
rate.

In practice, it is difficult to find a quantitative method to determine 
whether the requirements can be met, so we can only try through 
experimentation. For now, this strategy appears to satisfy our needs.

> I will rewrite the patch along the lines of your flow rather than the
> pixel-clock threshold, and move the decision to the commit path. For
> what it is worth, the version I have been running locally since 7 August
> has driven 3840x2160@120 HDR over DisplayPort with no HDMI output
> present at all, which is the case the FRL-gated condition cannot serve;
> it also drops the rate back to 500 MHz on modeset and restores it, so
> the refcount side behaves.
> 
> Thanks again - this turned a guess into a measurement.
>

Thank you for doing this, let's see if others have any comments.

-- 
Best, 
Chaoyi