Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-07-09 Thread Daniel Vetter
On Thu, Jul 09, 2020 at 08:29:21AM +0100, Daniel Stone wrote: > Hi, > Jumping in after a couple of weeks where I've paged most everything > out of my brain ... > > On Fri, 19 Jun 2020 at 10:43, Daniel Vetter wrote: > > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote: > > > > The

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-07-09 Thread Daniel Stone
Hi, Jumping in after a couple of weeks where I've paged most everything out of my brain ... On Fri, 19 Jun 2020 at 10:43, Daniel Vetter wrote: > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote: > > > The proposed patches might very well encode the wrong contract, that's > > > all up

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-22 Thread Daniel Vetter
On Fri, Jun 19, 2020 at 3:12 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2020-06-19 10:43:09) > > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote: > > > Quoting Daniel Vetter (2020-06-19 09:51:59) > > > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson > > > > wrote: > > > > >

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-19 Thread Chris Wilson
Quoting Daniel Vetter (2020-06-19 10:43:09) > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-06-19 09:51:59) > > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson > > > wrote: > > > > Forcing a generic primitive to always be part of the same global

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-19 Thread Daniel Vetter
On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2020-06-19 09:51:59) > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson > > wrote: > > > Forcing a generic primitive to always be part of the same global map is > > > horrible. > > > > And no concrete example

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-19 Thread Chris Wilson
Quoting Daniel Vetter (2020-06-19 09:51:59) > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson > wrote: > > Forcing a generic primitive to always be part of the same global map is > > horrible. > > And no concrete example or reason for why that's not possible. > Because frankly it's not horrible,

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-19 Thread Daniel Vetter
On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson wrote: > > Quoting Daniel Stone (2020-06-11 10:01:46) > > Hi, > > > > On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote: > > > On Thu, 11 Jun 2020 at 18:01, Chris Wilson > > > wrote: > > > > Introducing a global lockmap that cannot capture the rules

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-19 Thread Chris Wilson
Quoting Daniel Stone (2020-06-11 10:01:46) > Hi, > > On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote: > > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > > Introducing a global lockmap that cannot capture the rules correctly, > > > > Can you document the rules all drivers should be

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-11 Thread Daniel Vetter
On Thu, Jun 11, 2020 at 4:29 PM Tvrtko Ursulin wrote: > > > On 11/06/2020 12:29, Daniel Vetter wrote: > > On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin > > wrote: > >> On 10/06/2020 16:17, Daniel Vetter wrote: > >>> On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin > >>> wrote: > > >

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-11 Thread Tvrtko Ursulin
On 11/06/2020 12:29, Daniel Vetter wrote: > On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin > wrote: >> On 10/06/2020 16:17, Daniel Vetter wrote: >>> On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin >>> wrote: On 04/06/2020 09:12, Daniel Vetter wrote: > Design is similar to the

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-11 Thread Daniel Vetter
On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin wrote: > > > On 10/06/2020 16:17, Daniel Vetter wrote: > > On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin > > wrote: > >> > >> > >> On 04/06/2020 09:12, Daniel Vetter wrote: > >>> Design is similar to the lockdep annotations for workers, but with >

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-11 Thread Tvrtko Ursulin
On 10/06/2020 16:17, Daniel Vetter wrote: > On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin > wrote: >> >> >> On 04/06/2020 09:12, Daniel Vetter wrote: >>> Design is similar to the lockdep annotations for workers, but with >>> some twists: >>> >>> - We use a read-lock for the

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-11 Thread Daniel Stone
Hi, On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote: > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > Introducing a global lockmap that cannot capture the rules correctly, > > Can you document the rules all drivers should be following then, > because from here it looks to get refactored

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-11 Thread Dave Airlie
On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-06-04 09:12:09) > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > > this explicit annotation

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-11 Thread Chris Wilson
Quoting Daniel Vetter (2020-06-04 09:12:09) > Design is similar to the lockdep annotations for workers, but with > some twists: > > - We use a read-lock for the execution/worker/completion side, so that > this explicit annotation can be more liberally sprinkled around. > With read locks

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-10 Thread Daniel Vetter
On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin wrote: > > > On 04/06/2020 09:12, Daniel Vetter wrote: > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > >this explicit

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-10 Thread Tvrtko Ursulin
On 04/06/2020 09:12, Daniel Vetter wrote: Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-04 Thread Daniel Vetter
On Thu, Jun 4, 2020 at 11:27 AM Chris Wilson wrote: > > Quoting Daniel Vetter (2020-06-04 10:21:46) > > On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel) > > wrote: > > > > > > > > > On 6/4/20 10:12 AM, Daniel Vetter wrote: > > > ... > > > > Thread A: > > > > > > > > mutex_lock(A);

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-04 Thread Chris Wilson
Quoting Daniel Vetter (2020-06-04 10:21:46) > On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel) > wrote: > > > > > > On 6/4/20 10:12 AM, Daniel Vetter wrote: > > ... > > > Thread A: > > > > > > mutex_lock(A); > > > mutex_unlock(A); > > > > > > dma_fence_signal(); > > > >

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-04 Thread Daniel Vetter
On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel) wrote: > > > On 6/4/20 10:12 AM, Daniel Vetter wrote: > ... > > Thread A: > > > > mutex_lock(A); > > mutex_unlock(A); > > > > dma_fence_signal(); > > > > Thread B: > > > > mutex_lock(A); > > dma_fence_wait(); >

Re: [PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-04 Thread Intel
On 6/4/20 10:12 AM, Daniel Vetter wrote: ... Thread A: mutex_lock(A); mutex_unlock(A); dma_fence_signal(); Thread B: mutex_lock(A); dma_fence_wait(); mutex_unlock(A); Thread B is blocked on A signalling the fence, but A never gets around to

[PATCH 03/18] dma-fence: basic lockdep annotations

2020-06-04 Thread Daniel Vetter
Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't going to complain if the read-side isn't