On Wed, 2026-09-23 at 17:35 +0200, Christian König wrote: > On 9/23/26 17:27, Philipp Stanner wrote: > > On Wed, 2026-09-23 at 17:13 +0200, Christian König wrote: > > > On 9/23/26 17:03, Philipp Stanner wrote: > > > > > > > > […] > > > > > > > > > Consumers of a fence can instead notify themselves by > > > > + * registering a callback on the fence. > > > > > > Mhm, the wait callback is transparent to consumers it's just that > > > implementations used it for quite a number of different hacks. > > > > Right… > > > > but doesn't the question then become why dma_fence_wait_timeout() even > > exists? IOW, shall we deprecate it, too? > > Yes, without the wait callback it is only a wrapper to block the > current thread for a dma_fence to signal using a callback.
I agree that it's probably quite a common use-case. I'm not sure whether it's possible to write a convenient wrapper, though, since you need to carry a waitqueue around. Maybe we can put a task for it onto the DRM TODO list? > > It's still quite useful to have a common function for that I think. > > > It seems to be a reimplementation of waitqueues. The driver could get > > this functionality by using a waitqueue whose event gets triggered by a > > fence callback. > > > > dma_fence_default_wait() interacts directly with the task state with > > __XX_task() functions which looks very.. deep to me :) > > That is *exactly* what I pointed out as well >10 years ago before that stuff > was merged upstream :) > > A wait_event based implementation would be tons of cleaner if you ask me. So you objected and it was merged anyways? With any rationale? I think I understand now why sometimes people apply a Nacked-by, so that it's documented that people objected against merging. […] > > > > > > Well, what I'm trying to say in this docu is that the driver can kick > > off custom operations that shall be performed once everyone is "done" > > with the fence after signaling it. Any driver data that might still be > > around cannot be accessed by fence consumers after signaling anymore. > > So the driver could trigger cleanup work after a graceperiod, as long > > as it does not involve kfree()-ing the fence itself. > > That sounds sane to me, but I'm not sure how to phrase it cleaner either. > > For now I'm ok with it, maybe somebody else has a better idea to how write > this. I try to come up with something slightly better. P.
