Quoting Chris Wilson (2019-08-05 19:39:43) > As we need to acquire a mutex to serialise the final > intel_wakeref_put, we need to ensure that we are in process context at > that time. However, we want to allow operation on the intel_wakeref from > inside timer and other hardirq context, which means that need to defer > that final put to a workqueue. > > Inside the final wakeref puts, we are safe to operate in any context, as > we are simply marking up the HW and state tracking for the potential > sleep. It's only the serialisation with the potential sleeping getting > that requires careful wait avoidance. This allows us to retain the > immediate processing as before (we only need to sleep over the same > races as the current mutex_lock). > > v2: Add a selftest to ensure we exercise the code while lockdep watches. > v3: That test was extremely loud and complained about many things! > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111295 > Fixes: 18398904ca9e ("drm/i915: Only recover active engines") > Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref") > Signed-off-by: Chris Wilson <[email protected]> > Cc: Tvrtko Ursulin <[email protected]> > Cc: Mika Kuoppala <[email protected]>
Fwiw, I think the intel_gt_pm_wait_for_idle() hooked into DROP_IDLE will fix https://bugs.freedesktop.org/show_bug.cgi?id=111245 -Chris _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
