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

[Igor Paunovic <royalnet026@gmail.com>]

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