search for: fence_is_signaled

...re. > > Checking fence status from another drivers interrupt context is what really concerns me here, cause your driver doesn't have the slightest idea if the called driver is 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 inc...

...hanges, radeon reworked their page flip code which made things easier for me. - Added a delayed work for radeon that checks gpu lockups. - Reworked the radeon fence implementation to remove deadlocks, and end up slightly cleaner. --- Maarten Lankhorst (18): fence: add debugging lines to fence_is_signaled for the callback drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers drm/ttm: kill off some members to ttm_validate_buffer drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence...

...from not atomic context. >>> >>> If a driver needs to avoid blocking it should just use a workqueue and checking a fence outside your own driver is probably be better done in a bottom halve handler anyway. >> >> Except that you might want to do something like >> fence_is_signaled() in another driver to check whether you need to >> defer, or can submit the batch buffer immediately, saving a bunch of >> context switches. Running the is_signaled atomic is really useful here >> because it means you can't do too many scary things in your is_signaled >&gt...

...&nouveau_ttm_io_mem_free, diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 9a9e04985826..b1aba6f79605 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -139,17 +139,18 @@ static bool nouveau_fence_is_signaled(struct fence *f) } void -nouveau_fence_work(struct nouveau_fence *fence, +nouveau_fence_work(struct fence *fence, void (*func)(void *), void *data) { struct nouveau_fence_work *work; - if (fence_is_signaled(&fence->base)) + if (fence_is_signaled(fence)) goto err; work =...

...&nouveau_ttm_io_mem_free, diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index d24f8ce4341a..9f92ad37637d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -139,17 +139,18 @@ static bool nouveau_fence_is_signaled(struct fence *f) } void -nouveau_fence_work(struct nouveau_fence *fence, +nouveau_fence_work(struct fence *fence, void (*func)(void *), void *data) { struct nouveau_fence_work *work; - if (fence_is_signaled(&fence->base)) + if (fence_is_signaled(fence)) goto err; work =...

...p; fobj->shared_count) { - shared = kmalloc(sizeof(*shared) * fobj->shared_count, - GFP_KERNEL); - - if (!shared) { - ret = -ENOMEM; - __ttm_bo_unreserve(bo); - spin_unlock(&glob->lru_lock); - return ret; - } - - for (i = 0; i < fobj->shared_count; ++i) { - if (!fence_is_signaled(fobj->shared[i])) { - fence_get(fobj->shared[i]); - shared[shared_count++] = fobj->shared[i]; - } - } - if (!shared_count) { - kfree(shared); - shared = NULL; - } - } - - excl = reservation_object_get_excl(bo->resv); - if (excl && !fence_is_signaled(excl)) - fenc...

...>> atomic context. >> >> If a driver needs to avoid blocking it should just use a workqueue >> and checking a fence outside your own driver is probably be better >> done in a bottom halve handler anyway. > > Except that you might want to do something like > fence_is_signaled() in another driver to check whether you need to > defer, or can submit the batch buffer immediately, saving a bunch of > context switches. Running the is_signaled atomic is really useful here > because it means you can't do too many scary things in your is_signaled > handler. This...

...>> Checking fence status from another drivers interrupt context is what really concerns me here, cause your driver doesn't have the slightest idea if the called driver is 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 co...

If the fence context has notifies enabled, each of the fences' FENCE_FLAG_SIGNALED_BIT will be updated from the interrupt. We can rely on this status for reporting the current fence_is_signaled() and so avoid an expensive uncached read. Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: dri-devel at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++++ 1 file c...

...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 that is > interested in the fence state, together with fence_wait if it wants to > block and not just wants to know the momentary fence state. All the > other functions (the stuff that adds callbacks and the various _locked > and other versions) are just for fancy...

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...

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 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

...->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 that is >> interested in the fence state, together with fence_wait if it wants to >> block and not just wants to know the momentary fence state. All the >> other functions (the stuff that adds callbacks and the various _locked >> and other versions) ar...

...+ +/* + * In an ideal world, read would not assume the channel context is still alive. + * This function may be called from another device, running into free memory as a + * result. The drm node should still be there, so we can derive the index from + * the fence context. + */ +static bool nouveau_fence_is_signaled(struct fence *f) +{ + struct nouveau_fence *fence = container_of(f, struct nouveau_fence, base); + struct nouveau_channel *chan = fence->channel; + struct nouveau_fence_chan *fctx = chan->fence; + + return (int)(fctx->read(chan) - fence->base.seqno) >= 0; +} + void nouveau_fence_wo...

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

...erfect example of locking inversion. In the preliminary patches where I can sync radeon with other GPU's I've been very careful in all the places that call into fences, to make sure that radeon wouldn't try to handle lockups for a different (possibly also radeon) card. This is also why fence_is_signaled should never block, and why it trylocks the exclusive_lock. :-) I think lockdep would complain if I grabbed exclusive_lock while blocking in is_signaled. >> So from the core fence framework I think we already have exactly this, >> and we only need to adjust the radeon implementation a...

...l have_drawable_releases; + unsigned long cur, end = jiffies + timeout; + + qdev = container_of(fence->lock, struct qxl_device, release_lock); + release = container_of(fence, struct qxl_release, base); + have_drawable_releases = release->type == QXL_RELEASE_DRAWABLE; + +retry: + sc++; + + if (fence_is_signaled_locked(fence)) + goto signaled; + + qxl_io_notify_oom(qdev); + + for (count = 0; count < 11; count++) { + if (!qxl_queue_garbage_collect(qdev, true)) + break; + + if (fence_is_signaled_locked(fence)) + goto signaled; + } + + if (fence_is_signaled_locked(fence)) + goto signaled; + + if (h...

...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 that is interested in the fence state, together with fence_wait if it wants to block and not just wants to know the momentary fence state. All the other functions (the stuff that adds callbacks and the various _locked and other versions) are just for fancy special cases. &gt...