diff options
| author | Lyude Paul <lyude@redhat.com> | 2017-01-11 21:25:23 -0500 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2017-06-17 06:39:37 +0200 |
| commit | ff20cc9a608609b107b5092f9a2852f2dfe3f50d (patch) | |
| tree | 40e65d7d13ac91deefc51e3534347e9d01a8462a /net/lapb/lapb_subr.c | |
| parent | 711f4797a339e27906e6f69b16a09543374551e8 (diff) | |
drm/nouveau: Don't enabling polling twice on runtime resume
[ Upstream commit cae9ff036eea577856d5b12860b4c79c5e71db4a ]
As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.
This fixes hangs observed on the ThinkPad W541
Signed-off-by: Lyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net/lapb/lapb_subr.c')
0 files changed, 0 insertions, 0 deletions