On Fri, Jul 10, 2020 at 02:48:16PM +0200, Christian König wrote: > Am 10.07.20 um 14:43 schrieb Jason Gunthorpe: > > On Thu, Jul 09, 2020 at 10:09:11AM +0200, Daniel Vetter wrote: > > > Hi Jason, > > > > > > Below the paragraph I've added after our discussions around dma-fences > > > outside of drivers/gpu. Good enough for an ack on this, or want something > > > changed? > > > > > > Thanks, Daniel > > > > > > > + * Note that only GPU drivers have a reasonable excuse for both requiring > > > > + * &mmu_interval_notifier and &shrinker callbacks at the same time as having to > > > > + * track asynchronous compute work using &dma_fence. No driver outside of > > > > + * drivers/gpu should ever call dma_fence_wait() in such contexts. > > I was hoping we'd get to 'no driver outside GPU should even use > > dma_fence()' > > My last status was that V4L could come use dma_fences as well. I'm sure lots of places *could* use it, but I think I understood that it is a bad idea unless you have to fit into the DRM uAPI? You are better to do something contained in the single driver where locking can be analyzed. > I'm not 100% sure, but wouldn't MMU notifier + dma_fence be a valid use case > for things like custom FPGA interfaces as well? I don't think we should expand the list of drivers that use this technique. Drivers that can't suspend should pin memory, not use blocked notifiers to created pinned memory. Jason _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
