kernel/arch/mips/include/asm/io.h, branch linux-5.1.y

MIPS: Avoid using .set mips0 to restore ISA

2018-11-09T18:23:19Z

We currently have 2 commonly used methods for switching ISA within assembly code, then restoring the original ISA. 1) Using a pair of .set push & .set pop directives. For example: .set push .set mips32r2 .set pop 2) Using .set mips0 to restore the ISA originally specified on the command line. For example: .set mips32r2 .set mips0 Unfortunately method 2 does not work with nanoMIPS toolchains, where the assembler rejects the .set mips0 directive like so: Error: cannot change ISA from nanoMIPS to mips0 In preparation for supporting nanoMIPS builds, switch all instances of method 2 in generic non-platform-specific code to use push & pop as in method 1 instead. The .set push & .set pop is arguably cleaner anyway, and if nothing else it's good to consistently use one method. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21037/ Cc: linux-mips@linux-mips.org

MIPS: Enable IOREMAP_PROT config option for MIPS cpus

2018-11-05T18:15:28Z

Allows the users of ptrace to access memory mapped by the ptraced process using the same cache coherency attributes as the original process. For example while using gdb with ioremap_prot() incorporated, both gdb and the process being traced will have same cache coherency attributes. Signed-off-by: Hassan Naveed Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20955/ Cc:

MIPS: Provide actually relaxed MMIO accessors

2018-10-09T17:44:29Z

Improve performance for the relevant systems and remove the DMA ordering barrier from `readX_relaxed' and `writeX_relaxed' MMIO accessors, where it is not needed according to our requirements[1]. For consistency make the same arrangement with low-level port I/O accessors, but do not actually provide any accessors making use of it. References: [1] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt, Section "KERNEL I/O BARRIER EFFECTS" Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20865/ Cc: Ralf Baechle

MIPS: Enforce strong ordering for MMIO accessors

2018-10-09T17:43:35Z

Architecturally the MIPS ISA does not specify ordering requirements for uncached bus accesses such as MMIO operations normally use and therefore explicit barriers have to be inserted between MMIO accesses where unspecified ordering of operations would cause unpredictable results. For example the R2020 write buffer implements write gathering and combining[1] and as used with the DECstation models 2100 and 3100 for MMIO accesses it bypasses the read buffer entirely, because conflicts are resolved by the memory controller for DRAM accesses only[2] (NB the R2020 and R3020 buffers are the same except for the maximum clock rate). Consequently if a device has say a 16-bit control register at offset 0, a 16-bit event mask register at offset 2 and a 16-bit reset register at offset 4, and the initial value of the control register is 0x1111, then in the absence of barriers a hypothetical code sequence like this: u16 init_dev(u16 __iomem *dev); u16 x; write16(dev + 2, 0xffff); write16(dev + 0, 0x2222); x = read16(dev + 0); write16(dev + 1, 0x3333); write16(dev + 0, 0x4444); return x; } will return 0x1111 and issue a single 32-bit write of 0x33334444 (in the little-endian bus configuration) to offset 0 on the system bus. This is because the read to set `x' from offset 0 bypasses the write of 0x2222 that is still in the write buffer pending the completion of the write of 0xffff to the reset register. Then the write of 0x3333 to the event mask register is merged with the preceding write to the control register as they share the same word address, making it a 32-bit write of 0x33332222 to offset 0. Finally the write of 0x4444 to the control register is combined with the outstanding 32-bit write of 0x33332222 to offset 0, because, again, it shares the same address. This is an example from a legacy system, given here because it is well documented and affects a machine we actually support. But likewise modern MIPS systems may implement weak MMIO ordering, possibly even without having it clearly documented except for being compliant with the architecture specification with respect to the currently defined SYNC instruction variants[3]. Considering the above and that we are required to implement MMIO accessors such that individual accesses made with them are strongly ordered with respect to each other[4], add the necessary barriers to our `inX', `outX', `readX' and `writeX' handlers, as well the associated special use variants. It's up to platforms then to possibly define the respective barriers so as to expand to nil if no ordering enforcement is actually needed for a given system; SYNC is supposed to be as cheap as a NOP on strongly ordered MIPS implementations though. Retain the option to generate weakly-ordered accessors, so that the arrangement for `war_io_reorder_wmb' is not lost in case we need it for fully raw accessors in the future. The reason for this is that it is unclear from commit 1e820da3c9af ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT") and especially commit 8faca49a6731 ("MIPS: Modify core io.h macros to account for the Octeon Errata Core-301.") why they are needed there under the previous assumption that these accessors can be weakly ordered. References: [1] "LR3020 Write Buffer", LSI Logic Corporation, September 1988, Section "Byte Gathering", pp. 6-7 [2] "DECstation 3100 Desktop Workstation Functional Specification", Digital Equipment Corporation, Revision 1.3, August 28, 1990, Section 6.1 "Processor", p. 4 [3] "MIPS Architecture For Programmers, Volume II-A: The MIPS32 Instruction Set Manual", Imagination Technologies LTD, Document Number: MD00086, Revision 6.06, December 15, 2016, Table 5.5 "Encodings of the Bits[10:6] of the SYNC instruction; the SType Field", p. 409 [4] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt, Section "KERNEL I/O BARRIER EFFECTS" Signed-off-by: Maciej W. Rozycki References: 8faca49a6731 ("MIPS: Modify core io.h macros to account for the Octeon Errata Core-301.") References: 1e820da3c9af ("MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT") Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20864/ Cc: Ralf Baechle

MIPS: Correct `mmiowb' barrier for `wbflush' platforms

2018-10-09T17:42:40Z

Redefine `mmiowb' in terms of `iobarrier_w' so that it works correctly for MIPS I platforms, which have no SYNC machine instruction and use a call to `wbflush' instead. This doesn't change the semantics for CONFIG_CPU_CAVIUM_OCTEON, because `iobarrier_w' expands to `wmb', which is ultimately the same as the current arrangement. For MIPS I platforms this not only makes any code that would happen to use `mmiowb' build and run, but it actually enforces the ordering required as well, as `iobarrier_w' has it already covered with the use of `wmb'. Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20863/ Cc: Ralf Baechle

MIPS: Define MMIO ordering barriers

2018-10-09T17:42:39Z

Define MMIO ordering barriers as separate operations so as to allow making places where such a barrier is required distinct from places where a memory or a DMA barrier is needed. Architecturally MIPS does not specify ordering requirements for uncached bus accesses such as MMIO operations normally use and therefore explicit barriers have to be inserted between MMIO accesses where unspecified ordering of operations would cause unpredictable results. MIPS MMIO ordering barriers are implemented using the same underlying mechanism that memory or a DMA barrier ordering barriers use, that is either a suitable SYNC instruction or a platform-specific `wbflush' call. However platforms may implement different ordering rules for different kinds of bus activity, so having a separate API makes it possible to remove unnecessary barriers and avoid a performance hit they may cause due to unrelated bus activity by making their implementation expand to nil while keeping the necessary ones. Also having distinct barriers for each kind of use makes it easier for the reader to understand what code has been intended to do. Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20862/ Cc: Ralf Baechle

MIPS: Loongson-3: Enable Store Fill Buffer at runtime

2018-09-18T23:21:52Z

New Loongson-3 (Loongson-3A R2, Loongson-3A R3, and newer) has SFB (Store Fill Buffer) which can improve the performance of memory access. Now, SFB enablement is controlled by CONFIG_LOONGSON3_ENHANCEMENT, and the generic kernel has no benefit from SFB (even it is running on a new Loongson-3 machine). With this patch, we can enable SFB at runtime by detecting the CPU type (the expense is war_io_reorder_wmb() will always be a 'sync', which will hurt the performance of old Loongson-3). [paul.burton@mips.com: Further info from Huacai: In practise, I found that sometimes there are boot failures if I enable SFB/LPA in cpu_probe(). I don't know why because processor designers also haven't give me an explaination, but I think this may have some relationships to speculative execution.] Signed-off-by: Huacai Chen Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20426/ Cc: Ralf Baechle Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Huacai Chen

MIPS: Remove SLOW_DOWN_IO

2018-08-30T16:41:17Z

arch/mips appears to have inherited SLOW_DOWN_IO from arch/x86 in antiquity, but we never define CONF_SLOWDOWN_IO so this is unused code. Perhaps it was once useful to keep the MIPS header close to the x86 version to ease comparisons or porting changes, but they've diverged significantly at this point & x86 does this differently now anyway. Delete the dead code. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20343/ Cc: linux-mips@linux-mips.org

MIPS: Use GENERIC_IOMAP

2018-08-30T16:41:16Z

MIPS has a copy of lib/iomap.c with minor alterations, none of which are necessary given appropriate definitions of PIO_OFFSET, PIO_MASK & PIO_RESERVED. Provide such definitions, select GENERIC_IOMAP & remove arch/mips/lib/iomap.c to cut back on the needless duplication. The one change this does make is to our mmio_{in,out}s[bwl] functions, which began to deviate from their generic counterparts with commit 0845bb721ebb ("MIPS: iomap: Use __mem_{read,write}{b,w,l} for MMIO"). I suspect that this commit was incorrect, and that the SEAD-3 platform should have instead selected CONFIG_SWAP_IO_SPACE. Since the SEAD-3 platform code is now gone & the board is instead supported by the generic platform (CONFIG_MIPS_GENERIC) which selects CONFIG_SWAP_IO_SPACE anyway, this shouldn't be a problem any more. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20342/ Cc: linux-mips@linux-mips.org

MIPS: Fix ISA virt/bus conversion for non-zero PHYS_OFFSET

2018-07-30T17:27:28Z

isa_virt_to_bus() & isa_bus_to_virt() claim to treat ISA bus addresses as being identical to physical addresses, but they fail to do so in the presence of a non-zero PHYS_OFFSET. Correct this by having them use virt_to_phys() & phys_to_virt(), which consolidates the calculations to one place & ensures that ISA bus addresses do indeed match physical addresses. Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/20047/ Cc: James Hogan Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: Vladimir Kondratiev