Re: [PATCH v2 6/9] drm/rockchip: vop2: Report POST_BUF_EMPTY at most once per frame

[Damon Ding <damon.ding@rock-chips.com>]

Hi Arun,

On 11/12/2026 4:33 PM, Arun Iyengar via B4 Relay wrote:
> From: Arun Iyengar <aiyengar1990@gmail.com>
> 
> POST_BUF_EMPTY is raised for every line on which the post processing
> stage of a video port finds no data. The interrupt handler only
> rate-limits the error message and leaves the interrupt enabled, so an
> underflowing video port keeps the CPU in the interrupt handler 50000 to
> 300000 times per second, for as long as the configuration that causes
> the underflow stays in place (e.g. 120000 interrupts per second for
> 3840x2160@120 with two full screen layers on one AXI port).
> 
> Mask POST_BUF_EMPTY when it fires and unmask it at the next frame start.
> The frame start (FS) interrupt is enabled for that frame even when
> vblank reporting is off, and disabled again once POST_BUF_EMPTY is
> re-armed or the video port is switched off. VP_INT_EN is write-masked,
> so masking POST_BUF_EMPTY leaves FS alone; FS only needs enabling here
> while vblank reporting has it off. A new per video port lock
> serialises the interrupt enable bookkeeping between the interrupt
> handler and the vblank callbacks. The error is still reported, now at
> most once per frame and video port.
> 
> Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
> Signed-off-by: Arun Iyengar <aiyengar1990@gmail.com>
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 91 ++++++++++++++++++++++++++--
>   drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 10 +++
>   2 files changed, 97 insertions(+), 4 deletions(-)

Well. This change can indeed reduce CPU interrupt pressure when 
occasional POST_BUF_EMPTY occurs. However, we do not expect this error 
to happen during normal system operation: if POST_BUF_EMPTY shows up, it 
should be resolved by adjusting layers configurations or improving DDR 
bandwidth, rather than being masked.

On the other hand, this approach drops the per-line POST_BUF_EMPTY
information. In complex debugging scenarios we still need the per-line
error reports to locate issues, for example partial line data corruption
with AFBC on Cluster planes. Reporting only one interrupt per frame 
would hide these critical debug details.

So in my opinion, we should keep POST_BUF_EMPTY handling as it is.

Nacked-by: Damon Ding <damon.ding@rock-chips.com>

Best regards,
Damon