On 5/22/25 15:43, Philipp Stanner wrote: >> >> Well there is no need to implement it, but when it is implemented the >> caller *must* call it when polling. > > I don't understand. Please elaborate on that a bit more. If there's no > need to implement it, then why can't one have a > __dma_fence_is_signaled(), which is then identical?
Because the caller then doesn't call it when it is implemented. E.g. you give people a function which ignores the callback. >> >> IIRC the background that we didn't allowed this was that we already >> had the case that users only looked at the signaling bit and then >> where surprised that it never changed. > > Why would anyone expect that a fence gets signaled by calling a > function with the name "dma_fence_is_signaled()"? :-) Because when that function returns true the fence is considered signaled. > That was my original point, the name is not intuitive at all. > > For example, if a driver doesn't implement that callback but signals > fences in interrupt handlers, and then forgets to (re-)activate the > interrupt, fences will never get signaled and callers to > dma_fence_is_signaled() will never read 'true', which isn't surprising. > > Again, the point remains the same: the driver must guarantee that > fences will get signaled. Independently from how consumers of the fence > check it. Consumers could just stop calling dma_fence_is_signaled() > after the point in time T alltogether and then the driver would still > have to signal everything. No it doesn't. You need to call dma_fence_enable_signaling for that. Regards, Christian. > > > P. > > > >> >> Regards, >> Christian. >> >>> >>> >>> P. >>> >>>> >>>> Regards, >>>> Christian. >>> >> >
