On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote: > On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote: > > We have two once very similar functions, i915_gpu_idle() and > > i915_gem_idle(). The former is used as the lower level operation to > > flush work on the GPU, whereas the latter is the high level interface to > > flush the GEM bookkeeping in addition to flushing the GPU. As such > > i915_gem_idle() also clears out the request and activity lists and > > cancels the delayed work. This is what we need for unloading the driver, > > unfortunately we called i915_gpu_idle() instead. > > > > In the process, make sure that when cancelling the delayed work and > > timer, which is synchronous, that we do not hold any locks to prevent a > > deadlock if the work item is already waiting upon the mutex. This > > requires us to push the mutex down from the caller to i915_gem_idle(). > > > > v2: s/i915_gem_idle/i915_gem_suspend/ > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Tested-by: xunx.fang@xxxxxxxxx > > Queued for -next, thanks for the patch. Oops, spotted a bug in my v2. ums.mm_suspend should only be set for !kms. Sorry that slipped my mind when doing the s/_idle/_suspend. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
