NVidia driver for amd64 / Page Attribute Table status?
John Baldwin
jhb at freebsd.org
Tue Nov 15 07:40:56 PST 2005
On Tuesday 15 November 2005 08:58 am, Andrew Gallatin wrote:
> John Baldwin writes:
> > On Sunday 13 November 2005 06:20 am, Marcin Koziej wrote:
> > > Would it be possible for You to put a snapshot patch against CURRENT
> > > for jhb_pat branch somewhere? I can't make it with P4DB interface, and
> > > i don't have access to p4.
> > >
> > > Best regards,
> > > m.
> >
> > Sure, though it's not commit ready yet.
> >
> > http://www.FreeBSD.org/~jhb/patches/pat.patch
>
> I have a question about this.. I maintain a driver where our
> device really, really wants to have its memory mapped write-combined.
> I currently use mem_range_attr_set() to (try to) do this.
>
> The problem is that some BIOSes leave useless uncacheable MTRR
> attributes laying around which obscure our device (and in fact, nearly
> all the PCI memory space). In order for the mem_range_attr_set() to
> work, there cannot be another conflicting MTRR attribute already
> covering our memory, so we play games with shell scripts which try to
> remove the uncacheable attributes. This is a royal PITA.
>
> With your new PAT stuff, does this mean that I'll no longer have
> to worry about the MTRR attributes, and I can be certain of getting
> my memory mapped write-combined?
On modern CPUs, yes. (Anything later than a PIII I think). You'll just be
able to use pmap_mapdev_attr(), though it will only work on i386 and
eventually amd64 for now. Also, that currently only affects the in-kernel
mapping, there currently isn't anything to handle the cache mode of user
mappings.
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-current
mailing list