On Fri, Aug 26, 2016 at 01:47:50PM +0100, John Harrison wrote: > On 25/08/2016 10:08, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c > >index 5e60519ede8d..babeaa8b1273 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++ b/drivers/gpu/drm/i915/intel_lrc.c > >@@ -538,14 +538,15 @@ static void intel_lrc_irq_handler(unsigned long data) > > static void execlists_submit_request(struct drm_i915_gem_request *request) > Need to document that submit_request is now called from a callback > and potentially from a tasklet or even an IRQ? Yes, the signal notify is always in atomic context, because the parent is holding an irq spinlock. We should avoid limiting when kfence_complete() is legal (hardirq support should be a requirement), but different users may know that their fences are nevery used from such contexts (though this notify is always atomic due to the spinlock). The release notify may also be in any context - when mixing with dma fences it may indeed be from atomic context due to the fence tacking a spinlock around its callbacks. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
