similar to: [PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before > the rework to event interface, so I guess it got reintroduced. I don't know how/why you think this fixes anything. The interrupt handler can't possibly be called until after priv->base.vblank has

nv92 hardware has only 16 interrupt lines, while nv94 and later has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect PDISP setup. This is a regression introduced with commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3 Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon May 12 15:22:42 2014 +1000 gpio: split g92 class from nv50 Reported-by: estece on #nouveau Cc: stable

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

Drop vma_node from ttm_buffer_object, use the gem struct (base.vma_node) instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h

Drop vma_node from ttm_buffer_object, use the gem struct (base.vma_node) instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h

Drop vma_node from ttm_buffer_object, use the gem struct (base.vma_node) instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h

So... I was wondering what the impact of splitting up the card compilation by e.g. generation would be. Depending on the split things would get fairly intertwined, so I thought I'd start small. This just splits NVC0 from everything else. I figure that for the people this matters the most to, NVC0 is the least relevant card -- people with sub-1GB of RAM, older hardware. With my config options

Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have had my mouse pointer disappear soon after logging in, and I have observed the system freezing temporarily when clicking on objects and when typing text. I have also found records of push buffer errors in dmesg output: [ 6625.450394] nouveau 0000:01:00.0: disp: ERROR 1 [PUSHBUFFER_ERR] 02 [] chid 0 mthd 0000 data 00000400 I

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I decided to let the user still specify config=BLA=1 to override the hw disable in case we get something wrong or for double-checking stuff, but I suspect it won't really be used much. I'm not terribly fond of the message text, if you come up with something better, feel free to drop it in.

I don't see why the display engine would need write access to the entirety of vram, when read-only access is enough. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nv50_display.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

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

Op 30-07-13 04:42, Ben Skeggs schreef: > On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before >> the rework to event interface, so I guess it got reintroduced. > I don't know how/why you think this fixes anything. The interrupt >

Since the original merge of nouveau to upstream kernel, we were assuming that nv90 (and later) cards have 32 lines. Based on mmio traces of the binary driver, as well as PBUS error messages during read/write of the e070/e074 registers, we can conclude that nv92 has only 16 lines whereas nv94 (and later) cards have 32. Reported-and-tested-by: David M. Lloyd <david.lloyd at redhat.com>

Lockdep report [1] correctly identifies a potential deadlock between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due to inverted lock order of event->lock with drm core's dev->vblank_time_lock. Fix vblank event deadlock by converting event handler list to RCU. List updates remain serialized by event->lock. List traversal & handler execution is lockless which

This fixes a deadlock inversion when vblank is enabled/disabled by drm. &dev->vblank_time_lock is always taken when the vblank state is toggled, which caused a deadlock when &event->lock was also taken during event_get/put. Solve the race by requiring that lock to change enable/disable state, and always keeping vblank on the event list. Core drm ignores unwanted vblanks, so extra

On Tue, 25 Aug 2020 at 17:21, Alexander Kapshuk <alexander.kapshuk at gmail.com> wrote: > > Since upgrading to linux-next based on 5.9.0-rc1 and 5.9.0-rc2 I have > had my mouse pointer disappear soon after logging in, and I have > observed the system freezing temporarily when clicking on objects and > when typing text. > I have also found records of push buffer errors in

> Hi Gerd, > > I've been seeing a regression on Nouveau with recent linux-next releases > and git bisect points at this commit as the first bad one. If I revert > it (there's a tiny conflict with a patch that was merged subsequently), > things are back to normal. > > I think the reason for this issue is that Nouveau doesn't use GEM > objects for all buffer

On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > So... I was wondering what the impact of splitting up the card compilation by > e.g. generation would be. Depending on the split things would get fairly > intertwined, so I thought I'd start small. This just splits NVC0 from > everything else. I figure that for the people this matters the most to,

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This has received light testing on NV18 and NV34 cards, using the modetest tool. Userspace support to use this for xv is not yet ready. I decided against creating a new "pvideo" engine -- that just seems way too heavy-handed compared to the ~10 lines of code in disp/nv04.c to deal with the PVIDEO interrupts. Even though