[Nouveau] [PATCH] drm/nouveau: enlarge GART aperture (v2)

2010-02-08 Thread Luca Barbieri
Changes in v2: - Compute size based on ramin_rsvd_size This patch enlarges the PCI GART aperture to 512 MB, or the space covered by a DMA object filling half RAMIN. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophistica

Re: [Nouveau] [PATCH] drm/nouveau: Add proper vgaarb support.

2010-02-08 Thread Ben Skeggs
On Mon, 2010-02-08 at 18:44 +0100, Maarten Maathuis wrote: > 2010/2/8 Marcin Kościelnicki : > > Signed-off-by: Marcin Kościelnicki > > --- > > drivers/gpu/drm/nouveau/nouveau_state.c |7 +++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/gpu/drm/nouveau/

Re: [Nouveau] [PATCH] drm/nouveau: Add proper vgaarb support.

2010-02-08 Thread Maarten Maathuis
2010/2/8 Marcin Kościelnicki : > Signed-off-by: Marcin Kościelnicki > --- >  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 > b/drivers/gpu/drm/nouveau/nouveau_state.c > index fcd7

Re: [Nouveau] [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL

2010-02-08 Thread Maarten Maathuis
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 wrote: > - Marcin Slusarz pointed out that this triggers a BUG_ON, because kzall

[Nouveau] [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL

2010-02-08 Thread Maarten Maathuis
- Marcin Slusarz 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

[Nouveau] [Bug 26102] Rotating one monitor of a dual-head setup causes cursor problems

2010-02-08 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=26102 B Jonnh changed: What|Removed |Added CC||anarkog...@gmail.com --- Comment #3 from B

Re: [Nouveau] [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL

2010-02-08 Thread Pekka Paalanen
On Mon, 8 Feb 2010 12:02:01 +0100 Maarten Maathuis wrote: > Thanks for pointing that out, is it preferred to use goto style > failure or just stick the spin unlock everywhere where you return? In this particular case, just add the unlock where it is needed. But, keep in mind what might happen, i

Re: [Nouveau] [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL

2010-02-08 Thread Maarten Maathuis
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 wrote: > On Sun,  7 Feb 2010 02:11:20 +0100 > Maarten Maathuis wrote: > >> - 'joi' on irc pointed out that

Re: [Nouveau] [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL

2010-02-08 Thread Pekka Paalanen
On Sun, 7 Feb 2010 02:11:20 +0100 Maarten Maathuis wrote: > - '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 c

Re: [Nouveau] [PATCH 1/2] libdrm/nouveau: new optimized libdrm pushbuffer ABI

2010-02-08 Thread Ben Skeggs
On Mon, 2010-02-08 at 10:04 +0100, Luca Barbieri wrote: > > IMO, the changes are good. However, DRM_NOUVEAU_HEADER_PATCHLEVEL is > > used to indicate the version of the kernel interface that's supported, > > and not the libdrm API version. > > OK. > > Perhaps it would be useful to add a libdrm A

Re: [Nouveau] [PATCH 1/2] libdrm/nouveau: new optimized libdrm pushbuffer ABI

2010-02-08 Thread Luca Barbieri
> IMO, the changes are good.  However, DRM_NOUVEAU_HEADER_PATCHLEVEL is > used to indicate the version of the kernel interface that's supported, > and not the libdrm API version. OK. Perhaps it would be useful to add a libdrm API version number as well? ___