Quoting Mika Kuoppala (2019-08-08 14:49:40)
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
>
> > Quoting Mika Kuoppala (2019-08-07 16:04:56)
> >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
