similar to: [PATCH] drm/nouveau: bring back blit subchannel for pre nv50 GPUs

1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128 was important as otherwise the GPU spams us with `CACHE_ERROR` messages. We use the blit subchannel inside our vblank handling, so we should keep at least this part. v2: Only do it for NV11+ GPUs Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/201 Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev

On Fri, May 26, 2023 at 5:11?AM Karol Herbst <kherbst at redhat.com> wrote: > > 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128 > was important as otherwise the GPU spams us with `CACHE_ERROR` messages. > > We use the blit subchannel inside our vblank handling, so we should keep > at least this part. > > v2: Only do it for NV11+ GPUs > >

Trying to build parisc:allmodconfig with gcc 12.x or later results in the following build error. drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: 'memcpy' accessing 4294967264 or more bytes at offsets 0 and 32 overlaps 6442450881 bytes at offset -2147483617 [-Werror=restrict] 161 | memcpy(data,

Trying to build parisc:allmodconfig with gcc 12.x or later results in the following build error. drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: 'memcpy' accessing 4294967264 or more bytes at offsets 0 and 32 overlaps 6442450881 bytes at offset -2147483617 [-Werror=restrict] 161 | memcpy(data,

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

(adding linux-hardening at vger.kernel.org) Le 18/05/2024 ? 16:37, Guenter Roeck a ?crit?: > Trying to build parisc:allmodconfig with gcc 12.x or later results > in the following build error. > > drivers/gpu/drm/nouveau/nvif/object.c: In function 'nvif_object_mthd': > drivers/gpu/drm/nouveau/nvif/object.c:161:9: error: > 'memcpy' accessing 4294967264 or more

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. The driver's internal implementation later got accidentally restored during a merge commit. Remove the file from the driver. No functional changes. v2: * point Fixes tag to merge commit (Alex) Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>

Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") converted nouveau to generic fbdev emulation. Also remove the internal implementation from the driver. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") Cc: Ben Skeggs <bskeggs at redhat.com> Cc:

On Fri, 2020-10-23 at 11:01 +0200, Sebastian Andrzej Siewior wrote: > On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote: > > I've only as yet seen nouveau lockdep gripage when firing up one of my > > full distro KVM's. > > Could you please check !RT with the `threadirqs' command line option? I > don't think RT is doing here anything different (except for

On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") > converted nouveau to generic fbdev emulation. Also remove the internal > implementation from the driver. No functional changes. Looking at 4a16dd9d18a0, it appears to have removed this file already. I guess it

Hi Am 09.01.23 um 15:15 schrieb Alex Deucher: > On Mon, Jan 9, 2023 at 9:06 AM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers") >> converted nouveau to generic fbdev emulation. Also remove the internal >> implementation from the driver. No functional changes. > > Looking

On Fri, 23 Oct 2020 14:07:13 +0200 Mike Galbraith wrote: > On Fri, 2020-10-23 at 11:01 +0200, Sebastian Andrzej Siewior wrote: > > On 2020-10-22 07:28:20 [+0200], Mike Galbraith wrote: > > > I've only as yet seen nouveau lockdep gripage when firing up one of my > > > full distro KVM's. > > > > Could you please check !RT with the `threadirqs'

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

- 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

Fixes GART leak (as accounted by nouveau_drm.gem.gart_available). Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Running glxinfo in a loop is enough to trigger it - after several thousand runs (depending on GART size), X server crashes and does not come back in a correct state (corruptions and crashes). With this patch applied, it's possible again to do full piglit

It will be useful for various synchronization purposes, mostly stolen from "[PATCH] drm/nv50: synchronize user channel after buffer object move on kernel channel" by Maarten Maathuis. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 4 +++- drivers/gpu/drm/nouveau/nouveau_dma.c | 17 +++++++++++++++++

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

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

NACK. This patches breaks MP performance counters on Fermi/Kepler because they actually use software methods to configure multiplexers. Global perf counters will also use software methods to init, sample and read hardware counters, so this SW object is definitely needed. Instead of removing it, we need to do something like that: http://paste.awesom.eu/EQeX Thanks. On 11/27/2015 02:05 AM,

Commit "drm/nouveau: port all engines to new engine module format" changed IB size calculation to be less wasteful, but didn't take into account already existing off-by-one bugs :). So: - ib_max is the last entry, so we need to +1 when calculating number of free entries - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1 on nouveau_gem_ioctl_pushbuf