Re: ia64 implementation of lib/iomap.c

From: Linus Torvalds <>
Date: 2004-10-27 01:21:15
On Tue, 26 Oct 2004, David Mosberger wrote:
>   Bjorn> I heard a rumor that ioreadX() on PIO cookies is supposed to
>   Bjorn> have looser semantics than inX() on the port, so we might be
>   Bjorn> able to get away without the memory fence in inb().  But I
>   Bjorn> can't substantiate that, so this keeps the generic behavior
>   Bjorn> of ioreadX() and inX() having identical semantics for PIO.
> Can somebody confirm?  Dropping the mf.a from ioreadX() for I/O port
> accesses would save lots of cycles.

My personal opinion is (but I don't know that everybody will buy into
this) that the _CPU_ serialization of "io_read/io_write()" has to be
independent of whether the argument points to an IO port or memory-mapped

That's simply because I believe that we should encourage implementations
to be able to have a straight-line path in the accessor functions if the
hardware just supports it (ie there should be no need to check the type at
run-time unless the hardware _forces_ that check on you due to the
ioremap() phase not being able to do everything once-and-for-all).

So historically, on x86, an IO port access would be totally synchronous,
in that a outb() will actually _wait_ for the out to hit the bus. Quite
frankly, I don't think most other architectures ever implemented this even
for IO ports, and we should not even _try_ to do so for io_writeX().

HOWEVER. From a _bus_ standpoint, an IO port access is still very 
different from a memory-mapped IO access. In particular, we still have to 
guarantee that IO port accesses never get merged, and that they never get 
re-ordered. If the CPU needs to do those guarantees by hand, then they 
need to be there in the code. But I guess that those are really just the 
same guarantees as for a non-porefetchable MMIO region, so again this 
implies that the _software_ side should be the same for MMIO as for PIO.

And I don't know what "mf.a" means on ia64. Magic hardware.

I assume it's just a "total ordering", and no, I don't think we need it.  
As long as the page tables (or something else in the actual hardware)  
guarantees that reads and writes don't get re-ordered, I think we're fine.

If it's the old "ordering between CPU's" issue, then I think it's back to 
the CPU serialization side, and we should just say "if you use io_write(), 
you get the same CPU serialization for both IO ports and MMIO, and if you 
want inter-CPU ordering, you need to use a spinlock".

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Tue Oct 26 11:22:02 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:32 EST