[BUG] Rockchip VOP2 Mainline Resume from Suspend

[Andy Yan]

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 > 
/sys/module/drm/parameters/debug


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.