On Thu, Aug 25, 2016 at 02:49:59PM +0300, Joonas Lahtinen wrote:
> > + * we move the task_list from this the next ready fence to the tail of
> > + * the original fence's task_list (and so added to the list to be
> > + * woken).
> > + */
> > + smp_mb__before_spinlock();
> > + if (!li
On Thu, Aug 25, 2016 at 02:49:59PM +0300, Joonas Lahtinen wrote:
> On to, 2016-08-25 at 10:08 +0100, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> > @@ -0,0 +1,329 @@
> > +/*
> > + * (C) Copyright 2016 Intel Corporation
> > + *
> > + * This program is free software; you can r
On to, 2016-08-25 at 10:08 +0100, Chris Wilson wrote:
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> @@ -0,0 +1,329 @@
> +/*
> + * (C) Copyright 2016 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
On Thu, Aug 25, 2016 at 11:42:41AM +0100, John Harrison wrote:
> I'm not convinced the benefit is worth the
> confusion and maintenance risk. E.g. is unsigned long guaranteed to
> always and ever be sufficient for a pointer?
Yes, unsigned long will always be sufficient for a kernel pointer. I'm
su
Writing up the IRC discussion...
I think the naming of _complete() vs _done() is unnecessarily confusing
- the first being an action and the second a query. Chris says that the
idea is to match the existing naming convention of 'struct completion'.
If the plan is to eventually move this code o
This is really a core kernel struct in disguise until we can finally
place it in kernel/. There is an immediate need for a fence collection
mechanism that is more flexible than fence-array, in particular being
able to easily drive request submission via events (and not just
interrupt driven). The s
