similar to: [PATCH] drm/nouveau: bump fence timeout to 150 seconds

Displaying 20 results from an estimated 4000 matches similar to: "[PATCH] drm/nouveau: bump fence timeout to 150 seconds"

2014 May 14
0
[RFC PATCH v1 07/16] drm/nouveau: rework to new fence interface
From: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/core/core/event.c | 4 drivers/gpu/drm/nouveau/nouveau_bo.c | 6 drivers/gpu/drm/nouveau/nouveau_display.c | 4 drivers/gpu/drm/nouveau/nouveau_fence.c | 434 ++++++++++++++++++++---------
2023 Aug 29
1
[PATCH drm-misc-next] drm/nouveau: fence: fix undefined fence state after emit
nouveau_fence_emit() can fail before and after initializing the dma-fence and hence before and after initializing the dma-fence' kref. In order to avoid nouveau_fence_emit() potentially failing before dma-fence initialization pass the channel to nouveau_fence_new() already and perform the required check before even allocating the fence. While at it, restore the original behavior of
2024 Jan 23
1
[PATCH] nouveau: rip out fence irq allow/block sequences.
From: Dave Airlie <airlied at redhat.com> fences are signalled on nvidia hw using non-stall interrupts. non-stall interrupts are not latched from my reading. When nouveau emits a fence, it requests a NON_STALL signalling, but it only calls the interface to allow the non-stall irq to happen after it has already emitted the fence. A recent change eacabb546271 ("nouveau: push event
2024 Jan 25
1
[PATCH] nouveau: rip out fence irq allow/block sequences.
On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote: > From: Dave Airlie <airlied at redhat.com> > > fences are signalled on nvidia hw using non-stall interrupts. > > non-stall interrupts are not latched from my reading. > > When nouveau emits a fence, it requests a NON_STALL signalling, > but it only calls the interface to allow the non-stall irq to happen
2012 Apr 22
1
[PATCH 2/5] drm/nouveau: base fence timeout on time of emission
Wait loop can be interrupted by signal, so if signals are raised periodically (e.g. SIGALRM) this loop may never finish. Use emission time as a base for fence timeout. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
2024 Jan 29
1
[PATCH] nouveau: offload fence uevents work to workqueue
From: Dave Airlie <airlied at redhat.com> This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 ++++++++++++++++++------ drivers/gpu/drm/nouveau/nouveau_fence.h | 1 + 2 files changed, 19
2010 Jan 06
0
[PATCH] Fix null deref in nouveau_fence_emit due to deleted fence
Currently Nouveau will unvalidate all buffers if it is forced to wait on one, and then start revalidating from the beginning. While doing so, it destroys the operation fence, causing nouveau_fence_emit to crash. This patch fixes this bug by taking the fence object out of validate_op and creating it just before emit. The fence pointer is initialized to 0 and unref'ed unconditionally. In
2024 Feb 22
1
[PATCH] drm/nouveau: use dedicated wq for fence uevents work
Using the kernel global workqueue to signal fences can lead to unexpected deadlocks. Some other work (e.g. from a different driver) could directly or indirectly depend on this fence to be signaled. However, if the WQ_MAX_ACTIVE limit is reached by waiters, this can prevent the work signaling the fence from running. While this seems fairly unlikely, it's potentially exploitable. Fixes:
2024 Feb 23
1
[PATCH] drm/nouveau: use dedicated wq for fence uevents work
On Fri, Feb 23, 2024 at 10:14:53AM +1000, Dave Airlie wrote: > On Fri, 23 Feb 2024 at 00:45, Danilo Krummrich <dakr at redhat.com> wrote: > > > > Using the kernel global workqueue to signal fences can lead to > > unexpected deadlocks. Some other work (e.g. from a different driver) > > could directly or indirectly depend on this fence to be signaled. > >
2010 May 31
2
[PATCH] drm/nouveau: reduce usage of fence spinlock to when absolutely necessary
From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 2 -- drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - drivers/gpu/drm/nouveau/nouveau_fence.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nv04_graph.c | 1 - 4 files changed, 4 insertions(+), 28 deletions(-) diff
2016 Sep 07
1
[PATCH] drm/nouveau: Skip fence context seqno check if notifies are enabled
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:
2015 Oct 10
2
[PATCH] nouveau: avoid emitting new fences unnecessarily
Right now we emit on every kick, but this is only necessary if something will ever be able to observe that the fence completed. If there are no refs, leave the fence alone and emit it another day. This also happens to work around an issue for the kick handler -- a kick can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be due to lack of space in the pushbuf. We want the emit to
2012 Apr 22
2
[RFC PATCH 5/5] drm/nouveau: gpu lockup recovery
Overall idea: Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, handle them at ioctl level, reset the GPU and repeat last ioctl. GPU reset is done by doing suspend / resume cycle with few tweaks: - CPU-only bo eviction - ignoring vm flush / fence timeouts - shortening waits Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Tested only on nv92. ---
2016 Nov 04
0
[PATCH] nouveau: remove unused variables
I am a little unsure about the change in nouveau_fence, maybe somebody with more knowledge about the code can look into it? Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/dispnv04/arb.c | 6 ++---- drm/nouveau/nouveau_fence.c | 2 -- drm/nouveau/nvkm/subdev/fb/ramgk104.c | 4 +--- 3 files changed, 3 insertions(+), 9 deletions(-) diff --git
2013 Sep 02
2
[PATCH] drm/nv84-: write fence value on exit, and restore value on init.
This increases the chance slightly that recovery from lockup can happen succesfully. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nv84_fence.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c b/drivers/gpu/drm/nouveau/nv84_fence.c index 2cf0ade..daf4b18 100644 ---
2018 Nov 15
1
[PATCH -next] drm/nouveau: fix copy-paste error in nouveau_fence_wait_uevent_handler
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/nouveau/nouveau_fence.c: In function 'nouveau_fence_wait_uevent_handler': drivers/gpu/drm/nouveau/nouveau_fence.c:156:27: warning: variable 'chan' set but not used [-Wunused-but-set-variable] nouveau_fence_update should use rcu protected 'chan' rather than 'fence->channel' Fixes:
2020 Jan 10
1
[PATCH] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
Like other cases, it should use rcu protected 'chan' rather than 'fence->channel' in nouveau_fence_wait_uevent_handler. Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu") Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- 1 file changed, 1 insertion(+), 1
2009 Dec 25
1
[PATCH] drm/nv50: synchronize user channel after buffer object move on kernel channel
- This is not yet a generic implementation that will work everywhere, but it's a start. - This will fix the corruption surrounding pixmap/texture bo moves on nv50. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 ++- drivers/gpu/drm/nouveau/nouveau_channel.c | 9 ++- drivers/gpu/drm/nouveau/nouveau_dma.c | 26
2020 Feb 14
0
[PATCH AUTOSEL 5.5 357/542] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ] Like other cases, it should use rcu protected 'chan' rather than 'fence->channel' in nouveau_fence_wait_uevent_handler. Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu") Signed-off-by: YueHaibing
2020 Feb 14
0
[PATCH AUTOSEL 5.4 311/459] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler
From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 1eb013473bff5f95b6fe1ca4dd7deda47257b9c2 ] Like other cases, it should use rcu protected 'chan' rather than 'fence->channel' in nouveau_fence_wait_uevent_handler. Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and protect with rcu") Signed-off-by: YueHaibing