Radeon DRM GART mapping bogosity

[Michel Dänzer]

On Tue, 2005-05-03 at 10:09 +0200, Jerome Glisse wrote:
> On 5/3/05, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> > Ok, I'm cross posting here because X.org is doing it wrong too. On R300,
> > for some reason I don't fully understand, it just goes back to the "old"
> > way of putting the FB at 0 

I think that should be fixed as well, BTW.

> > (though it does properly use CONFIG_MEMSIZE
> > to set the size part of MC_FB_LOCATION), but for non R300, it does try
> > to put the framebuffer at the same address as the BAR ... and then tries
> > to use CONFIG_APER_SIZE for the size part of MC_FB_LOCATION, which is
> > incorrect.
> > 
> > The result is that on !r300, it won't crash since X.Org and DRI won't
> > create an overlapping mapping, but they won't be able to use all of VRAM
> > of some cards where CONFIG_APER_SIZE < CONFIG_MEM_SIZE, and on r300, it
> > will possibly create overlapping mappings and will cause all sorts of
> > troubles if you get the above case.
> 
> Has i still doesn't understand the big pictures of video drivers, i
> was wondering if this could have an impact on bytes swapping on r300. 
> Thus the problem of bit blit we have on r300 & X driver. I don't think 
> so but as i don't well understand all this... 

No, the big endian hostdata blit issues with R300 class cards are
strictly between the CP and the hostdata registers (as hostdata blits
work as expected with MMIO) and not related to the framebuffer or the
GART.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer