Hi Dave,
2010/3/25 Dave Airlie airl...@linux.ie:
Some nouveau updates + misc drm core fixes,
radeon kms: mostly fixes, however a cleanup to the ugly asic tables to
avoid drift between C prototypes moves some stuff around, and I've merged
Jerome's GPU recovery code, as I'd much rather users
On Sun, 2010-03-21 at 18:19 -0600, Pete Zaitcev wrote:
On Wed, 17 Mar 2010 08:26:59 -0700
Bjorn Helgaas bjorn.helg...@hp.com wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=15533
Any luck testing the patch from the bugzilla? I'd really like to get
this figured out so we can get
On Thu, Mar 25, 2010 at 4:52 PM, Pekka Enberg penb...@cs.helsinki.fi wrote:
Hi Dave,
2010/3/25 Dave Airlie airl...@linux.ie:
Some nouveau updates + misc drm core fixes,
radeon kms: mostly fixes, however a cleanup to the ugly asic tables to
avoid drift between C prototypes moves some stuff
On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it works a lot better.
Signed-off-by: Dave
On Don, 2010-03-25 at 03:35 +, Dave Airlie wrote:
[...] I've merged Jerome's GPU recovery code, as I'd much rather users
had some of hope of recovering from their GPU locking up than a dead
box. It seems to work for quite a lot of people that have tested it,
and it won't make a GPU
2010/3/25 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just fallback place the objects rather than completely
failing it
On Don, 2010-03-25 at 19:56 +1000, Dave Airlie wrote:
2010/3/25 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz would fail to start due to a lack
of memory, we can just
The fb_ops can only be called from fbcon or the fbdev userland
interface.
The fbcon calls should only happen when the VC is in KD_TEXT mode. Now
with the DRM backend we have the advantage of creating a mapping
seperate
from the console mapping. A fb_open/fb_close
https://bugzilla.kernel.org/show_bug.cgi?id=14801
--- Comment #6 from Alex Deucher alexdeuc...@gmail.com 2010-03-25 15:44:02
---
does booting with pci=nomsi fix the problem? If so, this is likely a duplicate
of bug https://bugzilla.kernel.org/show_bug.cgi?id=15626
--
Configure bugmail:
This add the support for the new fault callback, does change anything
from driver point of view, thought it should allow nouveau to add
support for unmappable VRAM.
Improvement: store the aperture base in a variable so that we don't
call a function to get it on each fault.
Patch hasn't been
So in these patchset i use bool instead of atomic remove empty line
removal, and i hope addressed standing issues. Again only compile
tested for nouveau vmwgfx. Tested this time only tested on RV710
with special patch to force unmappable vram use.
All TTM driver have been converted to new io_mem_reserve/free
interface which allow driver to choose and return proper io
base, offset to core TTM for ioremapping if necessary. This
patch remove what is now deadcode.
V2 adapt to match with change in first patch of the patchset
V3 update after
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
This patch update radeon to the new no_wait splitted argument
TTM functionality.
Compile tested only (but thing should run as there is no
operating change from driver point of view)
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |4 ++--
This add the support for the new fault callback, does change anything
from driver point of view.
Improvement: store the aperture base in a variable so that we don't
call a function to get it on each fault.
Patch hasn't been tested.
V2 don't derefence bo-mem.mm_node as it's not NULL only for
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
This add the support for the new fault callback and also the
infrastructure for supporting unmappable VRAM.
V2 validate BO with no_wait = true
V3 don't derefence bo-mem.mm_node as it's not NULL only for
VRAM or GTT
V4 update to splitted no_wait ttm change
V5 update to new balanced
This patch update radeon to the new no_wait splitted argument
TTM functionality.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_object.c |6 ++--
drivers/gpu/drm/radeon/radeon_ttm.c| 39 +--
2 files changed, 24
This patch update radeon to the new no_wait splitted argument
TTM functionality.
Compile tested only (but thing should run as there is no
operating change from driver point of view)
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 45
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_ttm.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
There is case where we want to be able to wait only for the
GPU while not waiting for other buffer to be unreserved. This
patch split the no_wait argument all the way down in the whole
ttm path so that upper level can decide on what to wait on or
not.
This patch break the API to other modules,
This patch enable the use of unmappable VRAM thanks to
previous TTM infrastructure change.
V2 update after io_mem_reserve/io_mem_free callback balancing
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |5 -
drivers/gpu/drm/radeon/r100.c |5
On fault the driver is given the opportunity to perform any operation
it sees fit in order to place the buffer into a CPU visible area of
memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
should keep working properly. Future patch will take advantage of this
infrastructure and
http://bugs.freedesktop.org/show_bug.cgi?id=27314
--- Comment #1 from Travis Glenn Hansen travisghan...@yahoo.com 2010-03-25
10:38:58 PST ---
Created an attachment (id=34442)
-- (http://bugs.freedesktop.org/attachment.cgi?id=34442)
Xorg.0.log
--
Configure bugmail:
On Thu, 2010-03-25 at 11:11 +0100, Michel Dänzer wrote:
On Don, 2010-03-25 at 19:56 +1000, Dave Airlie wrote:
2010/3/25 Michel Dänzer mic...@daenzer.net:
On Fri, 2010-03-19 at 10:35 +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
On constrained r100 systems compiz
'
undeclared (first use in this function)
Signed-off-by: Randy Dunlap randy.dun...@oracle.com
Cc: David Airlie airl...@linux.ie
---
drivers/gpu/drm/drm_fb_helper.c |2 ++
1 file changed, 2 insertions(+)
--- linux-next-20100325.orig/drivers/gpu/drm/drm_fb_helper.c
+++ linux-next-20100325/drivers
26 matches
Mail list logo
