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
|