Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Nov 2005 10:30:57 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        freebsd-current@freebsd.org
Subject:   Re: NVidia driver for amd64 / Page Attribute Table status?
Message-ID:  <200511151030.58879.jhb@freebsd.org>
In-Reply-To: <17273.59797.727269.288021@grasshopper.cs.duke.edu>
References:  <436E66FB.60700@desk.pl> <200511141153.27640.jhb@freebsd.org> <17273.59797.727269.288021@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

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@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511151030.58879.jhb>