[Intel-gfx] [PATCH] drm/i915: Skip waking the device to service pwrite

[Chris Wilson]

Quoting Daniel Vetter (2017-09-04 09:12:12)
> On Wed, Aug 30, 2017 at 06:48:19PM +0100, Chris Wilson wrote:
> > If the device is in runtime suspend, resuming takes time and reduces our
> > powersaving. If this was for a small write into an object, that resume
> > will take longer than any savings in using the indirect GGTT access to
> > avoid the cpu cache.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 21 ++++++++++++++++++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index 93dfa793975a..8940a6873ca5 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1229,7 +1229,21 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
> >       if (ret)
> >               return ret;
> >  
> > -     intel_runtime_pm_get(i915);
> > +     if (i915_gem_object_has_struct_page(obj)) {
> 
> I don't really see why we need to check for has_struct_page here (we do
> already outside the lock grabbing), and why if that's not the case we hit
> the slow-path?

We can't use the alternate paths if we don't have struct_page, hence we
have to force use of GTT if !i915_gem_object_has_struct_page. The
previous test is to also make sure we come down this path and not fail.
-Chris