__ioremap_at() in 2.4.0-test9-pre2

[Paul Mackerras]

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 at 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/