similar to: [PATCH] drm/nouveau: fix nv84 fence context leak

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

From: Thierry Reding <treding at nvidia.com> The nouveau_fence_get_get_driver_name() function has a redundant _get in its name. Remove it. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c

dma_fence_default_wait is the default now. Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_fence.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 503fa94dc06d..444bbde65344

dma_fence_default_wait is the default now. Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_fence.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 503fa94dc06d..444bbde65344

dma_fence_default_wait is the default now. Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_fence.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index 412d49bc6e56..99be61ddeb75

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

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/radeon/radeon.h | 15 +-- drivers/gpu/drm/radeon/radeon_device.c | 1 drivers/gpu/drm/radeon/radeon_fence.c | 189 +++++++++++++++++++++++++------- 3 files changed, 153 insertions(+), 52 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index

op 15-05-14 11:42, Christian K?nig schreef: > Am 15.05.2014 11:38, schrieb Maarten Lankhorst: >> op 15-05-14 11:21, Christian K?nig schreef: >>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst: >>>> op 14-05-14 17:29, Christian K?nig schreef: >>>>>> + /* did fence get signaled after we enabled the sw irq? */ >>>>>> + if

> + /* did fence get signaled after we enabled the sw irq? */ > + if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >= fence->seq) { > + radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring); > + return false; > + } > + > + fence->fence_wake.flags = 0; > + fence->fence_wake.private = NULL; > + fence->fence_wake.func =

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:

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. Signed-off-by: Martin Peres <martin.peres at labri.fr> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv84.c | 19 ++++++++++++++++++- 1 file changed, 18

http://bugs.freedesktop.org/show_bug.cgi?id=25267 Summary: nv84 (GeForce 8600GT M) doesn't suspend with 2 cards but with 1 Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo:

On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Hey, > > Op 04-06-13 20:38, Ilia Mirkin schreef: >> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >>> These chipsets include the VP2 engine which is composed of a bitstream >>> processor (BSP) that decodes H.264 and a video

Am 15.05.2014 15:04, schrieb Maarten Lankhorst: > op 15-05-14 11:42, Christian K?nig schreef: >> Am 15.05.2014 11:38, schrieb Maarten Lankhorst: >>> op 15-05-14 11:21, Christian K?nig schreef: >>>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst: >>>>> op 14-05-14 17:29, Christian K?nig schreef: >>>>>>> + /* did fence get signaled

On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > This increases the chance slightly that recovery from lockup can happen > succesfully. I'd *really* love to see proof of this. When channels die, all outstanding fences are marked as signalled. This should do absolutely nothing... > > Signed-off-by: Maarten Lankhorst

Op 04-09-13 05:21, Ben Skeggs schreef: > On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> This increases the chance slightly that recovery from lockup can happen >> succesfully. > I'd *really* love to see proof of this. When channels die, all > outstanding fences are marked as signalled. This should do

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

https://bugs.freedesktop.org/show_bug.cgi?id=54359 Bug #: 54359 Summary: X crashes after resume (8600GT / NV84) Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

https://bugs.freedesktop.org/show_bug.cgi?id=95330 Bug ID: 95330 Summary: [NV84] Hangs with gr: DATA_ERROR [INVALID_BITFIELD], TRAP_PROP [RT_FAULT], fb: trapped write [PGRAPH] [PROP] [RT0] [PAGE_NOT_PRESENT], bsp: Watchdog interrupt, engine hung Product: xorg Version: unspecified