[Top] [All Lists]

Re: ioremap() broken?

To: "Harald Koerfgen" <>
Subject: Re: ioremap() broken?
From: "William J. Earl" <>
Date: Tue, 15 Feb 2000 11:01:13 -0800 (PST)
Cc: "Kevin D. Kissell" <>,, Geert Uytterhoeven <>
In-reply-to: <>
References: <00f001bf77a7$01e6cd10$> <>
Harald Koerfgen writes:
 > On 15-Feb-00 Kevin D. Kissell wrote:
 > > It is a coincidence that ioremap() is so simple on most current MIPS 
 > > platforms.  On some systems, and on MIPS systems with more than 
 > > 512M of combined memory and mapped I/O, it would be necessary
 > > to invoke VM functions to create (and possibly wire) a kernel address
 > > mapping, and on such systems ioremap() would have some real work
 > > to do.
 > Yes, indeed. The Philips PR31700/Toshiba TMPR3912 is such a beast and I could
 > imagine that other MIPS based embedded CPUs tend to be similar.
 > On this particular CPU PCMCIA memory is accessed through *physical* addresses
 > 0x64000000-0x6bffffff, and thus unreachable through KSEG0 or KSEG1. To make
 > things even more delicate, this CPU is based on a R3000 core and supports 4kB
 > pages only, so even ye olde "let's create a wired TLB entry with 16 MB page
 > size"-trick will not work. 

     As part of the XFS port to Linux, Steve Lord ( has done
a function to map a set of pages into contiguous kernel virtual space,
where the kernel virtual space is dynamically allocated and released as
one acquires and releases the mapping.  (For calls which happen to resolve
to a single, statically-mapped page, the call can use the static mapping.)
This is presently embedded in a higher-level module, but it could be made
a separate facility.  The present implementation is inefficient, as it uses
an inefficient underlying Linux facility, but that could be fixed if there
much need for it.  Check with Steve Lord if interested.  The XFS source
is trickling out onto as we finished the encumbrance reviews,
but it will be at least a few weeks more before a compilable patch is

<Prev in Thread] Current Thread [Next in Thread>