similar to: [PATCH] drm/nouveau: idle all channels before suspending

Not holding the mutex potentially causes corruption of the kernel channel when page flipping. Cc: stable at vger.kernel.org #3.13 Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 29c3efdfc7dd..76e3cf025c10 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c

This adds some basic debug information about the internal nouveau state. making it slightly easier to determine which bo belongs to which vm address, as long as that program is still running. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/vm.h b/drivers/gpu/drm/nouveau/core/include/subdev/vm.h index

Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_drm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drm/nouveau_drm.c b/drm/nouveau_drm.c index 65910e3..9eb90a6 100644 --- a/drm/nouveau_drm.c +++ b/drm/nouveau_drm.c @@ -562,21 +562,22 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime) NV_INFO(drm, "evicting

If there are no channels, chan would never end up being NULL, and so the null pointer check would fail. Solve this by initializing chan to NULL, and iterating over temp instead. Fixes oops when running intel-gpu-tools/tests/kms_flip, which attempts to do some intel ioctl's on a nouveau device. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at

nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check

If either idling channels or suspending the fence were to fail, the display would never be resumed. Also if a client fails, resume the fence (not functionally important, but it would potentially leak memory). See https://bugs.freedesktop.org/show_bug.cgi?id=70213 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested, but makes sense given that the bug report has cursor setting

The ffsll function is a lot slower than the __ffs64 built-in which compiles to a single instruction on 64-bit. It's also nice to avoid custom versions of standard functions. Note that __ffs == ffs - 1. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I wrote a user-space program to test these out and make sure that the functions behaved as expected. The logic in abi16 had to be

On 23/12/14 10:40, Vince Hsu wrote: > This patch adds some checks in the suspend/resume functions to distinguish > the dGPU and mobile GPU and exports some variables/functions so that the > nouveau platform device can reuse them. > Hi Vince, Afaiu one needs to export a symbol as it's used by another module or subsystem. With the follow up two patches you are not doing either one,

Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot <acourbot

Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on architectures for which coherency is not guaranteed by the bus. Signed-off-by: Alexandre Courbot <acourbot

When `nouveau_dmem_copy_one` is called, the following error occurs: [272146.675156] nouveau 0000:06:00.0: fifo: PBDMA9: 00000004 [HCE_PRIV] ch 1 00000300 00003386 This indicates that a copy push command triggered a Host Copy Engine Privileged error on channel 1 (Copy Engine channel). To address this issue, modify the Copy Engine channel to allow privileged push commands Fixes: 6de125383a5cc

From: Yonatan Maman <Ymaman at Nvidia.com> When `nouveau_dmem_copy_one` is called, the following error occurs: [272146.675156] nouveau 0000:06:00.0: fifo: PBDMA9: 00000004 [HCE_PRIV] ch 1 00000300 00003386 This indicates that a copy push command triggered a Host Copy Engine Privileged error on channel 1 (Copy Engine channel). To address this issue, modify the Copy Engine channel to allow

Fence lock needs to be initialized before any call to nouveau_channel_put because it calls nouveau_channel_idle->nouveau_fence_update which uses fence lock. BUG: spinlock bad magic on CPU#0, test/24134 lock: ffff88019f90dba8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 Pid: 24134, comm: test Not tainted 3.0.0-nv+ #800 Call Trace: spin_bug+0x9c/0xa3 do_raw_spin_lock+0x29/0x13c

Unmapping it while it's still in use (e.g. by M2MF) can lead to page faults and a lot of TRAP_M2MF spam in dmesg. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index 4124192..3b6dc88 100644

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:

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

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- nouveau/abi16.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++----- nouveau/nouveau.c | 56 +++++++------------------------------------------ nouveau/private.h | 7 ++----- 3 files changed, 67 insertions(+), 58 deletions(-) diff --git a/nouveau/abi16.c b/nouveau/abi16.c index

This patch adds some checks in the suspend/resume functions to distinguish the dGPU and mobile GPU and exports some variables/functions so that the nouveau platform device can reuse them. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau_drm.c | 16 +++++++++++----- drm/nouveau_drm.h | 2 ++ 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/drm/nouveau_drm.c

Regression from "drm/nve0: use async copy engine for ttm buffer moves if available". Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 325b8cb..dc04395 100644 ---

Hi Emil, On 12/30/2014 10:34 AM, Emil Velikov wrote: > On 23/12/14 10:40, Vince Hsu wrote: >> This patch adds some checks in the suspend/resume functions to distinguish >> the dGPU and mobile GPU and exports some variables/functions so that the >> nouveau platform device can reuse them. >> > Hi Vince, > > Afaiu one needs to export a symbol as it's used by