Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread Daniel Vetter
On Fri, Jul 10, 2020 at 4:23 PM Jason Gunthorpe 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 i

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread Jason Gunthorpe
On Fri, Jul 10, 2020 at 03:01:10PM +0200, Christian König wrote: > 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 w

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread 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 hav

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread 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 dr

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread Jason Gunthorpe
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 actu

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread Daniel Vetter
On Fri, Jul 10, 2020 at 3:48 PM Jason Gunthorpe wrote: > > On Fri, Jul 10, 2020 at 03:01:10PM +0200, Christian König wrote: > > 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:

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread Christian König
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

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-10 Thread Christian König
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 + *

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-09 Thread Daniel Vetter
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 &shrink

[PATCH 02/25] dma-fence: prime lockdep annotations

2020-07-07 Thread Daniel Vetter
Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required. - it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mm