Re: [RFC] I/O Access Abstractions

[Jeff Garzik <jgarzik@mandrakesoft.com>]

David Howells wrote:
> 
> Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> > Russell King wrote:
> > >
> > > On Mon, Jul 02, 2001 at 05:56:56PM +0100, Alan Cox wrote:
> > > > Case 1:
> > > >       You pass a single cookie to the readb code
> > > >       Odd platforms decode it
> > >
> > > Last time I checked, ioremap didn't work for inb() and outb().
> >
> > It should :)
> 
> Surely it shouldn't... ioremap() is for mapping "memory-mapped I/O" resources
> into the kernel's virtual memory scheme (at least on the i386 arch). There's
> no way to tell the CPU/MMU that a particular pages should assert the IO access
> pin rather than memory access pin (or however it is done externally).

The "at least on the i386 arch" part is the key caveat.  On PPC AFAIK,
PIO is remapped and treated very similarly to MMIO.  ioremap on x86, for
PIO, could probably be a no-op, simply returning the same address it was
given.  For other arches which want to do more complex mappings, ioremap
is IMHO the perfect part of the API for the job.

Basically I don't understand the following train of thought:

* We needed to remap MMIO, therefore ioremap was created.
* Now, we need to remap PIO too [on some arches].  Let's hide the
remapping in arch-specific code.

That's an understandable train of thought from an
implement-it-now-in-2.4 standpoint, but not from a
2.5-design-something-better standpoint.

	Jeff


-- 
Jeff Garzik      | "I respect faith, but doubt is
Building 1024    |  what gives you an education."
MandrakeSoft     |           -- Wilson Mizner