Re: [PATCH] libdrm support for GTT mapping
On Wed, 2008-10-22 at 15:20 -0700, Jesse Barnes wrote: On Wednesday, October 22, 2008 3:08 pm Jesse Barnes wrote: Fairly straightforward aside from the aforementioned question about how to set tiling stride values for a given object. DDX driver patch? i830_memory.c: In function ‘i830_allocate_memory_tiled’: i830_memory.c:935: error: too few arguments to function ‘dri_bo_set_tiling’ No stride value is being passed to dri_bo_set_tiling. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm support for GTT mapping
On Thursday, October 23, 2008 3:11 am Steven J Newbury wrote: On Wed, 2008-10-22 at 15:20 -0700, Jesse Barnes wrote: On Wednesday, October 22, 2008 3:08 pm Jesse Barnes wrote: Fairly straightforward aside from the aforementioned question about how to set tiling stride values for a given object. DDX driver patch? i830_memory.c: In function ‘i830_allocate_memory_tiled’: i830_memory.c:935: error: too few arguments to function ‘dri_bo_set_tiling’ No stride value is being passed to dri_bo_set_tiling. Yeah you need the corresponding libdrm patch (posted to dri-devel) to make this work. Jesse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes for 2.6.27-rc1
On Thu, 2008-10-23 at 04:52 +0100, Dave Airlie wrote: commit 9e44af790f8bf8c3aa8a3101fd4f9bca2e932baa Author: Keith Packard [EMAIL PROTECTED] Date: Thu Oct 16 21:18:27 2008 -0700 drm/i915: hold dev-struct_mutex and DRM lock during vblank ring operations To synchronize clip lists with the X server, the DRM lock must be held while looking at drawable clip lists. To synchronize with other ring access, the ring mutex must be held while inserting commands into the ring. Failure to do the first resulted in easy visual corruption when moving windows, and the second could have corrupted the ring with DRI2. Grabbing the DRM lock involves using the DRM tasklet mechanism, grabbing the ring mutex means potentially sleeping. Deal with both of these by always running the tasklet from a work handler. Does that still provide good enough latency to prevent tearing though, e.g. with reduced blanking modes? commit 35ad68c18148a18938ff4f40e945c9734e7d2265 Author: Eric Anholt [EMAIL PROTECTED] Date: Fri Oct 17 11:03:53 2008 -0700 drm: Remove two leaks of vblank reference count in error paths. If the failing paths were hit, the vblank IRQ would never get turned off again. Signed-off-by: Eric Anholt [EMAIL PROTECTED] Acked-by: Keith Packard [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 786225eb2f4e55b5dda3cf8c62a145e824aae199 Author: Zhenyu Wang [EMAIL PROTECTED] Date: Fri Oct 17 15:48:44 2008 +0800 drm: fix leak of cliprects in drm_rmdraw() Signed-off-by: Zhenyu Wang [EMAIL PROTECTED] Signed-off-by: Eric Anholt [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] Will changes like these outside of the i915 driver still be merged to drm Git? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes for 2.6.27-rc1
On Thu, 2008-10-23 at 10:54 +0200, Michel Dänzer wrote: Does that still provide good enough latency to prevent tearing though, e.g. with reduced blanking modes? It now depends on the scheduler and what else is running on the system. Yes, this is not ideal, but the sketch of how DRI2 would work that we discussed during XDS would use an entirely different mechanism which is not subject to this issue. The issue here is that the ring is now protected by a mutex, and so we cannot insert commands to the main ring in a context where we cannot sleep. Correctness requires that we respect the ring access rules. Will changes like these outside of the i915 driver still be merged to drm Git? Dave Airlie talked about doing some back-porting work to pull DRM changes from Linux back to the drm repository. I'm not sure anyone has gotten started doing this in earnest yet. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes for 2.6.27-rc1
On Thu, 2008-10-23 at 18:10 +0200, Thomas Hellström wrote: I haven't looked into the code for a while, but isn't it possible to use a spinlock (_bh) for ring protection? Because we may have to wait for the hardware to drain the ring, it wouldn't be a good idea to hold a spinlock. In the worst case, with the hardware locked up, you will have wedged the entire machine. Or perhaps even the hardware ring lock bit? Or are you protecting other things with the ring mutex as well? It can still take a long time to wait for the hardware, so we want to allow other tasks to run. Using the separate high-priority ring will allow us to insert commands into that ring and have it automatically interrupt the main ring execution, all without needing to wait for access to the main ring. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes for 2.6.27-rc1
Keith Packard wrote: On Thu, 2008-10-23 at 18:10 +0200, Thomas Hellström wrote: I haven't looked into the code for a while, but isn't it possible to use a spinlock (_bh) for ring protection? Because we may have to wait for the hardware to drain the ring, it wouldn't be a good idea to hold a spinlock. In the worst case, with the hardware locked up, you will have wedged the entire machine. Ok. Or perhaps even the hardware ring lock bit? Or are you protecting other things with the ring mutex as well? It can still take a long time to wait for the hardware, so we want to allow other tasks to run. Using the separate high-priority ring will allow us to insert commands into that ring and have it automatically interrupt the main ring execution, all without needing to wait for access to the main ring. Yes, that sounds like the best solution. /Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 18191] Xorg segfault in _swrast_copy_teximage2d
http://bugs.freedesktop.org/show_bug.cgi?id=18191 --- Comment #1 from Chris Coulson [EMAIL PROTECTED] 2008-10-23 13:23:59 PST --- Created an attachment (id=19831) -- (http://bugs.freedesktop.org/attachment.cgi?id=19831) Output of lspci -vvnn -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 18191] Xorg segfault in _swrast_copy_teximage2d
http://bugs.freedesktop.org/show_bug.cgi?id=18191 --- Comment #3 from Chris Coulson [EMAIL PROTECTED] 2008-10-23 13:24:43 PST --- Created an attachment (id=19833) -- (http://bugs.freedesktop.org/attachment.cgi?id=19833) Xorg.0.log.old -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 2008-10-23 at 13:38 -0700, Andrew Morton wrote: I guess one could reimplemenet kmap_atomic_pfn() to call this. Sometime. The goal is to stop needing this function fairly soon and replace it with a 'real' io-mapping implementation for 32-bit processors. Given that all highmem-implementing archtiectures must use the same declaration here, we might as well put it into include/linux/highmem.h. Although that goes against current mistakes^Wcode. I'd hate to break with a long tradition. Does powerpc32 still implement highmem? It seems that way. You broke it, no? Powerpc32 doesn't have kmap_atomic_pfn either. Seems like the set of HIGHMEM functions is not uniform across architectures. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 23 Oct 2008, Andrew Morton wrote: Given that all highmem-implementing archtiectures must use the same declaration here, we might as well put it into include/linux/highmem.h. Although that goes against current mistakes^Wcode. Does powerpc32 still implement highmem? It seems that way. You broke it, no? This really shouldn't be in highmem.h AT ALL. The whole point of that function has absolutely nothing to do with highmem, and it *must* be useful on non-highmem configurations to be appropriate. So I'd much rather create a new linux/kmap.h or something. Or just expose this from to asm/fixmap.h or something. Let's not confuse this with highmem, even if the implementation _historically_ was due to that. Linus - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] GTT mapping support for GEM
On Wednesday, October 22, 2008 2:42 pm Jesse Barnes wrote: Ok, this one actually works w/o corrupting your display. However, after running for awhile I end up hitting the BUG_ON at i915_gem.c:1061, so I'm hoping someone can tell me where I messed up the list handling (the change in i915_gem_retire_request tries to deal with that, since the flushing list is also non-empty at leavevt time for some reason). Ok, some more details on this. It looks like we're getting to unbind with an active object, generally from get_fence but sometimes from other paths too. The object is active so i915_gem_wait_rendering(obj) ends up calling i915_wait_request() on it. But the object itself isn't on any of the lists: inactive, flushing, or active, which is probably why wait_request doesn't end up clearing its active flag (even though its seqno has passed). Also, I confirmed that i915_gem_object_set_domain wasn't queuing a request with the object by putting the BUG_ON(obj-active) up above it, so this seems to be just an object retirement bug of some kind... Jesse - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] GTT mapping support for GEM
On Thursday, October 23, 2008 5:09 pm Jesse Barnes wrote: On Thursday, October 23, 2008 3:51 pm Jesse Barnes wrote: On Wednesday, October 22, 2008 2:42 pm Jesse Barnes wrote: Ok, this one actually works w/o corrupting your display. However, after running for awhile I end up hitting the BUG_ON at i915_gem.c:1061, so I'm hoping someone can tell me where I messed up the list handling (the change in i915_gem_retire_request tries to deal with that, since the flushing list is also non-empty at leavevt time for some reason). Ok, some more details on this. It looks like we're getting to unbind with an active object, generally from get_fence but sometimes from other paths too. The object is active so i915_gem_wait_rendering(obj) ends up calling i915_wait_request() on it. But the object itself isn't on any of the lists: inactive, flushing, or active, which is probably why wait_request doesn't end up clearing its active flag (even though its seqno has passed). Also, I confirmed that i915_gem_object_set_domain wasn't queuing a request with the object by putting the BUG_ON(obj-active) up above it, so this seems to be just an object retirement bug of some kind... Here's the latest patch I'm playing with, which includes some fixes for things Eric noticed today: - fixup errot paths in map_gtt_ioctl (don't leak refs, make sure to unlock) - remove mapped list, just add gtt mapped stuff to the inactive list (assuming this is the first time it's bound) - don't allocate a fence register for every GTT bind, only do it for faulted objects (otherwise we end up just wasting them all) - play with just zapping the page range from get_fence (this somewhat works--it's more stable but there's some corruption, so either I'm not zapping the previous map correctly or I'm setting the fences up wrong) As for the lists, I realized that the pinned front buffer probably won't be on any lists, at least to begin with, so that could explain what I saw earlier. However it should have a nonzero pin count so I don't know why we'd try to evict it... Ugg, get_fence was pretty broken in the !reg case... fixing that makes things a bit more stable... -- Jesse Barnes, Intel Open Source Technology Center - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] GTT mapping support for GEM
On Thursday, October 23, 2008 3:51 pm Jesse Barnes wrote:
On Wednesday, October 22, 2008 2:42 pm Jesse Barnes wrote:
Ok, this one actually works w/o corrupting your display. However, after
running for awhile I end up hitting the BUG_ON at i915_gem.c:1061, so I'm
hoping someone can tell me where I messed up the list handling (the
change in i915_gem_retire_request tries to deal with that, since the
flushing list is also non-empty at leavevt time for some reason).
Ok, some more details on this. It looks like we're getting to unbind with
an active object, generally from get_fence but sometimes from other paths
too. The object is active so i915_gem_wait_rendering(obj) ends up calling
i915_wait_request() on it. But the object itself isn't on any of the
lists: inactive, flushing, or active, which is probably why wait_request
doesn't end up clearing its active flag (even though its seqno has passed).
Also, I confirmed that i915_gem_object_set_domain wasn't queuing a request
with the object by putting the BUG_ON(obj-active) up above it, so this
seems to be just an object retirement bug of some kind...
Here's the latest patch I'm playing with, which includes some fixes for things
Eric noticed today:
- fixup errot paths in map_gtt_ioctl (don't leak refs, make sure to unlock)
- remove mapped list, just add gtt mapped stuff to the inactive list
(assuming this is the first time it's bound)
- don't allocate a fence register for every GTT bind, only do it for faulted
objects (otherwise we end up just wasting them all)
- play with just zapping the page range from get_fence (this somewhat
works--it's more stable but there's some corruption, so either I'm not
zapping the previous map correctly or I'm setting the fences up wrong)
As for the lists, I realized that the pinned front buffer probably won't be on
any lists, at least to begin with, so that could explain what I saw earlier.
However it should have a nonzero pin count so I don't know why we'd try to
evict it...
Jesse
diff --git a/Makefile b/Makefile
index 16e3fbb..fac635f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 27
-EXTRAVERSION =
+EXTRAVERSION = -drm-gtt
NAME = Rotary Wombat
# *DOCUMENTATION*
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index bde64b8..9916366 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -262,6 +262,9 @@ static int drm_addmap_core(struct drm_device * dev, unsigned int offset,
DRM_DEBUG(AGP offset = 0x%08lx, size = 0x%08lx\n, map-offset, map-size);
break;
+ case _DRM_GEM:
+ DRM_ERROR(tried to rmmap GEM object\n);
+ break;
}
case _DRM_SCATTER_GATHER:
if (!dev-sg) {
@@ -419,6 +422,9 @@ int drm_rmmap_locked(struct drm_device *dev, drm_local_map_t *map)
dmah.size = map-size;
__drm_pci_free(dev, dmah);
break;
+ case _DRM_GEM:
+ DRM_ERROR(tried to rmmap GEM object\n);
+ break;
}
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 96f416a..aad8d76 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -236,6 +236,7 @@ int drm_lastclose(struct drm_device * dev)
dev-lock.file_priv = NULL;
wake_up_interruptible(dev-lock.lock_queue);
}
+ dev-dev_mapping = NULL;
mutex_unlock(dev-struct_mutex);
DRM_DEBUG(lastclose completed\n);
@@ -290,6 +291,8 @@ EXPORT_SYMBOL(drm_init);
*/
static void drm_cleanup(struct drm_device * dev)
{
+ struct drm_driver *driver = dev-driver;
+
DRM_DEBUG(\n);
if (!dev) {
@@ -319,6 +322,9 @@ static void drm_cleanup(struct drm_device * dev)
drm_ht_remove(dev-map_hash);
drm_ctxbitmap_cleanup(dev);
+ if (driver-driver_features DRIVER_GEM)
+ drm_gem_destroy(dev);
+
drm_put_minor(dev-primary);
if (drm_put_dev(dev))
DRM_ERROR(Cannot unload module\n);
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 0d46627..0958cf6 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -147,11 +147,21 @@ int drm_open(struct inode *inode, struct file *filp)
spin_lock(dev-count_lock);
if (!dev-open_count++) {
spin_unlock(dev-count_lock);
- return drm_setup(dev);
+ retcode = drm_setup(dev);
+ goto out;
}
spin_unlock(dev-count_lock);
}
+out:
+ mutex_lock(dev-struct_mutex);
+ if (dev-dev_mapping == NULL)
+ dev-dev_mapping = inode-i_mapping;
+ else if (dev-dev_mapping != inode-i_mapping)
+ WARN(1, dev-dev_mapping not inode mapping (%p expected %p)\n,
+ dev-dev_mapping, inode-i_mapping);
+ mutex_unlock(dev-struct_mutex);
+
return retcode;
}
EXPORT_SYMBOL(drm_open);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ccd1afd..431dc3c 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -64,6 +64,13 @@
* up at a later date, and as our interface with shmfs for memory allocation.
*/
+/*
+ * We make up offsets for buffer
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 2008-10-23 at 14:24 -0700, Linus Torvalds wrote: The whole point of that function has absolutely nothing to do with highmem, and it *must* be useful on non-highmem configurations to be appropriate. Right, I'd just like my io_mapping_map_atomic_wc to be able to rapidly map random pages from my PCI BAR in WC mode. The code in your tree uses kmap_atomic_pfn, which does the mapping, but use the wrong prot bits. On a system with MTRR failure, this all ends badly, with factors of 20 performance drops for copying data from the CPU to the aperture. So I'd much rather create a new linux/kmap.h or something. Or just expose this from to asm/fixmap.h or something. Let's not confuse this with highmem, even if the implementation _historically_ was due to that. Sure, we readily admit that we're abusing the highmem API. So we wrapped that abusive code in a pretty package that can be re-implemented however you desire. How (and when) would you like to see this fixed? -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ATI XV Output Patch
I've pulled GIT xf86-video-ati for some months now and I always have
to apply this patch:
diff --git a/src/radeon_video.c b/src/radeon_video.c
index ac60166..c400468 100644
--- a/src/radeon_video.c
+++ b/src/radeon_video.c
@@ -1597,5 +1597,8 @@ skip_theatre:
static XF86VideoAdaptorPtr
RADEONSetupImageVideo(ScreenPtr pScreen)
{
+// Disable this Xv adaptor
+return NULL;
+
ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum];
RADEONPortPrivPtr pPriv;
XF86VideoAdaptorPtr adapt;
Without it, I can't watch videos with xv output. Any reason this issue
is not getting fixed?
--
Esben Stien is [EMAIL PROTECTED] s a
http://www. s tn m
irc://irc. b - i . e/%23contact
sip:b0ef@ e e
jid:b0ef@n n
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 23 Oct 2008, Keith Packard wrote: So I'd much rather create a new linux/kmap.h or something. Or just expose this from to asm/fixmap.h or something. Let's not confuse this with highmem, even if the implementation _historically_ was due to that. Sure, we readily admit that we're abusing the highmem API. So we wrapped that abusive code in a pretty package that can be re-implemented however you desire. How (and when) would you like to see this fixed? I'm not entirely sure who wants to own up to owning that particular part of code, and is willing to make kmap_atomic_prot_pfn() also work in the absense of CONFIG_HIGHMEM. I suspect it's Ingo, but I also suspect that he'd like to see a tested patch by somebody who actually _uses_ this code. So I would suspect that if you guys actually write a patch, and make sure that it works on x86-32 even _without_ CONFIG_HIGHMEM, and send it to Ingo, good things will happen. As to the without CONFIG_HIGHMEM part: making all of this work even without HIGHMEM should literally be a matter of: - remove the '#ifdef CONFIG_HIGHMEM' in asm/fixmap_32.h, so that we have fixmap entries for the temporary kernel mappings regardless (ie FIX_KMAP_BEGIN and FIX_KMAP_END). - move the code for the atomic accesses that use those fixmap entries into a file that gets compiled regardless of CONFIG_HIGHMEM. Or at least just kmap_atomic_prot_pfn() and kunmap_atomic(). and it probably should all work automatically. The kmap_atomic() stuff really should be almost totally independent of CONFIG_HIGHMEM, since it's really much more closely related to fixmaps than HIGHMEM. I guess there may be some debugging code that depends on HIGHMEM (eg that whole testing for whether a page is a highmem page or not), so it might be a _bit_ more than just moving code around, but I really didn't look closer. Then, there's the issue of 64-bit, and just mapping everything there, and the interface to that. I liked the trivial extension to struct resource to have a cached mapping pointer. So if we can just make it pass resources around and get a page that way (and not even need kmap() on 64-bit architections), that would be good. It's too late for -rc1 (which I'm planning on cutting within the hour), and if it ends up being complex, I guess that it means this will eb a 2.6.29 issue. But if it really is just a matter of mostly just some trivial code movement and both the gfx and x86 people are all happy, I'll happily take it for -rc2, and we can just leave this all behind us. Linus - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 2008-10-23 at 14:24 -0700, Linus Torvalds wrote: The whole point of that function has absolutely nothing to do with highmem, and it *must* be useful on non-highmem configurations to be appropriate. So I'd much rather create a new linux/kmap.h or something. Or just expose this from to asm/fixmap.h or something. Let's not confuse this with highmem, even if the implementation _historically_ was due to that. Well, on powerpc, we just went (or rather, Kumar just went) through the oops of implementing fixmap and then kmap on top of it... just because we wanted kmap_atomic functionality on non-highmem platforms :-) (and the fixmap approach has some other interesting features). So yes, I agree. Typically very useful for any 32-bit processor with a memory mapped PCI Express config space since it's something like 256M of virtual space to map it all iirc. Cheers, Ben. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote: Then, there's the issue of 64-bit, and just mapping everything there, and the interface to that. I liked the trivial extension to struct resource to have a cached mapping pointer. So if we can just make it pass resources around and get a page that way (and not even need kmap() on 64-bit architections), that would be good. I'm not that fan of carrying a mapping with a struct resource because if we do that we should probably also refcount the mapping, and then there is the whole question of mappings with different attributes, etc etc... Cheers, Ben. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote: I'm not entirely sure who wants to own up to owning that particular part of code, and is willing to make kmap_atomic_prot_pfn() also work in the absense of CONFIG_HIGHMEM. All of the kmap_atomic functions *do* work without CONFIG_HIGHMEM, they just don't do what we want in this case. Without knowing the history, it seems fairly clear that the kmap functions are designed to map physical memory pages into the kernel virtual address space. On small 32-bit systems, that's trivial, you just use the direct map (as one does on 64-bit systems). The magic fixmap entries make this work with CONFIG_HIGHMEM as well. So, I fear touching the kmap API as it appears to have a specific and useful purpose, irrespective of the memory size the kernel is configured for. What I've proposed is that we create a new io-space specific set of fixmap APIs. On CONFIG_HIGHMEM, they'd just use the existing kmap_atomic mechanism, but on small 32-bit systems, we'd enable the fixmaps and have some for that environment as well. So I would suspect that if you guys actually write a patch, and make sure that it works on x86-32 even _without_ CONFIG_HIGHMEM, and send it to Ingo, good things will happen. Ok, we can give this a try. and it probably should all work automatically. The kmap_atomic() stuff really should be almost totally independent of CONFIG_HIGHMEM, since it's really much more closely related to fixmaps than HIGHMEM. As above, I think kmap_atomic should be left alone as a way of quickly mapping memory pages. There are a users of both kmap_atomic_prot (xen) and kmap_atomic_pfn (crash dumps). I guess there may be some debugging code that depends on HIGHMEM (eg that whole testing for whether a page is a highmem page or not), so it might be a _bit_ more than just moving code around, but I really didn't look closer. Then, there's the issue of 64-bit, and just mapping everything there, and the interface to that. I liked the trivial extension to struct resource to have a cached mapping pointer. So if we can just make it pass resources around and get a page that way (and not even need kmap() on 64-bit architections), that would be good. The io_mapping API I proposed does precisely this. On 32-bit systems, it uses kmap_atomic for each page access while on 64-bit systems it uses ioremap_wc at device init time and then just uses an offset for each page access. Hiding this detail behind an API leaves the driver code independent of this particular choice. It's too late for -rc1 (which I'm planning on cutting within the hour), and if it ends up being complex, I guess that it means this will eb a 2.6.29 issue. If we do end up pushing this out to 2.6.29, I'd like to see kmap_atomic_prot_pfn in place as a stop-gap so that PAT performance on 32-bit systems is reasonable. I don't think too many people are running desktop systems without CONFIG_HIGHMEM at this point, and if so, we can just suggest that perhaps they change their configuration. But if it really is just a matter of mostly just some trivial code movement and both the gfx and x86 people are all happy, I'll happily take it for -rc2, and we can just leave this all behind us. I'll try to get something working in the next day or so and see how it looks. My plan at this point is to create new API for 32-bit systems: void *io_map_atomic_wc(unsigned long pfn) void io_unmap_atomic(void *addr); With this, I can switch my existing io_mapping API over to an io-specific interface and implement those using the fixmap code. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Fri, 2008-10-24 at 14:24 +1100, Benjamin Herrenschmidt wrote: I'm not that fan of carrying a mapping with a struct resource because if we do that we should probably also refcount the mapping, and then there is the whole question of mappings with different attributes, etc etc... I'm fine with sticking the mapping in a separate structure; it's just the return from ioremap_wc on 64-bit systems, and nothing at all on 32-bit systems. I don't really see the advantage of moving it into the resource, especially as we may need different access modes (UC vs WC) for different portions of a single BAR. We may want to add some bounds and access mode information to this structure to check for broken drivers. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
