On Wed, 21 Feb 2007, Ralf Baechle wrote: > > should guarantee "val" has reached the register (mmiowb() replacing > > incorrect mb() used in many places like this), but with either definition > > of mmiowb() and a MIPS-I-style external write-back buffer it will not > > work. > > Does a read from the same device suffice to provide the necessary flushing > the same way as it does on PCI? No. Neither the R2020 nor the R3220 write-back buffer chips (used for the R2000 and R3000, respectively) as used in DECstation systems support snooping for MMIO, so reads from that space will bypass writes pending in the buffer, even for the very same address. There is some logic in the memory controller to resolve such conflicts, but it is activated for main RAM accesses only. Once the write-back buffer has been drained there is no need for a read-back though. The CP0 condition can be used to check whether there are any pending writes in the buffer (it is false if there are). OTOH, DECstation systems that do not use either of the write-back buffers mentioned above do require a "sync" (if using the R4000 or R4400 CPU) followed by a read-back (any uncached address does) to drain the write-back buffer in the MB (memory buffer) ASIC. > I'm not opposed to allowing platform specific definitions for operations > like mmiowbb() but I think we really should get rid of the special MIPS > iob() operation. Certainly, but before that happens there has to be a way to be able to specify the desired barrier in a generic driver like defxx.c without the need to know the underlying platform. Maciej
