similar to: [PATCH] drm/nouveau: Unregister irq handler if init fails

--- drivers/gpu/drm/nouveau/nouveau_state.c | 73 ++++++++++++++++++++----------- 1 files changed, 48 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 2ed41d3..9fc5824 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -317,7 +317,7 @@ nouveau_card_init(struct

- Use the "direct" objects that previously only the kernel fifo had. - This avoids corruption on some buffer moves. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 23 ++--------------- drivers/gpu/drm/nouveau/nouveau_object.c | 36 ++++++++++++++++++++++++++++ drivers/gpu/drm/nouveau/nouveau_state.c | 38

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv04_graph.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_graph.c b/drivers/gpu/drm/nouveau/nv04_graph.c index 396ee92..d561d77 100644 --- a/drivers/gpu/drm/nouveau/nv04_graph.c +++ b/drivers/gpu/drm/nouveau/nv04_graph.c @@ -543,7 +543,7 @@

http://bugs.freedesktop.org/show_bug.cgi?id=11868 Summary: Starting X for the second time fails (without reloading drm modules) Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

Compiled, tested. Look ok. -- Jabber/XMPP: okias at isgeek.info SIP VoIP: sip:17474537254 at proxy01.sipphone.com -------------- next part -------------- This patch remove leftover from UMS. Signed-off-by: David Heidelberger <d.okias at gmail.com> --- diff -Naur a/drivers/gpu/drm/nouveau/nouveau_dma.c b/drivers/gpu/drm/nouveau/nouveau_dma.c --- a/drivers/gpu/drm/nouveau/nouveau_dma.c

noaccel=1 disables all acceleration and doesn't even attempt initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon unaccelerated. Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nouveau_drv.c | 8 +++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_fbcon.c | 10 ++++++--

The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. Signed-off-by: Henrik Rydberg <rydberg at euromail.se> --- Hi Ben, this patch is still needed in 3.6-rc1, so perhaps we should apply it after all. I

Hello, I am kernel engineer working on PV-OPS kernel trying to get it work in Dom0 with an NVidia (NV30 right now) card. But there are issues, such as that the pv-ops kernel has a different understanding of memory (for details check out: http://wiki.xensource.com/xenwiki/XenPVOPSDRM). I've fleshed out most of them (like GART had the wrong phys addresses, ouch!), but the one that I am

Hi Ben, Dave, Since 3.5-rc0, I have been experiencing occasional screen corruption on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver version is xf86-video-nouvea-1.0.1-1 (arch). I do not know what the root problem is, but I have been able to isolate the symptoms to the usage of nva3_copy.c. The patch below is the least intrusive way I could find which kills the symptoms.

nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68 ++++++++++++++++++++++++++++++-

Hi Patch "drm/nouveau: use drm_mm in preference to custom code doing the same thing" in nouveau tree introduced new deadlock possibility, for which lockdep complains loudly: [ 1541.070202] [drm] nouveau 0000:02:00.0: Allocating FIFO number 3 [ 1541.084772] [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 3 [ 2417.733440] [drm] nouveau 0000:02:00.0:

- In the case of nvbo->head it is really important to avoid an OOPS if ttm_buffer_object_init fails. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 ++ drivers/gpu/drm/nouveau/nouveau_channel.c | 1 + drivers/gpu/drm/nouveau/nouveau_object.c | 1 + 3 files changed, 4 insertions(+), 0 deletions(-) diff --git

Overall idea: Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, handle them at ioctl level, reset the GPU and repeat last ioctl. GPU reset is done by doing suspend / resume cycle with few tweaks: - CPU-only bo eviction - ignoring vm flush / fence timeouts - shortening waits Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- Tested only on nv92. ---

Several nvidia-based systems don't support backlight control via the standard ACPI control mechanisms. Instead, it's necessary for the driver to modify the backlight control registers directly. This patch adds support for determining whether the registers appear to be in use, and if so registers a kernel backlight device to control them. The backlight can then be controlled via

Changes in v2: - Addressed review comments nouveau_bo_wait will make the GPU channel wait for fence if possible, otherwise falling back to waiting with the CPU using ttm_bo_wait. The nouveau_fence_sync function currently returns -ENOSYS, and is the focus of the next patch. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 68

- 'joi' on irc pointed out that this triggers a BUG_ON, because kzalloc could sleep. - The irq handler should restore the value NV03_PFIFO_CACHES, but still it's better if this stuff doesn't happen in the middle of fifo create context. I see no reason in spin locking pgraph create context, it isn't activated at that stage. - Move and rename the lock after some discussion with

This adds basic support for driving sensor chips off the nvidia i2c buses, along with basic support for reading the internal GPU sensor on supported chipsets. It's heavily cribbed off nvclock. Having scanned a large number of bioses, I'm pretty convinced that the appropriate i2c bus is always number 2 in the list on <g80 - I'm not sure about later cards yet. There's still a lot

Overall idea: Detect lockups by watching for timeouts (vm flush / fence), return -EIOs, handle them at ioctl level, reset the GPU and repeat last ioctl. GPU reset is done by doing suspend / resume cycle with few tweaks: - CPU-only bo eviction - ignoring vm flush / fence timeouts - shortening waits Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> ---

Hi, Please find attached the patches which I currently use on my desktop machine for dual head with the randr branch to fix the issues which I found. They may help others as well but may e.g. also disable the Xv blitter which might be working for some (but didn't on my card) - more information is found in the text comments in the patches. I have to hurry so this is short, will be back.

- 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