From: Paul Mackerras <paulus@linuxcare•com.au>
To: Dan Malek <dan@mvista•com>
Cc: frowand@mvista•com,
Linux/PPC Development <linuxppc-dev@lists•linuxppc.org>
Subject: Re: __ioremap_at() in 2.4.0-test9-pre2
Date: Sun, 1 Oct 2000 19:16:20 +1100 (EST) [thread overview]
Message-ID: <14806.62164.27906.255635@argo.linuxcare.com.au> (raw)
In-Reply-To: <39D68EB8.4CAD5168@mvista.com>
Dan Malek writes:
> This "equivalent" mapping is going to be the greatest challenge. The
> reason this happens is because we need access through the MMU before
> the kernel has initialized the kernel VM allocator. Parts of the early
> kernel initialization that have to access control/status registers of
> various types are going to be mapped 1:1. After some of these proposed
> changes, these mappings are going to be destroyed and remapped (to get
> the "standard" 0xff000000 address). This is really bad for the
Ummm, no, I think we may have a misunderstanding here.
First, you can use ioremap before the kernel VM allocator is set up,
and you can continue to use the virtual addresses you get by doing so.
So no mappings are going to be destroyed and remapped. All we do for
early ioremaps of addresses < ioremap_base is to allocate addresses
starting at ioremap_base and going down. And yes, we will need to do
that for addresses >= 0xff000000 too (in fact 0xfe000000 if we are
using CONFIG_HIGHMEM). Actually, there's really no reason why we
shouldn't do that for all physical addresses. So the code in ioremap
would become something like this:
if (mem_init_done) {
struct vm_struct *area;
area = get_vm_area(size, VM_IOREMAP);
if (area == 0)
return NULL;
v = VMALLOC_VMADDR(area->addr);
} else {
v = (ioremap_bot -= size);
}
(leaving out the "if (p >= ioremap_base)" test), and we could
initialize ioremap_bot to 0xff000000 (or 0xfe000000 in the highmem
case).
Secondly, all your integrated devices would be using memory-mapped
I/O, so the question of what _IO_BASE is, and how inb/outb work, is
pretty much irrelevant to you, isn't it?
Paul.
--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare•com.au, http://www.linuxcare.com.au/
Linuxcare. Support for the revolution.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-10-01 8:16 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-17 18:59 __ioremap_at() in 2.4.0-test9-pre2 Geert Uytterhoeven
2000-09-19 3:59 ` Paul Mackerras
2000-09-19 5:56 ` Michel Lanners
2000-09-19 14:28 ` Dan Malek
2000-09-19 18:31 ` Roman Zippel
2000-09-19 20:09 ` Dan Malek
2000-09-19 23:42 ` Roman Zippel
2000-09-20 0:10 ` Dan Malek
2000-09-20 17:18 ` Roman Zippel
2000-09-20 18:11 ` Dan Malek
2000-09-20 20:22 ` Roman Zippel
2000-09-20 20:41 ` David Edelsohn
2000-09-21 2:16 ` Dan Malek
2000-09-21 2:26 ` David Edelsohn
2000-09-21 2:40 ` Dan Malek
2000-09-21 3:53 ` David Edelsohn
2000-09-19 22:06 ` Matt Porter
2000-09-19 22:58 ` Paul Mackerras
2000-09-20 6:12 ` Matt Porter
2000-09-20 12:15 ` Geert Uytterhoeven
2000-09-20 23:08 ` Paul Mackerras
2000-09-21 20:12 ` Matt Porter
2000-09-20 8:34 ` Roman Zippel
2000-09-20 22:54 ` Paul Mackerras
2000-09-20 15:56 ` Dan Malek
2000-09-20 23:22 ` Paul Mackerras
2000-09-21 2:13 ` Dan Malek
2000-09-21 2:35 ` Paul Mackerras
2000-09-21 3:57 ` Dan Malek
2000-09-21 5:06 ` Paul Mackerras
2000-09-21 6:51 ` Dan Malek
2000-09-21 14:03 ` Geert Uytterhoeven
2000-09-21 22:40 ` Benjamin Herrenschmidt
2000-09-22 3:53 ` Dan Malek
2000-09-22 11:58 ` Geert Uytterhoeven
2000-09-22 18:46 ` Dan Malek
2000-09-22 20:06 ` Frank Rowand
2000-09-23 21:38 ` Matt Porter
2000-09-21 20:22 ` Matt Porter
2000-09-22 3:49 ` Paul Mackerras
2000-09-22 4:16 ` Dan Malek
2000-09-23 12:34 ` Geert Uytterhoeven
2000-09-27 10:37 ` Benjamin Herrenschmidt
2000-09-28 9:59 ` Geert Uytterhoeven
2000-09-28 19:19 ` Benjamin Herrenschmidt
2000-09-28 23:33 ` Benjamin Herrenschmidt
2000-09-29 5:08 ` Dan Malek
2000-09-29 11:37 ` Geert Uytterhoeven
2000-09-29 17:12 ` Kostas Gewrgiou
2000-09-29 17:18 ` Benjamin Herrenschmidt
2000-09-29 21:35 ` Michel Lanners
2000-09-30 0:11 ` Matt Porter
2000-09-29 0:22 ` Paul Mackerras
2000-09-29 0:40 ` Benjamin Herrenschmidt
2000-09-29 1:17 ` Paul Mackerras
2000-09-29 4:22 ` Dan Malek
2000-09-29 4:29 ` Dan Malek
2000-09-29 4:36 ` Paul Mackerras
2000-09-29 5:40 ` Dan Malek
2000-09-29 19:07 ` Frank Rowand
2000-09-30 1:39 ` Paul Mackerras
2000-09-30 22:50 ` Frank Rowand
2000-10-01 1:09 ` Dan Malek
2000-10-01 8:16 ` Paul Mackerras [this message]
2000-10-01 21:30 ` Dan Malek
2000-10-01 22:50 ` Paul Mackerras
2000-10-02 9:04 ` Dan Malek
2000-09-28 23:24 ` Frank Rowand
2000-09-21 13:44 ` Geert Uytterhoeven
2000-09-21 22:41 ` Benjamin Herrenschmidt
2000-09-22 21:59 ` Michel Lanners
2000-09-20 12:08 ` Geert Uytterhoeven
2000-09-20 16:31 ` Matt Porter
-- strict thread matches above, loose matches on Subject: below --
2000-09-21 7:30 Iain Sandoe
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=14806.62164.27906.255635@argo.linuxcare.com.au \
--to=paulus@linuxcare$(echo .)com.au \
--cc=dan@mvista$(echo .)com \
--cc=frowand@mvista$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)linuxppc.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