drm/i915: flush delayed_resume_work when suspending
authorPaulo Zanoni <paulo.r.zanoni@intel.com>
Fri, 27 Jun 2014 21:51:51 +0000 (18:51 -0300)
committerJani Nikula <jani.nikula@intel.com>
Tue, 1 Jul 2014 14:32:26 +0000 (17:32 +0300)
commit84a2ab8ec76b4fa47f490a01c8186e4b4d757bfe
tree32b2dc4693f8cdc0ab30656a32b9c32c28af96f5
parent91565c85b66db820f01894a971d39aaef60c4325
drm/i915: flush delayed_resume_work when suspending

It is possible that, by the time we run i915_drm_freeze(),
delayed_resume_work was already queued but did not run yet. If it
still didn't run after intel_runtime_pm_disable_interrupts(), by the
time it runs it will try to change the interrupt registers with the
interrupts already disabled, which will trigger a WARN. We can
reliably reproduce this with the pm_rpm system-suspend test case.

In order to avoid the problem, we have to flush the work before
disabling the interrupts. We could also cancel the work instead of
flushing it, but that would require us to put a runtime PM reference -
and any other resource we may need in the future - in case the work
was already queued, so I believe flushing the work is more
future-proof, although less efficient. But I can also change this part
if someone requests.

Another thing I tried was to move the intel_suspend_gt_powersave()
call to before intel_runtime_pm_disable_interrupts(), but since that
function needs to be called after the interrupts are already disabled,
due to dev_priv->rps.work, this strategy didn't work.

Testcase: igt/pm_rpm/system-suspend
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80517
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drivers/gpu/drm/i915/i915_drv.c