diff options
| author | Dave Airlie <airlied@linux.ie> | 2009-10-09 20:09:52 +1000 |
|---|---|---|
| committer | Dave Airlie <airlied@linux.ie> | 2009-10-09 20:09:52 +1000 |
| commit | 1b25bad2d8ebe481ffb4b0fd3a85ab636bd4fec2 (patch) | |
| tree | a00148cf4ecfe3b277b63c17bd3b1b1202ff6e4a | |
| parent | a956d478043b44c49aed39c7aa3d576ef32cadc5 (diff) | |
Revert "radeon: clamp the internal FB map to the aperture size"
This reverts commit 5f846360c46f5a989f5d0fde6d251cdbd61d4968.
Numerous reports of system hangs since this, I'm guessing
some sort of conflict with the drm memory setup. This code
has always been fragile between kernel/userspace drivers.
| -rw-r--r-- | src/radeon_driver.c | 9 |
1 files changed, 0 insertions, 9 deletions
diff --git a/src/radeon_driver.c b/src/radeon_driver.c index d5704d3..d039920 100644 --- a/src/radeon_driver.c +++ b/src/radeon_driver.c @@ -1403,15 +1403,6 @@ static void RADEONInitMemoryMap(ScrnInfoPtr pScrn) if (aper_size > mem_size) mem_size = aper_size; - /* don't map the whole FB in the internal address space. - * we don't currently use fb space larger than the aperture - * size and on cards with 1 GB of vram, this can overflow - * the internal top of gart calculation on some systems. - * See fdo bug 24301. - */ - if (mem_size > aper_size) - mem_size = aper_size; - #ifdef XF86DRI /* Apply memory map limitation if using an old DRI */ if (info->directRenderingEnabled && !info->dri->newMemoryMap) { |