kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/arch/arm/include/asm/io.h

429 lines
14 KiB
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04 10:11:33 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ARM] move include/asm-arm to arch/arm/include/asm Move platform independent header files to arch/arm/include/asm, leaving those in asm/arch* and asm/plat* alone. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-02 10:55:55 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() If we are building for a LE platform, and we haven't overriden the MMIO ops, then we can optimize the mem*io operations using the standard string functions. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-05-07 14:22:40 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: mm: Make virt_to_pfn() a static inline Making virt_to_pfn() a static inline taking a strongly typed (const void *) makes the contract of a passing a pointer of that type to the function explicit and exposes any misuse of the macro virt_to_pfn() acting polymorphic and accepting many types such as (void *), (unitptr_t) or (unsigned long) as arguments without warnings. Doing this is a bit intrusive: virt_to_pfn() requires PHYS_PFN_OFFSET and PAGE_SHIFT to be defined, and this is defined in <asm/page.h>, so this must be included *before* <asm/memory.h>. The use of macros were obscuring the unclear inclusion order here, as the macros would eventually be resolved, but a static inline like this cannot be compiled with unresolved macros. The naive solution to include <asm/page.h> at the top of <asm/memory.h> does not work, because <asm/memory.h> sometimes includes <asm/page.h> at the end of itself, which would create a confusing inclusion loop. So instead, take the approach to always unconditionally include <asm/page.h> at the end of <asm/memory.h> arch/arm uses <asm/memory.h> explicitly in a lot of places, however it turns out that if we just unconditionally include <asm/memory.h> into <asm/page.h> and switch all inclusions of <asm/memory.h> to <asm/page.h> instead, we enforce the right order and <asm/memory.h> will always have access to the definitions. Put an inclusion guard in place making it impossible to include <asm/memory.h> explicitly. Link: https://lore.kernel.org/linux-mm/20220701160004.2ffff4e5ab59a55499f4c736@linux-foundation.org/ Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-06-02 10:18:32 +02:00
arm: switch to GENERIC_PCI_IOMAP arm copied pci_iomap from generic code, probably to avoid pulling the rest of iomap.c in. Since that's in a separate file now, we can reuse the common implementation. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2011-11-24 20:57:23 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: 7930/1: Introduce atomic MMIO modify Some SoC have MMIO regions that are shared across orthogonal subsystems. This commit implements a possible solution for the thread-safe access of such regions through a spinlock-protected API. Concurrent access is protected with a single spinlock for the entire MMIO address space. While this protects shared-registers, it also serializes access to unrelated/unshared registers. We add relaxed and non-relaxed variants, by using writel_relaxed and writel, respectively. The rationale for this is that some users may not require register write completion but only thread-safe access to a register. Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-12-18 23:08:52 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: 8341/1: io: Unpessimize relaxed io accessors commit 195bbcac2e5c12f7fb ("ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors") disables writeback addressing modes for raw i/o. However, the "+Q" output constraint forces the compiler to disable load hoist optimizations (because the output constraint informs the compiler of memory stores which the compiler assumes may alias other memory). Since the relaxed accessors only guarantee ordering wrt i/o accesses to the same device and not to main memory, there's never a possibility of an accessor invalidating a hoisted load (because only non-i/o loads would have been hoisted). The effect is especially noticable with complex address inputs in loops. For example, the following code: #include <linux/kernel.h> #include <linux/io.h> static const int *remap; void wr_loop(void __iomem *base, int c, int val) { int i; for (i = 0; i < c; i++) writew_relaxed(val, base + remap[c >> 2]); } generates current master | this patch 0: e3510000 cmp r1, #0 | 0: e3510000 cmp r1, #0 4: d12fff1e bxle lr | 4: d12fff1e bxle lr 8: e3003000 movw r3, #0 | 8: e3c1c003 bic ip, r1, #3 c: e3403000 movt r3, #0 | c: e6ff2072 uxth r2, r2 10: e92d4010 push {r4, lr} | 10: e3a03000 mov r3, #0 14: e6ff2072 uxth r2, r2 | 14: e59cc000 ldr ip, [ip] 18: e3c14003 bic r4, r1, #3 | 18: e080000c add r0, r0, ip 1c: e593e000 ldr lr, [r3] | 20: e3a03000 mov r3, #0 | 1c: e1c020b0 strh r2, [r0] | 20: e2833001 add r3, r3, #1 24: e79ec004 ldr ip, [lr, r4] | 24: e1530001 cmp r3, r1 28: e080c00c add ip, r0, ip | 28: 1afffffb bne 1c 2c: e1cc20b0 strh r2, [ip] | 2c: e12fff1e bx lr 30: e2833001 add r3, r3, #1 | 34: e1530001 cmp r3, r1 | 38: 1afffff9 bne 24 | | 3c: e8bd8010 pop {r4, pc} | Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-13 14:18:50 +01:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: 8341/1: io: Unpessimize relaxed io accessors commit 195bbcac2e5c12f7fb ("ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors") disables writeback addressing modes for raw i/o. However, the "+Q" output constraint forces the compiler to disable load hoist optimizations (because the output constraint informs the compiler of memory stores which the compiler assumes may alias other memory). Since the relaxed accessors only guarantee ordering wrt i/o accesses to the same device and not to main memory, there's never a possibility of an accessor invalidating a hoisted load (because only non-i/o loads would have been hoisted). The effect is especially noticable with complex address inputs in loops. For example, the following code: #include <linux/kernel.h> #include <linux/io.h> static const int *remap; void wr_loop(void __iomem *base, int c, int val) { int i; for (i = 0; i < c; i++) writew_relaxed(val, base + remap[c >> 2]); } generates current master | this patch 0: e3510000 cmp r1, #0 | 0: e3510000 cmp r1, #0 4: d12fff1e bxle lr | 4: d12fff1e bxle lr 8: e3003000 movw r3, #0 | 8: e3c1c003 bic ip, r1, #3 c: e3403000 movt r3, #0 | c: e6ff2072 uxth r2, r2 10: e92d4010 push {r4, lr} | 10: e3a03000 mov r3, #0 14: e6ff2072 uxth r2, r2 | 14: e59cc000 ldr ip, [ip] 18: e3c14003 bic r4, r1, #3 | 18: e080000c add r0, r0, ip 1c: e593e000 ldr lr, [r3] | 20: e3a03000 mov r3, #0 | 1c: e1c020b0 strh r2, [r0] | 20: e2833001 add r3, r3, #1 24: e79ec004 ldr ip, [lr, r4] | 24: e1530001 cmp r3, r1 28: e080c00c add ip, r0, ip | 28: 1afffffb bne 1c 2c: e1cc20b0 strh r2, [ip] | 2c: e12fff1e bx lr 30: e2833001 add r3, r3, #1 | 34: e1530001 cmp r3, r1 | 38: 1afffff9 bne 24 | | 3c: e8bd8010 pop {r4, pc} | Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-13 14:18:50 +01:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: 8341/1: io: Unpessimize relaxed io accessors commit 195bbcac2e5c12f7fb ("ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors") disables writeback addressing modes for raw i/o. However, the "+Q" output constraint forces the compiler to disable load hoist optimizations (because the output constraint informs the compiler of memory stores which the compiler assumes may alias other memory). Since the relaxed accessors only guarantee ordering wrt i/o accesses to the same device and not to main memory, there's never a possibility of an accessor invalidating a hoisted load (because only non-i/o loads would have been hoisted). The effect is especially noticable with complex address inputs in loops. For example, the following code: #include <linux/kernel.h> #include <linux/io.h> static const int *remap; void wr_loop(void __iomem *base, int c, int val) { int i; for (i = 0; i < c; i++) writew_relaxed(val, base + remap[c >> 2]); } generates current master | this patch 0: e3510000 cmp r1, #0 | 0: e3510000 cmp r1, #0 4: d12fff1e bxle lr | 4: d12fff1e bxle lr 8: e3003000 movw r3, #0 | 8: e3c1c003 bic ip, r1, #3 c: e3403000 movt r3, #0 | c: e6ff2072 uxth r2, r2 10: e92d4010 push {r4, lr} | 10: e3a03000 mov r3, #0 14: e6ff2072 uxth r2, r2 | 14: e59cc000 ldr ip, [ip] 18: e3c14003 bic r4, r1, #3 | 18: e080000c add r0, r0, ip 1c: e593e000 ldr lr, [r3] | 20: e3a03000 mov r3, #0 | 1c: e1c020b0 strh r2, [r0] | 20: e2833001 add r3, r3, #1 24: e79ec004 ldr ip, [lr, r4] | 24: e1530001 cmp r3, r1 28: e080c00c add ip, r0, ip | 28: 1afffffb bne 1c 2c: e1cc20b0 strh r2, [ip] | 2c: e12fff1e bx lr 30: e2833001 add r3, r3, #1 | 34: e1530001 cmp r3, r1 | 38: 1afffff9 bne 24 | | 3c: e8bd8010 pop {r4, pc} | Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-13 14:18:50 +01:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: 8341/1: io: Unpessimize relaxed io accessors commit 195bbcac2e5c12f7fb ("ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors") disables writeback addressing modes for raw i/o. However, the "+Q" output constraint forces the compiler to disable load hoist optimizations (because the output constraint informs the compiler of memory stores which the compiler assumes may alias other memory). Since the relaxed accessors only guarantee ordering wrt i/o accesses to the same device and not to main memory, there's never a possibility of an accessor invalidating a hoisted load (because only non-i/o loads would have been hoisted). The effect is especially noticable with complex address inputs in loops. For example, the following code: #include <linux/kernel.h> #include <linux/io.h> static const int *remap; void wr_loop(void __iomem *base, int c, int val) { int i; for (i = 0; i < c; i++) writew_relaxed(val, base + remap[c >> 2]); } generates current master | this patch 0: e3510000 cmp r1, #0 | 0: e3510000 cmp r1, #0 4: d12fff1e bxle lr | 4: d12fff1e bxle lr 8: e3003000 movw r3, #0 | 8: e3c1c003 bic ip, r1, #3 c: e3403000 movt r3, #0 | c: e6ff2072 uxth r2, r2 10: e92d4010 push {r4, lr} | 10: e3a03000 mov r3, #0 14: e6ff2072 uxth r2, r2 | 14: e59cc000 ldr ip, [ip] 18: e3c14003 bic r4, r1, #3 | 18: e080000c add r0, r0, ip 1c: e593e000 ldr lr, [r3] | 20: e3a03000 mov r3, #0 | 1c: e1c020b0 strh r2, [r0] | 20: e2833001 add r3, r3, #1 24: e79ec004 ldr ip, [lr, r4] | 24: e1530001 cmp r3, r1 28: e080c00c add ip, r0, ip | 28: 1afffffb bne 1c 2c: e1cc20b0 strh r2, [ip] | 2c: e12fff1e bx lr 30: e2833001 add r3, r3, #1 | 34: e1530001 cmp r3, r1 | 38: 1afffff9 bne 24 | | 3c: e8bd8010 pop {r4, pc} | Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-13 14:18:50 +01:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: 8341/1: io: Unpessimize relaxed io accessors commit 195bbcac2e5c12f7fb ("ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors") disables writeback addressing modes for raw i/o. However, the "+Q" output constraint forces the compiler to disable load hoist optimizations (because the output constraint informs the compiler of memory stores which the compiler assumes may alias other memory). Since the relaxed accessors only guarantee ordering wrt i/o accesses to the same device and not to main memory, there's never a possibility of an accessor invalidating a hoisted load (because only non-i/o loads would have been hoisted). The effect is especially noticable with complex address inputs in loops. For example, the following code: #include <linux/kernel.h> #include <linux/io.h> static const int *remap; void wr_loop(void __iomem *base, int c, int val) { int i; for (i = 0; i < c; i++) writew_relaxed(val, base + remap[c >> 2]); } generates current master | this patch 0: e3510000 cmp r1, #0 | 0: e3510000 cmp r1, #0 4: d12fff1e bxle lr | 4: d12fff1e bxle lr 8: e3003000 movw r3, #0 | 8: e3c1c003 bic ip, r1, #3 c: e3403000 movt r3, #0 | c: e6ff2072 uxth r2, r2 10: e92d4010 push {r4, lr} | 10: e3a03000 mov r3, #0 14: e6ff2072 uxth r2, r2 | 14: e59cc000 ldr ip, [ip] 18: e3c14003 bic r4, r1, #3 | 18: e080000c add r0, r0, ip 1c: e593e000 ldr lr, [r3] | 20: e3a03000 mov r3, #0 | 1c: e1c020b0 strh r2, [r0] | 20: e2833001 add r3, r3, #1 24: e79ec004 ldr ip, [lr, r4] | 24: e1530001 cmp r3, r1 28: e080c00c add ip, r0, ip | 28: 1afffffb bne 1c 2c: e1cc20b0 strh r2, [ip] | 2c: e12fff1e bx lr 30: e2833001 add r3, r3, #1 | 34: e1530001 cmp r3, r1 | 38: 1afffff9 bne 24 | | 3c: e8bd8010 pop {r4, pc} | Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-13 14:18:50 +01:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
ARM: 8341/1: io: Unpessimize relaxed io accessors commit 195bbcac2e5c12f7fb ("ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors") disables writeback addressing modes for raw i/o. However, the "+Q" output constraint forces the compiler to disable load hoist optimizations (because the output constraint informs the compiler of memory stores which the compiler assumes may alias other memory). Since the relaxed accessors only guarantee ordering wrt i/o accesses to the same device and not to main memory, there's never a possibility of an accessor invalidating a hoisted load (because only non-i/o loads would have been hoisted). The effect is especially noticable with complex address inputs in loops. For example, the following code: #include <linux/kernel.h> #include <linux/io.h> static const int *remap; void wr_loop(void __iomem *base, int c, int val) { int i; for (i = 0; i < c; i++) writew_relaxed(val, base + remap[c >> 2]); } generates current master | this patch 0: e3510000 cmp r1, #0 | 0: e3510000 cmp r1, #0 4: d12fff1e bxle lr | 4: d12fff1e bxle lr 8: e3003000 movw r3, #0 | 8: e3c1c003 bic ip, r1, #3 c: e3403000 movt r3, #0 | c: e6ff2072 uxth r2, r2 10: e92d4010 push {r4, lr} | 10: e3a03000 mov r3, #0 14: e6ff2072 uxth r2, r2 | 14: e59cc000 ldr ip, [ip] 18: e3c14003 bic r4, r1, #3 | 18: e080000c add r0, r0, ip 1c: e593e000 ldr lr, [r3] | 20: e3a03000 mov r3, #0 | 1c: e1c020b0 strh r2, [r0] | 20: e2833001 add r3, r3, #1 24: e79ec004 ldr ip, [lr, r4] | 24: e1530001 cmp r3, r1 28: e080c00c add ip, r0, ip | 28: 1afffffb bne 1c 2c: e1cc20b0 strh r2, [ip] | 2c: e12fff1e bx lr 30: e2833001 add r3, r3, #1 | 34: e1530001 cmp r3, r1 | 38: 1afffff9 bne 24 | | 3c: e8bd8010 pop {r4, pc} | Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-04-13 14:18:50 +01:00
ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors Data aborts taken to hyp mode do not provide a valid instruction syndrome field in the HSR if the faulting instruction is a memory access using a writeback addressing mode. For hypervisors emulating MMIO accesses to virtual peripherals, taking such an exception requires disassembling the faulting instruction in order to determine the behaviour of the access. Since this requires manually walking the two stages of translation, the world must be stopped to prevent races against page aging in the guest, where the first-stage translation is invalidated after the hypervisor has translated to an IPA and the physical page is reused for something else. This patch avoids taking this heavy performance penalty when running Linux as a guest by ensuring that our I/O accessors do not make use of writeback addressing modes. Cc: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-08-24 15:18:45 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ARM] __ioremap doesn't use 4th argument The "align" argument in ARMs __ioremap is unused and provides a misleading expectation that it might do something. It doesn't. Remove it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-11-17 16:48:00 +00:00
[ARM] mm 10: allow memory type to be specified with ioremap __ioremap() took a set of page table flags (specifically the cacheable and bufferable bits) to control the mapping type. However, with the advent of ARMv6, this is far too limited. Replace the page table flags with a memory type index, so that the desired attributes can be selected from the mem_type table. Finally, to prevent silent miscompilation due to the differing arguments, rename the __ioremap() and __ioremap_pfn() functions. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-05 20:59:27 +01:00
[ARM] Remove MT_DEVICE_IXP2000 and associated definitions As of the previous commit, MT_DEVICE_IXP2000 encodes to the same PTE bit encoding as MT_DEVICE, so it's now redundant. Convert MT_DEVICE_IXP2000 to use MT_DEVICE instead, and remove its aliases. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-07 12:42:51 +01:00
[ARM] mm 10: allow memory type to be specified with ioremap __ioremap() took a set of page table flags (specifically the cacheable and bufferable bits) to control the mapping type. However, with the advent of ARMv6, this is far too limited. Replace the page table flags with a memory type index, so that the desired attributes can be selected from the mem_type table. Finally, to prevent silent miscompilation due to the differing arguments, rename the __ioremap() and __ioremap_pfn() functions. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-05 20:59:27 +01:00
[ARM] Remove MT_DEVICE_IXP2000 and associated definitions As of the previous commit, MT_DEVICE_IXP2000 encodes to the same PTE bit encoding as MT_DEVICE, so it's now redundant. Convert MT_DEVICE_IXP2000 to use MT_DEVICE instead, and remove its aliases. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-09-07 12:42:51 +01:00
[ARM] mm 10: allow memory type to be specified with ioremap __ioremap() took a set of page table flags (specifically the cacheable and bufferable bits) to control the mapping type. However, with the advent of ARMv6, this is far too limited. Replace the page table flags with a memory type index, so that the desired attributes can be selected from the mem_type table. Finally, to prevent silent miscompilation due to the differing arguments, rename the __ioremap() and __ioremap_pfn() functions. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-05 20:59:27 +01:00
ARM: Add caller information to ioremap This allows the procfs vmallocinfo file to show who created the ioremap regions. Note: __builtin_return_address(0) doesn't do what's expected if its used in an inline function, so we leave __arm_ioremap callers in such places alone. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-12-18 11:10:03 +00:00
[ARM] mm 10: allow memory type to be specified with ioremap __ioremap() took a set of page table flags (specifically the cacheable and bufferable bits) to control the mapping type. However, with the advent of ARMv6, this is far too limited. Replace the page table flags with a memory type index, so that the desired attributes can be selected from the mem_type table. Finally, to prevent silent miscompilation due to the differing arguments, rename the __ioremap() and __ioremap_pfn() functions. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-05 20:59:27 +01:00
ARM: 7728/1: mm: Use phys_addr_t properly for ioremap functions Several of the ioremap functions use unsigned long in places resulting in truncation if physical addresses greater than 4G are passed in. Change the types of the functions and the callers accordingly. Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-05-16 19:40:22 +01:00
ARM: Add caller information to ioremap This allows the procfs vmallocinfo file to show who created the ioremap regions. Note: __builtin_return_address(0) doesn't do what's expected if its used in an inline function, so we leave __arm_ioremap callers in such places alone. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-12-18 11:10:03 +00:00
ARM: 7728/1: mm: Use phys_addr_t properly for ioremap functions Several of the ioremap functions use unsigned long in places resulting in truncation if physical addresses greater than 4G are passed in. Change the types of the functions and the callers accordingly. Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-05-16 19:40:22 +01:00
ARM: add __arm_iomem_set_ro() to write-protect ioremapped area __arm_iomem_set_ro() marks an ioremapped area read-only. This is intended for use with __arm_ioremap_exec() to allow the kernel to write some code into e.g. SRAM and then write-protect it so the kernel doesn't complain about W+X mappings. Tested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-09-21 12:57:22 +01:00
ARM: provide runtime hook for ioremap/iounmap We have compile time over-ride of ioremap and iounmap, but an run-time override is needed for multi-platform builds. This adds an extra function pointer check, but ioremap is not peformance critical. The option for compile time selection remains. The caller variant is used here to provide correct caller information as ARM can only support level 0 for __builtin_return_address. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org>
2012-02-10 17:05:13 -06:00
ARM: 7728/1: mm: Use phys_addr_t properly for ioremap functions Several of the ioremap functions use unsigned long in places resulting in truncation if physical addresses greater than 4G are passed in. Change the types of the functions and the callers accordingly. Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Laura Abbott <lauraa@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-05-16 19:40:22 +01:00
ARM: provide runtime hook for ioremap/iounmap We have compile time over-ride of ioremap and iounmap, but an run-time override is needed for multi-platform builds. This adds an extra function pointer check, but ioremap is not peformance critical. The option for compile time selection remains. The caller variant is used here to provide correct caller information as ARM can only support level 0 for __builtin_return_address. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nicolas Pitre <nico@linaro.org>
2012-02-10 17:05:13 -06:00
[ARM] __ioremap doesn't use 4th argument The "align" argument in ARMs __ioremap is unused and provides a misleading expectation that it might do something. It doesn't. Remove it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-11-17 16:48:00 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ARM] Add a common typesafe __io implementation As Al did for Versatile in 2ad4f86b60b649fd7428265c08d73a3bd360c81b, add a typesafe __io implementation for platforms to use. Convert platforms to use this new simple typesafe implementation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-11-30 11:45:54 +00:00
ARM: create a common IOMEM definition Several platforms create IOMEM defines for casting to 'void __iomem *', and other platforms are incorrectly using __io() macro for the same purpose. This creates a common definition and removes all the platform specific versions. Rather than try to make linux/io.h and asm/io.h assembly safe, the assembly version of IOMEM is moved into asm/assembler.h. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@ti.com> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Ryan Mallon <rmallon@gmail.com> Cc: Eric Miao <eric.y.miao@gmail.com> Cc: Haojian Zhuang <haojian.zhuang@marvell.com> Acked-by: David Brown <davidb@codeaurora.org> Cc: Daniel Walker <dwalker@fifo99.com> Cc: Bryan Huntsman <bryanh@codeaurora.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Paul Walmsley <paul@pwsan.com> Acked-by: Viresh Kumar <viresh.kumar@st.com> Cc: Rajeev Kumar <rajeev-dlh.kumar@st.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de>
2012-03-10 10:30:31 -06:00
ARM: io: ensure inb/outb() et.al. are properly ordered on ARMv6+ Ensure that the ISA/PCI IO space accessors are properly ordered on ARMv6+ architectures. These should always be ordered with respect to all other accesses. This also fixes __iormb() and __iowmb() not being visible to ioread/ iowrite if a platform defines its own MMIO accessors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-01-30 11:29:40 +00:00
Disintegrate asm/system.h for ARM Disintegrate asm/system.h for ARM. Signed-off-by: David Howells <dhowells@redhat.com> cc: Russell King <linux@arm.linux.org.uk> cc: linux-arm-kernel@lists.infradead.org
2012-03-28 18:30:01 +01:00
ARM: io: ensure inb/outb() et.al. are properly ordered on ARMv6+ Ensure that the ISA/PCI IO space accessors are properly ordered on ARMv6+ architectures. These should always be ordered with respect to all other accesses. This also fixes __iormb() and __iowmb() not being visible to ioread/ iowrite if a platform defines its own MMIO accessors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-01-30 11:29:40 +00:00
ARM: Add fixed PCI i/o mapping This adds a fixed virtual mapping for PCI i/o addresses. The mapping is located at the last 2MB of vmalloc region (0xfee00000-0xff000000). 2MB is used to align with PMD size, but IO_SPACE_LIMIT is 1MB. The space is reserved after .map_io and can be mapped at any time later with pci_ioremap_io. Platforms which need early i/o mapping (e.g. for vga console) can call pci_map_io_early in their .map_io function. This has changed completely from the 1st implementation which only supported creating the static mapping at .map_io. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Nicolas Pitre <nico@linaro.org>
2012-02-29 18:10:58 -06:00
ARM: Define PCI_IOBASE as the base of virtual PCI IO space This is needed for calls into OF code that parses PCI ranges. It signals support for memory mapped PCI I/O accesses that are described by device trees. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> CC: Russell King <linux@arm.linux.org.uk> CC: Rob Herring <robh+dt@kernel.org>
2014-09-29 15:29:22 +01:00
ARM: Add fixed PCI i/o mapping This adds a fixed virtual mapping for PCI i/o addresses. The mapping is located at the last 2MB of vmalloc region (0xfee00000-0xff000000). 2MB is used to align with PMD size, but IO_SPACE_LIMIT is 1MB. The space is reserved after .map_io and can be mapped at any time later with pci_ioremap_io. Platforms which need early i/o mapping (e.g. for vga console) can call pci_map_io_early in their .map_io function. This has changed completely from the 1st implementation which only supported creating the static mapping at .map_io. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Nicolas Pitre <nico@linaro.org>
2012-02-29 18:10:58 -06:00
ARM: pxa/sa1100: move I/O space to PCI_IOBASE PXA and StrongARM1100 traditionally map their I/O space 1:1 into virtual memory, using a per-bus io_offset that matches the base address of the ioremap mapping. In order for PXA to work in a multiplatform config, this needs to change so I/O space starts at PCI_IOBASE (0xfee00000). Since the pcmcia soc_common support is shared with StrongARM1100, both have to change at the same time. The affected machines are: - Anything with a PCMCIA slot now uses pci_remap_iospace, which is made available to PCMCIA configurations as well, rather than just PCI. The first PCMCIA slot now starts at port number 0x10000. - The Zeus and Viper platforms have PC/104-style ISA buses, which have a static mapping for both I/O and memory space at 0xf1000000, which can no longer work. It does not appear to have any in-tree users, so moving it to port number 0 makes them behave like a traditional PC. - SA1100 does support ISA slots in theory, but all machines that originally enabled this appear to have been removed from the tree ages ago, and the I/O space is never mapped anywhere. - The Nanoengine machine has support for PCI slots, but looks like this never included I/O space, the resources only define the location for memory and config space. With this, the definitions of __io() and IO_SPACE_LIMIT can be simplified, as the only remaining cases are the generic PCI_IOBASE and the custom inb()/outb() macros on RiscPC. S3C24xx still has a custom inb()/outb() in this here, but this is already removed in another branch. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-24 14:36:35 +02:00
ARM: 8060/1: mm: allow sub-architectures to override PCI I/O memory type Due to a design incompatibility between the PCIe Marvell controller and the Cortex-A9, stressing PCIe devices with a lot of traffic quickly causes a deadlock. One part of the workaround for this is to have all PCIe regions mapped as strongly-ordered (MT_UNCACHED) instead of the default MT_DEVICE. While the arch_ioremap_caller() mechanism allows sub-architecture code to override ioremap(), used to map PCIe memory regions, there isn't such a mechanism to override the behavior of pci_ioremap_io(). This commit adds the arch_pci_ioremap_mem_type variable, initialized to MT_DEVICE by default, and that sub-architecture code can override. We have chosen to expose a single variable rather than offering the possibility of overriding the entire pci_ioremap_io(), because implementing pci_ioremap_io() requires calling functions (get_mem_type()) that are private to the arch/arm/mm/ code. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2014-05-19 11:04:39 +01:00
arm: ioremap: Implement standard PCI function pci_remap_iospace() pci_remap_iospace() is standard PCI core function. Architecture code can reimplement default core implementation if needs custom arch specific functionality. ARM needs custom implementation due to pci_ioremap_set_mem_type() hook which allows ARM platforms to change mem type for iospace. Implement this pci_remap_iospace() function for ARM architecture to correctly handle pci_ioremap_set_mem_type() hook, which allows usage of this standard PCI core function also for platforms which needs different mem type (e.g. Marvell Armada 375, 38x and 39x). Link: https://lore.kernel.org/r/20211124154116.916-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-11-24 16:41:12 +01:00
ARM: Implement pci_remap_cfgspace() interface The PCI bus specification (rev 3.0, 3.2.5 "Transaction Ordering and Posting") defines rules for PCI configuration space transactions ordering and posting, that state that configuration writes have to be non-posted transactions. Current ioremap interface on ARM provides mapping functions that provide "bufferable" writes transactions (ie ioremap uses MT_DEVICE memory type) aka posted writes, so PCI host controller drivers have no arch interface to remap PCI configuration space with memory attributes that comply with the PCI specifications for configuration space. Implement an ARM specific pci_remap_cfgspace() interface that allows to map PCI config memory regions with MT_UNCACHED memory type (ie strongly ordered - non-posted writes), providing a remap function that complies with PCI specifications for config space transactions. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@armlinux.org.uk>
2017-04-19 17:48:53 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: make mach/io.h include optional Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h. Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does. Most PCI platforms need mach/io.h for now, but ks8695 doesn't which means i/o accesses are broken. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2012-03-04 22:03:33 -06:00
[ARM] Move include/asm-arm/arch-* to arch/arm/*/include/mach This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-05 16:14:15 +01:00
ARM: make mach/io.h include optional Add a kconfig option NEED_MACH_IO_H to conditionally include mach/io.h. Basing this on CONFIG_PCI and CONFIG_ISA doesn't quite work. Most ISA platforms don't need mach/io.h, but ebsa110 does. Most PCI platforms need mach/io.h for now, but ks8695 doesn't which means i/o accesses are broken. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by: Nicolas Pitre <nico@linaro.org>
2012-03-04 22:03:33 -06:00
ARM: pxa/sa1100: move I/O space to PCI_IOBASE PXA and StrongARM1100 traditionally map their I/O space 1:1 into virtual memory, using a per-bus io_offset that matches the base address of the ioremap mapping. In order for PXA to work in a multiplatform config, this needs to change so I/O space starts at PCI_IOBASE (0xfee00000). Since the pcmcia soc_common support is shared with StrongARM1100, both have to change at the same time. The affected machines are: - Anything with a PCMCIA slot now uses pci_remap_iospace, which is made available to PCMCIA configurations as well, rather than just PCI. The first PCMCIA slot now starts at port number 0x10000. - The Zeus and Viper platforms have PC/104-style ISA buses, which have a static mapping for both I/O and memory space at 0xf1000000, which can no longer work. It does not appear to have any in-tree users, so moving it to port number 0 makes them behave like a traditional PC. - SA1100 does support ISA slots in theory, but all machines that originally enabled this appear to have been removed from the tree ages ago, and the I/O space is never mapped anywhere. - The Nanoengine machine has support for PCI slots, but looks like this never included I/O space, the resources only define the location for memory and config space. With this, the definitions of __io() and IO_SPACE_LIMIT can be simplified, as the only remaining cases are the generic PCI_IOBASE and the custom inb()/outb() macros on RiscPC. S3C24xx still has a custom inb()/outb() in this here, but this is already removed in another branch. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-24 14:36:35 +02:00
ARM: io: add a default IO_SPACE_LIMIT definition Add a default IO_SPACE_LIMIT definition. Explain the chosen value and suggest why platforms would want to make it larger. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-06 12:49:59 +01:00
ARM: pxa/sa1100: move I/O space to PCI_IOBASE PXA and StrongARM1100 traditionally map their I/O space 1:1 into virtual memory, using a per-bus io_offset that matches the base address of the ioremap mapping. In order for PXA to work in a multiplatform config, this needs to change so I/O space starts at PCI_IOBASE (0xfee00000). Since the pcmcia soc_common support is shared with StrongARM1100, both have to change at the same time. The affected machines are: - Anything with a PCMCIA slot now uses pci_remap_iospace, which is made available to PCMCIA configurations as well, rather than just PCI. The first PCMCIA slot now starts at port number 0x10000. - The Zeus and Viper platforms have PC/104-style ISA buses, which have a static mapping for both I/O and memory space at 0xf1000000, which can no longer work. It does not appear to have any in-tree users, so moving it to port number 0 makes them behave like a traditional PC. - SA1100 does support ISA slots in theory, but all machines that originally enabled this appear to have been removed from the tree ages ago, and the I/O space is never mapped anywhere. - The Nanoengine machine has support for PCI slots, but looks like this never included I/O space, the resources only define the location for memory and config space. With this, the definitions of __io() and IO_SPACE_LIMIT can be simplified, as the only remaining cases are the generic PCI_IOBASE and the custom inb()/outb() macros on RiscPC. S3C24xx still has a custom inb()/outb() in this here, but this is already removed in another branch. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-24 14:36:35 +02:00
ARM: io: add a default IO_SPACE_LIMIT definition Add a default IO_SPACE_LIMIT definition. Explain the chosen value and suggest why platforms would want to make it larger. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-06 12:49:59 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[PATCH] ARM: Fix speeling eroor in io.h Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-27 14:23:38 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: io: ensure inb/outb() et.al. are properly ordered on ARMv6+ Ensure that the ISA/PCI IO space accessors are properly ordered on ARMv6+ architectures. These should always be ordered with respect to all other accesses. This also fixes __iormb() and __iowmb() not being visible to ioread/ iowrite if a platform defines its own MMIO accessors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-01-30 11:29:40 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: io: ensure inb/outb() et.al. are properly ordered on ARMv6+ Ensure that the ISA/PCI IO space accessors are properly ordered on ARMv6+ architectures. These should always be ordered with respect to all other accesses. This also fixes __iormb() and __iowmb() not being visible to ioread/ iowrite if a platform defines its own MMIO accessors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-01-30 11:29:40 +00:00
[PATCH] ARM: 2649/1: Fix 'sparse -Wbitwise' warnings from MMIO macros Patch from Olav Kongas On ARM, the outX() and writeX() families of macros take the result of cpu_to_leYY(), which is of restricted type __leYY, and feed it to __raw_writeX(), which expect an argument of unrestricted type. This results in 'sparse -Wbitwise' warnings about incorrect types in assignments. Analogous type mismatch warnings are issued for inX() and readX() counterparts. The below patch resolves these warnings by adding forced typecasts. Signed-off-by: Olav Kongas Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29 22:08:34 +01:00
ARM: io: ensure inb/outb() et.al. are properly ordered on ARMv6+ Ensure that the ISA/PCI IO space accessors are properly ordered on ARMv6+ architectures. These should always be ordered with respect to all other accesses. This also fixes __iormb() and __iowmb() not being visible to ioread/ iowrite if a platform defines its own MMIO accessors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-01-30 11:29:40 +00:00
[PATCH] ARM: 2649/1: Fix 'sparse -Wbitwise' warnings from MMIO macros Patch from Olav Kongas On ARM, the outX() and writeX() families of macros take the result of cpu_to_leYY(), which is of restricted type __leYY, and feed it to __raw_writeX(), which expect an argument of unrestricted type. This results in 'sparse -Wbitwise' warnings about incorrect types in assignments. Analogous type mismatch warnings are issued for inX() and readX() counterparts. The below patch resolves these warnings by adding forced typecasts. Signed-off-by: Olav Kongas Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29 22:08:34 +01:00
ARM: io: ensure inb/outb() et.al. are properly ordered on ARMv6+ Ensure that the ISA/PCI IO space accessors are properly ordered on ARMv6+ architectures. These should always be ordered with respect to all other accesses. This also fixes __iormb() and __iowmb() not being visible to ioread/ iowrite if a platform defines its own MMIO accessors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-01-30 11:29:40 +00:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[ARM] Fix compiler warnings for memcpy_toio/memcpy_fromio/memset_io Add 'volatile' to the __iomem pointers for these functions as per x86. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-09-24 10:42:06 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: io: fix comment grammar Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-05-31 14:18:19 -05:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: kill off __mem_pci __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
2012-02-10 20:04:56 -06:00
ARM: 7118/1: rename temp variable in read*_relaxed() This resolves the following sparse warning from readl() and other macros, which ends up embedding readl_relaxed() using the same variable. arch/arm/mach-tegra/dma.c:169:8: warning: symbol '__v' shadows an earlier one arch/arm/mach-tegra/dma.c:169:8: originally declared here Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-10-04 03:44:07 +01:00
ARM: kill off __mem_pci __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
2012-02-10 20:04:56 -06:00
ARM: 7118/1: rename temp variable in read*_relaxed() This resolves the following sparse warning from readl() and other macros, which ends up embedding readl_relaxed() using the same variable. arch/arm/mach-tegra/dma.c:169:8: warning: symbol '__v' shadows an earlier one arch/arm/mach-tegra/dma.c:169:8: originally declared here Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-10-04 03:44:07 +01:00
ARM: kill off __mem_pci __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
2012-02-10 20:04:56 -06:00
ARM: 6271/1: Introduce *_relaxed() I/O accessors This patch introduces readl*_relaxed()/write*_relaxed() as the main I/O accessors (when __mem_pci is defined). The standard read*()/write*() macros are now based on the relaxed accessors. This patch is in preparation for a subsequent patch which adds barriers to the I/O accessors. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-28 22:00:54 +01:00
ARM: fix out[bwl]() out[bwl]() had a side effect that gcc read-back from the register after writing its value. This causes a problem for at least 3c589_cs, which spits out lots of "adapter failure, FIFO diagnostic register 2011." Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-05-25 08:39:25 +01:00
ARM: 6271/1: Introduce *_relaxed() I/O accessors This patch introduces readl*_relaxed()/write*_relaxed() as the main I/O accessors (when __mem_pci is defined). The standard read*()/write*() macros are now based on the relaxed accessors. This patch is in preparation for a subsequent patch which adds barriers to the I/O accessors. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-28 22:00:54 +01:00
ARM: Add barriers to io{read,write}{8,16,32} accessors as well The ioread/iowrite accessors also need barriers as they're used in place of readl/writel et.al. in portable drivers. Create __iormb() and __iowmb() which are conditionally defined to be barriers dependent on ARM_DMA_MEM_BUFFERABLE, and always use these macros in the accessors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-29 11:38:05 +01:00
ARM: kill off __mem_pci __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
2012-02-10 20:04:56 -06:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: kill off __mem_pci __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
2012-02-10 20:04:56 -06:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() If we are building for a LE platform, and we haven't overriden the MMIO ops, then we can optimize the mem*io operations using the standard string functions. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-05-07 14:22:40 +01:00
ARM: avoid unwanted GCC memset()/memcpy() optimisations for IO variants We don't want GCC optimising our memset_io(), memcpy_fromio() or memcpy_toio() variants, so we must not call one of the standard functions. Provide a separate name for our assembly memcpy() and memset() functions, and use that instead, thereby bypassing GCC's ability to optimise these operations. GCCs optimisation may introduce unaligned accesses which are invalid for device mappings. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-03 15:22:54 +01:00
ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() If we are building for a LE platform, and we haven't overriden the MMIO ops, then we can optimize the mem*io operations using the standard string functions. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-05-07 14:22:40 +01:00
ARM: avoid unwanted GCC memset()/memcpy() optimisations for IO variants We don't want GCC optimising our memset_io(), memcpy_fromio() or memcpy_toio() variants, so we must not call one of the standard functions. Provide a separate name for our assembly memcpy() and memset() functions, and use that instead, thereby bypassing GCC's ability to optimise these operations. GCCs optimisation may introduce unaligned accesses which are invalid for device mappings. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-03 15:22:54 +01:00
ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() If we are building for a LE platform, and we haven't overriden the MMIO ops, then we can optimize the mem*io operations using the standard string functions. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-05-07 14:22:40 +01:00
ARM: avoid unwanted GCC memset()/memcpy() optimisations for IO variants We don't want GCC optimising our memset_io(), memcpy_fromio() or memcpy_toio() variants, so we must not call one of the standard functions. Provide a separate name for our assembly memcpy() and memset() functions, and use that instead, thereby bypassing GCC's ability to optimise these operations. GCCs optimisation may introduce unaligned accesses which are invalid for device mappings. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-03 15:22:54 +01:00
ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() If we are building for a LE platform, and we haven't overriden the MMIO ops, then we can optimize the mem*io operations using the standard string functions. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-05-07 14:22:40 +01:00
ARM: kill off __mem_pci __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
2012-02-10 20:04:56 -06:00
ARM: optimize memset_io()/memcpy_fromio()/memcpy_toio() If we are building for a LE platform, and we haven't overriden the MMIO ops, then we can optimize the mem*io operations using the standard string functions. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-05-07 14:22:40 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: kill off __mem_pci __mem_pci is only used to enable readl/writel and friends. Just condition this on readl being defined and remove all the __mem_pci defines. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Lennert Buytenhek <kernel@wantstofly.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Nicolas Pitre <nico@fluxnic.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Colin Cross <ccross@android.com> Cc: Olof Johansson <olof@lixom.net> Cc: Stephen Warren <swarren@nvidia.com>
2012-02-10 20:04:56 -06:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: io: document ARM specific behaviour of ioremap*() implementations Add documentation of the ARM specific behaviour of the mappings setup by the ioremap() series of macros. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-01 10:02:39 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: io: document ARM specific behaviour of ioremap*() implementations Add documentation of the ARM specific behaviour of the mappings setup by the ioremap() series of macros. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-01 10:02:39 +01:00
[ARM] 3070/2: Add __ioremap_pfn() API Patch from Deepak Saxena In working on adding 36-bit addressed supersection support to ioremap(), I came to the conclusion that it would be far simpler to do so by just splitting __ioremap() into a main external interface and adding an __ioremap_pfn() function that takes a pfn + offset into the page that __ioremap() can call. This way existing callers of __ioremap() won't have to change their code and 36-bit systems will just call __ioremap_pfn() and we will not have to deal with unsigned long long variables. Note that __ioremap_pfn() should _NOT_ be called directly by drivers but is reserved for use by arch_ioremap() implementations that map 32-bit resource regions into the real 36-bit address and then call this new function. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-01-09 19:23:11 +00:00
ARM: io: document ARM specific behaviour of ioremap*() implementations Add documentation of the ARM specific behaviour of the mappings setup by the ioremap() series of macros. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-01 10:02:39 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
ARM: io: convert ioremap*() to functions Convert the ioremap*() preprocessor macros to real functions, moving them out of line. This allows us to kill off __arm_ioremap(), and __arm_iounmap() helpers, and remove __arm_ioremap_pfn_caller() from global view. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-01 10:06:32 +01:00
ARM: memremap: implement arch_memremap_wb() The generic memremap() falls back to using ioremap_cache() to create MEMREMAP_WB mappings if the requested region is not already covered by the linear mapping, unless the architecture provides an implementation of arch_memremap_wb(). Since ioremap_cache() is not appropriate on ARM to map memory with the same attributes used for the linear mapping, implement arch_memremap_wb() which does exactly that. Also, relax the WARN() check to allow MT_MEMORY_RW mappings of pfn_valid() pages. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-02-22 15:02:08 +01:00
ARM: io: convert ioremap*() to functions Convert the ioremap*() preprocessor macros to real functions, moving them out of line. This allows us to kill off __arm_ioremap(), and __arm_iounmap() helpers, and remove __arm_ioremap_pfn_caller() from global view. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-01 10:06:32 +01:00
ARM: mm: kill unused runtime hook arch_iounmap() Since the following commits, v5.4 commit 59d3ae9a5bf6 ("ARM: remove Intel iop33x and iop13xx support") v5.11 commit 3e3f354bc383 ("ARM: remove ebsa110 platform") The runtime hook arch_iounmap() on ARM is useless, kill arch_iounmap() and __iounmap(). Cc: Russell King <linux@armlinux.org.uk> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20220607125027.44946-2-wangkefeng.wang@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2022-06-07 20:50:22 +08:00
ARM: io: convert ioremap*() to functions Convert the ioremap*() preprocessor macros to real functions, moving them out of line. This allows us to kill off __arm_ioremap(), and __arm_iounmap() helpers, and remove __arm_ioremap_pfn_caller() from global view. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-01 10:06:32 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
mm/memremap: Pass down MEMREMAP_* flags to arch_memremap_wb() x86 version of arch_memremap_wb() needs the flags to decide if the mapping has to be encrypted or decrypted. Pass down the flag to arch_memremap_wb(). All current implementations ignore the argument. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20250217163822.343400-2-kirill.shutemov@linux.intel.com
2025-02-17 18:38:20 +02:00
ARM: memremap: implement arch_memremap_wb() The generic memremap() falls back to using ioremap_cache() to create MEMREMAP_WB mappings if the requested region is not already covered by the linear mapping, unless the architecture provides an implementation of arch_memremap_wb(). Since ioremap_cache() is not appropriate on ARM to map memory with the same attributes used for the linear mapping, implement arch_memremap_wb() which does exactly that. Also, relax the WARN() check to allow MT_MEMORY_RW mappings of pfn_valid() pages. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-02-22 15:02:08 +01:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
[PATCH] ARM: 2747/1: allow platforms to provide their own iomap implementation Patch from Lennert Buytenhek This patch conditionalises the io{read,write}{8,16,32} defines and the prototypes for ioport_map/ioport_unmap in asm-arm/io.h on ioread8 not already having been defined. This is done so that platforms can provide their own implementation of the iomap API, ixp2000 for example needs this. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Deepak Saxena Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-24 23:11:31 +01:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
[PATCH] ARM: Add iomap support for ARM Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-20 18:44:37 +01:00
ARM: Use include/asm-generic/io.h Include the generic I/O header file so that duplicate implementations can be removed. This will also help to establish consistency across more architectures regarding which accessors they support. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-07-28 16:34:18 +02:00
[ARM] 4388/1: no need for arm/mm mmap range checks for non-mmu We don't need valid_phys_addr_range() or valid_mmap_phys_addr_range() for the !CONFIG_MMU case. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-17 06:22:41 +01:00
[ARM] 3813/1: prevent >= 4G /dev/mem mmap() Prevent userland from mapping in physical address regions >= 4G by checking for that in valid_mmap_phys_addr_range(). Unfortunately, we cannot override valid_mmap_phys_addr_range() without also overriding valid_phys_addr_range(), so copy drivers/char/mem.c's version of valid_phys_addr_range() over to arch/arm/mm/mmap.c as well. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-16 10:50:22 +01:00
/dev/mem: use phys_addr_t for physical addresses This patch fixes the /dev/mem driver to use phys_addr_t for physical addresses. This is required on PAE systems, especially those that run entirely out of >4G physical memory space. Signed-off-by: Cyril Chemparathy <cyril@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-09-12 14:05:58 -04:00
[ARM] 3813/1: prevent >= 4G /dev/mem mmap() Prevent userland from mapping in physical address regions >= 4G by checking for that in valid_mmap_phys_addr_range(). Unfortunately, we cannot override valid_mmap_phys_addr_range() without also overriding valid_phys_addr_range(), so copy drivers/char/mem.c's version of valid_phys_addr_range() over to arch/arm/mm/mmap.c as well. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-16 10:50:22 +01:00
arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map The semantics of pfn_valid() is to check presence of the memory map for a PFN and not whether a PFN is covered by the linear map. The memory map may be present for NOMAP memory regions, but they won't be mapped in the linear mapping. Accessing such regions via __va() when they are memremap()'ed will cause a crash. On v5.4.y the crash happens on qemu-arm with UEFI [1]: <1>[ 0.084476] 8<--- cut here --- <1>[ 0.084595] Unable to handle kernel paging request at virtual address dfb76000 <1>[ 0.084938] pgd = (ptrval) <1>[ 0.085038] [dfb76000] *pgd=5f7fe801, *pte=00000000, *ppte=00000000 ... <4>[ 0.093923] [<c0ed6ce8>] (memcpy) from [<c16a06f8>] (dmi_setup+0x60/0x418) <4>[ 0.094204] [<c16a06f8>] (dmi_setup) from [<c16a38d4>] (arm_dmi_init+0x8/0x10) <4>[ 0.094408] [<c16a38d4>] (arm_dmi_init) from [<c0302e9c>] (do_one_initcall+0x50/0x228) <4>[ 0.094619] [<c0302e9c>] (do_one_initcall) from [<c16011e4>] (kernel_init_freeable+0x15c/0x1f8) <4>[ 0.094841] [<c16011e4>] (kernel_init_freeable) from [<c0f028cc>] (kernel_init+0x8/0x10c) <4>[ 0.095057] [<c0f028cc>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c) On kernels v5.10.y and newer the same crash won't reproduce on ARM because commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with for_each_mem_range()") changed the way memory regions are registered in the resource tree, but that merely covers up the problem. On ARM64 memory resources registered in yet another way and there the issue of wrong usage of pfn_valid() to ensure availability of the linear map is also covered. Implement arch_memremap_can_ram_remap() on ARM and ARM64 to prevent access to NOMAP regions via the linear mapping in memremap(). Link: https://lore.kernel.org/all/Yl65zxGgFzF1Okac@sirena.org.uk Link: https://lkml.kernel.org/r/20220426060107.7618-1-rppt@kernel.org Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Reported-by: "kernelci.org bot" <bot@kernelci.org> Tested-by: Mark Brown <broonie@kernel.org> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Brown <broonie@kernel.org> Cc: Mark-PK Tsai <mark-pk.tsai@mediatek.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Tony Lindgren <tony@atomide.com> Cc: Will Deacon <will@kernel.org> Cc: <stable@vger.kernel.org> [5.4+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-05-09 17:34:28 -07:00
[ARM] 4388/1: no need for arm/mm mmap range checks for non-mmu We don't need valid_phys_addr_range() or valid_mmap_phys_addr_range() for the !CONFIG_MMU case. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-17 06:22:41 +01:00
[ARM] 3813/1: prevent >= 4G /dev/mem mmap() Prevent userland from mapping in physical address regions >= 4G by checking for that in valid_mmap_phys_addr_range(). Unfortunately, we cannot override valid_mmap_phys_addr_range() without also overriding valid_phys_addr_range(), so copy drivers/char/mem.c's version of valid_phys_addr_range() over to arch/arm/mm/mmap.c as well. Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-09-16 10:50:22 +01:00
[ARM] Move prototype for register_isa_ports to asm/io.h Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-08-28 12:45:16 +01:00
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00