[lkml]   [2001]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] I/O Access Abstractions
David Howells wrote:
> Jeff Garzik <> 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 Garzik | "I respect faith, but doubt is
Building 1024 | what gives you an education."
MandrakeSoft | -- Wilson Mizner
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.092 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site