On Wed, 30 Jan 2002, Maciej W. Rozycki wrote: > worse, recently I've identified a case it doesn't work at all on an > R4400SC CPU -- values written to an i/o memory resource were not committed > to the device even after executing over 40 subsequent instructions. Nice patch! I was under the impression that the mb() functions existed to maintain order of memory access and were not defined as flushes per say - so is the time delay a concern (perhaps sticking a sync before ERET is appropriate?) I spent some time talking with the Sandcraft people about memory barrier issues, and it turns out that at least on the SR71000 (and in most cases the RM7K) the order of SysAD transactions will always match the order of the instruction stream, but all writes are posted and all reads are split - that is the CPU can execute two back to back uncached loads and several back to back uncached stores without stalling the pipeline, or getting the IO's out of order. Adding sync's and uncached loads only slows things down for these chips. I understand this is because the CPUs have a single load/store unit and do not do out of order execution. Many older/embedded MIPS designs probably have a similar configuration, they could likely also run with out the syncs. So - could you add something like CONFIG_IN_ORDER_IO which would nullify the syncs for these processors? BTW, does anyone know what CONFIG_WB is ment to mean? The CPU has a write buffer that does not preserve order? Thanks, Jason
