[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ia64
Subject:    Re: pgprot_writecombine & shub 1.x
From:       Jesse Barnes <jbarnes () engr ! sgi ! com>
Date:       2005-01-20 16:45:42
Message-ID: 200501200845.42587.jbarnes () engr ! sgi ! com
[Download RAW message or body]

On Thursday, January 20, 2005 1:03 am, Jes Sorensen wrote:
> What about real memory and mapping it uncached? Do we need to play the
> same trick before allowing it to be mapped uncached? and for IO memory
> mapped uncached?

Real memory that we map uncached or WC should be in it's own granule.  Since 
we don't have an allocator for that yet, it's generally an unsafe thing to do 
(there are exceptions though, like the mspec driver).  And yes, we should 
probably be consulting the EFI memory map before setting any attributes on a 
page (i.e. at memory init time and whenever we change the pgprot bits), but 
since almost all conventional memory can be mapped uncached or cached, and I 
think all I/O memory can be mapped uncached, I didn't worry about those cases 
(well, that and I doubt that many EFI memory maps are up to the task--it 
would be ashame to break a bunch of otherwise working machines by forcing 
them to move to a more complete EFI memory map).

> Trying to map real memory uncached was what made me stumble upon the
> PREFETCH_VISIBILITY limitation in the PAL code.

Ah, I wondered about that :)

Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]