From: Jes Sorensen <jes@wildopensource.com>
To: linux-ia64@vger.kernel.org
Subject: Re: pgprot_writecombine & shub 1.x
Date: Fri, 21 Jan 2005 09:01:58 +0000 [thread overview]
Message-ID: <yq0d5vz17g9.fsf@jaguar.mkp.net> (raw)
In-Reply-To: <200501111200.02504.jbarnes@sgi.com>
>>>>> "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
prev parent reply other threads:[~2005-01-21 9:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-11 20:00 pgprot_writecombine & shub 1.x Jesse Barnes
2005-01-11 22:12 ` David Mosberger
2005-01-11 22:35 ` Jesse Barnes
2005-01-12 18:51 ` Jim Hull
2005-01-12 19:31 ` Hugo Kohmann
2005-01-12 19:32 ` Jesse Barnes
2005-01-12 21:54 ` David Mosberger
2005-01-19 17:28 ` Jesse Barnes
2005-01-19 17:53 ` David Mosberger
2005-01-19 17:56 ` Jesse Barnes
2005-01-19 18:04 ` David Mosberger
2005-01-19 18:16 ` Luck, Tony
2005-01-19 18:21 ` Jesse Barnes
2005-01-19 18:38 ` Luck, Tony
2005-01-19 19:33 ` Bjorn Helgaas
2005-01-19 21:51 ` Jesse Barnes
2005-01-19 22:00 ` Luck, Tony
2005-01-19 22:03 ` Jesse Barnes
2005-01-19 22:07 ` David Mosberger
2005-01-19 22:16 ` Jesse Barnes
2005-01-19 22:20 ` David Mosberger
2005-01-19 22:22 ` Jesse Barnes
2005-01-19 22:25 ` David Mosberger
2005-01-19 22:36 ` Jesse Barnes
2005-01-19 22:39 ` David Mosberger
2005-01-19 22:53 ` Jesse Barnes
2005-01-20 9:03 ` Jes Sorensen
2005-01-20 13:43 ` Hugo Kohmann
2005-01-20 16:42 ` Jesse Barnes
2005-01-20 16:45 ` Jesse Barnes
2005-01-20 17:17 ` David Mosberger
2005-01-21 9:00 ` Jes Sorensen
2005-01-21 9:01 ` Jes Sorensen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq0d5vz17g9.fsf@jaguar.mkp.net \
--to=jes@wildopensource.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox