[Intel-gfx] [PATCH v2 1/3] drm/i915: Refactor wakeup of the next breadcrumb waiter

Chris Wilson chris at chris-wilson.co.uk
Fri Mar 3 14:07:56 UTC 2017


On Fri, Mar 03, 2017 at 12:17:08PM +0000, Chris Wilson wrote:
> Refactor the common task of updating the first_waiter, serialised with
> the interrupt handler. When we update the first_waiter, we also need to
> wakeup the new bottom-half in order to complete the actions that we may
> have delegated to it (such as checking the irq-seqno coherency or waking
> up other lower priority concurrent waiters).
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/intel_breadcrumbs.c | 48 +++++++++++++-------------------
>  1 file changed, 19 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> index 235d4645a5cf..1cc50304f824 100644
> --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> @@ -287,6 +287,21 @@ static inline void __intel_breadcrumbs_finish(struct intel_breadcrumbs *b,
>  	wake_up_process(wait->tsk); /* implicit smp_wmb() */
>  }
>  
> +static inline void __intel_breadcrumbs_next(struct intel_engine_cs *engine,
> +					    struct rb_node *next)
> +{
> +	struct intel_breadcrumbs *b = &engine->breadcrumbs;
> +
> +	GEM_BUG_ON(!b->irq_armed);
> +	b->first_wait = to_wait(next);
> +
> +	/* We always wake up the next waiter that takes over as the bottom-half
> +	 * as we may delegate not only the irq-seqno barrier to the next waiter
> +	 * but also the task of waking up concurrent waiters.
> +	 */
> +	wake_up_process(to_wait(next)->tsk);

Alternatively:

-       wake_up_process(to_wait(next)->tsk);
+       if ((engine->irq_seqno_barrier &&
+            test_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted)) ||
+           i915_seqno_passed(intel_engine_get_seqno(engine),
+                             to_wait(next)->seqno))
+               wake_up_process(to_wait(next)->tsk);

A plain wake_up_process() is certainly much less fragile.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list