search for: fence_enable_sw_signaling

...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. fence_wait itself doesn't have to be, so it's easy to grab >> exclusive_lock there. > > I don't think you understood my point here: Completely drop enable_signaling, it's unnecessary and only complicates the in...

...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 doesn't have to be, so it's easy to grab > exclusive_lock there. I don't think you understood my point here: Completely drop enable_signaling, it's unnecessary and only complicates the interface. We pur...

...really capable of checking the fence right now. I think there is a usecase for having atomic context allowed with fence_is_signaled, but I don't think there is one for interrupt context, so it's good with me if fence_is_signaled cannot be called in interrupt context, or with irqs disabled. fence_enable_sw_signaling disables interrupts because it holds fence->lock, so in theory it could be called from any context including interrupts. But no sane driver author does that, or at least I hope not.. Would a sanity check like the one below be enough to allay your fears? 8<------- diff --git a/include/linux/...

...e = reservation_object_get_excl(rbo->tbo.resv); + if (fence) { + fence_get(fence); + work->fence = (struct radeon_fence *)fence; + + if (!fence->ops->signaled) + /* + * make sure if this fence doesn't belong to this + * device that it will still signal completion + */ + fence_enable_sw_signaling(fence); + } + /* Only 27 bit offset for legacy CRTC */ r = radeon_bo_pin_restricted(rbo, RADEON_GEM_DOMAIN_VRAM, ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27, &base); diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 3b27cac9240b..e082fe...

...gt;fence = (struct radeon_fence *)fence_get_rcu(fence); + rcu_read_unlock(); + } while (fence && !work->fence); + + if (fence && !fence->ops->signaled) { + /* + * make sure if this fence doesn't belong to this + * device that it will still signal completion + */ + fence_enable_sw_signaling(fence); } /* We borrow the event spin lock for protecting flip_work */ diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 8538aebb6580..53104f80d382 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c...

...of checking the fence right now. > I think there is a usecase for having atomic context allowed with fence_is_signaled, but I don't think there is one for interrupt context, so it's good with me if fence_is_signaled cannot be called in interrupt context, or with irqs disabled. > > fence_enable_sw_signaling disables interrupts because it holds fence->lock, so in theory it could be called from any context including interrupts. But no sane driver author does that, or at least I hope not.. > > Would a sanity check like the one below be enough to allay your fears? > 8<------- > > diff...

...tory. > 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. fence_wait itself doesn't have to be, so it's easy to grab >>> exclusive_lock there. >> >> I don't think you understood my point here: Completely drop >> enable_signaling, it's unnecessary a...

On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: > On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote: > > Am 22.07.2014 06:05, schrieb Dave Airlie: > > >On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > > >>Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > >

Am 19.05.2014 10:00, schrieb Maarten Lankhorst: > op 15-05-14 18:13, Christian K?nig schreef: >> Am 15.05.2014 17:58, schrieb Maarten Lankhorst: >>> op 15-05-14 17:48, Christian K?nig schreef: >>>> Am 15.05.2014 16:18, schrieb Maarten Lankhorst: >>>>> op 15-05-14 15:19, Christian K?nig schreef: >>>>>> Am 15.05.2014 15:04, schrieb

...e because it means you can't do too many scary things in your is_signaled handler. 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 doesn't have to be, so it's easy to grab exclusive_lock there. Simple fence drivers may drop some state after calling fence_signal, so calling .enable_signaling after fence_signal is bad, and fence_signal must also wait...

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- include/linux/fence.h | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index d174585b874b..c1a4519ba2f5 100644 ---

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers are converted to the fence api, fence_lock is removed and rcu is used in its place. qxl is the first

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. :-) I've done at least basic