drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission
authorDave Gordon <david.s.gordon@intel.com>
Mon, 13 Jun 2016 16:57:34 +0000 (17:57 +0100)
committerTvrtko Ursulin <tvrtko.ursulin@intel.com>
Tue, 14 Jun 2016 14:04:08 +0000 (15:04 +0100)
commit4d75787b8752cc5113462bc9a3c212ff726928ae
tree786cf8a5eacec5b547c046021af5928e7adb5797
parentf10d69a76b11c9a2137393b042d18cd903dbd9e3
drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at
this point. But then, the booted kernel is replaced by the hibernated
image, and this resumed kernel will also try to reload the GuC firmware
(which will fail). To recover, we reset the GuC and try again (which
should work). But this GuC reset doesn't also reset the doorbell
hardware, so it can be left in a state inconsistent with that assumed
by the driver and/or the newly-loaded GuC firmware.

It would be better if the GuC reset also cleared all doorbell state,
but that's not how the hardware currently works; also, the driver cannot
directly reprogram the doorbell hardware (only the GuC can do that).

So this patch cycles through all doorbells, assigning and releasing each
in turn, so that all the doorbell hardware is left in a consistent
state, no matter how it was programmed by the previously-running kernel
and/or GuC firmware.

v2: don't use kmap_atomic() now that client page 0 is kept mapped.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465837054-16245-2-git-send-email-david.s.gordon@intel.com
drivers/gpu/drm/i915/i915_guc_submission.c