Quoting Mika Kuoppala (2019-08-08 15:47:07) > Chris Wilson <[email protected]> writes: > > > 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 > > References: https://bugs.freedesktop.org/show_bug.cgi?id=111245 > > References: https://bugs.freedesktop.org/show_bug.cgi?id=111256 > > 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]> > > Ok, this was discussed on the other submission thread and > confusion cleared. There was no aim for implicit sync > for gem_wait but rather refine the resolution. > > The test looked vicious enough, for both domains so > we should notice if things fly apart. > > Reviewed-by: Mika Kuoppala <[email protected]>
This is one of those that is difficult to reason without tests and difficult to nail down in tests. I'm sure there's plenty of refinement to come. :| Thanks, -Chris _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
