EXA support for nv driver

[Benjamin Herrenschmidt]

On Fri, 2005-08-26 at 14:59 +0100, Alan Cox wrote:
> On Gwe, 2005-08-26 at 16:58 +1000, Benjamin Herrenschmidt wrote:
> > Mapping cacheable ? Hrm... I'm not sure that would work with many
> > chipsets as I'm not sure they would trigger proper coherency protocol
> > when beeing accessed by the card. I currently map them non-cacheable on
> > Macs but it might be worth trying on some chipsets I suppose...
> 
> x86 requires your mappings for the same physical page are consistent, so
> you have to be very careful how you view a block of pages. That said
> there should be advantages in pulling pages out of the gart, processing
> them cached, flusing the page to ram and then putting it back uncached
> in the gart

Yes, and that can bite us on ppc too, though we have been lucky so far.
The problem is that we need to map those AGP pages non-cacheable because
AGP isn't cache coherent and AGP "clients" don't have hooks for flushing
the cache at the right time (would be expensive too), but at the same
time, we can't easily "remove" those pages from the kernel linear
mapping which is cacheable... This is especially true when using large
pages for the kernel linear mapping (which we really don't want to drop)
since ppc has this "issue" of not beeing able to mix small & large page
sizes in a 256Mb segment, thus we can't just "break up" the 16M page
that contains AGP pages.

So currently, we are on the unsafe-side of things on ppc because of
that, but it seems we have been lucky enough so far that it didn't
trigger any visible problem.

On x86, most if not all chipsets afaik can map the AGP aperture in
processor memory, so there is no need to to have a mapping on the RAM
pages themselves, and thus the problem shouldn't exist at the page
tables level (I don't know about the MTRR stuff), except for the GART
itself maybe, but in that case, it's easy to just map it cacheable and
do appropriate flushes when updating it.

Ben.