[BUG] Rockchip VOP2 Mainline Resume from Suspend

Andy Yan andy.yan at rock-chips.com
Thu Apr 13 04:10:29 PDT 2023

Hi Morgan:

  Some information hope can help you.

On 4/13/23 06:25, Chris Morgan wrote:
> I noticed a bug on the Rockchip mainline VOP2 driver where it fails to
> resume from suspend.
> I dumped the registers and noticed the following were changed between
> working (pre-suspend) and non working (post-suspend) states.
> pre: 0xfe0400b0: 0x00000030
> post: 0xfe0400b0: 0x00000010
> pre: 0xfe0400bc: 0x000003CD
> post: 0xfe0400bc: 0x000003ED
> pre:0xfe0400cc: 0x000000E3
> post: 0xfe0400cc: 0x000000EF

registers at offset 0xb0/bc/cc are interrupts status registers , so it 
has no effect for your case.

> pre: 0xfe04181c: 0x00000280
> pre: 0xfe041820: 0x01DF027F
> pre: 0xfe041824: 0x01DF027F
> post: 0xfe04181c: 0x00000000
> post: 0xfe041820: 0x00000000
> post: 0xfe041824: 0x00000000
> pre: 0xfe041830: 0x00000044
> pre: 0xfe041834: 0x00000000
> post: 0xfe041830: 0x00000000
> post: 0xfe041834: 0x10001000

registers at offset 0x1800(1c/20/24/30/34) control the display src/dst 
rectangle , so this are what matters.

This register should be set in function vop2_plane_atomic_update.

Maybe you can enable drm_debug.: echo 0xff > 

and trace the function call before and after suspend.

> What's interesting is that if I write the pre-suspend values back the
> display starts to work again. I assume this means something is missing
> from the driver that needs to catch a resume from suspend scenario?
> Let me know if there's any more I can do to help debug this further.
> I'm not very knowledgeable on the DRM side of the house, but hopefully
> this is enough information to find the issue.
> Thank you.

More information about the Linux-rockchip mailing list