lkml.org 
[lkml]   [1999]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: MTRR & NVTNT
From
Date
Scott Lampert <fortunato@heavymetal.org> writes:
> On Thu, Mar 11, 1999 at 08:35:58PM +1100, Richard Gooch wrote:
> > Scott Lampert writes:
> >
> > > Forgive me if I show my lack of knowledge on the subject, but
> > > I've been trying to figure out how to get MTRR working with my
> > > Nvidia TNT AGP board in 2.2.3 but it keeps giving me errors such as:
> > > mtrr: base(0xe6000000) is not aligned on a size(0xff0000) boundary
> > >
> > > Of course, I agree, it apparently isn't aligned that way. Does this
> > > mean that one cannot use MTRR with the NVidia TNT boards? Looking
> > > on a Windows box with the same card it appears to break up the 16
> > > megs of video RAM into non-contiguous blocks. I'm not even sure if
> > > the Windows drivers are making use of the MTRRs. Anyhow, just
> > > thought I'd throw out the question and see if anyone would be kind
> > > enough to clue me in. Thanks,
> >
> > You have a 16 MB card. Why do you try to set the size to 15 MB
> > (0xff0000)?

But 0xff0000 is 16M - 64K.

I don't know anything about the TNT, but it's possible that it uses a
framebuffer of slightly less than 16MB, and a 64KB area for MMIO (or
maybe some real memory used for non-framebuffer purposes).

> Doh! You're right of course. Setting it to size (0x1000000) worked
> fine. That leads me to another two questions if you have the time:
>
> My X server has this line for video ram:
>
> (--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xe4000000, 0xe6000000
>
> Does this mean I should have two 8 meg MTRR entries at those base
> addresses or just ignore the first one?

The part you want a write-combining region for is the frame-buffer. If
it's not clear from the X server output, there is another way. With X
running, find the pid of the X server and cat /proc/<pid>/maps. One of
the entries will be the mmap of the framebuffer, and you can find its
physical address and exact size.

> And secondly I noticed when I use the VESA fb console, it
> works fine, however when it tries to automatically set the MTRR at
> the 0xe6000000 base address it incorrectly tries to use size
> 0xff0000 like I was doing before and gets the same error. This
> would appear to be a bug. I know you didn't write this part of the
> kernel, but since I'm carboning this to the kernel list I figured
> I'd mention it in case it was significant.

Which makes it look likely that you really do have a 0xff0000 byte
framebuffer. If the other 64KB is an MMIO area, write-combining it
could lead to problems.

You can create a write-combining range over a 0xff0000 byte
framebuffer, but it's a little bit more complicated than usual.

The MTRRs only support regions with a power-of-two size. You could
break a region of size 0xff0000 into 8 such regions, but current Intel
processor only have 8 MTRR ranges, and you need one or more to cover
main memory.

There is another way: You can add a write-combining region, then cover
part of it with an uncached region, and within that part the uncached
region will take precedence. The MTRR driver code knows that cases of
overlapping regions like this are legal.

So something like

# echo "base=0xe6000000 size=0x1000000 type=write-combining" >! /proc/mtrr
# echo "base=0xe6ff0000 size=0x10000 type=uncachable" >! /proc/mtrr

it should work.

[The rest is mostly a note to Richard, since I'm on the subject.]

It would be nice if something did this automatically. Working out the
minimum number of regions needed to cover a range of any size is a
tractable problem, but would require quite a bit of code. However, two
region cases are pretty easy. Any range that has

- Any contiguous block of set bits in the size (can use a
"subtractive" region as above), or

- Two bits set anywhere in the size (can create two neighbouring
regions).

can be write-combined using two regions. It doesn't take much code to
detect and deal with these cases.

My MTRR support in XFree86 (to appear in 4.0) currently only deals
with power-of-two framebuffer ranges (actually it just passes the
framebuffer range straight to the MTRR driver), but I'm tempted to add
two region support.

The MTRR driver also provides MTRR access to the rest of the kernel;
from what Scott write, it looks like fbcon could use two region
support? There is a neat way to do it without changing the MTRR API:
The MTRR driver could reveal virtual MTRR ranges to user space and the
rest of the kernel, then when changes are made it "renders" the
virtual ranges into the true MTRR registers (or whatever non-Intel
processors have). This would also allow support of the fixed MTRR
ranges is a consistent way. The question is whether it could be done
without unduly increasing the size of the MTRR driver.

Dave Wragg



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.091 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site