search for: enable_signaling

...er you need >>>> to lock rdev->exclusive_lock here to make sure not to interfere >>>> with a possible reset. >>> Ah thanks, I'll add that. >>> >>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>> .enable_signaling = radeon_fence_enable_signaling, >>>>> .signaled = __radeon_fence_signaled, >>>> Do we still need those callback when we implemented the wait callback? >>> .get_timeline_name is used for debugging (trace events). >>> .signaled is the non-blocking ca...

...his call is comming from outside the radeon driver you need to >> lock rdev->exclusive_lock here to make sure not to interfere with a >> possible reset. > Ah thanks, I'll add that. > >>> .get_timeline_name = radeon_fence_get_timeline_name, >>> .enable_signaling = radeon_fence_enable_signaling, >>> .signaled = __radeon_fence_signaled, >> Do we still need those callback when we implemented the wait callback? > .get_timeline_name is used for debugging (trace events). > .signaled is the non-blocking call to check if the fence is sign...

> Maybe I've mixed things up a bit in my description. There is > fence_signal which the implementor/exporter of a fence must call when > the fence is completed. If the exporter has an ->enable_signaling > callback it can delay that call to fence_signal for as long as it > wishes as long as enable_signaling isn't called yet. But that's just > the optimization to not required irqs to be turned on all the time. > > The other function is fence_is_signaled, which is used by code...

...y useful here > because it means you can't do too many scary things in your is_signaled > handler. This is indeed a nice optimization, but nothing more. If you want to provide a is_signalled interface for atomic context then this should be optional, not mandatory. > > In case of enable_signaling it was the only sane solution, because > fence_signal can be called from irq context, and any calls after that to > fence_add_callback and fence_wait aren't allowed to do anything, so > fence_enable_sw_signaling and the default wait implementation must be > atomic. fence_wait itself...

...ecause it means you can't do too many scary things in your is_signaled >> handler. > > This is indeed a nice optimization, but nothing more. If you want to provide a is_signalled interface for atomic context then this should be optional, not mandatory. See below. >> In case of enable_signaling it was the only sane solution, because >> fence_signal can be called from irq context, and any calls after that to >> fence_add_callback and fence_wait aren't allowed to do anything, so >> fence_enable_sw_signaling and the default wait implementation must be >> atomic. f...

...side the radeon driver you need to lock rdev->exclusive_lock here to make sure not to interfere with a possible reset. >>>> Ah thanks, I'll add that. >>>> >>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>> .enable_signaling = radeon_fence_enable_signaling, >>>>>> .signaled = __radeon_fence_signaled, >>>>> Do we still need those callback when we implemented the wait callback? >>>> .get_timeline_name is used for debugging (trace events). >>>> .signaled is the...

dma_fence_default_wait is the default now, same for the trivial enable_signaling implementation. Reviewed-by: Eric Anholt <eric at anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: David Airlie <airlied at linux.ie> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org --- drivers/gpu/drm/virti...

On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig <deathsimple at vodafone.de> wrote: >> Would that be something you can agree to? > > > No, the whole enable_signaling stuff should go away. No callback from the > driver into the fence code, only the other way around. > > fence->signaled as well as fence->wait should become mandatory and only > called from process context without holding any locks, neither atomic nor > any mutex/semaphore (rcu...

...ev->exclusive_lock here to make sure not to interfere >>>>>> with a possible reset. >>>>> Ah thanks, I'll add that. >>>>> >>>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>>> .enable_signaling = radeon_fence_enable_signaling, >>>>>>> .signaled = __radeon_fence_signaled, >>>>>> Do we still need those callback when we implemented the wait >>>>>> callback? >>>>> .get_timeline_name is used for debugging (trace even...

Am 22.07.2014 17:42, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Drivers exporting fences need to provide a fence->signaled and a fence->wait >> function, everything else like fence->enable_signaling or calling >> fence_signaled() from the driver is optional. >> >> Drivers wanting to use exported fences don't call fence->signaled or >> fence->wait in atomic or interrupt context, and not with holding any global >> locking primitives (like mmap_sem etc...)....

...to lock rdev->exclusive_lock here to make sure not to interfere with a possible reset. >>>>>> Ah thanks, I'll add that. >>>>>> >>>>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>>>> .enable_signaling = radeon_fence_enable_signaling, >>>>>>>> .signaled = __radeon_fence_signaled, >>>>>>> Do we still need those callback when we implemented the wait callback? >>>>>> .get_timeline_name is used for debugging (trace events). >>&...

...en this call is comming from outside the radeon driver you need to lock rdev->exclusive_lock here to make sure not to interfere with a possible reset. >> Ah thanks, I'll add that. >> >>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>> .enable_signaling = radeon_fence_enable_signaling, >>>> .signaled = __radeon_fence_signaled, >>> Do we still need those callback when we implemented the wait callback? >> .get_timeline_name is used for debugging (trace events). >> .signaled is the non-blocking call to check if t...

..._timeout(fence->rdev, target_seq, > intr, timeout); > +} When this call is comming from outside the radeon driver you need to lock rdev->exclusive_lock here to make sure not to interfere with a possible reset. > .get_timeline_name = radeon_fence_get_timeline_name, > .enable_signaling = radeon_fence_enable_signaling, > .signaled = __radeon_fence_signaled, Do we still need those callback when we implemented the wait callback? Christian. > > diff --git a/drivers/gpu/drm/radeon/radeon_fence.c > b/drivers/gpu/drm/radeon/radeon_fence.c > index bc844f300d3f..2d4...

..., Jul 22, 2014 at 6:39 PM, Christian K?nig <christian.koenig at amd.com> wrote: >> Maybe I've mixed things up a bit in my description. There is >> fence_signal which the implementor/exporter of a fence must call when >> the fence is completed. If the exporter has an ->enable_signaling >> callback it can delay that call to fence_signal for as long as it >> wishes as long as enable_signaling isn't called yet. But that's just >> the optimization to not required irqs to be turned on all the time. >> >> The other function is fence_is_signaled, wh...

Am 22.07.2014 17:17, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 3:45 PM, Christian K?nig > <deathsimple at vodafone.de> wrote: >>> Would that be something you can agree to? >> >> No, the whole enable_signaling stuff should go away. No callback from the >> driver into the fence code, only the other way around. >> >> fence->signaled as well as fence->wait should become mandatory and only >> called from process context without holding any locks, neither atomic nor >> any...

...schrieb Daniel Vetter: >>> On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig >>> <christian.koenig at amd.com> wrote: >>>> Drivers exporting fences need to provide a fence->signaled and a fence->wait >>>> function, everything else like fence->enable_signaling or calling >>>> fence_signaled() from the driver is optional. >>>> >>>> Drivers wanting to use exported fences don't call fence->signaled or >>>> fence->wait in atomic or interrupt context, and not with holding any global >>>> lo...

...i915 as > I'll have for converting to the one used by radeon. If it would fit at > all. Oh my! No, I didn't wanted to suggest any global reset infrastructure. My idea was more that the fence framework provides a fence->process_signaling callback that is periodically called after enable_signaling is called to trigger manual signal processing in the driver. This would both be suitable as a fallback in case of not working interrupts as well as a chance for any driver to do necessary lockup handling. Christian. > I guess for radeon we just have to add tons of insulation by punting &gt...

...gnal from wherever you want to, so hopefully that >> doesn't restrict your implementation. >> >> End result: No one calls into radeon from interrupt context, and this is >> guaranteed. >> >> Would that be something you can agree to? > > No, the whole enable_signaling stuff should go away. No callback from the driver into the fence code, only the other way around. > > fence->signaled as well as fence->wait should become mandatory and only called from process context without holding any locks, neither atomic nor any mutex/semaphore (rcu might be ok)....

The trivial enable_signaling implementation matches the default code. v2: Fix up commit message to match patch better (Eric). Cc: Eric Anholt <eric at anholt.net> Reviewed-by: Eric Anholt <eric at anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: Dave Airlie <airlied at redhat.com&...

The trivial enable_signaling implementation matches the default code. v2: Fix up commit message to match patch better (Eric). Cc: Eric Anholt <eric at anholt.net> Reviewed-by: Eric Anholt <eric at anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: Dave Airlie <airlied at redhat.com&...