| Message ID | 20230221131658.5381-6-jiaxun.yang@flygoat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 7b76ab837522fd6aa72b25d1c5460995095fedc0 |
| Headers | show |
| Series | MIPS: Loongson64: Clear chaos in barriers | expand |
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h index d727e07ed3f0..9b611770c261 100644 --- a/arch/mips/include/asm/io.h +++ b/arch/mips/include/asm/io.h @@ -210,7 +210,7 @@ void iounmap(const volatile void __iomem *addr); #define ioremap_wc(offset, size) \ ioremap_prot((offset), (size), boot_cpu_data.writecombine) -#if defined(CONFIG_CPU_CAVIUM_OCTEON) || defined(CONFIG_CPU_LOONGSON64) +#if defined(CONFIG_CPU_CAVIUM_OCTEON) #define war_io_reorder_wmb() wmb() #else #define war_io_reorder_wmb() barrier()
It is clearly stated on "Loongson 3A3000/3B3000 processor user manual vol 2" that "All access requests using a non-cached algorithm are executed in a blocking order. That is, before the current read request data is returned to the processor, all subsequent requests are blocked and issued; All subsequent requests are blocked until the write request data has been sent or the issued write request has not received a write reply from the final receiver." Which means uncached read/write is strongly ordered. So we won't need this workaround. This option was introduced when we add initial support for GS464E, it looks like a misinterpretation of another section in the manual saying we need barriers to ensure MMIO order against DMA requests. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> --- arch/mips/include/asm/io.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)