Re: [RFC] I/O Access Abstractions

[David Howells <dhowells@redhat.com>]

Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> Alan Cox wrote:
> > 
> > > > >       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 :)
> > 
> > it doesnt need to.
> > 
> > pci_find_device returns the io address and can return a cookie, ditto
> > isapnp etc
> 
> Is the idea here to mitigate the amount of driver code changes, or
> something else?

A number of things:

 * It ought to be easier to deal with having a number of ways of accessing
   resources if you just had an ops table with each struct resource. This
   would allow the bus driver to provide each resource of each device on that
   bus with a set of operations for accessing registers within that resource,
   no matter what the actual mechanism for doing so. For example:

	* direct I/O port accesses
	* direct memory-mapped I/O accesses
	* address port/data port accesses (eg: pcnet32, PCI config, etc.)
	* hide sparse I/O port accesses (eg: non-adjacent 16550 registers)
	* small-window CPU->PCI bus mapping
	* emulation of I/O port range through memory window

   Note that any number of these things can exist on the same architecture, or
   even the same platform (the GEODE GX1 & SC1200 being excellent examples).

 * It should make drivers easier to write: they don't have to worry about
   whether a resource refers to memory or to I/O or to something more exotic.

 * It makes some drivers more flexible. For example, the ne2k-pci driver has
   to be set at _compile_ time to use _either_ I/O ports _or_ memory. It'd
   make Linux installation more better if _both_ were supported.

 * It'd allow some drivers to be massively cleaned up (serial.c).

 * Permit transparent byte-swapping.

There are some other minor benefits too, but they're far less important (such
as I/O access tracing).

> If you are sticking a cookie in there behind the scenes, why go ahead
> and use ioremap?
> 
> We -already- have a system which does remapping and returns cookies and
> such for PCI mem regions.  Why not use it for I/O regions too?

You can't remap I/O ports into memory space on the i386. You can't easily
remap PCI devices if the all PCI devices peer through a small sliding window
in the CPU address space.

David