Subject: Re: ioremap() broken?

From: "Kevin D. Kissell" <[email-masked]>
Date: Tue, 15 Feb 2000 12:22:49 +0100

>> > 1. Is it really necessary to add anything to the addr in the readb() et al.
>> >    macros? ioremap() already takes care of that.
>> 
>> There is something of an "embarassment of riches" in the kernel
>> code in terms of mechanism for getting at I/O resources.  I don't
>> think it was ever intended that people use readb() on addresses
>> that had already been massaged with ioremap().  ioremap() is
>> used where the driver *expects* an memory-mapped I/O model,
>> and is applied to pointers that will be used to directly reference
>> the device.  readb/writeb et. al. are for drivers that think that expect
>> a more peek/poke like model.  I don't think it was ever intended that
>> someone apply both at once!
>
>Yes it is! Please read Documentation/IO-mapping.txt. To access PCI memory
>space, you have to use ioremap() and readb() and friends. If PCI drivers have
>to work across differen architectures, this has to be fixed.

OK, having looked at the documentation, I've seen the Holy Word of 
Linus in the topic, even if it seems to be honored mainly in the breach 
in real world drivers. It also seems to be somewhat confusing
in its treatment of ISA versus PCI, and insufficient to handle some
possible system configurations.  More on this later.
.
But for Geert's problem, the fix is simple - get rid of the offset added 
in the readb() macro and its friends.   Linus' definitions are a bit vague.
The "addresses" returned by ioremap() need not, according to his
description, be valid addresses at all, but must simply be tokens that
are unique within the system and usable by readb() et. al.  All VM
manipulation *could* be handled in the readb() code, but that would
in general be inefficient.  It seems clear enough that ioremap() should 
encapsulate all address transformation and VM resource management, 
and that readb() should encapsulate the mechanics of the data transfer.

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.

The readb/writeb/etc. macros thus are not expected to fix any mappings,
but rather to provide wrappers that would conceal the use of special
I/O access instructions, non-fatal bus error resolution, etc., depending
on the platform and the architecture.  On current MIPS systems, it maps 
directly to a load/store.

            Kevin K.

---

From: Harald Koerfgen <[email-masked]>
Date: Tue, 15 Feb 2000 18:14:33 +0100 (MET)

> mapping, and on such systems ioremap() would have some real work

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. 

Before you're beginning to ask, yes, I *do* have Linux/MIPS running on a Sharp
Mobilon HC-4500 :-), and, no, PCMCIA is not working yet :-(

What I am trying to say is that sooner or later we may have to deal with this
case as well.

---
Regards,
Harald

---

From: "William J. Earl" <[email-masked]>
Date: Tue, 15 Feb 2000 11:01:13 -0800 (PST)

> On 15-Feb-00 Kevin D. Kissell wrote:
...
 > size"-trick will not work. 
...

     As part of the XFS port to Linux, Steve Lord ([email-masked]) 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 oss.sgi.com as we finished the encumbrance reviews,
but it will be at least a few weeks more before a compilable patch is
available.