In the savage DRM driver I added some code that uses knowledge about adjacent address ranges and BAR sizes (as opposed to the actual VRAM size) to allocate the minimum number of MTRRs. This was the only way to cover the frame buffer and additional frame buffer apertures without wasting too many MTRRs. It still relies on the automatic MTRR setup on some hardware where it does the right thing.
See savage_bci.c function savage_driver_firstopen for details. Regards, Felix Am Freitag, den 23.09.2005, 12:42 +0100 schrieb Alan Hourihane: > On Fri, 2005-09-23 at 12:30 +0100, Alan Hourihane wrote: > > Has anyone any objections to me removing the MTRR code from the DRM. > > > > It doesn't have the intimate knowledge needed to properly configure > > MTRR's and fails in many cases. > > > > There are two cases currently, one for the framebuffer and a second for > > the entire AGP space. > > > > Certainly in Intel hardware this is the same memory space and you always > > get bogus error messages in your kernel logs as things fail due to lack > > of boundary checks. > > > > I'm more of the opinion that it should be left up to userspace to > > configure MTRR's if it indeed wants them and we shouldn't force them > > within the DRM. > > > > Additionally, the Xserver (for user-space) already sets up the MTRR's, > > as should Xgl (Xegl) or other user space apps. > > > > What makes the situation a little worse is that vesafb (and other *fb > > drivers) also setup an mtrr which frequently stops subsequent processes > > from adding a new one that overlaps an existing write-combining range. > > But the *fb drivers do provide a nomtrr option in many cases. (But I'd > > like to remove it from them too :-) or at least default those to off) > > > > Comments ?? > > One thing to add, is that I did initially look at just removing > DRIVER_USE_MTRR from the intel DRM, but it really doesn't satisfy other > use cases for the other chipsets. Again, inline with the fact there may > already be existing mtrr's setup and the DRM fails to honour proper > checking. > > But I'm interested in others comments on this. > > Alan. > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
