Re: pgprot_writecombine & shub 1.x

From: Jes Sorensen <jes_at_wildopensource.com>
Date: 2005-01-21 20:01:58
>>>>> "Jesse" == Jesse Barnes <jbarnes@engr.sgi.com> writes:

Jesse> 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?

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

I am working on an allocator for that very reason, however I plan to
make it more generic so one can stick more than just uncached memory
into it (in it's own seperate pool of course).

Cheers,
Jes
-
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
Received on Fri Jan 21 04:04:22 2005

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:34 EST