Re: [PATCH v2 5/9] drm/rockchip: vop2: Balance window fetches across both AXI ports on RK3588

[Chaoyi Chen <chaoyi.chen@rock-chips.com>]

Hi Arun,

On 11/12/2026 4:33 PM, Arun Iyengar via B4 Relay wrote:
> From: Arun Iyengar <aiyengar1990@gmail.com>
> 
> The RK3588 VOP2 fetches through two AXI read ports. Every window has a
> fixed default port in rk3588_vop_win_data: Cluster0/1 and Esmart0/1 use
> AXI0, Cluster2/3 and Esmart2/3 use AXI1. The port is chosen by a per
> window register (CLUSTER_CTRL[13] / ESMART_AXI_CTRL[1]), though, and it
> is programmed on every plane update.
> 
> One port can't sustain two full screen 4K@120Hz layers. With the
> console on Cluster0 (the primary plane of video port 0) and a video on
> Esmart0 (its overlay plane), both on AXI0, HDMI 3840x2160@120 reports
> POST_BUF_EMPTY on about half of all lines (~120000 per second) and the
> picture is scrambled. The VOP read rate measured with the DDR PMU drops
> from the expected 6.3 GB/s to 3.2 GB/s: the fetch collapses instead of
> merely saturating. Measured at 4K@120Hz, XR24 primary plane:
> 
>   Cluster0 + Esmart0 (AXI0 + AXI0)	~120k POST_BUF_EMPTY/s
>   Cluster2 + Esmart2 (AXI1 + AXI1)	~100k/s
>   Esmart0 + Esmart1  (AXI0 + AXI0)	~90k/s (XR24 both)
>   Cluster0 + Esmart2 (AXI0 + AXI1)	0, 9.2 GB/s read
>   Cluster0 + Cluster2 (AXI0 + AXI1)	0, 8.6 GB/s read
> 
> Moving Esmart0 to AXI1 at runtime (with no other change) makes the
> first case clean. Raising ACLK_VOP from 750 to 850 MHz, or changing
> the NoC QoS priority or mode of the VOP ports, makes no difference,
> and neither does the buffer placement (both planes scanning out the
> same buffer fail the same way). So the limit is per port, and the
> fixed assignment puts both layers of the most common configuration on
> the same port while the other one sits idle. Lower modes are affected
> too: the same port also carries Cluster1 for a second display, and
> under DDR contention from other masters a 4K@60Hz port with the
> console, an overlay and a second display underflows for short bursts.
> 
> Choose the port of a window when it starts fetching instead. The atomic
> check assigns the ports from the whole new state and keeps the
> assignment in a private object for the next check. The port of a window
> is also stored in its plane state, and that is what the plane update
> programs: commits on different video ports aren't ordered against each
> other, so the private state of a commit may already be replaced and
> freed when its planes are updated. A window that keeps fetching keeps
> its port, so an active layer is never moved. The windows
> that start fetching, the busiest first, each get the port that leaves
> the busier port least loaded, preferring the default one on a tie. The
> load of a window is its estimated fetch rate: source size x bits per
> pixel of all its planes x refresh rate.
> 
> A window must not share an AXI read ID with another window on the same
> port. The IDs in the table are unique per default port, and mirrored
> between the two ports (Cluster0/Cluster2, Esmart0/Esmart2, ...), so a
> window can always use the port its mirror isn't on. A window that is
> switched off keeps fetching until the next frame start of its video
> port, so its read IDs stay in use for a window that starts on another
> video port in the same commit, and until the commit that switched it
> off is done.
> 
> This is only enabled for RK3588, where it was measured.

According to TRM, "In order to maintain synchronization between layers,
allocationg the layers used by the one port on AXI0 and AXI buses
respectively is not allowed."

Fortunately, we have another way to accomplish this: use the VP merge
feature. Please refer to the patch below.

https://lore.kernel.org/all/20261029081429.862-1-kernel@airkyi.com/

-- 
Best, 
Chaoyi