similar to: [RFC PATCH v1 00/16] Convert all ttm drivers to use the new reservation interface

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

From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the

Only one type was ever used. This is needed to simplify the fence support in the next commit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 5 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 ++------- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 50

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

Final driver! \o/ This is not a proper dma_fence because the hardware may never signal anything, so don't use dma-buf with qxl, ever. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/qxl/Makefile | 2 drivers/gpu/drm/qxl/qxl_cmd.c | 5 - drivers/gpu/drm/qxl/qxl_debugfs.c | 12 ++- drivers/gpu/drm/qxl/qxl_drv.h | 22 ++---

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes

--- drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +------- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +--- drivers/gpu/drm/nouveau/nouveau_fence.h | 2 drivers/gpu/drm/nouveau/nouveau_gem.c | 16 ++- drivers/gpu/drm/qxl/qxl_debugfs.c | 6 + drivers/gpu/drm/qxl/qxl_drv.h | 2 drivers/gpu/drm/qxl/qxl_kms.c | 1

--- drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +------- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +--- drivers/gpu/drm/nouveau/nouveau_fence.h | 2 drivers/gpu/drm/nouveau/nouveau_gem.c | 16 ++- drivers/gpu/drm/qxl/qxl_debugfs.c | 6 + drivers/gpu/drm/qxl/qxl_drv.h | 2 drivers/gpu/drm/qxl/qxl_kms.c | 1

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

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

nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68 ++++++++++++++++++++++++++++++-

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

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:

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:

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

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

No users are left, kill it off! :D Conversion to the reservation api is next on the list, after that the functionality can be restored with rcu. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++------- drivers/gpu/drm/nouveau/nouveau_display.c | 6 -- drivers/gpu/drm/nouveau/nouveau_gem.c | 16 +-----

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

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: