Am 10.07.20 um 14:54 schrieb Jason Gunthorpe:
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?
It would be a bit questionable if you use the container objects we came
up with in the DRM subsystem outside of it.
But using the dma_fence itself makes sense for everything which could do
async DMA in general.
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.
Agreed totally, it's a complete pain to maintain even for the GPU drivers.
Unfortunately that doesn't change users from requesting it. So I'm
pretty sure we are going to see more of this.
Christian.
Jason
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
