From: Lyude Paul <lyude@redhat.com> To: nouveau@lists.freedesktop.org Cc: stable@vger.kernel.org, Lukas Wunner <lukas@wunner.de>, Karol Herbst <karolherbst@gmail.com>, Ben Skeggs <bskeggs@redhat.com>, David Airlie <airlied@linux.ie>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH v3 4/8] drm/nouveau: Fix deadlock with fb_helper using new helpers Date: Mon, 30 Jul 2018 20:39:49 -0400 [thread overview] Message-ID: <20180731003954.19962-5-lyude@redhat.com> (raw) In-Reply-To: <20180731003954.19962-1-lyude@redhat.com> This removes the potential of deadlocking with fb_helper entirely by preventing it from handling hotplugs during the runtime suspend process as early as possible in the suspend process. If it turns out this is not possible, due to some fb_helper action having been queued up before we got a time to disable hotplugging, we simply return -EBUSY so that the runtime PM core attempts autosuspending the device again once fb_helper isn't doing anything. This fixes one of the issues causing deadlocks on runtime suspend/resume with nouveau on my P50. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Cc: Lukas Wunner <lukas@wunner.de> Cc: Karol Herbst <karolherbst@gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 8 ++++++++ drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 + 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index ee2546db09c9..d47cb5b2af98 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -836,6 +836,14 @@ nouveau_pmops_runtime_suspend(struct device *dev) return -EBUSY; } + /* There's no way for us to stop fb_helper work in reaction to + * hotplugs later in the RPM process. First off: we don't want to, + * fb_helper should be able to keep the GPU awake. Second off: it is + * capable of grabbing basically any lock in existence. + */ + if (!drm_fb_helper_suspend_hotplug(drm_dev->fb_helper)) + return -EBUSY; + nouveau_switcheroo_optimus_dsm(); ret = nouveau_do_suspend(drm_dev, true); pci_save_state(pdev); diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 85c1f10bc2b6..963ba630fd04 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -466,6 +466,7 @@ nouveau_fbcon_set_suspend_work(struct work_struct *work) console_unlock(); if (state == FBINFO_STATE_RUNNING) { + drm_fb_helper_resume_hotplug(drm->dev->fb_helper); pm_runtime_mark_last_busy(drm->dev->dev); pm_runtime_put_sync(drm->dev->dev); } -- 2.17.1
WARNING: multiple messages have this Message-ID (diff)
From: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Subject: [PATCH v3 4/8] drm/nouveau: Fix deadlock with fb_helper using new helpers Date: Mon, 30 Jul 2018 20:39:49 -0400 [thread overview] Message-ID: <20180731003954.19962-5-lyude@redhat.com> (raw) In-Reply-To: <20180731003954.19962-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> This removes the potential of deadlocking with fb_helper entirely by preventing it from handling hotplugs during the runtime suspend process as early as possible in the suspend process. If it turns out this is not possible, due to some fb_helper action having been queued up before we got a time to disable hotplugging, we simply return -EBUSY so that the runtime PM core attempts autosuspending the device again once fb_helper isn't doing anything. This fixes one of the issues causing deadlocks on runtime suspend/resume with nouveau on my P50. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Cc: Lukas Wunner <lukas@wunner.de> Cc: Karol Herbst <karolherbst@gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 8 ++++++++ drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 + 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index ee2546db09c9..d47cb5b2af98 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -836,6 +836,14 @@ nouveau_pmops_runtime_suspend(struct device *dev) return -EBUSY; } + /* There's no way for us to stop fb_helper work in reaction to + * hotplugs later in the RPM process. First off: we don't want to, + * fb_helper should be able to keep the GPU awake. Second off: it is + * capable of grabbing basically any lock in existence. + */ + if (!drm_fb_helper_suspend_hotplug(drm_dev->fb_helper)) + return -EBUSY; + nouveau_switcheroo_optimus_dsm(); ret = nouveau_do_suspend(drm_dev, true); pci_save_state(pdev); diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 85c1f10bc2b6..963ba630fd04 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -466,6 +466,7 @@ nouveau_fbcon_set_suspend_work(struct work_struct *work) console_unlock(); if (state == FBINFO_STATE_RUNNING) { + drm_fb_helper_resume_hotplug(drm->dev->fb_helper); pm_runtime_mark_last_busy(drm->dev->dev); pm_runtime_put_sync(drm->dev->dev); } -- 2.17.1 _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2018-07-31 0:40 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-31 0:39 [PATCH v3 0/8] Fix connector probing deadlocks from RPM bugs Lyude Paul 2018-07-31 0:39 ` Lyude Paul 2018-07-31 0:39 ` [PATCH v3 1/8] drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement Lyude Paul 2018-07-31 0:39 ` [PATCH v3 2/8] drm/nouveau: Enable polling even if we have runtime PM Lyude Paul 2018-07-31 0:39 ` Lyude Paul 2018-07-31 0:39 ` [PATCH v3 3/8] drm/fb_helper: Introduce hotplug_suspend/resume() Lyude Paul 2018-07-31 0:39 ` Lyude Paul [not found] ` <20180731003954.19962-4-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2018-07-31 14:14 ` William Lewis 2018-08-01 8:36 ` kbuild test robot 2018-08-01 9:53 ` kbuild test robot 2018-08-01 9:53 ` kbuild test robot 2018-08-06 8:43 ` Daniel Vetter 2018-08-06 19:15 ` Lyude Paul 2018-08-06 19:34 ` Lukas Wunner 2018-08-06 19:34 ` Lukas Wunner 2018-08-06 19:43 ` Daniel Vetter 2018-08-06 19:43 ` Daniel Vetter 2018-08-06 19:45 ` Alex Deucher 2018-08-06 19:45 ` Alex Deucher 2018-07-31 0:39 ` Lyude Paul [this message] 2018-07-31 0:39 ` [PATCH v3 4/8] drm/nouveau: Fix deadlock with fb_helper using new helpers Lyude Paul 2018-07-31 0:39 ` [PATCH v3 5/8] drm/nouveau: Use pm_runtime_get_noresume() in connector_detect() Lyude Paul 2018-07-31 0:39 ` Lyude Paul 2018-07-31 0:39 ` [PATCH v3 6/8] drm/nouveau: Respond to HPDs by probing one conn at a time Lyude Paul 2018-07-31 0:39 ` [PATCH v3 7/8] drm/nouveau: Fix deadlocks in nouveau_connector_detect() Lyude Paul 2018-07-31 0:39 ` [PATCH v3 8/8] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers Lyude Paul
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180731003954.19962-5-lyude@redhat.com \ --to=lyude@redhat.com \ --cc=airlied@linux.ie \ --cc=bskeggs@redhat.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=karolherbst@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lukas@wunner.de \ --cc=nouveau@lists.freedesktop.org \ --cc=stable@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.