[PATCH 1/2] drm/xe: Avoid fbdev suspend at runtime pm suspend
Francois Dugast
francois.dugast at intel.com
Fri Jun 7 08:59:42 UTC 2024
On Mon, Jun 03, 2024 at 05:52:17PM -0400, Rodrigo Vivi wrote:
> There's no need to suspend fbdev upon runtime_pm, and it is upseting
> lockdep:
>
> [ 313.150411] ======================================================
> [ 313.150412] WARNING: possible circular locking dependency detected
> [ 313.150413] 6.10.0-rc1pz+ #99 Tainted: G E
> [ 313.150414] ------------------------------------------------------
> [ 313.150414] kworker/2:0/33 is trying to acquire lock:
> [ 313.150415] ffffffffb5f61340 (console_lock){+.+.}-{0:0}, at: intel_fbdev_set_suspend+0x115/0x1e0 [xe]
> [ 313.150495]
> but task is already holding lock:
> [ 313.150495] ffffffffc0ce74a0 (xe_pm_runtime_lockdep_map){+.+.}-{0:0}, at: xe_pm_runtime_suspend+0x2a/0x2e0 [xe]
> [ 313.150561]
> which lock already depends on the new lock.
> [snip]
>
> -> #2 (xe_pm_runtime_lockdep_map){+.+.}-{0:0}:
> [ 313.150563] xe_pm_runtime_resume_and_get+0x44/0xb0 [xe]
> [ 313.150626] intelfb_create+0x150/0x360 [xe]
> [snip]
> [ 313.150932] xe_device_probe+0x439/0x4a0 [xe]
> -> #1 (&helper->lock){+.+.}-{3:3}:
> [snip]
> [ 313.151097] intel_fbdev_set_par+0x16/0x60 [xe]
> [snip]
> [ 313.151402] xe_device_probe+0x439/0x4a0 [xe]
> [snip]
> -> #0 (console_lock){+.+.}-{0:0}:
> [snip]
> [ 313.151548] intel_fbdev_set_suspend+0x115/0x1e0 [xe]
> [ 313.151607] xe_display_pm_suspend+0xd1/0x100 [xe]
> [ 313.151679] xe_pm_runtime_suspend+0x2bf/0x2e0 [xe]
> [snip]
> [ 313.151817] Chain exists of:
> console_lock --> &helper->lock --> xe_pm_runtime_lockdep_map
> [ 313.151819] Possible unsafe locking scenario:
> [ 313.151819] CPU0 CPU1
> [ 313.151820] ---- ----
> [ 313.151820] lock(xe_pm_runtime_lockdep_map);
> [ 313.151821] lock(&helper->lock);
> [ 313.151821] lock(xe_pm_runtime_lockdep_map);
> [ 313.151822] lock(console_lock);
> [ 313.151823]
> *** DEADLOCK ***
>
> Although we know that this scenario is a false positive because
> runtime_pm suspend can never happen while the probe hasn't finished,
> the best approach is to avoid the unnecessary calls.
>
> Cc: Paulo Zanoni <paulo.r.zanoni at intel.com>
> Cc: Anshuman Gupta <anshuman.gupta at intel.com>
> Cc: Francois Dugast <francois.dugast at intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
LGTM, maybe add kernel doc to those 2 functions so that the meaning
of the "runtime" argument is explicit:
Reviewed-by: Francois Dugast <francois.dugast at intel.com>
> ---
> drivers/gpu/drm/xe/display/xe_display.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/display/xe_display.c b/drivers/gpu/drm/xe/display/xe_display.c
> index 2a9b4a4f2e71..cd97975344f1 100644
> --- a/drivers/gpu/drm/xe/display/xe_display.c
> +++ b/drivers/gpu/drm/xe/display/xe_display.c
> @@ -333,7 +333,8 @@ void xe_display_pm_suspend(struct xe_device *xe, bool runtime)
>
> intel_opregion_suspend(xe, s2idle ? PCI_D1 : PCI_D3cold);
>
> - intel_fbdev_set_suspend(&xe->drm, FBINFO_STATE_SUSPENDED, true);
> + if (!runtime)
> + intel_fbdev_set_suspend(&xe->drm, FBINFO_STATE_SUSPENDED, true);
>
> intel_dmc_suspend(xe);
> }
> @@ -383,7 +384,8 @@ void xe_display_pm_resume(struct xe_device *xe, bool runtime)
>
> intel_opregion_resume(xe);
>
> - intel_fbdev_set_suspend(&xe->drm, FBINFO_STATE_RUNNING, false);
> + if (!runtime)
> + intel_fbdev_set_suspend(&xe->drm, FBINFO_STATE_RUNNING, false);
>
> intel_power_domains_enable(xe);
> }
> --
> 2.45.1
>
More information about the Intel-xe
mailing list