On 17.12.2023 09:44, Andy Yan wrote:
> From: Andy Yan
>
> Marek Report a possible irq lock inversion dependency warning when
> commit 81a06f1d02e5 ("Revert "drm/rockchip: vop2: Use regcache_sync()
> to fix suspend/resume"") lands linux-next.
>
> I can reproduce this warning with:
> CONFIG_PROVE_LOCKING=y
> CONFIG_DEBUG_LOCKDEP=y
>
> It seems than when use regmap_reinit_cache at runtime whith Mark's
> commit 3d59c22bbb8d ("drm/rockchip: vop2: Convert to use maple tree
> register cache"), it will trigger a possible irq lock inversion dependency
> warning.
>
> One solution is switch back to REGCACHE_RBTREE, but it seems that
> REGCACHE_MAPLE is the future, so I avoid ues regmap_reinit_cache,
> and drop all the regcache when vop is disabled, then we get a fresh
> start at next enbable time.
>
> [8.425923] dwmmc_rockchip fe2b.mmc: IDMAC supports 32-bit address
> mode.
> [8.427020] dwmmc_rockchip fe2b.mmc: Using internal DMA controller.
> [8.428013] dwmmc_rockchip fe2b.mmc: Version ID is 270a
> [8.429088] dwmmc_rockchip fe2b.mmc: DW MMC controller at irq 78,32
> bit host data width,256 deep fifo
> [8.454219] mmc_host mmc0: Bus speed (slot 0) = 375000Hz (slot req
> 40Hz, actual 375000HZ div = 0)
> [8.465446] rockchip-drm display-subsystem: bound fe04.vop (ops
> vop2_component_ops)
> [8.475586] dwhdmi-rockchip fe0a.hdmi: Detected HDMI TX controller
> v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
> [8.484326] dwhdmi-rockchip fe0a.hdmi: registered DesignWare HDMI I2C
> bus driver
> [8.490505] rockchip-drm display-subsystem: bound fe0a.hdmi (ops
> dw_hdmi_rockchip_ops)
> [8.501151] [drm] Initialized rockchip 1.0.0 20140818 for
> display-subsystem on minor 0
> [8.895456]
> [8.895473]
> [8.895480] WARNING: possible irq lock inversion dependency detected
> [8.895486] 6.7.0-rc5-next-20231215 #514 Not tainted
> [8.895496]
> [8.895501] swapper/0/0 just changed the state of lock:
> [8.895510] 070b6018
> (rockchip_drm_vop2:3116:(_regmap_config)->lock){-...}-{2:2}, at:
> regmap_lock_spinlock
> +0x14/0x24
> [8.895560] but this lock took another, HARDIRQ-unsafe lock in the past:
> [8.895566] (>ma_lock){+.+.}-{2:2}
> [8.895580]
> [8.895580]
> [8.895580] and interrupts could create inverse lock ordering between them.
> [8.895580]
> [8.895585]
> [8.895585] other info that might help us debug this:
> [8.895590] Possible interrupt unsafe locking scenario:
> [8.895590]
> [8.895594]CPU0CPU1
> [8.895598]
> [8.895602] lock(>ma_lock);
> [8.895614]local_irq_disable();
> [8.895617]
> lock(rockchip_drm_vop2:3116:(_regmap_config)->lock);
> [8.895629]lock(>ma_lock);
> [8.895641]
> [8.895644] lock(rockchip_drm_vop2:3116:(_regmap_config)->lock);
> [8.895655]
> [8.895655] *** DEADLOCK ***
> [8.895655]
> [8.895659] no locks held by swapper/0/0.
> [8.895664]
> [8.895664] the shortest dependencies between 2nd lock and 1st lock:
> [8.895672] -> (>ma_lock){+.+.}-{2:2} ops: 12 {
> [8.895704] HARDIRQ-ON-W at:
> [8.895713] lock_acquire+0x238/0x354
> [8.895732] _raw_spin_lock+0x3c/0x50
> [8.895749] regcache_maple_exit+0x64/0xc4
> [8.895766] regcache_exit+0x48/0xac
> [8.895780] regmap_reinit_cache+0x18/0x98
> [8.895793]
> vop2_crtc_atomic_enable+0xefc/0x1074
> [8.895810]
> drm_atomic_helper_commit_modeset_enables+0xac/0x264
> [8.895826]
> drm_atomic_helper_commit_tail_rpm+0x2c/0x78
> [8.895841] commit_tail+0x9c/0x178
> [8.895855] drm_atomic_helper_commit+0x17c/0x1ac
> [8.895869] drm_atomic_commit+0xac/0xec
> [8.895885]
> drm_client_modeset_commit_atomic+0x230/0x290
> [8.895896]
> drm_client_modeset_commit_locked+0x54/0x1c4
> [8.895907] drm_client_modeset_commit+0x2c/0x50
> [8.895917]
> __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf4
> [8.895934] drm_fb_helper_set_par+0x30/0x48
> [8.895948] fbcon_init+0x40c/0x498
> [8.895961] visual_init+0xb0/0x108
> [8.895972] do_bind_con_driver+0x1b8/0x38c
> [8.895983] do_take_over_console+0x148/0x1d4
> [8.895993] do_fbcon_takeover+0x6c/0xe0
> [8.896003]
