From: Kumar Gala <kumar.gala@freescale•com>
To: "Benjamin Herrenschmidt" <benh@kernel•crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs•org>,
linuxppc-embedded@ozlabs•org
Subject: Re: RFC: Deprecating io_block_mapping
Date: Wed, 25 May 2005 01:08:06 -0500 [thread overview]
Message-ID: <0015d371e12596fecdefd971b4fb1e5a@freescale.com> (raw)
In-Reply-To: <1117000809.6395.92.camel@gaston>
>> Somewhere, at some point, prior to VM setup, we need to forcibly map
>> virtual to physical addresses. These are going to be "hard coded"
>> mappings, that's exactly how ioremap_bot is set. This is why
>> io_block_mapping was created in the first place. Somehow you have
>> to specify this mapping before you have a VM allocator to give it to
>> you. :-)
>
> No, you just need to have ioremap_bot (which is in fact "top" not
> "bottom", bad naming) initialized to something sane. This is currently
> done in MMU_init() but could probably be initialized statically
> instead.
> I do just that on ppc64 and thus can ioremap at any time without
> needing
> to allocate vmalloc space. The vmalloc space is automatically "cap'd"
> by
> ioremap_bot anyway.
Can one of you explain why this is necessary. I believe it I just dont
understand. I think this is one of the abuses of io_block_mapping().
People, myself included, realize some of the caveats implied by calling
io_block_mapping().
- kumar
next prev parent reply other threads:[~2005-05-25 6:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-25 1:30 RFC: Deprecating io_block_mapping Benjamin Herrenschmidt
2005-05-25 2:17 ` Kumar Gala
2005-05-25 2:21 ` Benjamin Herrenschmidt
2005-05-25 2:30 ` Kumar Gala
2005-05-25 5:00 ` Dan Malek
2005-05-25 6:07 ` Pantelis Antoniou
2005-05-25 5:14 ` Dan Malek
2005-05-25 5:20 ` Benjamin Herrenschmidt
2005-05-25 5:49 ` Dan Malek
2005-05-25 6:00 ` Benjamin Herrenschmidt
2005-05-25 6:08 ` Kumar Gala [this message]
2005-05-25 7:04 ` Benjamin Herrenschmidt
2005-05-25 16:36 ` Dan Malek
2005-05-25 21:44 ` Benjamin Herrenschmidt
2005-05-26 6:00 ` Dan Malek
2005-05-26 6:20 ` Eugene Surovegin
2005-05-26 19:00 ` Dan Malek
2005-05-26 21:54 ` Benjamin Herrenschmidt
2005-05-26 6:41 ` Benjamin Herrenschmidt
2005-05-26 19:32 ` Dan Malek
2005-05-26 22:10 ` Benjamin Herrenschmidt
2005-05-26 20:30 ` Mark A. Greer
2005-05-26 22:13 ` Benjamin Herrenschmidt
2005-05-26 22:16 ` Mark A. Greer
2005-05-26 16:31 ` Matt Porter
2005-05-26 16:54 ` Eugene Surovegin
2005-05-25 4:48 ` Dan Malek
2005-05-25 4:45 ` Dan Malek
2005-05-25 5:15 ` Benjamin Herrenschmidt
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=0015d371e12596fecdefd971b4fb1e5a@freescale.com \
--to=kumar.gala@freescale$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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