On Fri, Jul 10, 2020 at 4:23 PM Jason Gunthorpe jgg@mellanox.com wrote:

On Fri, Jul 10, 2020 at 04:02:35PM +0200, Daniel Vetter wrote:

...

...

dma_fence only possibly makes some sense if you intend to expose the completion outside a single driver.

The prefered kernel design pattern for this is to connect things with a function callback.

So the actual use case of dma_fence is quite narrow and tightly linked to DRM.

I don't think we should spread this beyond DRM, I can't see a reason.

Yeah v4l has a legit reason to use dma_fence, android wants that there.

'legit' in the sense the v4l is supposed to trigger stuff in DRM when V4L DMA completes? I would still see that as part of DRM

Yes, and also the other way around. But thus far it didn't land. -Daniel

Or is it building a parallel DRM like DMA completion graph?

...

...

Trying to improve performance of limited HW by using sketchy techniques at the cost of general system stability should be a NAK.

Well that's pretty much gpu drivers, all the horrors for a bit more speed :-)

On the text itself, should I upgrade to "must not" instead of "should not"? Or more needed?

Fundamentally having some unknowable graph of dependencies where parts of the graph can be placed in critical regions like notifiers is a complete maintenance nightmare.

I think building systems like this should be discouraged :\