UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/arch/arm/include/asm/tlbflush.h

513 lines
14 KiB
C
Raw Normal View History

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-17 06:20:36 +08: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 17:55:55 +08:00
* arch/arm/include/asm/tlbflush.h
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-17 06:20:36 +08:00
*
* Copyright (C) 1999-2003 Russell King
*
* 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.
*/
#ifndef _ASMARM_TLBFLUSH_H
#define _ASMARM_TLBFLUSH_H
ARM: tlb: move noMMU tlb_flush() to asm/tlb.h There's no need to noMMU to put tlb_flush() in asm/tlbflush.h - it's part of the tlb shootdown interface. Move it to asm/tlb.h instead, as per x86. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-02-20 20:27:49 +08:00
#ifdef CONFIG_MMU
[ARM] noMMU: removes TLB codes in nommu mode This patch removes TLB related codes in nommu mode. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-02-25 05:41:25 +08: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-17 06:20:36 +08:00
#include <asm/glue.h>
#define TLB_V3_PAGE (1 << 0)
#define TLB_V4_U_PAGE (1 << 1)
#define TLB_V4_D_PAGE (1 << 2)
#define TLB_V4_I_PAGE (1 << 3)
#define TLB_V6_U_PAGE (1 << 4)
#define TLB_V6_D_PAGE (1 << 5)
#define TLB_V6_I_PAGE (1 << 6)
#define TLB_V3_FULL (1 << 8)
#define TLB_V4_U_FULL (1 << 9)
#define TLB_V4_D_FULL (1 << 10)
#define TLB_V4_I_FULL (1 << 11)
#define TLB_V6_U_FULL (1 << 12)
#define TLB_V6_D_FULL (1 << 13)
#define TLB_V6_I_FULL (1 << 14)
#define TLB_V6_U_ASID (1 << 16)
#define TLB_V6_D_ASID (1 << 17)
#define TLB_V6_I_ASID (1 << 18)
Check whether the TLB operations need broadcasting on SMP systems ARMv7 SMP hardware can handle the TLB maintenance operations broadcasting in hardware so that the software can avoid the costly IPIs. This patch adds the necessary checks (the MMFR3 CPUID register) to avoid the broadcasting if already supported by the hardware. (this patch is based on the work done by Tony Thompson @ ARM) Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2009-05-30 21:00:14 +08:00
/* Unified Inner Shareable TLB operations (ARMv7 MP extensions) */
#define TLB_V7_UIS_PAGE (1 << 19)
#define TLB_V7_UIS_FULL (1 << 20)
#define TLB_V7_UIS_ASID (1 << 21)
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
#define TLB_BARRIER (1 << 28)
[ARM] Feroceon: L2 cache support This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-23 04:45:04 +08:00
#define TLB_L2CLEAN_FR (1 << 29) /* Feroceon */
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-17 06:20:36 +08:00
#define TLB_DCLEAN (1 << 30)
#define TLB_WB (1 << 31)
/*
* MMU TLB Model
* =============
*
* We have the following to choose from:
* v3 - ARMv3
* v4 - ARMv4 without write buffer
* v4wb - ARMv4 with write buffer without I TLB flush entry instruction
* v4wbi - ARMv4 with write buffer with I TLB flush entry instruction
[ARM] Feroceon: L2 cache support This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-23 04:45:04 +08:00
* fr - Feroceon (v4wbi with non-outer-cacheable page table walks)
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
* fa - Faraday (v4 with write buffer with UTLB)
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-17 06:20:36 +08:00
* v6wbi - ARMv6 with write buffer with I TLB flush entry instruction
[ARM] 5192/1: ARM TLB: add v7wbi_{possible,always}_flags to {possible,always}_tlb_flags Commit 2ccdd1e77da52ad494e9af46bf272d816830cb28 doesn't add v7wbi_possible_flags and v7wbi_always_flags to possible_tlb_flags and always_tlb_flags. This causes the L2 cache flush in clean_pmd_entry() (intended for Feroceon only) to execute on ARMv7, and the CPU hangs. This patch is required for OMAP3 boards to boot. Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-12 07:04:15 +08:00
* v7wbi - identical to v6wbi
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-17 06:20:36 +08:00
*/
#undef _TLB
#undef MULTI_TLB
ARM: Allow SMP kernels to boot on UP systems UP systems do not implement all the instructions that SMP systems have, so in order to boot a SMP kernel on a UP system, we need to rewrite parts of the kernel. Do this using an 'alternatives' scheme, where the kernel code and data is modified prior to initialization to replace the SMP instructions, thereby rendering the problematical code ineffectual. We use the linker to generate a list of 32-bit word locations and their replacement values, and run through these replacements when we detect a UP system. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-04 17:47:48 +08:00
#ifdef CONFIG_SMP_ON_UP
#define MULTI_TLB 1
#endif
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-17 06:20:36 +08:00
#define v4_tlb_flags (TLB_V4_U_FULL | TLB_V4_U_PAGE)
#ifdef CONFIG_CPU_TLB_V4WT
# define v4_possible_flags v4_tlb_flags
# define v4_always_flags v4_tlb_flags
# ifdef _TLB
# define MULTI_TLB 1
# else
# define _TLB v4
# endif
#else
# define v4_possible_flags 0
# define v4_always_flags (-1UL)
#endif
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
#define fa_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
ARM: Add support for FA526 v2 Adds support for Faraday FA526 core. This core is used at least by: Cortina Systems Gemini and Centroid family Cavium Networks ECONA family Grain Media GM8120 Pixelplus ImageARM Prolific PL-1029 Faraday IP evaluation boards v2: - move TLB_BTB to separate patch - update copyrights Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
2009-03-25 19:10:01 +08:00
TLB_V4_U_FULL | TLB_V4_U_PAGE)
#ifdef CONFIG_CPU_TLB_FA
# define fa_possible_flags fa_tlb_flags
# define fa_always_flags fa_tlb_flags
# ifdef _TLB
# define MULTI_TLB 1
# else
# define _TLB fa
# endif
#else
# define fa_possible_flags 0
# define fa_always_flags (-1UL)
#endif
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-17 06:20:36 +08:00
#define v4wbi_tlb_flags (TLB_WB | TLB_DCLEAN | \
TLB_V4_I_FULL | TLB_V4_D_FULL | \
TLB_V4_I_PAGE | TLB_V4_D_PAGE)
#ifdef CONFIG_CPU_TLB_V4WBI
# define v4wbi_possible_flags v4wbi_tlb_flags
# define v4wbi_always_flags v4wbi_tlb_flags
# ifdef _TLB
# define MULTI_TLB 1
# else
# define _TLB v4wbi
# endif
#else
# define v4wbi_possible_flags 0
# define v4wbi_always_flags (-1UL)
#endif
[ARM] Feroceon: L2 cache support This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-23 04:45:04 +08:00
#define fr_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_L2CLEAN_FR | \
TLB_V4_I_FULL | TLB_V4_D_FULL | \
TLB_V4_I_PAGE | TLB_V4_D_PAGE)
#ifdef CONFIG_CPU_TLB_FEROCEON
# define fr_possible_flags fr_tlb_flags
# define fr_always_flags fr_tlb_flags
# ifdef _TLB
# define MULTI_TLB 1
# else
# define _TLB v4wbi
# endif
#else
# define fr_possible_flags 0
# define fr_always_flags (-1UL)
#endif
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-17 06:20:36 +08:00
#define v4wb_tlb_flags (TLB_WB | TLB_DCLEAN | \
TLB_V4_I_FULL | TLB_V4_D_FULL | \
TLB_V4_D_PAGE)
#ifdef CONFIG_CPU_TLB_V4WB
# define v4wb_possible_flags v4wb_tlb_flags
# define v4wb_always_flags v4wb_tlb_flags
# ifdef _TLB
# define MULTI_TLB 1
# else
# define _TLB v4wb
# endif
#else
# define v4wb_possible_flags 0
# define v4wb_always_flags (-1UL)
#endif
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
#define v6wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
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-17 06:20:36 +08:00
TLB_V6_I_FULL | TLB_V6_D_FULL | \
TLB_V6_I_PAGE | TLB_V6_D_PAGE | \
TLB_V6_I_ASID | TLB_V6_D_ASID)
#ifdef CONFIG_CPU_TLB_V6
# define v6wbi_possible_flags v6wbi_tlb_flags
# define v6wbi_always_flags v6wbi_tlb_flags
# ifdef _TLB
# define MULTI_TLB 1
# else
# define _TLB v6wbi
# endif
#else
# define v6wbi_possible_flags 0
# define v6wbi_always_flags (-1UL)
#endif
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
#define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
Check whether the TLB operations need broadcasting on SMP systems ARMv7 SMP hardware can handle the TLB maintenance operations broadcasting in hardware so that the software can avoid the costly IPIs. This patch adds the necessary checks (the MMFR3 CPUID register) to avoid the broadcasting if already supported by the hardware. (this patch is based on the work done by Tony Thompson @ ARM) Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2009-05-30 21:00:14 +08:00
TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID)
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
#define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
Check whether the TLB operations need broadcasting on SMP systems ARMv7 SMP hardware can handle the TLB maintenance operations broadcasting in hardware so that the software can avoid the costly IPIs. This patch adds the necessary checks (the MMFR3 CPUID register) to avoid the broadcasting if already supported by the hardware. (this patch is based on the work done by Tony Thompson @ ARM) Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2009-05-30 21:00:14 +08:00
TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID)
[ARM] 4394/1: ARMv7: Add the TLB range operations We are currently using the ARMv6 operations but need to duplicate some of the code because of the introduction of the new CPU barrier instructions in ARMv7. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-18 18:25:31 +08:00
#ifdef CONFIG_CPU_TLB_V7
ARM: Allow SMP kernels to boot on UP systems UP systems do not implement all the instructions that SMP systems have, so in order to boot a SMP kernel on a UP system, we need to rewrite parts of the kernel. Do this using an 'alternatives' scheme, where the kernel code and data is modified prior to initialization to replace the SMP instructions, thereby rendering the problematical code ineffectual. We use the linker to generate a list of 32-bit word locations and their replacement values, and run through these replacements when we detect a UP system. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-04 17:47:48 +08:00
# ifdef CONFIG_SMP_ON_UP
# define v7wbi_possible_flags (v7wbi_tlb_flags_smp | v7wbi_tlb_flags_up)
# define v7wbi_always_flags (v7wbi_tlb_flags_smp & v7wbi_tlb_flags_up)
# elif defined(CONFIG_SMP)
# define v7wbi_possible_flags v7wbi_tlb_flags_smp
# define v7wbi_always_flags v7wbi_tlb_flags_smp
# else
# define v7wbi_possible_flags v7wbi_tlb_flags_up
# define v7wbi_always_flags v7wbi_tlb_flags_up
# endif
[ARM] 4394/1: ARMv7: Add the TLB range operations We are currently using the ARMv6 operations but need to duplicate some of the code because of the introduction of the new CPU barrier instructions in ARMv7. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-05-18 18:25:31 +08:00
# ifdef _TLB
# define MULTI_TLB 1
# else
# define _TLB v7wbi
# endif
#else
# define v7wbi_possible_flags 0
# define v7wbi_always_flags (-1UL)
#endif
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-17 06:20:36 +08:00
#ifndef _TLB
#error Unknown TLB model
#endif
#ifndef __ASSEMBLY__
Detach sched.h from mm.h First thing mm.h does is including sched.h solely for can_do_mlock() inline function which has "current" dereference inside. By dealing with can_do_mlock() mm.h can be detached from sched.h which is good. See below, why. This patch a) removes unconditional inclusion of sched.h from mm.h b) makes can_do_mlock() normal function in mm/mlock.c c) exports can_do_mlock() to not break compilation d) adds sched.h inclusions back to files that were getting it indirectly. e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were getting them indirectly Net result is: a) mm.h users would get less code to open, read, preprocess, parse, ... if they don't need sched.h b) sched.h stops being dependency for significant number of files: on x86_64 allmodconfig touching sched.h results in recompile of 4083 files, after patch it's only 3744 (-8.3%). Cross-compile tested on all arm defconfigs, all mips defconfigs, all powerpc defconfigs, alpha alpha-up arm i386 i386-up i386-defconfig i386-allnoconfig ia64 ia64-up m68k mips parisc parisc-up powerpc powerpc-up s390 s390-up sparc sparc-up sparc64 sparc64-up um-x86_64 x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig as well as my two usual configs. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-21 05:22:52 +08:00
#include <linux/sched.h>
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-17 06:20:36 +08:00
struct cpu_tlb_fns {
void (*flush_user_range)(unsigned long, unsigned long, struct vm_area_struct *);
void (*flush_kern_range)(unsigned long, unsigned long);
unsigned long tlb_flags;
};
/*
* Select the calling method
*/
#ifdef MULTI_TLB
#define __cpu_flush_user_tlb_range cpu_tlb.flush_user_range
#define __cpu_flush_kern_tlb_range cpu_tlb.flush_kern_range
#else
#define __cpu_flush_user_tlb_range __glue(_TLB,_flush_user_tlb_range)
#define __cpu_flush_kern_tlb_range __glue(_TLB,_flush_kern_tlb_range)
extern void __cpu_flush_user_tlb_range(unsigned long, unsigned long, struct vm_area_struct *);
extern void __cpu_flush_kern_tlb_range(unsigned long, unsigned long);
#endif
extern struct cpu_tlb_fns cpu_tlb;
#define __cpu_tlb_flags cpu_tlb.tlb_flags
/*
* TLB Management
* ==============
*
* The arch/arm/mm/tlb-*.S files implement these methods.
*
* The TLB specific code is expected to perform whatever tests it
* needs to determine if it should invalidate the TLB for each
* call. Start addresses are inclusive and end addresses are
* exclusive; it is safe to round these addresses down.
*
* flush_tlb_all()
*
* Invalidate the entire TLB.
*
* flush_tlb_mm(mm)
*
* Invalidate all TLB entries in a particular address
* space.
* - mm - mm_struct describing address space
*
* flush_tlb_range(mm,start,end)
*
* Invalidate a range of TLB entries in the specified
* address space.
* - mm - mm_struct describing address space
* - start - start address (may not be aligned)
* - end - end address (exclusive, may not be aligned)
*
* flush_tlb_page(vaddr,vma)
*
* Invalidate the specified page in the specified address range.
* - vaddr - virtual address (may not be aligned)
* - vma - vma_struct describing address range
*
* flush_kern_tlb_page(kaddr)
*
* Invalidate the TLB entry for the specified page. The address
* will be in the kernels virtual memory space. Current uses
* only require the D-TLB to be invalidated.
* - kaddr - Kernel virtual memory address
*/
/*
* We optimise the code below by:
* - building a set of TLB flags that might be set in __cpu_tlb_flags
* - building a set of TLB flags that will always be set in __cpu_tlb_flags
* - if we're going to need __cpu_tlb_flags, access it once and only once
*
* This allows us to build optimal assembly for the single-CPU type case,
* and as close to optimal given the compiler constrants for multi-CPU
* case. We could do better for the multi-CPU case if the compiler
* implemented the "%?" method, but this has been discontinued due to too
* many people getting it wrong.
*/
ARM: Remove support for ARMv3 ARM610 and ARM710 CPUs This patch removes support for ARMv3 CPUs, which haven't worked properly for quite some time (see the FIXME comment in arch/arm/mm/fault.c). The only V3 parts left is the cache model for ARMv3, which is needed for some odd reason by ARM740T CPUs, and being able to build with -march=armv3, which is required for the RiscPC platform due to its bus structure. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-05-04 19:04:26 +08:00
#define possible_tlb_flags (v4_possible_flags | \
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-17 06:20:36 +08:00
v4wbi_possible_flags | \
[ARM] Feroceon: L2 cache support This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-23 04:45:04 +08:00
fr_possible_flags | \
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-17 06:20:36 +08:00
v4wb_possible_flags | \
ARM: Add support for FA526 v2 Adds support for Faraday FA526 core. This core is used at least by: Cortina Systems Gemini and Centroid family Cavium Networks ECONA family Grain Media GM8120 Pixelplus ImageARM Prolific PL-1029 Faraday IP evaluation boards v2: - move TLB_BTB to separate patch - update copyrights Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
2009-03-25 19:10:01 +08:00
fa_possible_flags | \
[ARM] 5192/1: ARM TLB: add v7wbi_{possible,always}_flags to {possible,always}_tlb_flags Commit 2ccdd1e77da52ad494e9af46bf272d816830cb28 doesn't add v7wbi_possible_flags and v7wbi_always_flags to possible_tlb_flags and always_tlb_flags. This causes the L2 cache flush in clean_pmd_entry() (intended for Feroceon only) to execute on ARMv7, and the CPU hangs. This patch is required for OMAP3 boards to boot. Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-12 07:04:15 +08:00
v6wbi_possible_flags | \
v7wbi_possible_flags)
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-17 06:20:36 +08:00
ARM: Remove support for ARMv3 ARM610 and ARM710 CPUs This patch removes support for ARMv3 CPUs, which haven't worked properly for quite some time (see the FIXME comment in arch/arm/mm/fault.c). The only V3 parts left is the cache model for ARMv3, which is needed for some odd reason by ARM740T CPUs, and being able to build with -march=armv3, which is required for the RiscPC platform due to its bus structure. Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-05-04 19:04:26 +08:00
#define always_tlb_flags (v4_always_flags & \
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-17 06:20:36 +08:00
v4wbi_always_flags & \
[ARM] Feroceon: L2 cache support This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-23 04:45:04 +08:00
fr_always_flags & \
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-17 06:20:36 +08:00
v4wb_always_flags & \
ARM: Add support for FA526 v2 Adds support for Faraday FA526 core. This core is used at least by: Cortina Systems Gemini and Centroid family Cavium Networks ECONA family Grain Media GM8120 Pixelplus ImageARM Prolific PL-1029 Faraday IP evaluation boards v2: - move TLB_BTB to separate patch - update copyrights Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
2009-03-25 19:10:01 +08:00
fa_always_flags & \
[ARM] 5192/1: ARM TLB: add v7wbi_{possible,always}_flags to {possible,always}_tlb_flags Commit 2ccdd1e77da52ad494e9af46bf272d816830cb28 doesn't add v7wbi_possible_flags and v7wbi_always_flags to possible_tlb_flags and always_tlb_flags. This causes the L2 cache flush in clean_pmd_entry() (intended for Feroceon only) to execute on ARMv7, and the CPU hangs. This patch is required for OMAP3 boards to boot. Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-08-12 07:04:15 +08:00
v6wbi_always_flags & \
v7wbi_always_flags)
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-17 06:20:36 +08:00
#define tlb_flag(f) ((always_tlb_flags & (f)) || (__tlb_flag & possible_tlb_flags & (f)))
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
#define __tlb_op(f, insnarg, arg) \
do { \
if (always_tlb_flags & (f)) \
asm("mcr " insnarg \
: : "r" (arg) : "cc"); \
else if (possible_tlb_flags & (f)) \
asm("tst %1, %2\n\t" \
"mcrne " insnarg \
: : "r" (arg), "r" (__tlb_flag), "Ir" (f) \
: "cc"); \
} while (0)
#define tlb_op(f, regs, arg) __tlb_op(f, "p15, 0, %0, " regs, arg)
#define tlb_l2_op(f, regs, arg) __tlb_op(f, "p15, 1, %0, " regs, arg)
[PATCH] ARM SMP: TLB implementations only affect local CPU The existing TLB flush implementations only have an effect on the local CPU. Prefix them with local_. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-28 20:40:39 +08:00
static inline void local_flush_tlb_all(void)
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-17 06:20:36 +08:00
{
const int zero = 0;
const unsigned int __tlb_flag = __cpu_tlb_flags;
if (tlb_flag(TLB_WB))
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
dsb();
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-17 06:20:36 +08:00
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V3_FULL, "c6, c0, 0", zero);
tlb_op(TLB_V4_U_FULL | TLB_V6_U_FULL, "c8, c7, 0", zero);
tlb_op(TLB_V4_D_FULL | TLB_V6_D_FULL, "c8, c6, 0", zero);
tlb_op(TLB_V4_I_FULL | TLB_V6_I_FULL, "c8, c5, 0", zero);
tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
if (tlb_flag(TLB_BARRIER)) {
ARM: 6112/1: Use the Inner Shareable I-cache and BTB ops on ARMv7 SMP The standard I-cache Invalidate All (ICIALLU) and Branch Predication Invalidate All (BPIALL) operations are not automatically broadcast to the other CPUs in an ARMv7 MP system. The patch adds the Inner Shareable variants, ICIALLUIS and BPIALLIS, if ARMv7 and SMP. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-05-08 01:03:05 +08:00
dsb();
isb();
}
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-17 06:20:36 +08:00
}
[PATCH] ARM SMP: TLB implementations only affect local CPU The existing TLB flush implementations only have an effect on the local CPU. Prefix them with local_. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-28 20:40:39 +08:00
static inline void local_flush_tlb_mm(struct mm_struct *mm)
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-17 06:20:36 +08:00
{
const int zero = 0;
const int asid = ASID(mm);
const unsigned int __tlb_flag = __cpu_tlb_flags;
if (tlb_flag(TLB_WB))
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
dsb();
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-17 06:20:36 +08:00
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
if (possible_tlb_flags & (TLB_V3_FULL|TLB_V4_U_FULL|TLB_V4_D_FULL|TLB_V4_I_FULL)) {
if (cpumask_test_cpu(get_cpu(), mm_cpumask(mm))) {
tlb_op(TLB_V3_FULL, "c6, c0, 0", zero);
tlb_op(TLB_V4_U_FULL, "c8, c7, 0", zero);
tlb_op(TLB_V4_D_FULL, "c8, c6, 0", zero);
tlb_op(TLB_V4_I_FULL, "c8, c5, 0", zero);
}
put_cpu();
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-17 06:20:36 +08:00
}
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V6_U_ASID, "c8, c7, 2", asid);
tlb_op(TLB_V6_D_ASID, "c8, c6, 2", asid);
tlb_op(TLB_V6_I_ASID, "c8, c5, 2", asid);
ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Cc: <stable@kernel.org> Tested-by: Rob Clark <rob@ti.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-05 18:20:51 +08:00
#ifdef CONFIG_ARM_ERRATA_720789
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V7_UIS_ASID, "c8, c3, 0", zero);
ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Cc: <stable@kernel.org> Tested-by: Rob Clark <rob@ti.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-05 18:20:51 +08:00
#else
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V7_UIS_ASID, "c8, c3, 2", asid);
ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Cc: <stable@kernel.org> Tested-by: Rob Clark <rob@ti.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-05 18:20:51 +08:00
#endif
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
if (tlb_flag(TLB_BARRIER))
ARM: 6112/1: Use the Inner Shareable I-cache and BTB ops on ARMv7 SMP The standard I-cache Invalidate All (ICIALLU) and Branch Predication Invalidate All (BPIALL) operations are not automatically broadcast to the other CPUs in an ARMv7 MP system. The patch adds the Inner Shareable variants, ICIALLUIS and BPIALLIS, if ARMv7 and SMP. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-05-08 01:03:05 +08:00
dsb();
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-17 06:20:36 +08:00
}
static inline void
[PATCH] ARM SMP: TLB implementations only affect local CPU The existing TLB flush implementations only have an effect on the local CPU. Prefix them with local_. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-28 20:40:39 +08:00
local_flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr)
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-17 06:20:36 +08:00
{
const int zero = 0;
const unsigned int __tlb_flag = __cpu_tlb_flags;
uaddr = (uaddr & PAGE_MASK) | ASID(vma->vm_mm);
if (tlb_flag(TLB_WB))
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
dsb();
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-17 06:20:36 +08:00
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
if (possible_tlb_flags & (TLB_V3_PAGE|TLB_V4_U_PAGE|TLB_V4_D_PAGE|TLB_V4_I_PAGE|TLB_V4_I_FULL) &&
cpumask_test_cpu(smp_processor_id(), mm_cpumask(vma->vm_mm))) {
tlb_op(TLB_V3_PAGE, "c6, c0, 0", uaddr);
tlb_op(TLB_V4_U_PAGE, "c8, c7, 1", uaddr);
tlb_op(TLB_V4_D_PAGE, "c8, c6, 1", uaddr);
tlb_op(TLB_V4_I_PAGE, "c8, c5, 1", uaddr);
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-17 06:20:36 +08:00
if (!tlb_flag(TLB_V4_I_PAGE) && tlb_flag(TLB_V4_I_FULL))
[ARM] 3759/2: Remove uses of %? Patch from Daniel Jacobowitz The ARM kernel has several uses of asm("foo%?"). %? is a GCC internal modifier used to output conditional execution predicates. However, no version of GCC supports conditionalizing asm statements. GCC 4.2 will correctly expand %? to the empty string in user asms. Earlier versions may reuse the condition from the previous instruction. In 'if (foo) asm ("bar%?");' this is somewhat likely to be right... but not reliable. So, the only safe thing to do is to remove the uses of %?. I believe the tlbflush.h occurances were supposed to be removed before, based on the comment about %? not working at the top of that file. Old versions of GCC could omit branches around user asms if the asm didn't mark the condition codes as clobbered. This problem hasn't been seen on any recent (3.x or 4.x) GCC, but it could theoretically happen. So, where %? was removed a cc clobber was added. Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-08-30 22:02:08 +08:00
asm("mcr p15, 0, %0, c8, c5, 0" : : "r" (zero) : "cc");
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-17 06:20:36 +08:00
}
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V6_U_PAGE, "c8, c7, 1", uaddr);
tlb_op(TLB_V6_D_PAGE, "c8, c6, 1", uaddr);
tlb_op(TLB_V6_I_PAGE, "c8, c5, 1", uaddr);
ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Cc: <stable@kernel.org> Tested-by: Rob Clark <rob@ti.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-05 18:20:51 +08:00
#ifdef CONFIG_ARM_ERRATA_720789
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V7_UIS_PAGE, "c8, c3, 3", uaddr & PAGE_MASK);
ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Cc: <stable@kernel.org> Tested-by: Rob Clark <rob@ti.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-05 18:20:51 +08:00
#else
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V7_UIS_PAGE, "c8, c3, 1", uaddr);
ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Cc: <stable@kernel.org> Tested-by: Rob Clark <rob@ti.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-08-05 18:20:51 +08:00
#endif
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
if (tlb_flag(TLB_BARRIER))
ARM: 6112/1: Use the Inner Shareable I-cache and BTB ops on ARMv7 SMP The standard I-cache Invalidate All (ICIALLU) and Branch Predication Invalidate All (BPIALL) operations are not automatically broadcast to the other CPUs in an ARMv7 MP system. The patch adds the Inner Shareable variants, ICIALLUIS and BPIALLIS, if ARMv7 and SMP. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-05-08 01:03:05 +08:00
dsb();
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-17 06:20:36 +08:00
}
[PATCH] ARM SMP: TLB implementations only affect local CPU The existing TLB flush implementations only have an effect on the local CPU. Prefix them with local_. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-28 20:40:39 +08:00
static inline void local_flush_tlb_kernel_page(unsigned long kaddr)
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-17 06:20:36 +08:00
{
const int zero = 0;
const unsigned int __tlb_flag = __cpu_tlb_flags;
kaddr &= PAGE_MASK;
if (tlb_flag(TLB_WB))
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
dsb();
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-17 06:20:36 +08:00
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V3_PAGE, "c6, c0, 0", kaddr);
tlb_op(TLB_V4_U_PAGE, "c8, c7, 1", kaddr);
tlb_op(TLB_V4_D_PAGE, "c8, c6, 1", kaddr);
tlb_op(TLB_V4_I_PAGE, "c8, c5, 1", kaddr);
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-17 06:20:36 +08:00
if (!tlb_flag(TLB_V4_I_PAGE) && tlb_flag(TLB_V4_I_FULL))
[ARM] 3759/2: Remove uses of %? Patch from Daniel Jacobowitz The ARM kernel has several uses of asm("foo%?"). %? is a GCC internal modifier used to output conditional execution predicates. However, no version of GCC supports conditionalizing asm statements. GCC 4.2 will correctly expand %? to the empty string in user asms. Earlier versions may reuse the condition from the previous instruction. In 'if (foo) asm ("bar%?");' this is somewhat likely to be right... but not reliable. So, the only safe thing to do is to remove the uses of %?. I believe the tlbflush.h occurances were supposed to be removed before, based on the comment about %? not working at the top of that file. Old versions of GCC could omit branches around user asms if the asm didn't mark the condition codes as clobbered. This problem hasn't been seen on any recent (3.x or 4.x) GCC, but it could theoretically happen. So, where %? was removed a cc clobber was added. Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-08-30 22:02:08 +08:00
asm("mcr p15, 0, %0, c8, c5, 0" : : "r" (zero) : "cc");
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-17 06:20:36 +08:00
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_V6_U_PAGE, "c8, c7, 1", kaddr);
tlb_op(TLB_V6_D_PAGE, "c8, c6, 1", kaddr);
tlb_op(TLB_V6_I_PAGE, "c8, c5, 1", kaddr);
tlb_op(TLB_V7_UIS_PAGE, "c8, c3, 1", kaddr);
[ARM] 3352/1: DSB required for the completion of a TLB maintenance operation Patch from Catalin Marinas Chapter B2.7.3 in the latest ARM ARM (with v6 information) states that the completion of a TLB maintenance operation is only guaranteed by the execution of a DSB (Data Syncronization Barrier, formerly Data Write Barrier or Drain Write Buffer). Note that a DSB is only needed in the flush_tlb_kernel_* functions since the completion is guaranteed by a mode change (i.e. switching back to user mode) for the flush_tlb_user_* functions. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-03-07 22:42:27 +08:00
ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence Kernel space needs very little in the way of BTC maintanence as most mappings which are created and destroyed are non-executable, and so could never enter the instruction stream. The case which does warrant BTC maintanence is when a module is loaded. This creates a new executable mapping, but at that point the pages have not been initialized with code and data, so at that point they contain unpredictable information. Invalidating the BTC at this stage serves little useful purpose. Before we execute module code, we call flush_icache_range(), which deals with the BTC maintanence requirements. This ensures that we have a BTC maintanence operation before we execute code via the newly created mapping. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-05 16:01:13 +08:00
if (tlb_flag(TLB_BARRIER)) {
ARM: 6112/1: Use the Inner Shareable I-cache and BTB ops on ARMv7 SMP The standard I-cache Invalidate All (ICIALLU) and Branch Predication Invalidate All (BPIALL) operations are not automatically broadcast to the other CPUs in an ARMv7 MP system. The patch adds the Inner Shareable variants, ICIALLUIS and BPIALLIS, if ARMv7 and SMP. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-05-08 01:03:05 +08:00
dsb();
isb();
}
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-17 06:20:36 +08:00
}
/*
* flush_pmd_entry
*
* Flush a PMD entry (word aligned, or double-word aligned) to
* RAM if the TLB for the CPU we are running on requires this.
* This is typically used when we are creating PMD entries.
*
* clean_pmd_entry
*
* Clean (but don't drain the write buffer) if the CPU requires
* these operations. This is typically used when we are removing
* PMD entries.
*/
ARM: 7076/1: LPAE: Add (pte|pmd)val_t type definitions as u32 This patch defines the (pte|pmd)val_t as u32 and changes the page table types to be based on these. The PMD bits are converted to the corresponding type using the _AT macro. The flush_pmd_entry/clean_pmd_entry argument was changed to (void *) to allow them to be used with both PGD and PMD pointers and avoid code duplication. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-06 00:51:56 +08:00
static inline void flush_pmd_entry(void *pmd)
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-17 06:20:36 +08:00
{
const unsigned int __tlb_flag = __cpu_tlb_flags;
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_DCLEAN, "c7, c10, 1 @ flush_pmd", pmd);
tlb_l2_op(TLB_L2CLEAN_FR, "c15, c9, 1 @ L2 flush_pmd", pmd);
[ARM] Feroceon: L2 cache support This patch adds support for the unified Feroceon L2 cache controller as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo families of ARM SoCs. Note that: - Page table walks are outer uncacheable on Kirkwood and Discovery Duo, since the ARMv5 spec provides no way to indicate outer cacheability of page table walks (specifying it in TTBR[4:3] is an ARMv6+ feature). This requires adding L2 cache clean instructions to proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled by defining a new TLB type (TLB_FEROCEON) which is almost identical to the v4wbi one but provides a TLB_L2CLEAN_FR flag. - The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2 range by MVA' and 'invalidate L2 range by MVA') operations, and this patch uses those range operations for all Linux outer cache operations, as they are faster than the regular per-line operations. L2 range operations are not interruptible on this hardware, which avoids potential livelock issues, but can be bad for interrupt latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which allows you to select the maximum range size to operate on at once. (Valid range is between one cache line and one 4KiB page, and must be a multiple of the line size.) Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
2008-06-23 04:45:04 +08: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-17 06:20:36 +08:00
if (tlb_flag(TLB_WB))
[ARM] 4129/1: Add barriers after the TLB operations The architecture specification states that TLB operations are guaranteed to be complete only after the execution of a DSB (Data Synchronisation Barrier, former Data Write Barrier or Drain Write Buffer). The branch target cache invalidation is also needed. The ISB (Instruction Synchronisation Barrier, formerly Prefetch Flush) is needed unless there will be a return from exception before the corresponding mapping is used (i.e. user mappings). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2007-02-05 21:47:51 +08:00
dsb();
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-17 06:20:36 +08:00
}
ARM: 7076/1: LPAE: Add (pte|pmd)val_t type definitions as u32 This patch defines the (pte|pmd)val_t as u32 and changes the page table types to be based on these. The PMD bits are converted to the corresponding type using the _AT macro. The flush_pmd_entry/clean_pmd_entry argument was changed to (void *) to allow them to be used with both PGD and PMD pointers and avoid code duplication. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-06 00:51:56 +08:00
static inline void clean_pmd_entry(void *pmd)
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-17 06:20:36 +08:00
{
const unsigned int __tlb_flag = __cpu_tlb_flags;
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
tlb_op(TLB_DCLEAN, "c7, c10, 1 @ flush_pmd", pmd);
tlb_l2_op(TLB_L2CLEAN_FR, "c15, c9, 1 @ L2 flush_pmd", pmd);
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-17 06:20:36 +08:00
}
ARM: Optimize multi-CPU tlb flushing a little more The compiler does not conditionalize the assembly instructions for the tlb operations, which leads to sub-optimal code being generated when building a kernel for multiple CPUs. We can tweak things fairly simply as the code fragment below shows: 17f8: e3120001 tst r2, #1 ; 0x1 ... 1800: 0a000000 beq 1808 <handle_pte_fault+0x194> 1804: ee061f10 mcr 15, 0, r1, cr6, cr0, {0} 1808: e3120004 tst r2, #4 ; 0x4 180c: 0a000000 beq 1814 <handle_pte_fault+0x1a0> 1810: ee081f36 mcr 15, 0, r1, cr8, cr6, {1} becomes: 17f0: e3120001 tst r2, #1 ; 0x1 17f4: 1e063f10 mcrne 15, 0, r3, cr6, cr0, {0} 17f8: e3120004 tst r2, #4 ; 0x4 17fc: 1e083f36 mcrne 15, 0, r3, cr8, cr6, {1} Overall, for Realview with V6 and V7 CPUs configured: text data bss dec hex filename 4153998 207340 5371036 9732374 948116 ../build/realview/vmlinux.before 4153366 207332 5371036 9731734 947e96 ../build/realview/vmlinux.after Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-02-04 18:55:38 +08:00
#undef tlb_op
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-17 06:20:36 +08:00
#undef tlb_flag
#undef always_tlb_flags
#undef possible_tlb_flags
/*
* Convert calls to our calling convention.
*/
[PATCH] ARM SMP: TLB implementations only affect local CPU The existing TLB flush implementations only have an effect on the local CPU. Prefix them with local_. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-06-28 20:40:39 +08:00
#define local_flush_tlb_range(vma,start,end) __cpu_flush_user_tlb_range(start,end,vma)
#define local_flush_tlb_kernel_range(s,e) __cpu_flush_kern_tlb_range(s,e)
#ifndef CONFIG_SMP
#define flush_tlb_all local_flush_tlb_all
#define flush_tlb_mm local_flush_tlb_mm
#define flush_tlb_page local_flush_tlb_page
#define flush_tlb_kernel_page local_flush_tlb_kernel_page
#define flush_tlb_range local_flush_tlb_range
#define flush_tlb_kernel_range local_flush_tlb_kernel_range
#else
extern void flush_tlb_all(void);
extern void flush_tlb_mm(struct mm_struct *mm);
extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long uaddr);
extern void flush_tlb_kernel_page(unsigned long kaddr);
extern void flush_tlb_range(struct vm_area_struct *vma, unsigned long start, unsigned long end);
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
#endif
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-17 06:20:36 +08:00
/*
ARM: 6379/1: Assume new page cache pages have dirty D-cache There are places in Linux where writes to newly allocated page cache pages happen without a subsequent call to flush_dcache_page() (several PIO drivers including USB HCD). This patch changes the meaning of PG_arch_1 to be PG_dcache_clean and always flush the D-cache for a newly mapped page in update_mmu_cache(). The patch also sets the PG_arch_1 bit in the DMA cache maintenance function to avoid additional cache flushing in update_mmu_cache(). Tested-by: Rabin Vincent <rabin.vincent@stericsson.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-13 22:57:36 +08:00
* If PG_dcache_clean is not set for the page, we need to ensure that any
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-17 06:20:36 +08:00
* cache entries for the kernels virtual memory range are written
ARM: 6380/1: Introduce __sync_icache_dcache() for VIPT caches On SMP systems, there is a small chance of a PTE becoming visible to a different CPU before the current cache maintenance operations in update_mmu_cache(). To avoid this, cache maintenance must be handled in set_pte_at() (similar to IA-64 and PowerPC). This patch provides a unified VIPT cache handling mechanism and implements the __sync_icache_dcache() function for ARMv6 onwards architectures. It is called from set_pte_at() and replaces the update_mmu_cache(). The latter is still used on VIVT hardware where a vm_area_struct is required. Tested-by: Rabin Vincent <rabin.vincent@stericsson.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-13 22:58:06 +08:00
* back to the page. On ARMv6 and later, the cache coherency is handled via
* the set_pte_at() function.
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-17 06:20:36 +08:00
*/
ARM: 6380/1: Introduce __sync_icache_dcache() for VIPT caches On SMP systems, there is a small chance of a PTE becoming visible to a different CPU before the current cache maintenance operations in update_mmu_cache(). To avoid this, cache maintenance must be handled in set_pte_at() (similar to IA-64 and PowerPC). This patch provides a unified VIPT cache handling mechanism and implements the __sync_icache_dcache() function for ARMv6 onwards architectures. It is called from set_pte_at() and replaces the update_mmu_cache(). The latter is still used on VIVT hardware where a vm_area_struct is required. Tested-by: Rabin Vincent <rabin.vincent@stericsson.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-13 22:58:06 +08:00
#if __LINUX_ARM_ARCH__ < 6
MM: Pass a PTE pointer to update_mmu_cache() rather than the PTE itself On VIVT ARM, when we have multiple shared mappings of the same file in the same MM, we need to ensure that we have coherency across all copies. We do this via make_coherent() by making the pages uncacheable. This used to work fine, until we allowed highmem with highpte - we now have a page table which is mapped as required, and is not available for modification via update_mmu_cache(). Ralf Beache suggested getting rid of the PTE value passed to update_mmu_cache(): On MIPS update_mmu_cache() calls __update_tlb() which walks pagetables to construct a pointer to the pte again. Passing a pte_t * is much more elegant. Maybe we might even replace the pte argument with the pte_t? Ben Herrenschmidt would also like the pte pointer for PowerPC: Passing the ptep in there is exactly what I want. I want that -instead- of the PTE value, because I have issue on some ppc cases, for I$/D$ coherency, where set_pte_at() may decide to mask out the _PAGE_EXEC. So, pass in the mapped page table pointer into update_mmu_cache(), and remove the PTE value, updating all implementations and call sites to suit. Includes a fix from Stephen Rothwell: sparc: fix fallout from update_mmu_cache API change Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-12-19 00:40:18 +08:00
extern void update_mmu_cache(struct vm_area_struct *vma, unsigned long addr,
pte_t *ptep);
ARM: 6380/1: Introduce __sync_icache_dcache() for VIPT caches On SMP systems, there is a small chance of a PTE becoming visible to a different CPU before the current cache maintenance operations in update_mmu_cache(). To avoid this, cache maintenance must be handled in set_pte_at() (similar to IA-64 and PowerPC). This patch provides a unified VIPT cache handling mechanism and implements the __sync_icache_dcache() function for ARMv6 onwards architectures. It is called from set_pte_at() and replaces the update_mmu_cache(). The latter is still used on VIVT hardware where a vm_area_struct is required. Tested-by: Rabin Vincent <rabin.vincent@stericsson.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-09-13 22:58:06 +08:00
#else
static inline void update_mmu_cache(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
}
#endif
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-17 06:20:36 +08:00
#endif
[ARM] noMMU: removes TLB codes in nommu mode This patch removes TLB related codes in nommu mode. Signed-off-by: Hyok S. Choi <hyok.choi@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-02-25 05:41:25 +08:00
#endif /* CONFIG_MMU */
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-17 06:20:36 +08:00
#endif