On Sun, Jun 27, 2010 at 06:47:14PM +0100, Maciej W. Rozycki wrote: > > AFAIK, wmb in mips is implemented by calling sync, > > For platforms that support this instructions, yes. For platforms that support this instruction _AND_ are not strongly ordered. Iow we try to avoid it, if possible. Details are complicated. > > wmb->fast_wmb->__sync, which makes sure Loads and stores executed > > before the SYNC are completed before loads > > and stores after the SYNC can start > > You shouldn't be relying on implementation details -- WMB is defined as a > write ordering barrier only, so all the interface guarantees is any > outstanding stores will be seen on the processor's bus interface before > any future store starts. This is AFAIR the case with (at least some) > platforms that do not have the SYNC instruction -- where any outstanding > stores can still be delayed until after a future load. > > Actually with the recent introduction of the SYNC_WMB instruction it's > likely it'll get used as the implementation of the WMB interface as soon > as the distribution of the instruction is wide enough across platforms. > As the name implies, this instruction only guarantees an ordering barrier > for stores and not for loads. > > > But will this instruction write the cache back too? > > No, SYNC is only meaningful for uncached (and cached coherent) accesses. > I think that's clear from how the instruction has been specified. > > > take usb example, it will call this maco before it let host processing > > the commands on dram, so I wondering whether sync will write the cache > > back to memory. > > You need to call the appropriate helper -- see the DMA API document for > details. Or use a coherent (in the Linux sense) mapping, which in turn > will make CPU-side memory accesses to this area uncached on non-coherent > (in the MIPS sense) systems. Ralf
