[Intel-gfx] [PATCH 08/13] drm/i915: Drive request submission through fence callbacks
Chris Wilson
chris at chris-wilson.co.uk
Fri Aug 26 16:20:56 UTC 2016
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
More information about the Intel-gfx
mailing list