radeon memory not detected correctly with DRI (pci quirk?)

[Brian Hinz]

Hi,

I've been trying to track down the source of a bug that's prevented DRI from 
working on my laptop since the 2.6.11 kernel (DRI + kernel >2.6.10 causes 
blank screen and high cpu utilization).  After diffing 2.6.10/2.6.11 I found 
that the following change:

bluejay linux # diff linux-2.6.10/drivers/char/agp/generic.c 
linux-2.6.11/drivers/char/agp/generic.c
213,214c213
<               new->memory[i] =
<                       agp_bridge->driver->mask_memory(bridge, 
virt_to_phys(addr), type);
---
>               new->memory[i] = virt_to_gart(addr);

seemed to be the cause of the problem (although I couldn't see why).  By 
patching a 2.6.15 kernel to use the agp_bridge->driver->mask_memory, rather 
than the newer virt_to_gart I was able to start X (7.0 modular) with DRI. 
Afterwards I noticed that when if I use a framebuffer like radeonfb or 
vesafb-tng, I get MTRR overlaps.  /proc/mtrr shows that the overlaps are due 
to DRI (incorrectly) detecting 128Mb of video memory, while radeonfb finds 
the correct amount (16Mb).  lspci also reports 128Mb however, so it appears 
that this is really an issue with the PCI registers being incorrectly 
initialized.  Just to be sure, I hacked the radeon_cp.c file from the DRI 
code from CVS and replaced the call to pci_get_resource_len with the numeric 
value of 16Mb.  As expected, the mtrr overlaps are gone.  So what's the 
proper way to handle this if the hardware or the bios is really incorrect? 
Add an entry into the kernel quirks.c?  If those registers are set by the 
bios, can it be overridden with a custom DSDT block (I did try re-compiling 
the kernel with pci access mode=bios, no difference though)?  I haven't 
tried re-compiling the kernel with virt_to_gart and the hardcoded value of 
the fb size in the DRI code together, I don't really understand the kernel 
agp code well enough to see if that's really where the problem lies.  If 
anyone can shed some light on this or offer advice on how to proceed it 
would be appreciated. Also, the machine is a Transmeta efficeon based 
notebook (sharp mm20) with a mobility M6 LY chip, and I'm using cvs versions 
of both the xf86-video-ati and drm.  A complete description of the problem 
can be found at:
http://bugzilla.kernel.org/show_bug.cgi?id=4513

Thanks,
-brian