similar to: [PATCH 1/2] drm/nv04: Fix NV04 set_operation software method.

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv04_graph.c | 571 ++++++++++++++++++++++++++++++++-- 1 files changed, 538 insertions(+), 33 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_graph.c b/drivers/gpu/drm/nouveau/nv04_graph.c index d96c351..1b0af3a 100644 --- a/drivers/gpu/drm/nouveau/nv04_graph.c +++

From: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_channel.c | 2 -- drivers/gpu/drm/nouveau/nouveau_drv.h | 1 - drivers/gpu/drm/nouveau/nouveau_fence.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nv04_graph.c | 1 - 4 files changed, 4 insertions(+), 28 deletions(-) diff

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

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

--- drivers/gpu/drm/nouveau/nouveau_state.c | 52 ++++++++++++++++--------------- 1 files changed, 27 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 2ed41d3..25d207c 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

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

Commit f4ebcd133b9 ("dri/nouveau: NV17_3D class is not available for NV1a chipset") fixed this partially by using the correct 3d class. However there were a lot of checks left over comparing against the chipset. Reported-and-tested-by: John F. Godfrey <jfgodfrey at gmail.com> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I guess I didn't have to change the

We want to be able to guarantee the location of the allocated buffer object if we're going to be able to reliably allocate the existing framebuffer at startup. Add an argument to do so and pass that through to the ttm core. Signed-off-by: Matthew Garrett <mjg at redhat.com> --- drivers/bcma/main.c | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++++++-

http://bugs.freedesktop.org/show_bug.cgi?id=14010 Summary: TNT2 generate too much noise in logs Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

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

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:

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

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

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

Today I tried Ubuntu-10.04 on a system with an NV34 (Geforce-5200) AMD-751 (Ironlake) Northbridge, however the kernel-module fails to initialize. Any idea what could be going wrong? Thank you in advance, Clemens PS: I filed a bug at ubuntu's launchpad: https://bugs.launchpad.net/ubuntu/+bug/580656 May 14 19:17:28 max-desktop kernel: [ 3.266782] [drm] Initialized drm 1.1.0 20060810 May

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.

This will fix races between generated ctxprogs and interrupt handler. Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv50_grctx.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_grctx.c b/drivers/gpu/drm/nouveau/nv50_grctx.c index d105fcd..9f909ab 100644 ---

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

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

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