On Wed, 2005-05-04 at 09:48 +1000, Benjamin Herrenschmidt wrote:
> > If a conflict can't be avoided, we could fail gracefully upfront
> > (suggesting to make the GART aperture smaller, ...) instead of risking
> > subtle breakage?
>
> Well, I don't know of any clean platform independant way to know if
> there is a conflict or not, that is to know where RAM is in bus space.
> Especially from the PCI view, it can be anywhere. In some cases, you
> have to go through an iommu, that on most ppc64 machines (and I suppose
> sparc64 and x86_64). So the space you are looking for "preserving" is
> the iommu virtual space, which may even be different than the real ram
> space.
>
> Something that would probably work as good we can for now is to assume
> RAM at 0, check for overlap above framebuffer and eventually move the
> GART below the fb if it does, though ... maybe Michel is right and just
> ask the user to reduce the GART when it doesn't fit above the fb ? I
> hope firmwares will usually be smart enough to map the fb not at the top
> of the address space...
Ok, here's a new patch that I'll send to Linus if you (Michel) acks it.
I use CONFIG_MEMSIZE, I don't try to max out with CONFIG_APER_SIZE since
I beleive we just don't care, and that avoids putting pressure on the
GART location on configs that have a large aperture size.
If the GART doesn't fit, I move it to below the framebuffer and print a
warning.
The only thing is, that patch relies on CONFIG_MEMSIZE beeing a power of
2 I suppose... Is that always true ? If not, we'll need some hackery to
get to the nearest power of 2.
Ben.
Index: linux-work/drivers/char/drm/radeon_drv.h
===================================================================
--- linux-work.orig/drivers/char/drm/radeon_drv.h 2005-05-02
10:48:09.000000000 +1000
+++ linux-work/drivers/char/drm/radeon_drv.h 2005-05-03 17:51:55.000000000
+1000
@@ -346,6 +346,7 @@
#define RADEON_CLOCK_CNTL_DATA 0x000c
# define RADEON_PLL_WR_EN (1 << 7)
#define RADEON_CLOCK_CNTL_INDEX 0x0008
+#define RADEON_CONFIG_MEMSIZE 0x00f8
#define RADEON_CONFIG_APER_SIZE 0x0108
#define RADEON_CRTC_OFFSET 0x0224
#define RADEON_CRTC_OFFSET_CNTL 0x0228
Index: linux-work/drivers/char/drm/radeon_cp.c
===================================================================
--- linux-work.orig/drivers/char/drm/radeon_cp.c 2005-05-02
10:48:09.000000000 +1000
+++ linux-work/drivers/char/drm/radeon_cp.c 2005-05-04 11:36:49.000000000
+1000
@@ -1269,6 +1269,7 @@
{
drm_radeon_private_t *dev_priv = dev->dev_private;;
DRM_DEBUG( "\n" );
+ u32 gart_loc;
dev_priv->is_pci = init->is_pci;
@@ -1476,8 +1477,16 @@
dev_priv->gart_size = init->gart_size;
- dev_priv->gart_vm_start = dev_priv->fb_location
- + RADEON_READ( RADEON_CONFIG_APER_SIZE );
+ gart_loc = dev_priv->fb_location + RADEON_READ(RADEON_CONFIG_MEMSIZE);
+ /* overflow ? */
+ if ((gart_loc + dev_priv->gart_size) < dev_priv->fb_location) {
+ DRM_INFO("Warning ! Gart does not fit above framebuffer in "
+ "card space, moving it below. Risks collision with "
+ " main memory ! ");
+ gart_loc = dev_priv->fb_location - dev_priv->gart_size;
+ }
+
+ dev_priv->gart_vm_start = gart_loc;
#if __OS_HAS_AGP
if ( !dev_priv->is_pci )
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
