Re: __ioremap_at() in 2.4.0-test9-pre2

Dan Malek writes:

You still have to be careful here.  Drivers that are written to
do this may also make the assumption they can store that "address"
in a 16-bit (signed, even worse) variable.  You will have to change
drivers (or structures) in this case.

Sure.  Fortunately PPC isn't the only architecture where I/O ports can
be > 16 bits, I believe sparc64 runs into this too.  In fact sparc64
needs 32-bit interrupt numbers rather than 8-bit, as well.

I don't so much care if in/out is used/abused, but I think device
drivers should be written such that they ask for addresses through
the PCI (or other I/O) subsystem, rather than just grab BARs and

Definitely, for drivers for PCI devices.

expect to use them.  The x86 in/out was stupid back in 1983, and is
even less useful today.  It is lots easier to adopt a memory mapped
model and adapt it to x86, than for the rest of us to keep trying to
create contortions of an address map just so we can use poorly written

"Virtual != physical" is "contortions" ???

x86 device drivers.  I think it is easier to update a driver, which
I have done on a couple of occasions, to be more portable than to
try and find ways to use it without making any changes.  The authors
of the drivers have even accepted this in some cases :-).

I suggest you post a patch on linux-kernel to change all the device
drivers to use memory-mapped I/O.  I wish you luck.  :-) :-)

These address mapping hacks were fine years ago when there was
only one PCI bus at a fixed address in the system.  Today, there
are lots of busses, with transparent (or not) bridges, and we have
a PCI subsystem in Linux that is maturing into a really useful set of
functions.  The embedded CompactPCI systems are way ahead of workstations
in terms of complexity of PCI (and other) bus structures.  In these
environments we rely heavily on the virtual mapping of I/O, and if
you have a BAR it doesn't mean much to your driver.  I would like to
see us look toward the future, to a model where we map I/O through
the VM subsystem, instead of trying to find hacks to support addressing
assumptions that just aren't valid any longer.

You'll have to explain this a little more.  When you say "virtual
mapping of I/O", do you mean I/O devices in PCI memory space or in PCI
I/O space?  We (of course) already map I/O registers in PCI memory
space through the VM subsystem.  Are you talking about PCI I/O space?
What sorts of VM mapping tricks do you want to do for PCI I/O space,
and why?

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/