Paul Mackerras <[EMAIL PROTECTED]> wrote: > > +On some systems, I/O writes are not strongly ordered across all CPUs, and > > so +locking should be used, and mmiowb() should be issued prior to > > unlocking the +critical section. > > I think we should say more strongly that mmiowb() is required where > MMIO accesses are done under a spinlock, and that if your driver is > missing them then that is a bug. I don't think it makes sense to say > that mmiowb is required "on some systems".
The point I was trying to make was that on some systems writes are not strongly ordered, so we need mmiowb() on _all_ systems. I'll fix the text to make that point. > There shouldn't be any problem here, because readw/writew _must_ > ensure that the device accesses are serialized. No. That depends on the properties of the memory window readw/writew write through, the properties of the CPU wrt memory accesses, and what explicit barriers at interpolated inside readw/writew themselves. If we're accessing a frame buffer, for instance, we might want it to be able to reorder and combine reads and writes. > Of course, on an SMP system it would be quite possible for the > interrupt to be taken on another CPU, and in that case disabling > interrupts (I assume that by "DISABLE IRQ" you mean > local_irq_disable() or some such) Yes. There are quite a few different ways to disable interrupts. > gets you absolutely nothing; you need to use a spinlock, and then the mmiowb > is required. I believe I've said that, though perhaps not sufficiently clearly. > You may like to include these words describing some of the rules: Thanks, I probably will. David - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
