Re: __ioremap_at() in 2.4.0-test9-pre2

[Dan Malek <dan@mvista.com>]

Frank Rowand wrote:

> This raises a question about equivalent mapping though.  Everything above
> ioremap_base is equivalently mapped by ioremap().  In 2.4.0-test2
> ioremap_base is initialized in MMU_init():

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
integrated
devices since any that used the original mapping, either in the hardware
registers or in data structures, must be tracked down, changed and
initialized all over again.  Either the "iobase" variable is going to
continue to live, or io.h is going to be filled with lots of #ifdefs
with different constants (again).


> So to answer your question, I arbitrarilly chose 0xe8000000 as ioremap_base
> because it seemed within reason, given other existing values.  I can move
> ioremap_base to lots of other places if I need to.

The 0xff000000 simply isn't workable on many of the embedded 8xx
and cPCI prep/chrp boards for the reason I mentioned above.  If Paul
wants to do this on the PMacs to assist the problem he is trying to
solve, that's fine.  I don't see any value, and only lots of time spent
in both coding and processors cycles, in trying to make this a common
VM mapping across all PowerPC platforms.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/