[Intel-gfx] [PATCH 3/3] drm/i915: Defer final intel_wakeref_put to process context

[Chris Wilson]

Quoting Mika Kuoppala (2019-08-08 14:49:40)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > Quoting Mika Kuoppala (2019-08-07 16:04:56)
> >> Chris Wilson <chris at chris-wilson.co.uk> writes:
> >> >       if (flags & I915_WAIT_LOCKED) {
> >> > -             int err;
> >> > -
> >> >               lockdep_assert_held(&i915->drm.struct_mutex);
> >> >  
> >> > -             err = wait_for_engines(&i915->gt);
> >> > -             if (err)
> >> > -                     return err;
> >> > -
> >> 
> >> Hmm where does the implicit wait for idle come from now?
> >
> > Instead of having the wait here, we moved it into the engine/gt pm
> > tracking and added an intel_gt_pm_wait_for_idle().
> 
> I see that we do wait on switching to kernel context. However
> still failing to grasp the way we end up waiting on (implicit?)
> releasing of the gt pm (and where)

Inside the switch-to-kernel context, we call intel_gt_pm_wait_for_idle()
which waits for the intel_wakeref.count to hit 0 and for the wakeref to
be released (that's the wake_up_var() inside
____intel_wakeref_put_last). wait_for_idle is then just

int intel_wakeref_wait_for_idle(struct intel_wakeref *wf)
{
        return wait_var_event_killable(&wf->wakeref,
                                       !intel_wakeref_is_active(wf));
}

Instead of i915_gem_wait_for_idle() ensuring that the pm is idled, we've
lifted that to the two callers that cared.
-Chris