diff options
| author | Lyude Paul <lyude@redhat.com> | 2017-01-11 21:25:23 -0500 |
|---|---|---|
| committer | Dave Airlie <airlied@redhat.com> | 2017-01-27 10:43:42 +1000 |
| commit | cae9ff036eea577856d5b12860b4c79c5e71db4a (patch) | |
| tree | f230de52d5ed8f7a47580615006d3729ced8825d /drivers/gpu/drm/nouveau/nouveau_drv.h | |
| parent | 6c971c09f38704513c426ba6515f22fb3d6c87d5 (diff) | |
| download | op-kernel-dev-cae9ff036eea577856d5b12860b4c79c5e71db4a.zip op-kernel-dev-cae9ff036eea577856d5b12860b4c79c5e71db4a.tar.gz | |
drm/nouveau: Don't enabling polling twice on runtime resume
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>
Diffstat (limited to 'drivers/gpu/drm/nouveau/nouveau_drv.h')
0 files changed, 0 insertions, 0 deletions
