BEGIN_RING also does autobind, the rest seems ok.
Maarten.
On Sun, Mar 14, 2010 at 2:53 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 14.03.2010 13:03, Maarten Maathuis wrote:
On Sun, Mar 14, 2010 at 11:32 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
Hi
Ping?
On Mon, Mar 1, 2010 at 9:55 PM, Jerome Glisse gli...@freedesktop.org wrote:
On Mon, Mar 01, 2010 at 07:34:39PM +0100, Maarten Maathuis wrote:
- A few comments existed here and there that referred to a bo-mutex.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Reviewed-by: Jerome
On Mon, Mar 8, 2010 at 10:06 PM, Lev A. Melnikovsky melnikov...@mail.ru wrote:
...please, could someone investigate this? I'd be glad to provide more
info or test patches or whatever...
On Sun, 28 Feb 2010 at 6:50pm, Lev A. Melnikovsky wrote:
LAM Hi there,
LAM
LAM I have just decided to
On Fri, Mar 5, 2010 at 2:23 AM, Dave Airlie airl...@gmail.com wrote:
So with all this ongoing Linus crap I'm going to be brave and ask for
reasons why
0.0.16 kernel API can't become 1.0.0.
Pros:
All old userspace compatibility is gone.
No more UMS cruft to support.
Something can be shipped
people that get to keep the
pieces.
Sincerely,
Maarten Maathuis.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications
On Thu, Mar 4, 2010 at 10:21 PM, Maarten Maathuis madman2...@gmail.com wrote:
On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Hmm. What the hell am I supposed to do about
(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
(EE) NOUVEAU
On Thu, Mar 4, 2010 at 7:18 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Hmm. What the hell am I supposed to do about
(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
(EE) NOUVEAU(0): 879:
now?
pushed.
On Mon, Mar 1, 2010 at 10:26 PM, Francisco Jerez curroje...@riseup.net wrote:
Acked-by: Francisco Jerez curroje...@riseup.net
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
- A few comments existed here and there that referred to a bo-mutex.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/ttm/ttm_bo.c|6 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
include/drm/ttm/ttm_bo_api.h|3 +--
include/drm/ttm/ttm_bo_driver.h
- The headerfile says you can't write to it without holding the lock.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
- pre-nv50 has one too (in WRITE_PUT).
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_dma.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c
b/drivers/gpu/drm/nouveau/nouveau_dma.c
index
- Currently reloc'ing a user bo to gart will first cause an allocation in vram,
which is then cpu written to, then the bo gets moved to gart.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
nouveau/nouveau_reloc.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff
On Tue, Feb 23, 2010 at 6:59 AM, Dave Airlie airl...@gmail.com wrote:
On Sat, Feb 20, 2010 at 12:22 PM, Maarten Maathuis madman2...@gmail.com
wrote:
- Without this change I get a general protection fault.
- Also use PTR_ERR where applicable.
I just want to make sure I understand, but really
- Without this change I get a general protection fault.
- Also use PTR_ERR where applicable.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/ttm/ttm_tt.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm
I am not a member, which says something already. But in short
everything surrounding the board has never tempted to sign up or vote.
Apart from hosting a few servers i never knew what they were doing.
This situation has somewhat improved but it's still vague. At the
moment i still do not feel the
I don't mind, i just thought this was preferred. I did gave you the
final sign-off, to indicate you were the final author.
2010/2/17 Michel Dänzer mic...@daenzer.net:
On Tue, 2010-02-16 at 22:55 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used for acceleration, any decent memory
Both patches are functional on their own, Michel's patch just makes it prettier.
2010/2/17 Dave Airlie airl...@gmail.com:
2010/2/17 Michel Dänzer mic...@daenzer.net:
On Tue, 2010-02-16 at 22:55 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used for acceleration, any decent memory
On Tue, Feb 16, 2010 at 11:00 AM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
Am Dienstag, 16. Februar 2010 09:53:58 schrieb Ben Skeggs:
On Tue, 2010-02-16 at 09:25 +0100, Johannes Obermayr wrote:
Hi,
Ben Skeggs latest changes in Mesa cause a build failure (libdrm is latest
git
On Tue, Feb 16, 2010 at 11:00 AM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
Am Dienstag, 16. Februar 2010 09:53:58 schrieb Ben Skeggs:
On Tue, 2010-02-16 at 09:25 +0100, Johannes Obermayr wrote:
Hi,
Ben Skeggs latest changes in Mesa cause a build failure (libdrm is latest
git
.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
exa/exa_migration_mixed.c | 48
1 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa
The channel/context switch lock related patches (to the best of
knowledge) haven't even gone outside the nouveau tree, so the initial
damage isn't even there. At least not for the first path. As for the
2nd patch, that one was squished into the original patch for this pull
iirc.
Maarten.
On Mon,
The channel/context switch lock related patches (to the best of
knowledge) haven't even gone outside the nouveau tree, so the initial
damage isn't even there. At least not for the first path. As for the
2nd patch, that one was squished into the original patch for this pull
iirc.
Maarten.
On Mon,
2010/2/15 Michel Dänzer mic...@daenzer.net:
On Thu, 2010-02-11 at 20:06 +0100, Maarten Maathuis wrote:
2010/2/11 Michel Dänzer mic...@daenzer.net:
Thanks for tackling this, Maarten!
On Thu, 2010-02-11 at 19:05 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used
.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/exa/exa_migration_mixed.c b/exa/exa_migration_mixed.c
index 6816e6c..d200917 100644
--- a/exa/exa_migration_mixed.c
+++ b
One possibility would be to put exaDoMigration with src with preg on
the deferred pixmap list, i haven't tested this, but i could try this
evening or tomorrow.
Maarten.
2010/2/11 Maarten Maathuis madman2...@gmail.com:
2010/2/11 Michel Dänzer mic...@daenzer.net:
Thanks for tackling
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps with preg are incomplete (in the gpu pixmap), so also put them
on the deferred pixmap list.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c | 31
This is the other way to do it.
On Fri, Feb 12, 2010 at 7:02 PM, Maarten Maathuis madman2...@gmail.com wrote:
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps with preg are incomplete (in the gpu pixmap), so also put
them
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps may need updating, so move in the pixmap unconditionally, it
should be a no-op in most cases anyway.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
exa/exa_migration_mixed.c
This should be exa/mixed instead of exa.
On Thu, Feb 11, 2010 at 7:05 PM, Maarten Maathuis madman2...@gmail.com wrote:
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps may need updating, so move in the pixmap unconditionally
2010/2/11 Michel Dänzer mic...@daenzer.net:
Thanks for tackling this, Maarten!
On Thu, 2010-02-11 at 19:05 +0100, Maarten Maathuis wrote:
- A mapped pixmap can't be used for acceleration, any decent memory manager
will refuse this.
- Source pixmaps may need updating, so move in the pixmap
What happens if you have two cards, one RS200 and one RV280 (just an
example). I think you shouldn't change values in a static struct.
On Wed, Feb 10, 2010 at 11:10 PM, Pauli Nieminen suok...@gmail.com wrote:
r200 cards have dma engine which can be used to tranfer data
between vram and system
Pushed as announced.
On Mon, Feb 8, 2010 at 6:39 PM, Maarten Maathuis madman2...@gmail.com wrote:
Added the Tested-by, added Marcin's real name. And added a spin
unlock in the nv50 fifo failure path.
Will push in a day if there are no further comments.
Maarten.
On Mon, Feb 8, 2010 at 6:38
Thanks for pointing that out, is it preferred to use goto style
failure or just stick the spin unlock everywhere where you return?
Maarten.
On Mon, Feb 8, 2010 at 11:30 AM, Pekka Paalanen p...@iki.fi wrote:
On Sun, 7 Feb 2010 02:11:20 +0100
Maarten Maathuis madman2...@gmail.com wrote
Added the Tested-by, added Marcin's real name. And added a spin
unlock in the nv50 fifo failure path.
Will push in a day if there are no further comments.
Maarten.
On Mon, Feb 8, 2010 at 6:38 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Marcin Slusarz pointed out that this triggers
2010/2/8 Marcin Kościelnicki koria...@0x04.net:
Signed-off-by: Marcin Kościelnicki koria...@0x04.net
---
drivers/gpu/drm/nouveau/nouveau_state.c | 7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c
, it isn't activated at that
stage.
- Move and rename the lock after some discussion with 'joi', even better naming
suggestions are appreciated.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_channel.c |9 ++---
drivers/gpu/drm/nouveau/nouveau_drv.h
On Thu, Feb 4, 2010 at 11:58 AM, Adrian Knoth a...@drcomp.erfurt.thur.de
wrote:
On Tue, Feb 02, 2010 at 02:35:04PM +0100, Maarten Maathuis wrote:
Hi!
When the X pointer changes from arrow to the vertical text selection
bar, firewire streaming is interrupted. Same with scrolling in firefox
On Thu, Feb 4, 2010 at 1:38 PM, Adrian Knoth a...@drcomp.erfurt.thur.de wrote:
On Thu, Feb 04, 2010 at 12:19:14PM +0100, Maarten Maathuis wrote:
Hi!
When the X pointer changes from arrow to the vertical text selection
bar, firewire streaming is interrupted. Same with scrolling in firefox
Pushed as announced, with a few minor style changes that checkpatch pointed out.
On Wed, Feb 3, 2010 at 7:02 PM, Maarten Maathuis madman2...@gmail.com wrote:
Patches 4-6 will be pushed tomorrow if there are no objections.
Acks or comments appreciated as usual.
Maarten.
On Tue, Feb 2, 2010
1-3 pushed as announced.
On Tue, Feb 2, 2010 at 10:37 PM, Maarten Maathuis madman2...@gmail.com wrote:
I intend to push patch 1-3 tomorrow if there are no objections.
Acks are appreciated as usual.
On Tue, Feb 2, 2010 at 10:36 PM, Maarten Maathuis madman2...@gmail.com
wrote:
- ramfc
Patches 4-6 will be pushed tomorrow if there are no objections.
Acks or comments appreciated as usual.
Maarten.
On Tue, Feb 2, 2010 at 10:36 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Under some rare conditions i've managed to get pgraph errors after the
channel is closed, which has
users or splitting vram into 2
zones.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index
- ramfc is zero'ed upon destruction, so it's safer to do things in the right
order.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nv50_fifo.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_fifo.c
b
- Unset the bit that indicates that a ctxprog can continue at the end.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_irq.c | 139 ++---
1 files changed, 75 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
- The nv50 pgraph handler (for example) could reenable pgraph fifo access and
that would be bad when pgraph context is being unloaded (we need the garuantee
a ctxprog isn't running).
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_channel.c |9
is set as invalid. So remove them altogether.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_channel.c |7 +++
drivers/gpu/drm/nouveau/nv50_graph.c | 10 +++---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu
I intend to push patch 1-3 tomorrow if there are no objections.
Acks are appreciated as usual.
On Tue, Feb 2, 2010 at 10:36 PM, Maarten Maathuis madman2...@gmail.com wrote:
- ramfc is zero'ed upon destruction, so it's safer to do things in the right
order.
Signed-off-by: Maarten Maathuis
- Depth and stencil buffers are supposed to be large enough in general.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers
- ramfc is zero'ed upon destruction, so it's safer to do things in the right
order.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nv50_fifo.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_fifo.c
b
Someone should probably check this out on earlier cards as well.
On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis madman2...@gmail.com wrote:
- We need to disable pgraph fifo access before checking the current channel,
otherwise we could still hit a running ctxprog.
- The writes to 0x400500
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_irq.c | 140 ++---
1 files changed, 76 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c
b/drivers/gpu/drm/nouveau/nouveau_irq.c
index baa9b3e
is set as invalid. So remove them altogether.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nouveau_channel.c |7 +++
drivers/gpu/drm/nouveau/nv50_graph.c | 10 +++---
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu
I'm wondering if the write to 0x400824 should be outside the loop,
since it's a flag blocking a ctxprog from continuing.
Anyone know why this one wasn't looping but the pre-nv50 one is?
On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis madman2...@gmail.com wrote:
Signed-off-by: Maarten Maathuis
If there are no objections, please share them as soon as possible.
On Mon, Feb 1, 2010 at 7:40 PM, Maarten Maathuis madman2...@gmail.com wrote:
Someone should probably check this out on earlier cards as well.
On Mon, Feb 1, 2010 at 7:34 PM, Maarten Maathuis madman2...@gmail.com wrote:
- We
Acked-by: Maarten Maathuis madman2...@gmail.com
On Thu, Jan 28, 2010 at 10:33 PM, Maarten Maathuis madman2...@gmail.com wrote:
Looks sane to me, it would be nice if someone else also agreed, before
committing.
On Thu, Jan 28, 2010 at 5:28 PM, Luca Barbieri l...@luca-barbieri.com wrote
Looks sane to me, it would be nice if someone else also agreed, before
committing.
On Thu, Jan 28, 2010 at 5:28 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Please apply or state objections to this patch.
Thanks.
___
Nouveau mailing list
On Wed, Jan 27, 2010 at 8:16 AM, yakui.z...@intel.com wrote:
From: Zhao Yakui yakui.z...@intel.com
Sometimes one connector can support more than one connector type. And it
will switch the connector type/id dynamically according to the external
connected device.
I very much doubt it's the
On Thu, Jan 21, 2010 at 3:44 PM, Francisco Jerez curroje...@riseup.net wrote:
Luca Barbieri l...@luca-barbieri.com writes:
Nvidia cards have a synchronization primitive that could be used to
synchronize several FIFOs in hardware (AKA semaphores, see [1] for an
example).
Does this operate
On Thu, Jan 21, 2010 at 4:56 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Doing it without software methods means you need to have a semaphore
that exists in the cpu domain and therefore cannot be used again
until the cpu is sure it's done. So that will probably require a
rotating queue of
On Thu, Jan 21, 2010 at 3:44 PM, Francisco Jerez curroje...@riseup.net wrote:
Luca Barbieri l...@luca-barbieri.com writes:
Nvidia cards have a synchronization primitive that could be used to
synchronize several FIFOs in hardware (AKA semaphores, see [1] for an
example).
Does this operate
Could you resend these (not just this one) patches as proper git
send-email patches, those have authorship too, so they can be used
with git am.
Maarten.
On Tue, Jan 12, 2010 at 3:32 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
From: Marcin Slusarz marcin.slus...@gmail.com
Subject:
Sorry, this was a brainfart.
On Thu, Jan 14, 2010 at 11:30 PM, Maarten Maathuis madman2...@gmail.com wrote:
Could you resend these (not just this one) patches as proper git
send-email patches, those have authorship too, so they can be used
with git am.
Maarten.
On Tue, Jan 12, 2010 at 3:32
I'll push this one tomorrow.
On Thu, Jan 14, 2010 at 11:54 PM, Maarten Maathuis madman2...@gmail.com wrote:
Sorry, this was a brainfart.
On Thu, Jan 14, 2010 at 11:30 PM, Maarten Maathuis madman2...@gmail.com
wrote:
Could you resend these (not just this one) patches as proper git
send
I'll push this one tomorrow if there are no complaints.
On Tue, Jan 12, 2010 at 3:38 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
From: Marcin Slusarz marcin.slus...@gmail.com
Subject: [libdrm PATCH] nouveau: disable flush_notify on channel_free
We don't want do call flush_notify when
For completeness, track 8 means the pages are mapped write combined,
and req 16 means they were going to be mapped uncached (this is for
agp gart). This can be found in the x86 specific PAE code that is
invoked upon ioremap.
On Tue, Jan 12, 2010 at 1:10 AM, Xavier shinin...@gmail.com wrote:
On
On Mon, Jan 11, 2010 at 6:57 PM, Alex Deucher alexdeuc...@gmail.com wrote:
From 6d980869ef031752dac505c1aacbbe221fb2c6e7 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Mon, 11 Jan 2010 12:39:35 -0500
Subject: [PATCH] drm/radeon/kms/rv100: reject modes 135 Mhz on DVI
- This should fix the problem with gpu hangs people have had when closing
channels.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
drivers/gpu/drm/nouveau/nv50_graph.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b
This patch alone, so ignore the 3/3. I think this fixes the channel
unload hang issues in a less obscure way. Feedback appreciated as
usual.
On Mon, Jan 11, 2010 at 9:18 PM, Maarten Maathuis madman2...@gmail.com wrote:
- This should fix the problem with gpu hangs people have had when closing
This patch *is* alone, sorry for the typo.
On Mon, Jan 11, 2010 at 9:20 PM, Maarten Maathuis madman2...@gmail.com wrote:
This patch alone, so ignore the 3/3. I think this fixes the channel
unload hang issues in a less obscure way. Feedback appreciated as
usual.
On Mon, Jan 11, 2010 at 9:18
at 11:11 PM, Ben Skeggs skeg...@gmail.com wrote:
On Mon, 2010-01-11 at 22:12 +0100, Maarten Maathuis wrote:
A few comments are in order, i noticed that this additional
wait_for_idle does cause delays sometimes (obviously). and it seems
like an excellent way to do a DOS attack on your gpu. fbcon
page_address on x86_64,
since that doesn't have or need PAE or anything like that.
/Thomas
Maarten Maathuis wrote:
I've been noticing for a while that i've been getting general
protection faults in ttm_to_swapout, this time i was printk'ing the
virtual addresses.
In case it's not obvious
page_address on x86_64,
since that doesn't have or need PAE or anything like that.
/Thomas
Maarten Maathuis wrote:
I've been noticing for a while that i've been getting general
protection faults in ttm_to_swapout, this time i was printk'ing the
virtual addresses.
In case it's not obvious
I've been noticing for a while that i've been getting general
protection faults in ttm_to_swapout, this time i was printk'ing the
virtual addresses.
In case it's not obvious, the result of kmap_atomic() is wrong.
This is nouveau/linux-2.6 which is somewhere after 2.6.32. I was
wondering if
This is the patch
http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=aac125bb84c73a7637de5e85a6cc23ab81357552
Maybe a rebased patch went upstream (no idea if this happened already)?
Maarten.
On Sat, Jan 9, 2010 at 5:05 PM, Alexey Dobriyan adobri...@gmail.com wrote:
On Mon, Jan 04, 2010
I've been noticing for a while that i've been getting general
protection faults in ttm_to_swapout, this time i was printk'ing the
virtual addresses.
In case it's not obvious, the result of kmap_atomic() is wrong.
This is nouveau/linux-2.6 which is somewhere after 2.6.32. I was
wondering if
:55 PM, Maarten Maathuis madman2...@gmail.com wrote:
On Tue, Jan 5, 2010 at 10:19 PM, Maarten Maathuis madman2...@gmail.com
wrote:
On Tue, Jan 5, 2010 at 9:41 AM, Maarten Maathuis madman2...@gmail.com
wrote:
On Tue, Jan 5, 2010 at 4:20 AM, Ben Skeggs skeg...@gmail.com wrote:
On Mon, 2010-01
the patch line by line, and only agree with the
intention of the patch:
Acked-By: Maarten Maathuis madman2...@gmail.com
Assuming curro_ concerns are dealt with.
On Wed, Jan 6, 2010 at 9:59 PM, Francisco Jerez curroje...@riseup.net wrote:
Ben Skeggs skeg...@gmail.com writes:
I did a very quick
It should be Acked-by (notice the lack of capital b):
Acked-by: Maarten Maathuis madman2...@gmail.com
And curro_ == Francisco Jerez, i was thinking in irc mode.
On Wed, Jan 6, 2010 at 11:16 PM, Maarten Maathuis madman2...@gmail.com wrote:
I had a quick look, and i have nothing to add. I must
On Tue, Jan 5, 2010 at 4:20 AM, Ben Skeggs skeg...@gmail.com wrote:
On Mon, 2010-01-04 at 23:54 +0100, Maarten Maathuis wrote:
I forgot to mention that you should run nop from fbcon without X
running for reliable lockups.
Yup, that's what I've been doing.
On Mon, Jan 4, 2010 at 11:39 PM
Pushed after conformation that nv3x and nv4x work.
On Tue, Jan 5, 2010 at 3:19 AM, Younes Manton youne...@gmail.com wrote:
On Wed, Dec 30, 2009 at 4:36 PM, Maarten Maathuis madman2...@gmail.com
wrote:
- The previous solution was hacky and didn't do subchannel autobinding.
- The beheaviour
Update to the latest mesa, it's a know bug and the fix was finally
pushed about 20 minutes ago.
Maarten.
On Tue, Jan 5, 2010 at 7:28 PM, Tavian Barnes taviana...@gmail.com wrote:
I upgraded mesa, libdrm, xf86-video-nouveau and the DRM module to
latest git recently (previously I had git
On Tue, Jan 5, 2010 at 9:41 AM, Maarten Maathuis madman2...@gmail.com wrote:
On Tue, Jan 5, 2010 at 4:20 AM, Ben Skeggs skeg...@gmail.com wrote:
On Mon, 2010-01-04 at 23:54 +0100, Maarten Maathuis wrote:
I forgot to mention that you should run nop from fbcon without X
running for reliable
On Tue, Jan 5, 2010 at 10:19 PM, Maarten Maathuis madman2...@gmail.com wrote:
On Tue, Jan 5, 2010 at 9:41 AM, Maarten Maathuis madman2...@gmail.com wrote:
On Tue, Jan 5, 2010 at 4:20 AM, Ben Skeggs skeg...@gmail.com wrote:
On Mon, 2010-01-04 at 23:54 +0100, Maarten Maathuis wrote:
I forgot
On Tue, Jan 5, 2010 at 10:19 PM, Maarten Maathuis madman2...@gmail.com wrote:
On Tue, Jan 5, 2010 at 9:41 AM, Maarten Maathuis madman2...@gmail.com wrote:
On Tue, Jan 5, 2010 at 4:20 AM, Ben Skeggs skeg...@gmail.com wrote:
On Mon, 2010-01-04 at 23:54 +0100, Maarten Maathuis wrote:
I forgot
Module: Mesa
Branch: master
Commit: 29d2ab37e65c9242d01f63cc5376cb6929f9285f
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=29d2ab37e65c9242d01f63cc5376cb6929f9285f
Author: Marcin Slusarz marcin.slus...@gmail.com
Date: Tue Dec 29 00:36:17 2009 +0100
nouveau: kill nouveau_push.h and
Module: Mesa
Branch: master
Commit: c306ef5e81da5456d39a6e98cfc1f5f00b9c77a7
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=c306ef5e81da5456d39a6e98cfc1f5f00b9c77a7
Author: Maarten Maathuis madman2...@gmail.com
Date: Sun Dec 20 12:19:19 2009 +0100
nv50: remove vtxbuf stateobject
:36 PM, Maarten Maathuis madman2...@gmail.com wrote:
Many people using nv50+ hardware are aware of gpu lockups when a fifo
closes under certain conditions. Based on a mmio-trace and some trail
and error testing i've come up with a patch that improves the
situation on my NV96.
This patch needs
I forgot to mention that you should run nop from fbcon without X
running for reliable lockups.
On Mon, Jan 4, 2010 at 11:39 PM, Ben Skeggs skeg...@gmail.com wrote:
On Mon, 2010-01-04 at 20:29 +0100, Maarten Maathuis wrote:
I've narrowed it down further, the pgraph-fifo_access bit is still
2009/12/31 Maarten Maathuis madman2...@gmail.com:
Yes, i'm seeing these corruptions. Busy with something else atm though.
Maarten.
2009/12/31 Michel Dänzer mic...@daenzer.net:
On Wed, 2009-12-30 at 16:11 -0500, Andrew Chant wrote:
The output of git-bisect, which I verified by checking out
Please do report your successes, and not only failures.
On Sat, Jan 2, 2010 at 4:36 PM, Maarten Maathuis madman2...@gmail.com wrote:
Many people using nv50+ hardware are aware of gpu lockups when a fifo
closes under certain conditions. Based on a mmio-trace and some trail
and error testing
Does this patch help?
From f1fa2e3b15e24175fb899418bbe0d587237ca797 Mon Sep 17 00:00:00 2001
From: Maarten Maathuis madman2...@gmail.com
Date: Sun, 3 Jan 2010 02:14:36 +0100
Subject: [PATCH] exa: Some compat defines for depth 30 formats.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
Attempt 2, better?
From 061cb284b93612848296599759b915a4d66b6d01 Mon Sep 17 00:00:00 2001
From: Maarten Maathuis madman2...@gmail.com
Date: Sun, 3 Jan 2010 02:14:36 +0100
Subject: [PATCH] exa: Some compat defines for new pixman formats.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
I hope you did add a note for your victims :-)
On Sun, Jan 3, 2010 at 1:37 AM, Johannes Obermayr
johannesoberm...@gmx.de wrote:
Am Samstag, 2. Januar 2010 16:39:55 schrieb Maarten Maathuis:
Please do report your successes, and not only failures.
Hi,
I included it in my openSUSE Build
fallbacks.
Signed-off-by: Michel Dänzer daen...@vmware.com
Acked-By: Maarten Maathuis madman2...@gmail.com
Signed-off-by: Keith Packard kei...@keithp.com
:04 04 1f2bb220d39d1ea98fbe330b08786570fb089190
9cbf71dd4c6aa203c0f5220e88f9263f583a8faa M exa
Thanks
- This avoids problematic reloc'ed while mapped messages and
some associated corruption as well.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_screen.c | 21 +
src/gallium/drivers/nouveau/nouveau_screen.h |3 +++
src
debugging is on it will check
for abuse.
- The values for nv30/nv40 may be off, but this should be easily caught with
DEBUG on.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
src/gallium/drivers/nouveau/nouveau_stateobj.h | 289 +---
src/gallium/drivers/nv04/nv04_screen.c
Same patch from before, without the debatable unmap change.
On Wed, Dec 30, 2009 at 10:36 PM, Maarten Maathuis madman2...@gmail.com wrote:
- This avoids problematic reloc'ed while mapped messages and
some associated corruption as well.
Signed-off-by: Maarten Maathuis madman2...@gmail.com
The prerequisite patch (which kills nouveau_push) got stuck in queue
because of it's size.
This patch is here for discussion, and it needs testing on nv30/nv40
for miscalculated so sizes.
On Wed, Dec 30, 2009 at 10:36 PM, Maarten Maathuis madman2...@gmail.com wrote:
- The previous solution
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/28 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-12-28 at 13:27 +0100, Maarten Maathuis wrote:
Why does it help to allocate the sys_ptr up front, why does that avoid
migration (i would except sys_ptr to be allocated when needed
Acked-by: Maarten Maathuis madman2...@gmail.com
2009/12/28 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-12-28 at 16:05 +0100, Maarten Maathuis wrote:
2009/12/28 Michel Dänzer mic...@daenzer.net:
On Mon, 2009-12-28 at 13:51 +0100, Maarten Maathuis wrote:
I don't quite get why this has
201 - 300 of 858 matches
Mail list logo
