diff options
| author |   Chris Wilson <chris@chris-wilson.co.uk> | 2015-04-07 16:20:49 +0100 |
|---|---|---|
| committer |   Daniel Vetter <daniel.vetter@ffwll.ch> | 2015-04-10 08:56:14 +0200 |
| commit | 4bb1bedb28e0f1d04fa6bf5bdcdaecabd904b21c (patch) | |
| tree | c4e25342351ace931026bf40d91abe92496da39b /drivers/gpu/drm/i915/i915_trace.h | |
| parent | drm/i915: Use simpler form of spin_lock_irq(execlist_lock) (diff) | |
| download | linux-dev-4bb1bedb28e0f1d04fa6bf5bdcdaecabd904b21c.tar.xz linux-dev-4bb1bedb28e0f1d04fa6bf5bdcdaecabd904b21c.zip | |
drm/i915: Use the global runtime-pm wakelock for a busy GPU for execlists
When we submit a request to the GPU, we first take the rpm wakelock, and
only release it once the GPU has been idle for a small period of time
after all requests have been complete. This means that we are sure no
new interrupt can arrive whilst we do not hold the rpm wakelock and so
can drop the individual get/put around every single request inside
execlists.
Note: to close one potential issue we should mark the GPU as busy
earlier in __i915_add_request.
To elaborate: The issue is that we emit the irq signalling sequence
before we grab the rpm reference, which means we could miss the
resulting interrupt (since that's not set up when suspended). The only
bad side effect is a missed interrupt, gt mmio writes automatically
wake up the hw itself. But otoh we have an umbrella rpm reference for
the entirety of execbuf, as long as that's there we're covered.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Explain a bit more about the add_request issue, which after
some irc chatting with Chris turns out to not be an issue really.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/i915/i915_trace.h')
0 files changed, 0 insertions, 0 deletions