On Wed, Oct 16, 2013 at 05:47:26PM +0100, Chris Wilson wrote: > 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 <ch...@chris-wilson.co.uk> > > > Tested-by: xunx.f...@intel.com > > > > 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.
Actually I've noticed since it was missing from the changelog, but figured you've decided against that. I'll rectify it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
