On Wed, 2026-02-11 at 15:59 +0100, Christian König wrote:
> On 2/11/26 10:50, Philipp Stanner wrote:
> > On Tue, 2026-02-10 at 11:01 +0100, Christian König wrote:
> ...
> > > Using a per-fence spinlock allows completely decoupling spinlock producer
> > > and consumer life times, simplifying the handling in most use cases.
> >
> > That's a good commit message btw, detailing what the motivation is.
> > Would be great to see messages like that more frequently :]
>
> Yeah, but they are not so easy to write.
Valuable things are rarely easy :}
>
> > > trace_dma_fence_init(fence);
> > > @@ -1091,7 +1094,7 @@ __dma_fence_init(struct dma_fence *fence, const
> > > struct dma_fence_ops *ops,
> > > * dma_fence_init - Initialize a custom fence.
> > > * @fence: the fence to initialize
> > > * @ops: the dma_fence_ops for operations on this fence
> > > - * @lock: the irqsafe spinlock to use for locking this fence
> > > + * @lock: optional irqsafe spinlock to use for locking this fence
> > > * @context: the execution context this fence is run on
> > > * @seqno: a linear increasing sequence number for this context
> > > *
> > > @@ -1101,6 +1104,10 @@ __dma_fence_init(struct dma_fence *fence, const
> > > struct dma_fence_ops *ops,
> > > *
> > > * context and seqno are used for easy comparison between fences,
> > > allowing
> > > * to check which fence is later by simply using dma_fence_later().
> > > + *
> > > + * It is strongly discouraged to provide an external lock. This is only
> > > allowed
> >
> > "strongly discouraged […] because this does not decouple lock and fence
> > life times." ?
>
> Good point, added some more text.
>
> > > + * for legacy use cases when multiple fences need to be prevented from
> > > + * signaling out of order.
> >
> > I think our previous discussions revealed that the external lock does
> > not even help with that, does it?
>
> Well only when you provide a ->signaled() callback in the dma_fence_ops.
Mhm, no?
The external lock does not protect against signaling out ouf order,
independently of that callback, because a driver can take and release
that lock in between signaling.
The way how to get this right is to make the fence context and actual
object with actual rules. In Rust, it could also house timeline and
driver name strings, requiring two fewer callbacks.
>
> The reason we have so much different approaches in the dma_fence handling is
> because it is basically the unification multiple different driver
> implementations which all targeted more or less different use cases.
>
When did dma_fence actually come to be? I suppose at some point we
discovered that all drivers basically have very similar requirements
regarding their job completion signaling.
> > >
[…]
> > >
> > > enum dma_fence_flag_bits {
> > > DMA_FENCE_FLAG_INITIALIZED_BIT,
> > > + DMA_FENCE_FLAG_INLINE_LOCK_BIT,
> >
> > Just asking about a nit: what's the order here, always alphabetically?
>
> In which the flags are used in the code flow.
Not intuitive, but it's OK, no big deal
P.
