[Intel-gfx] [PATCH 2/3] drm/i915: Use RPM as the barrier for controlling user mmap access
Chris Wilson
chris at chris-wilson.co.uk
Thu Oct 13 15:15:23 UTC 2016
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() ?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list