similar to: [PATCH] drm/nouveau: resume display if any later suspend bits fail

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

Seems to make suspend slightly more reliable on my system. Cc: stable at vger.kernel.org [3.7+] Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b6bdc9f..5032c31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -464,6

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

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

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,

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

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

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

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

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

It can help to remove any ambiguity about which options were passed to Nouveau, especially in case the user had some options set in /etc/modprobe.d/*.conf that he forgot about, as they won't appear in a dmesg. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau_chan.c | 2 +- drm/nouveau_chan.h | 2 ++ drm/nouveau_connector.c | 6 +++---

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

Since commit 0fa9061ae8c ("drm/nouveau/mc: handle irq-related setup ourselves"), drm_device->irq_enabled remained unset. This is needed in order to properly wait for a vblank event in the generic drm code. See https://bugs.freedesktop.org/show_bug.cgi?id=74195 Reported-by: Jan Janecek <janjanjanx at gmail.com> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc:

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

before: "nouveau E[X[3162]] failed to idle channel 0xcccc0000 [X[3162]]" after: "nouveau E[X[3162]] failed to idle channel: -16" Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_chan.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c

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

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #41 from Ilia Mirkin <imirkin at alum.mit.edu> --- The fix for that compilation issue is contained in d1b167e168bdac0b6af11e7a8c601773639fc419 Basically you need to make nouveau_channel_idle return an int, and just stick a 'return ret' at the end. And adjust the prototype in nouveau_drv.h. -- You are receiving this

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng