Commit 3d474da ("MIPS: Enforce strong ordering for MMIO accessors")
intruduced this barrier to ensure the correctness of IO access ordering
with following reasons:
1. DECstation systems with hardware write barrier can reorder IO writes.
2. Cavium and Loongson have errata which reorders MMIO.
3. MIPS Spec didn't enforce ordering of MMIO access.
For reason 1, the concern is still valid, so the barrier is kept when
CONFIG_CPU_HAS_WB. For reason 2, we had confirmed that Loongson doesn't
have such errata, Cavium's issue is workarounded by war_io_reorder_wmb.
For reason 3, I had got confirmation from CIP United that all cores
by MTI (MIPS Techonologies) won't do this. Given that other platform had
live without these barriers for a long peroid, removing this barrier
is unlikely to bring any problem.
SYNC based barrier is very heavy on Loongson and MTI cores as it will
issue a SYNC command on their bus and invalidate all present instrutions
in pipeline. We should generally avoid that.
Signed-off-by: Jiaxun Yang <[email protected]>
---
arch/mips/include/asm/io.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 8a148277d9e6..faa38049412f 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -225,7 +225,11 @@ void iounmap(const volatile void __iomem *addr);
#define war_io_reorder_wmb() barrier()
#endif
+#if defined(CONFIG_CPU_HAS_WB)
#define __io_br() mb()
+#else
+#define __io_br() barrier()
+#endif
/* prevent prefetching of coherent DMA data ahead of a dma-complete */
#define __io_ar(v) rmb()
--
2.35.1
On Mon, 21 Feb 2022, Jiaxun Yang wrote:
> Commit 3d474da ("MIPS: Enforce strong ordering for MMIO accessors")
Please follow the canonical commit reference format including a 12-digit
hexadecimal hash reference (`scripts/checkpatch.pl' would have pointed it
out).
> SYNC based barrier is very heavy on Loongson and MTI cores as it will
> issue a SYNC command on their bus and invalidate all present instrutions
> in pipeline. We should generally avoid that.
Use whatever lighterweight barrier instruction you have available for
your specific platforms then that fulfills the ordering enforcement
required here for your specific platforms of concern that you have
identified and know well rather than across the board. The reason for
this is this is an optimisation and the default barrier model needs to
ensure correct execution with any implementation.
Maciej