On Fri, 06 Feb 2026 10:32:38 +0100 Philipp Stanner <[email protected]> wrote:
> On Thu, 2026-02-05 at 13:16 +0000, Gary Guo wrote: > > On Thu Feb 5, 2026 at 10:16 AM GMT, Boris Brezillon wrote: > > > On Tue, 3 Feb 2026 09:14:01 +0100 > > > Philipp Stanner <[email protected]> wrote: > > > > > > > > > […] > > > > > +#[pin_data] > > > > +pub struct DmaFence<T> { > > > > + /// The actual dma_fence passed to C. > > > > + #[pin] > > > > + inner: Opaque<bindings::dma_fence>, > > > > + /// User data. > > > > + #[pin] > > > > + data: T, > > > > > > A DmaFence is a cross-device synchronization mechanism that can (and > > > will) > > > > > I'm not questioning the truth behind this statement. They are designed > to do that. But is that actually being done, currently? I recently > found that the get_driver_name() callback intended to inform the > consumer of a fence about who actually issued the fence is only ever > used by i915. It's also used by the dma-buf layer to expose info about dma-bufs through debugfs (see dma_{fence,resv}_describe() and dma_buf_debug_show()), meaning all GPU drivers adding their fences to the dma_resv of an imported/exported buffer object should expect to have their ::get_{driver,timeline}_name() implementation called.
