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

[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 91910ffe0964..587a91af5a3f 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -1469,7 +1469,9 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
> > >  	 */
> > >  	if (!i915_gem_object_has_struct_page(obj) ||
> > >  	    cpu_write_needs_clflush(obj)) {
> > > +		intel_runtime_pm_get(dev_priv);
> > >  		ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
> > > +		intel_runtime_pm_put(dev_priv);
> > 
> > I'd move the rpm_get/put into gtt_pwrite_fast - there's only one caller,
> > and it's in the spirit of this patch of moving the rpm get/put closer to
> > where we really need it.
> 
> What I've also done is move rpm_get/rpm_put into i915_gem_release_mmap()
> and split out the RPM-suspend only i915_gem_release_all_mmaps() (if I
> can think of a good name to better distinguish the two I'll do that as
> well). The benefit being is that instead of simply asserting in one that
> we hold the rpm-wakeref we take it.
> 
> i915_gem_runtime_suspend__mmaps() ?

Or maybe throw a ggtt in there for giggles, but yeah.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch