Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

2016-10-13 Thread Daniel Vetter
On Thu, Oct 13, 2016 at 04:15:23PM +0100, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote: > > On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > > b/drivers/gpu/drm/i915/i915_gem.c > > > index

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

2016-10-13 Thread Chris Wilson
On Thu, Oct 13, 2016 at 04:44:23PM +0200, Daniel Vetter wrote: > On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 91910ffe0964..587a91af5a3f 100644 > > ---

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

2016-10-13 Thread Daniel Vetter
On Tue, Oct 11, 2016 at 03:37:58PM +0100, Chris Wilson wrote: > We can remove the false coupling between RPM and struct mutex by the > observation that we can use the RPM wakeref as the barrier around user > mmap access. That is as we tear down the user's PTE atomically from > within rpm suspend

[Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access

2016-10-11 Thread Chris Wilson
We can remove the false coupling between RPM and struct mutex by the observation that we can use the RPM wakeref as the barrier around user mmap access. That is as we tear down the user's PTE atomically from within rpm suspend and then to fault in new PTE requires the rpm wakeref, means that no