Re: [Intel-gfx] [PATCH 05/41] drm/i915: Move fence cancellation to runtime suspend

2016-10-21 Thread Chris Wilson
On Fri, Oct 21, 2016 at 03:48:27PM +0300, Imre Deak wrote: > On to, 2016-10-20 at 16:03 +0100, Chris Wilson wrote: > > At the moment, we have dependency on the RPM as a barrier itself in both > > i915_gem_release_all_mmaps() and i915_gem_restore_fences(). > > i915_gem_restore_fences() is also

Re: [Intel-gfx] [PATCH 05/41] drm/i915: Move fence cancellation to runtime suspend

2016-10-21 Thread Imre Deak
On to, 2016-10-20 at 16:03 +0100, Chris Wilson wrote: > At the moment, we have dependency on the RPM as a barrier itself in both > i915_gem_release_all_mmaps() and i915_gem_restore_fences(). > i915_gem_restore_fences() is also called along !runtime pm paths, but we > can move the markup of lost

[Intel-gfx] [PATCH 05/41] drm/i915: Move fence cancellation to runtime suspend

2016-10-20 Thread Chris Wilson
At the moment, we have dependency on the RPM as a barrier itself in both i915_gem_release_all_mmaps() and i915_gem_restore_fences(). i915_gem_restore_fences() is also called along !runtime pm paths, but we can move the markup of lost fences alongside releasing the mmaps into a common

[Intel-gfx] [PATCH 05/41] drm/i915: Move fence cancellation to runtime suspend

2016-10-14 Thread Chris Wilson
At the moment, we have dependency on the RPM as a barrier itself in both i915_gem_release_all_mmaps() and i915_gem_restore_fences(). i915_gem_restore_fences() is also called along !runtime pm paths, but we can move the markup of lost fences alongside releasing the mmaps into a common