Re: [git pull] drm fixes

2010-03-25 Thread Pekka Enberg
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 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
 lockup problem worse. This also finally fixes HDMI audio on rv7xx cards.

Are there any i915 fixes pending? I tried 2.6.34-rc2 few days ago and
all I got was a blank screen at start up. The driver is pretty busted
for 2.6.33 also, I'm getting random screen corruption and the
occasional blank screen (which is fixed by suspend/resume).

I'm unfortunately busy with working on something else so I don't have
time right now to debug the thing. Just wanted to know if you're aware
of the quality problems with i915 and if there are any fixes pending.

   Pekka

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Regression in i915 on 2.6.34-rc1

2010-03-25 Thread Bjorn Helgaas
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 the fix in the next -rc and move on
  to the next _CRS issue :-)
 
 I was on vacation, sorry. Got to it today. In short, the test patch fails.
 Please see the dmesg with ACPI debugging in bugzilla as requested.

Ping!  If you haven't seen the last bugzilla update, I'd really like an
acpidump and some details about what machine this is.

Thanks,
  Bjorn



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [git pull] drm fixes

2010-03-25 Thread Dave Airlie
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 around, and 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
 lockup problem worse. This also finally fixes HDMI audio on rv7xx cards.

 Are there any i915 fixes pending? I tried 2.6.34-rc2 few days ago and
 all I got was a blank screen at start up. The driver is pretty busted
 for 2.6.33 also, I'm getting random screen corruption and the
 occasional blank screen (which is fixed by suspend/resume).

 I'm unfortunately busy with working on something else so I don't have
 time right now to debug the thing. Just wanted to know if you're aware
 of the quality problems with i915 and if there are any fixes pending.

I leave i915 up to Eric after -rc1, we found it hard to sync our
schedules before,

I'm sure he has some stuff in his tree.

Dave.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.

2010-03-25 Thread Michel Dänzer
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 Airlie airl...@redhat.com

This change seems to trigger or at least greatly expedite GPU lockups on
my PowerBook. With the change applied, my normal X session locked up the
GPU after just a few minutes several times. Now with it reverted it's
back to the previous stability.

I don't know why that is - maybe something doesn't properly deal with
BOs getting placed differently in some cases now - but anyway I suspect
the implications of this change haven't been fully thought through: The
log message sounds as though the change was mainly written with
radeon_bo_create() / radeon_bo_list_validate() in mind, but
radeon_ttm_placement_from_domain() is also called from other places:

  * radeon_bo_pin(): The change could lead to a BO being pinned to
GTT instead of VRAM, which would probably be bad. 
  * radeon_evict_flags(): The change might have undesirable
consequences here as well, not sure.

I don't think the way we currently use the same arrays for normal and
busy placement makes a lot of sense, but we probably need a better
mechanism to specify which placements are desirable / acceptable in each
case.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer






--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [git pull] drm fixes

2010-03-25 Thread Michel Dänzer
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 lockup problem worse.

Actually, I'm not sure that's true in all cases. With Jerome's changes,
a GPU lockup seems to basically turn my PowerBook into a pretty brick
right away. It would be preferable to have non-working local display
(actually, it should be possible to fall back to software for 2D?) but
be able to log in via SSH and do post-mortem analysis and reboot
cleanly.

That said, I don't know if Jerome's changes actually made things any
worse, as I hadn't run into GPU lockups for a while before yesterday
(see my other list post). But the commit logs did mention that the GPU
reset is unlikely to work with the R300 generation... (though I suspect
the fact this isn't x86 may not exactly help)


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.

2010-03-25 Thread Dave Airlie
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 works a lot better.

 Signed-off-by: Dave Airlie airl...@redhat.com

 This change seems to trigger or at least greatly expedite GPU lockups on
 my PowerBook. With the change applied, my normal X session locked up the
 GPU after just a few minutes several times. Now with it reverted it's
 back to the previous stability.

Care to try in pci mode? see if helps, it might be just straining AGP
a bit more,
maybe try 1x as well if you aren't already in it.


 I don't know why that is - maybe something doesn't properly deal with
 BOs getting placed differently in some cases now - but anyway I suspect
 the implications of this change haven't been fully thought through: The
 log message sounds as though the change was mainly written with
 radeon_bo_create() / radeon_bo_list_validate() in mind, but
 radeon_ttm_placement_from_domain() is also called from other places:

      * radeon_bo_pin(): The change could lead to a BO being pinned to
        GTT instead of VRAM, which would probably be bad.
      * radeon_evict_flags(): The change might have undesirable
        consequences here as well, not sure.

The first might be bad, but the second should be okay, I'll take a closer look
in the morning.

 I don't think the way we currently use the same arrays for normal and
 busy placement makes a lot of sense, but we probably need a better
 mechanism to specify which placements are desirable / acceptable in each
 case.

Well its not really a huge matrix of choices, I'm guessing we need more
info from userspace, or use the info better. Though in theory everything
should work in GTT or VRAM equally well just slower.

Dave.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.

2010-03-25 Thread Michel Dänzer
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 fallback place the objects rather than completely
  failing it works a lot better.
 
  Signed-off-by: Dave Airlie airl...@redhat.com
 
  This change seems to trigger or at least greatly expedite GPU lockups on
  my PowerBook. With the change applied, my normal X session locked up the
  GPU after just a few minutes several times. Now with it reverted it's
  back to the previous stability.
 
 Care to try in pci mode? see if helps, it might be just straining AGP
 a bit more,

Ugh, k I'll try... but that incurs such a huge performance hit that the
result might not be very meaningful I'm afraid.

 maybe try 1x as well if you aren't already in it.

I am, for some reason neither 2x nor 4x has ever worked reliably with
KMS although 4x was rock solid with UMS.


  I don't know why that is - maybe something doesn't properly deal with
  BOs getting placed differently in some cases now - but anyway I suspect
  the implications of this change haven't been fully thought through: The
  log message sounds as though the change was mainly written with
  radeon_bo_create() / radeon_bo_list_validate() in mind, but
  radeon_ttm_placement_from_domain() is also called from other places:
 
   * radeon_bo_pin(): The change could lead to a BO being pinned to
 GTT instead of VRAM, which would probably be bad.
   * radeon_evict_flags(): The change might have undesirable
 consequences here as well, not sure.
 
 The first might be bad, but the second should be okay, I'll take a closer look
 in the morning.

What about that there are now usually no busy placements specified,
couldn't that be a problem?


  I don't think the way we currently use the same arrays for normal and
  busy placement makes a lot of sense, but we probably need a better
  mechanism to specify which placements are desirable / acceptable in each
  case.
 
 Well its not really a huge matrix of choices, I'm guessing we need more
 info from userspace, or use the info better. Though in theory everything
 should work in GTT or VRAM equally well just slower.

E.g. scanout from GTT could easily exceed the available bandwidth.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

2010-03-25 Thread James Simmons

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 could be used to cleaning 
up 
the userland mmap as well as handle the console pinning. We can supply 
your own fb_mmap hook.
   
   Again, the issue is not userspace but that fb_ops hooks can be called
   from interrupt context etc.
  
  This should not happen. The VT layer is protected from calling in the 
  interrupt context. TNor does fbcon call any fb_ops methods from a irq.
 
 E.g. printk?

Sorry I have been sick. This is true when you are in KD_TEXT mode and using 
fbcon. 
Now while working on a graphical console yes you can have other hardware 
devices do
a printk which can alter the state of of your graphics card. As for debugging a 
graphics driver you have to be very careful with your printks. Usually in that 
case
I use two graphics cards in my system and map one to fbcon and test the other
graphcis cards driver.

P.S
The fbdev api is such that it doesn't always require a permanent 
framebuffer
mapping. This was done for the case of graphical hardware that lacks a directly 
accessable framebuffer. If you have accelerated fillrect,copyarea,and imageblit 
then 
you don't even the mapping except in the case of someone calling mmap on 
/dev/fbX.
I noticed the nouveau drivers has a accelerated fbcon :-)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 14801] radeon.modeset=1 boot option crashes system with ATI rc410 card producing garbled system logs

2010-03-25 Thread bugzilla-daemon
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: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 07/13] drm/nouveau/kms: add support for new TTM fault callback V3

2010-03-25 Thread Jerome Glisse
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 tested on any hw.

V2 don't derefence bo-mem.mm_node as it's not NULL only for
   VRAM or GTT
V3 update after io_mem_reserve/io_mem_free callback balancing

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |   51 ++
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5a167de..dafb79c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -761,6 +761,54 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo, 
struct file *filp)
return 0;
 }
 
+static int
+nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
+{
+   struct ttm_mem_type_manager *man = bdev-man[mem-mem_type];
+   struct drm_nouveau_private *dev_priv = nouveau_bdev(bdev);
+   struct drm_device *dev = dev_priv-dev;
+
+   mem-bus.offset = 0;
+   mem-bus.size = mem-num_pages  PAGE_SHIFT;
+   mem-bus.base = 0;
+   mem-bus.is_iomem = false;
+   if (!(man-flags  TTM_MEMTYPE_FLAG_MAPPABLE))
+   return -EINVAL;
+   switch (mem-mem_type) {
+   case TTM_PL_SYSTEM:
+   /* System memory */
+   return 0;
+   case TTM_PL_TT:
+#if __OS_HAS_AGP
+   if (dev_priv-gart_info.type == NOUVEAU_GART_AGP) {
+   mem-bus.offset = mem-mm_node-start  PAGE_SHIFT;
+   mem-bus.base = dev_priv-gart_info.aper_base;
+   mem-bus.is_iomem = true;
+   }
+#endif
+   return 0;
+   case TTM_PL_VRAM:
+   mem-bus.offset = mem-mm_node-start  PAGE_SHIFT;
+   mem-bus.base = drm_get_resource_start(dev, 1);
+   mem-bus.is_iomem = true;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return 0;
+}
+
+static void
+nouveau_ttm_io_mem_free(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
+{
+}
+
+static int
+nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
+{
+   return 0;
+}
+
 struct ttm_bo_driver nouveau_bo_driver = {
.create_ttm_backend_entry = nouveau_bo_create_ttm_backend_entry,
.invalidate_caches = nouveau_bo_invalidate_caches,
@@ -773,5 +821,8 @@ struct ttm_bo_driver nouveau_bo_driver = {
.sync_obj_flush = nouveau_fence_flush,
.sync_obj_unref = nouveau_fence_unref,
.sync_obj_ref = nouveau_fence_ref,
+   .fault_reserve_notify = nouveau_ttm_fault_reserve_notify,
+   .io_mem_reserve = nouveau_ttm_io_mem_reserve,
+   .io_mem_free = nouveau_ttm_io_mem_free,
 };
 
-- 
1.6.6.1


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


unmappable vram V6

2010-03-25 Thread Jerome Glisse
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.
http://people.freedesktop.org/~glisse/0014-TEST-UNMAPPABLE.patch

Seems to work flawlessly (quake3, compiz, glxgears, firefox running
side by side)

Cheers,
Jerome


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 12/13] drm/ttm: remove io_ field from TTM V4

2010-03-25 Thread Jerome Glisse
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 io_mem_reserve/io_mem_free callback balancing
V4 adjust to minor cleanup

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/ttm/ttm_bo.c  |   22 --
 drivers/gpu/drm/ttm/ttm_bo_util.c |   29 +
 include/drm/ttm/ttm_bo_driver.h   |   10 --
 3 files changed, 9 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2171f86..1f27cf2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -79,8 +79,6 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
int mem_type)
printk(KERN_ERR TTM_PFX use_type: %d\n, man-use_type);
printk(KERN_ERR TTM_PFX flags: 0x%08X\n, man-flags);
printk(KERN_ERR TTM_PFX gpu_offset: 0x%08lX\n, man-gpu_offset);
-   printk(KERN_ERR TTM_PFX io_offset: 0x%08lX\n, man-io_offset);
-   printk(KERN_ERR TTM_PFX io_size: %ld\n, man-io_size);
printk(KERN_ERR TTM_PFX size: %llu\n, man-size);
printk(KERN_ERR TTM_PFX available_caching: 0x%08X\n,
man-available_caching);
@@ -1563,26 +1561,6 @@ bool ttm_mem_reg_is_pci(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *mem)
return true;
 }
 
-int ttm_bo_pci_offset(struct ttm_bo_device *bdev,
- struct ttm_mem_reg *mem,
- unsigned long *bus_base,
- unsigned long *bus_offset, unsigned long *bus_size)
-{
-   struct ttm_mem_type_manager *man = bdev-man[mem-mem_type];
-
-   *bus_size = 0;
-   if (!(man-flags  TTM_MEMTYPE_FLAG_MAPPABLE))
-   return -EINVAL;
-
-   if (ttm_mem_reg_is_pci(bdev, mem)) {
-   *bus_offset = mem-mm_node-start  PAGE_SHIFT;
-   *bus_size = mem-num_pages  PAGE_SHIFT;
-   *bus_base = man-io_offset + (uintptr_t)man-io_addr;
-   }
-
-   return 0;
-}
-
 void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
 {
struct ttm_bo_device *bdev = bo-bdev;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 878dc49..9f9b287 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -83,31 +83,20 @@ EXPORT_SYMBOL(ttm_bo_move_ttm);
 
 int ttm_mem_io_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
 {
-   int ret;
+   int ret = 0;
 
-   if (bdev-driver-io_mem_reserve) {
-   if (!mem-bus.io_reserved) {
-   mem-bus.io_reserved = true;
-   ret = bdev-driver-io_mem_reserve(bdev, mem);
-   if (unlikely(ret != 0))
-   return ret;
-   }
-   } else {
-   ret = ttm_bo_pci_offset(bdev, mem, mem-bus.base, 
mem-bus.offset, mem-bus.size);
-   if (unlikely(ret != 0))
-   return ret;
-   mem-bus.is_iomem = (mem-bus.size  0) ? 1 : 0;
+   if (!mem-bus.io_reserved) {
+   mem-bus.io_reserved = true;
+   ret = bdev-driver-io_mem_reserve(bdev, mem);
}
-   return 0;
+   return ret;
 }
 
 void ttm_mem_io_free(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
 {
-   if (bdev-driver-io_mem_reserve) {
-   if (mem-bus.io_reserved) {
-   mem-bus.io_reserved = false;
-   bdev-driver-io_mem_free(bdev, mem);
-   }
+   if (mem-bus.io_reserved) {
+   mem-bus.io_reserved = false;
+   bdev-driver-io_mem_free(bdev, mem);
}
 }
 
@@ -411,7 +400,7 @@ static int ttm_bo_ioremap(struct ttm_buffer_object *bo,
 
if (!(man-flags  TTM_MEMTYPE_FLAG_NEEDS_IOREMAP)) {
map-bo_kmap_type = ttm_bo_map_premapped;
-   map-virtual = (void *)(((u8 *) man-io_addr) + bus_offset);
+   map-virtual = (void *)(bus_base + bus_offset);
} else {
map-bo_kmap_type = ttm_bo_map_iomap;
if (mem-placement  TTM_PL_FLAG_WC)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index da39865..35e2b9f 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -189,13 +189,6 @@ struct ttm_tt {
  * managed by this memory type.
  * @gpu_offset: If used, the GPU offset of the first managed page of
  * fixed memory or the first managed location in an aperture.
- * @io_offset: The io_offset of the first managed page of IO memory or
- * the first managed location in an aperture. For TTM_MEMTYPE_FLAG_CMA
- * memory, this should be set to NULL.
- * @io_size: The size of a managed IO region (fixed memory 

[PATCH 11/13] drm/vmwgfx: don't initialize TTM io memory manager field

2010-03-25 Thread Jerome Glisse
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 
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 7e28448..a0fb612 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -137,9 +137,6 @@ int vmw_invalidate_caches(struct ttm_bo_device *bdev, 
uint32_t flags)
 int vmw_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
  struct ttm_mem_type_manager *man)
 {
-   struct vmw_private *dev_priv =
-   container_of(bdev, struct vmw_private, bdev);
-
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
@@ -151,11 +148,8 @@ int vmw_init_mem_type(struct ttm_bo_device *bdev, uint32_t 
type,
case TTM_PL_VRAM:
/* On-card video ram */
man-gpu_offset = 0;
-   man-io_offset = dev_priv-vram_start;
-   man-io_size = dev_priv-vram_size;
man-flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_NEEDS_IOREMAP | TTM_MEMTYPE_FLAG_MAPPABLE;
-   man-io_addr = NULL;
man-available_caching = TTM_PL_MASK_CACHING;
man-default_caching = TTM_PL_FLAG_WC;
break;
-- 
1.6.6.1


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 04/13] drm/vmwgfx: update to TTM no_wait splitted argument

2010-03-25 Thread Jerome Glisse
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 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 0897359..dbd36b8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -570,7 +570,7 @@ static int vmw_validate_single_buffer(struct vmw_private 
*dev_priv,
 * Put BO in VRAM, only if there is space.
 */
 
-   ret = ttm_bo_validate(bo, vmw_vram_sys_placement, true, false);
+   ret = ttm_bo_validate(bo, vmw_vram_sys_placement, true, false, false);
if (unlikely(ret == -ERESTARTSYS))
return ret;
 
@@ -590,7 +590,7 @@ static int vmw_validate_single_buffer(struct vmw_private 
*dev_priv,
 * previous contents.
 */
 
-   ret = ttm_bo_validate(bo, vmw_vram_placement, true, false);
+   ret = ttm_bo_validate(bo, vmw_vram_placement, true, false, false);
return ret;
 }
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index a933670..80125ff 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -628,7 +628,7 @@ int vmw_dmabuf_from_vram(struct vmw_private *vmw_priv,
if (unlikely(ret != 0))
return ret;
 
-   ret = ttm_bo_validate(bo, vmw_sys_placement, false, false);
+   ret = ttm_bo_validate(bo, vmw_sys_placement, false, false, false);
ttm_bo_unreserve(bo);
 
return ret;
@@ -652,7 +652,7 @@ int vmw_dmabuf_to_start_of_vram(struct vmw_private 
*vmw_priv,
if (unlikely(ret != 0))
goto err_unlock;
 
-   ret = ttm_bo_validate(bo, ne_placement, false, false);
+   ret = ttm_bo_validate(bo, ne_placement, false, false, false);
ttm_bo_unreserve(bo);
 err_unlock:
ttm_write_unlock(vmw_priv-active_master-lock);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
index 5b6eabe..ad566c8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
@@ -118,7 +118,7 @@ static int vmw_dmabuf_pin_in_vram(struct vmw_private 
*dev_priv,
if (pin)
overlay_placement = vmw_vram_ne_placement;
 
-   ret = ttm_bo_validate(bo, overlay_placement, interruptible, false);
+   ret = ttm_bo_validate(bo, overlay_placement, interruptible, false, 
false);
 
ttm_bo_unreserve(bo);
 
-- 
1.6.6.1


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 08/13] drm/vmwgfx: add support for new TTM fault callback V3

2010-03-25 Thread Jerome Glisse
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
   VRAM or GTT
V3 update after io_mem_reserve/io_mem_free callback balancing

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |   40 +++-
 1 files changed, 39 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 825ebe3..7e28448 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -193,6 +193,41 @@ static void vmw_swap_notify(struct ttm_buffer_object *bo)
vmw_dmabuf_gmr_unbind(bo);
 }
 
+static int vmw_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct 
ttm_mem_reg *mem)
+{
+   struct ttm_mem_type_manager *man = bdev-man[mem-mem_type];
+   struct vmw_private *dev_priv = container_of(bdev, struct vmw_private, 
bdev);
+
+   mem-bus.is_iomem = false;
+   mem-bus.offset = 0;
+   mem-bus.size = mem-num_pages  PAGE_SHIFT;
+   mem-bus.base = 0;
+   if (!(man-flags  TTM_MEMTYPE_FLAG_MAPPABLE))
+   return -EINVAL;
+   switch (mem-mem_type) {
+   case TTM_PL_SYSTEM:
+   /* System memory */
+   return 0;
+   case TTM_PL_VRAM:
+   mem-bus.offset = mem-mm_node-start  PAGE_SHIFT;
+   mem-bus.base = dev_priv-vram_start;
+   mem-bus.is_iomem = true;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return 0;
+}
+
+static void vmw_ttm_io_mem_free(struct ttm_bo_device *bdev, struct ttm_mem_reg 
*mem)
+{
+}
+
+static int vmw_ttm_fault_reserve_notify(struct ttm_buffer_object *bo)
+{
+   return 0;
+}
+
 /**
  * FIXME: We're using the old vmware polling method to sync.
  * Do this with fences instead.
@@ -248,5 +283,8 @@ struct ttm_bo_driver vmw_bo_driver = {
.sync_obj_unref = vmw_sync_obj_unref,
.sync_obj_ref = vmw_sync_obj_ref,
.move_notify = vmw_move_notify,
-   .swap_notify = vmw_swap_notify
+   .swap_notify = vmw_swap_notify,
+   .fault_reserve_notify = vmw_ttm_fault_reserve_notify,
+   .io_mem_reserve = vmw_ttm_io_mem_reserve,
+   .io_mem_free = vmw_ttm_io_mem_free,
 };
-- 
1.6.6.1


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 10/13] drm/nouveau/kms: don't initialize TTM io memory manager field

2010-03-25 Thread Jerome Glisse
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 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index dafb79c..9812d1c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -391,13 +391,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man-available_caching = TTM_PL_FLAG_UNCACHED |
 TTM_PL_FLAG_WC;
man-default_caching = TTM_PL_FLAG_WC;
-
-   man-io_addr = NULL;
-   man-io_offset = drm_get_resource_start(dev, 1);
-   man-io_size = drm_get_resource_len(dev, 1);
-   if (man-io_size  nouveau_mem_fb_amount(dev))
-   man-io_size = nouveau_mem_fb_amount(dev);
-
man-gpu_offset = dev_priv-vm_vram_base;
break;
case TTM_PL_TT:
@@ -419,10 +412,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
 dev_priv-gart_info.type);
return -EINVAL;
}
-
-   man-io_offset  = dev_priv-gart_info.aper_base;
-   man-io_size= dev_priv-gart_info.aper_size;
-   man-io_addr   = NULL;
man-gpu_offset = dev_priv-vm_gart_base;
break;
default:
-- 
1.6.6.1


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 06/13] drm/radeon/kms: add support for new fault callback V5

2010-03-25 Thread Jerome Glisse
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 io_mem_reserve/free change

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/radeon_object.c |   26 -
 drivers/gpu/drm/radeon/radeon_object.h |2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c|   47 +++-
 3 files changed, 71 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 3adfa88..aef44f3 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -496,11 +496,33 @@ void radeon_bo_move_notify(struct ttm_buffer_object *bo,
radeon_bo_check_tiling(rbo, 0, 1);
 }
 
-void radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
+int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo)
 {
+   struct radeon_device *rdev;
struct radeon_bo *rbo;
+   unsigned long offset, size;
+   int r;
+
if (!radeon_ttm_bo_is_radeon_bo(bo))
-   return;
+   return 0;
rbo = container_of(bo, struct radeon_bo, tbo);
radeon_bo_check_tiling(rbo, 0, 0);
+   rdev = rbo-rdev;
+   if (bo-mem.mem_type == TTM_PL_VRAM) {
+   size = bo-mem.num_pages  PAGE_SHIFT;
+   offset = bo-mem.mm_node-start  PAGE_SHIFT;
+   if ((offset + size)  rdev-mc.visible_vram_size) {
+   /* hurrah the memory is not visible ! */
+   radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_VRAM);
+   rbo-placement.lpfn = rdev-mc.visible_vram_size  
PAGE_SHIFT;
+   r = ttm_bo_validate(bo, rbo-placement, false, true, 
false);
+   if (unlikely(r != 0))
+   return r;
+   offset = bo-mem.mm_node-start  PAGE_SHIFT;
+   /* this should not happen */
+   if ((offset + size)  rdev-mc.visible_vram_size)
+   return -EINVAL;
+   }
+   }
+   return 0;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index 7ab43de..353998d 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -168,6 +168,6 @@ extern int radeon_bo_check_tiling(struct radeon_bo *bo, 
bool has_moved,
bool force_drop);
 extern void radeon_bo_move_notify(struct ttm_buffer_object *bo,
struct ttm_mem_reg *mem);
-extern void radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
+extern int radeon_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
 extern int radeon_bo_get_surface_reg(struct radeon_bo *bo);
 #endif
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index ba4724c..d2700b8 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -437,10 +437,53 @@ static int radeon_bo_move(struct ttm_buffer_object *bo,
 memcpy:
r = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, no_wait_gpu, 
new_mem);
}
-
return r;
 }
 
+static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct 
ttm_mem_reg *mem)
+{
+   struct ttm_mem_type_manager *man = bdev-man[mem-mem_type];
+   struct radeon_device *rdev = radeon_get_rdev(bdev);
+
+   mem-bus.offset = 0;
+   mem-bus.size = mem-num_pages  PAGE_SHIFT;
+   mem-bus.base = 0;
+   mem-bus.is_iomem = false;
+   if (!(man-flags  TTM_MEMTYPE_FLAG_MAPPABLE))
+   return -EINVAL;
+   switch (mem-mem_type) {
+   case TTM_PL_SYSTEM:
+   /* system memory */
+   return 0;
+   case TTM_PL_TT:
+#if __OS_HAS_AGP
+   if (rdev-flags  RADEON_IS_AGP) {
+   /* RADEON_IS_AGP is set only if AGP is active */
+   mem-bus.offset = mem-mm_node-start  PAGE_SHIFT;
+   mem-bus.base = rdev-mc.agp_base;
+   mem-bus.is_iomem = true;
+   }
+#endif
+   return 0;
+   case TTM_PL_VRAM:
+   mem-bus.offset = mem-mm_node-start  PAGE_SHIFT;
+   /* check if it's visible */
+   if ((mem-bus.offset + mem-bus.size)  
rdev-mc.visible_vram_size)
+   return -EINVAL;
+   mem-bus.base = rdev-mc.aper_base;
+   mem-bus.is_iomem = true;
+   break;
+   default:
+   return -EINVAL;
+   }
+   return 0;
+}
+
+static void radeon_ttm_io_mem_free(struct ttm_bo_device *bdev, struct 
ttm_mem_reg *mem)
+{
+   /* 

[PATCH 02/13] drm/radeon/kms: update to TTM no_wait splitted argument

2010-03-25 Thread Jerome Glisse
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 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index fc9d00a..3adfa88 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -189,7 +189,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 
*gpu_addr)
bo-placement.lpfn = bo-rdev-mc.visible_vram_size  PAGE_SHIFT;
for (i = 0; i  bo-placement.num_placement; i++)
bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
-   r = ttm_bo_validate(bo-tbo, bo-placement, false, false);
+   r = ttm_bo_validate(bo-tbo, bo-placement, false, false, false);
if (likely(r == 0)) {
bo-pin_count = 1;
if (gpu_addr != NULL)
@@ -213,7 +213,7 @@ int radeon_bo_unpin(struct radeon_bo *bo)
return 0;
for (i = 0; i  bo-placement.num_placement; i++)
bo-placements[i] = ~TTM_PL_FLAG_NO_EVICT;
-   r = ttm_bo_validate(bo-tbo, bo-placement, false, false);
+   r = ttm_bo_validate(bo-tbo, bo-placement, false, false, false);
if (unlikely(r != 0))
dev_err(bo-rdev-dev, %p validate failed for unpin\n, bo);
return r;
@@ -328,7 +328,7 @@ int radeon_bo_list_validate(struct list_head *head)
lobj-rdomain);
}
r = ttm_bo_validate(bo-tbo, bo-placement,
-   true, false);
+   true, false, false);
if (unlikely(r))
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 43c5ab3..ba4724c 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -243,9 +243,9 @@ static void radeon_move_null(struct ttm_buffer_object *bo,
 }
 
 static int radeon_move_blit(struct ttm_buffer_object *bo,
-   bool evict, int no_wait,
-   struct ttm_mem_reg *new_mem,
-   struct ttm_mem_reg *old_mem)
+   bool evict, int no_wait_reserve, bool no_wait_gpu,
+   struct ttm_mem_reg *new_mem,
+   struct ttm_mem_reg *old_mem)
 {
struct radeon_device *rdev;
uint64_t old_start, new_start;
@@ -289,13 +289,14 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
r = radeon_copy(rdev, old_start, new_start, new_mem-num_pages, fence);
/* FIXME: handle copy error */
r = ttm_bo_move_accel_cleanup(bo, (void *)fence, NULL,
- evict, no_wait, new_mem);
+ evict, no_wait_reserve, no_wait_gpu, 
new_mem);
radeon_fence_unref(fence);
return r;
 }
 
 static int radeon_move_vram_ram(struct ttm_buffer_object *bo,
-   bool evict, bool interruptible, bool no_wait,
+   bool evict, bool interruptible,
+   bool no_wait_reserve, bool no_wait_gpu,
struct ttm_mem_reg *new_mem)
 {
struct radeon_device *rdev;
@@ -316,7 +317,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
*bo,
placement.busy_placement = placements;
placements = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT;
r = ttm_bo_mem_space(bo, placement, tmp_mem,
-interruptible, no_wait);
+interruptible, no_wait_reserve, no_wait_gpu);
if (unlikely(r)) {
return r;
}
@@ -330,11 +331,11 @@ static int radeon_move_vram_ram(struct ttm_buffer_object 
*bo,
if (unlikely(r)) {
goto out_cleanup;
}
-   r = radeon_move_blit(bo, true, no_wait, tmp_mem, old_mem);
+   r = radeon_move_blit(bo, true, no_wait_reserve, no_wait_gpu, tmp_mem, 
old_mem);
if (unlikely(r)) {
goto out_cleanup;
}
-   r = ttm_bo_move_ttm(bo, true, no_wait, new_mem);
+   r = ttm_bo_move_ttm(bo, true, no_wait_reserve, no_wait_gpu, new_mem);
 out_cleanup:
if (tmp_mem.mm_node) {
struct ttm_bo_global *glob = rdev-mman.bdev.glob;
@@ -348,7 +349,8 @@ out_cleanup:
 }
 
 static int radeon_move_ram_vram(struct ttm_buffer_object *bo,
-   bool evict, bool interruptible, bool no_wait,
+   bool evict, bool interruptible,
+   bool no_wait_reserve, bool no_wait_gpu,
 

[PATCH 03/13] drm/nouveau: update to TTM no_wait splitted argument

2010-03-25 Thread Jerome Glisse
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 ++--
 drivers/gpu/drm/nouveau/nouveau_gem.c |2 +-
 2 files changed, 26 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 0266124..5a167de 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -219,7 +219,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t memtype)
for (i = 0; i  nvbo-placement.num_placement; i++)
nvbo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(bo, nvbo-placement, false, false);
+   ret = ttm_bo_validate(bo, nvbo-placement, false, false, false);
if (ret == 0) {
switch (bo-mem.mem_type) {
case TTM_PL_VRAM:
@@ -256,7 +256,7 @@ nouveau_bo_unpin(struct nouveau_bo *nvbo)
for (i = 0; i  nvbo-placement.num_placement; i++)
nvbo-placements[i] = ~TTM_PL_FLAG_NO_EVICT;
 
-   ret = ttm_bo_validate(bo, nvbo-placement, false, false);
+   ret = ttm_bo_validate(bo, nvbo-placement, false, false, false);
if (ret == 0) {
switch (bo-mem.mem_type) {
case TTM_PL_VRAM:
@@ -456,7 +456,8 @@ nouveau_bo_evict_flags(struct ttm_buffer_object *bo, struct 
ttm_placement *pl)
 
 static int
 nouveau_bo_move_accel_cleanup(struct nouveau_channel *chan,
- struct nouveau_bo *nvbo, bool evict, bool no_wait,
+ struct nouveau_bo *nvbo, bool evict,
+ bool no_wait_reserve, bool no_wait_gpu,
  struct ttm_mem_reg *new_mem)
 {
struct nouveau_fence *fence = NULL;
@@ -467,7 +468,7 @@ nouveau_bo_move_accel_cleanup(struct nouveau_channel *chan,
return ret;
 
ret = ttm_bo_move_accel_cleanup(nvbo-bo, fence, NULL,
-   evict, no_wait, new_mem);
+   evict, no_wait_reserve, no_wait_gpu, 
new_mem);
if (nvbo-channel  nvbo-channel != chan)
ret = nouveau_fence_wait(fence, NULL, false, false);
nouveau_fence_unref((void *)fence);
@@ -491,7 +492,8 @@ nouveau_bo_mem_ctxdma(struct nouveau_bo *nvbo, struct 
nouveau_channel *chan,
 
 static int
 nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict, bool intr,
-int no_wait, struct ttm_mem_reg *new_mem)
+bool no_wait_reserve, bool no_wait_gpu,
+struct ttm_mem_reg *new_mem)
 {
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct drm_nouveau_private *dev_priv = nouveau_bdev(bo-bdev);
@@ -569,12 +571,13 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict, bool intr,
dst_offset += (PAGE_SIZE * line_count);
}
 
-   return nouveau_bo_move_accel_cleanup(chan, nvbo, evict, no_wait, 
new_mem);
+   return nouveau_bo_move_accel_cleanup(chan, nvbo, evict, 
no_wait_reserve, no_wait_gpu, new_mem);
 }
 
 static int
 nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool evict, bool intr,
- bool no_wait, struct ttm_mem_reg *new_mem)
+ bool no_wait_reserve, bool no_wait_gpu,
+ struct ttm_mem_reg *new_mem)
 {
u32 placement_memtype = TTM_PL_FLAG_TT | TTM_PL_MASK_CACHING;
struct ttm_placement placement;
@@ -587,7 +590,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool 
evict, bool intr,
 
tmp_mem = *new_mem;
tmp_mem.mm_node = NULL;
-   ret = ttm_bo_mem_space(bo, placement, tmp_mem, intr, no_wait);
+   ret = ttm_bo_mem_space(bo, placement, tmp_mem, intr, no_wait_reserve, 
no_wait_gpu);
if (ret)
return ret;
 
@@ -595,11 +598,11 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool 
evict, bool intr,
if (ret)
goto out;
 
-   ret = nouveau_bo_move_m2mf(bo, true, intr, no_wait, tmp_mem);
+   ret = nouveau_bo_move_m2mf(bo, true, intr, no_wait_reserve, 
no_wait_gpu, tmp_mem);
if (ret)
goto out;
 
-   ret = ttm_bo_move_ttm(bo, evict, no_wait, new_mem);
+   ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu, new_mem);
 out:
if (tmp_mem.mm_node) {
spin_lock(bo-bdev-glob-lru_lock);
@@ -612,7 +615,8 @@ out:
 
 static int
 nouveau_bo_move_flips(struct ttm_buffer_object *bo, bool evict, bool intr,
- bool no_wait, struct ttm_mem_reg *new_mem)
+ bool no_wait_reserve, bool no_wait_gpu,
+ struct ttm_mem_reg *new_mem)
 {
u32 placement_memtype = TTM_PL_FLAG_TT | TTM_PL_MASK_CACHING;
 

[PATCH 09/13] drm/radeon/kms: don't initialize TTM io memory manager field

2010-03-25 Thread Jerome Glisse
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 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d2700b8..0220154 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -161,22 +161,14 @@ static int radeon_init_mem_type(struct ttm_bo_device 
*bdev, uint32_t type,
  (unsigned)type);
return -EINVAL;
}
-   man-io_offset = rdev-mc.agp_base;
-   man-io_size = rdev-mc.gtt_size;
-   man-io_addr = NULL;
if (!rdev-ddev-agp-cant_use_aperture)
man-flags = TTM_MEMTYPE_FLAG_NEEDS_IOREMAP |
 TTM_MEMTYPE_FLAG_MAPPABLE;
man-available_caching = TTM_PL_FLAG_UNCACHED |
 TTM_PL_FLAG_WC;
man-default_caching = TTM_PL_FLAG_WC;
-   } else
-#endif
-   {
-   man-io_offset = 0;
-   man-io_size = 0;
-   man-io_addr = NULL;
}
+#endif
break;
case TTM_PL_VRAM:
/* On-card video ram */
@@ -186,9 +178,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
 TTM_MEMTYPE_FLAG_MAPPABLE;
man-available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man-default_caching = TTM_PL_FLAG_WC;
-   man-io_addr = NULL;
-   man-io_offset = rdev-mc.aper_base;
-   man-io_size = rdev-mc.aper_size;
break;
default:
DRM_ERROR(Unsupported memory type %u\n, (unsigned)type);
-- 
1.6.6.1


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 01/13] drm/ttm: split no_wait argument in 2 GPU or reserve wait

2010-03-25 Thread Jerome Glisse
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, update to others
driver are following in separate patches.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/ttm/ttm_bo.c  |   57 
 drivers/gpu/drm/ttm/ttm_bo_util.c |9 --
 include/drm/ttm/ttm_bo_api.h  |6 ++-
 include/drm/ttm/ttm_bo_driver.h   |   29 +++---
 4 files changed, 60 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9db02bb..6f51b30 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -357,7 +357,8 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
 
 static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo,
  struct ttm_mem_reg *mem,
- bool evict, bool interruptible, bool no_wait)
+ bool evict, bool interruptible,
+ bool no_wait_reserve, bool no_wait_gpu)
 {
struct ttm_bo_device *bdev = bo-bdev;
bool old_is_pci = ttm_mem_reg_is_pci(bdev, bo-mem);
@@ -402,12 +403,12 @@ static int ttm_bo_handle_move_mem(struct 
ttm_buffer_object *bo,
 
if (!(old_man-flags  TTM_MEMTYPE_FLAG_FIXED) 
!(new_man-flags  TTM_MEMTYPE_FLAG_FIXED))
-   ret = ttm_bo_move_ttm(bo, evict, no_wait, mem);
+   ret = ttm_bo_move_ttm(bo, evict, no_wait_reserve, no_wait_gpu, 
mem);
else if (bdev-driver-move)
ret = bdev-driver-move(bo, evict, interruptible,
-no_wait, mem);
+no_wait_reserve, no_wait_gpu, mem);
else
-   ret = ttm_bo_move_memcpy(bo, evict, no_wait, mem);
+   ret = ttm_bo_move_memcpy(bo, evict, no_wait_reserve, 
no_wait_gpu, mem);
 
if (ret)
goto out_err;
@@ -606,7 +607,7 @@ void ttm_bo_unref(struct ttm_buffer_object **p_bo)
 EXPORT_SYMBOL(ttm_bo_unref);
 
 static int ttm_bo_evict(struct ttm_buffer_object *bo, bool interruptible,
-   bool no_wait)
+   bool no_wait_reserve, bool no_wait_gpu)
 {
struct ttm_bo_device *bdev = bo-bdev;
struct ttm_bo_global *glob = bo-glob;
@@ -615,7 +616,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
int ret = 0;
 
spin_lock(bo-lock);
-   ret = ttm_bo_wait(bo, false, interruptible, no_wait);
+   ret = ttm_bo_wait(bo, false, interruptible, no_wait_gpu);
spin_unlock(bo-lock);
 
if (unlikely(ret != 0)) {
@@ -638,7 +639,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
placement.num_busy_placement = 0;
bdev-driver-evict_flags(bo, placement);
ret = ttm_bo_mem_space(bo, placement, evict_mem, interruptible,
-   no_wait);
+   no_wait_reserve, no_wait_gpu);
if (ret) {
if (ret != -ERESTARTSYS) {
printk(KERN_ERR TTM_PFX
@@ -650,7 +651,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
}
 
ret = ttm_bo_handle_move_mem(bo, evict_mem, true, interruptible,
-no_wait);
+no_wait_reserve, no_wait_gpu);
if (ret) {
if (ret != -ERESTARTSYS)
printk(KERN_ERR TTM_PFX Buffer eviction failed\n);
@@ -670,7 +671,8 @@ out:
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
-   bool interruptible, bool no_wait)
+   bool interruptible, bool no_wait_reserve,
+   bool no_wait_gpu)
 {
struct ttm_bo_global *glob = bdev-glob;
struct ttm_mem_type_manager *man = bdev-man[mem_type];
@@ -687,11 +689,11 @@ retry:
bo = list_first_entry(man-lru, struct ttm_buffer_object, lru);
kref_get(bo-list_kref);
 
-   ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
+   ret = ttm_bo_reserve_locked(bo, false, no_wait_reserve, false, 0);
 
if (unlikely(ret == -EBUSY)) {
spin_unlock(glob-lru_lock);
-   if (likely(!no_wait))
+   if (likely(!no_wait_gpu))
ret = ttm_bo_wait_unreserved(bo, interruptible);
 
kref_put(bo-list_kref, ttm_bo_release_list);
@@ -713,7 +715,7 @@ retry:
while (put_count--)
kref_put(bo-list_kref, ttm_bo_ref_bug);
 
-   ret = ttm_bo_evict(bo, 

[PATCH 13/13] drm/radeon/kms: enable use of unmappable VRAM V2

2010-03-25 Thread Jerome Glisse
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 -
 drivers/gpu/drm/radeon/r600.c  |5 -
 drivers/gpu/drm/radeon/rv770.c |5 -
 4 files changed, 0 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 7672f11..48e0dfb 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -475,11 +475,6 @@ int evergreen_mc_init(struct radeon_device *rdev)
rdev-mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
rdev-mc.visible_vram_size = rdev-mc.aper_size;
-   /* FIXME remove this once we support unmappable VRAM */
-   if (rdev-mc.mc_vram_size  rdev-mc.aper_size) {
-   rdev-mc.mc_vram_size = rdev-mc.aper_size;
-   rdev-mc.real_vram_size = rdev-mc.aper_size;
-   }
r600_vram_gtt_location(rdev, rdev-mc);
radeon_update_bandwidth_info(rdev);
 
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 7a1180d..fc95907 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2026,11 +2026,6 @@ void r100_vram_init_sizes(struct radeon_device *rdev)
else
rdev-mc.mc_vram_size = rdev-mc.real_vram_size;
}
-   /* FIXME remove this once we support unmappable VRAM */
-   if (rdev-mc.mc_vram_size  rdev-mc.aper_size) {
-   rdev-mc.mc_vram_size = rdev-mc.aper_size;
-   rdev-mc.real_vram_size = rdev-mc.aper_size;
-   }
 }
 
 void r100_vga_set_state(struct radeon_device *rdev, bool state)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index a948947..4206c8d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -713,11 +713,6 @@ int r600_mc_init(struct radeon_device *rdev)
rdev-mc.mc_vram_size = RREG32(CONFIG_MEMSIZE);
rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
rdev-mc.visible_vram_size = rdev-mc.aper_size;
-   /* FIXME remove this once we support unmappable VRAM */
-   if (rdev-mc.mc_vram_size  rdev-mc.aper_size) {
-   rdev-mc.mc_vram_size = rdev-mc.aper_size;
-   rdev-mc.real_vram_size = rdev-mc.aper_size;
-   }
r600_vram_gtt_location(rdev, rdev-mc);
 
if (rdev-flags  RADEON_IS_IGP)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 2b8a4e1..599121b 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -905,11 +905,6 @@ int rv770_mc_init(struct radeon_device *rdev)
rdev-mc.mc_vram_size = RREG32(CONFIG_MEMSIZE);
rdev-mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
rdev-mc.visible_vram_size = rdev-mc.aper_size;
-   /* FIXME remove this once we support unmappable VRAM */
-   if (rdev-mc.mc_vram_size  rdev-mc.aper_size) {
-   rdev-mc.mc_vram_size = rdev-mc.aper_size;
-   rdev-mc.real_vram_size = rdev-mc.aper_size;
-   }
r600_vram_gtt_location(rdev, rdev-mc);
radeon_update_bandwidth_info(rdev);
 
-- 
1.6.6.1


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 05/13] drm/ttm: ttm_fault callback to allow driver to handle bo placement V4

2010-03-25 Thread Jerome Glisse
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 remove the old path from TTM once driver are
converted.

V2 return VM_FAULT_NOPAGE if callback return -EBUSY or -ERESTARTSYS
V3 balance io_mem_reserve and io_mem_free call, fault_reserve_notify
   is responsible to perform any necessary task for mapping to succeed
V4 minor cleanup, atomic_t - bool as member is protected by reserve
   mecanism from concurent access

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/ttm/ttm_bo.c  |7 ++-
 drivers/gpu/drm/ttm/ttm_bo_util.c |   98 ++--
 drivers/gpu/drm/ttm/ttm_bo_vm.c   |   41 
 include/drm/ttm/ttm_bo_api.h  |   21 
 include/drm/ttm/ttm_bo_driver.h   |   16 ++-
 5 files changed, 111 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6f51b30..2171f86 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -632,6 +632,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
 
evict_mem = bo-mem;
evict_mem.mm_node = NULL;
+   evict_mem.bus.io_reserved = false;
 
placement.fpfn = 0;
placement.lpfn = 0;
@@ -1005,6 +1006,7 @@ int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
mem.num_pages = bo-num_pages;
mem.size = mem.num_pages  PAGE_SHIFT;
mem.page_alignment = bo-mem.page_alignment;
+   mem.bus.io_reserved = false;
/*
 * Determine where to move the buffer.
 */
@@ -1160,6 +1162,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo-mem.num_pages = bo-num_pages;
bo-mem.mm_node = NULL;
bo-mem.page_alignment = page_alignment;
+   bo-mem.bus.io_reserved = false;
bo-buffer_start = buffer_start  PAGE_MASK;
bo-priv_flags = 0;
bo-mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
@@ -1574,7 +1577,7 @@ int ttm_bo_pci_offset(struct ttm_bo_device *bdev,
if (ttm_mem_reg_is_pci(bdev, mem)) {
*bus_offset = mem-mm_node-start  PAGE_SHIFT;
*bus_size = mem-num_pages  PAGE_SHIFT;
-   *bus_base = man-io_offset;
+   *bus_base = man-io_offset + (uintptr_t)man-io_addr;
}
 
return 0;
@@ -1588,8 +1591,8 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
 
if (!bdev-dev_mapping)
return;
-
unmap_mapping_range(bdev-dev_mapping, offset, holelen, 1);
+   ttm_mem_io_free(bdev, bo-mem);
 }
 EXPORT_SYMBOL(ttm_bo_unmap_virtual);
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 865b2a8..878dc49 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -81,30 +81,59 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_move_ttm);
 
+int ttm_mem_io_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
+{
+   int ret;
+
+   if (bdev-driver-io_mem_reserve) {
+   if (!mem-bus.io_reserved) {
+   mem-bus.io_reserved = true;
+   ret = bdev-driver-io_mem_reserve(bdev, mem);
+   if (unlikely(ret != 0))
+   return ret;
+   }
+   } else {
+   ret = ttm_bo_pci_offset(bdev, mem, mem-bus.base, 
mem-bus.offset, mem-bus.size);
+   if (unlikely(ret != 0))
+   return ret;
+   mem-bus.is_iomem = (mem-bus.size  0) ? 1 : 0;
+   }
+   return 0;
+}
+
+void ttm_mem_io_free(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
+{
+   if (bdev-driver-io_mem_reserve) {
+   if (mem-bus.io_reserved) {
+   mem-bus.io_reserved = false;
+   bdev-driver-io_mem_free(bdev, mem);
+   }
+   }
+}
+
 int ttm_mem_reg_ioremap(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem,
void **virtual)
 {
struct ttm_mem_type_manager *man = bdev-man[mem-mem_type];
-   unsigned long bus_offset;
-   unsigned long bus_size;
-   unsigned long bus_base;
int ret;
void *addr;
 
*virtual = NULL;
-   ret = ttm_bo_pci_offset(bdev, mem, bus_base, bus_offset, bus_size);
-   if (ret || bus_size == 0)
+   ret = ttm_mem_io_reserve(bdev, mem);
+   if (ret)
return ret;
 
-   if (!(man-flags  TTM_MEMTYPE_FLAG_NEEDS_IOREMAP))
-   addr = (void *)(((u8 *) man-io_addr) + bus_offset);
-   else {
+   if (!(man-flags  TTM_MEMTYPE_FLAG_NEEDS_IOREMAP)) {
+   addr = (void *)(mem-bus.base + mem-bus.offset);
+   } else {
  

[Bug 27314] output not working on dell m6500

2010-03-25 Thread bugzilla-daemon
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: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH 1/2] drm/radeon/bo: add some fallback placements for VRAM only objects.

2010-03-25 Thread Michel Dänzer
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 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 Airlie airl...@redhat.com
  
   This change seems to trigger or at least greatly expedite GPU lockups on
   my PowerBook. With the change applied, my normal X session locked up the
   GPU after just a few minutes several times. Now with it reverted it's
   back to the previous stability.
  
  Care to try in pci mode? see if helps, it might be just straining AGP
  a bit more,
 
 Ugh, k I'll try... but that incurs such a huge performance hit that the
 result might not be very meaningful I'm afraid.

It didn't lock up in a couple of hours of suffering through PCI, so
maybe it is an AGP problem, or maybe PCI is just too slow to trigger
it... More likely the former though I guess.


   I don't know why that is - maybe something doesn't properly deal with
   BOs getting placed differently in some cases now - but anyway I suspect
   the implications of this change haven't been fully thought through: The
   log message sounds as though the change was mainly written with
   radeon_bo_create() / radeon_bo_list_validate() in mind, but
   radeon_ttm_placement_from_domain() is also called from other places:
  
* radeon_bo_pin(): The change could lead to a BO being pinned to
  GTT instead of VRAM, which would probably be bad.
* radeon_evict_flags(): The change might have undesirable
  consequences here as well, not sure.
  
  The first might be bad, but the second should be okay, I'll take a closer 
  look
  in the morning.
 
 What about that there are now usually no busy placements specified,
 couldn't that be a problem?

FWIW I tried re-using the normal placements for missing busy placements,
didn't help.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 1/3 -next] drm: fix build error when SYSRQ is disabled

2010-03-25 Thread Randy Dunlap
From: Randy Dunlap randy.dun...@oracle.com

Fix build error when CONFIG_MAGIC_SYSRQ is not enabled:

drivers/gpu/drm/drm_fb_helper.c:915: error: 'sysrq_drm_fb_helper_restore_op' 
undeclared (first use in this function)
drivers/gpu/drm/drm_fb_helper.c:929: error: 'sysrq_drm_fb_helper_restore_op' 
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/gpu/drm/drm_fb_helper.c
@@ -283,6 +283,8 @@ static struct sysrq_key_op sysrq_drm_fb_
.help_msg = force-fb(V),
.action_msg = Restore framebuffer console,
 };
+#else
+static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
 #endif
 
 static void drm_fb_helper_on(struct fb_info *info)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel