linux/arch/arm/mm/Kconfig

819 lines
20 KiB
Plaintext
Raw Normal View History

comment "Processor Type"
# Select CPU types depending on the architecture selected. This selects
# which CPUs we support in the kernel image, and the compiler instruction
# optimiser behaviour.
# ARM610
config CPU_ARM610
bool "Support ARM610 processor" if ARCH_RPC
select CPU_32v3
select CPU_CACHE_V3
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V3 if MMU
select CPU_TLB_V3 if MMU
select CPU_PABRT_LEGACY
help
The ARM610 is the successor to the ARM3 processor
and was produced by VLSI Technology Inc.
Say Y if you want support for the ARM610 processor.
Otherwise, say N.
# ARM7TDMI
config CPU_ARM7TDMI
bool "Support ARM7TDMI processor"
depends on !MMU
select CPU_32v4T
select CPU_ABRT_LV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V4
help
A 32-bit RISC microprocessor based on the ARM7 processor core
which has no memory control unit and cache.
Say Y if you want support for the ARM7TDMI processor.
Otherwise, say N.
# ARM710
config CPU_ARM710
bool "Support ARM710 processor" if ARCH_RPC
select CPU_32v3
select CPU_CACHE_V3
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V3 if MMU
select CPU_TLB_V3 if MMU
select CPU_PABRT_LEGACY
help
A 32-bit RISC microprocessor based on the ARM7 processor core
designed by Advanced RISC Machines Ltd. The ARM710 is the
successor to the ARM610 processor. It was released in
July 1994 by VLSI Technology Inc.
Say Y if you want support for the ARM710 processor.
Otherwise, say N.
# ARM720T
config CPU_ARM720T
bool "Support ARM720T processor" if ARCH_INTEGRATOR
select CPU_32v4T
select CPU_ABRT_LV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V4
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WT if MMU
select CPU_TLB_V4WT if MMU
help
A 32-bit RISC processor with 8kByte Cache, Write Buffer and
MMU built around an ARM7TDMI core.
Say Y if you want support for the ARM720T processor.
Otherwise, say N.
# ARM740T
config CPU_ARM740T
bool "Support ARM740T processor" if ARCH_INTEGRATOR
depends on !MMU
select CPU_32v4T
select CPU_ABRT_LV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V3 # although the core is v4t
select CPU_CP15_MPU
help
A 32-bit RISC processor with 8KB cache or 4KB variants,
write buffer and MPU(Protection Unit) built around
an ARM7TDMI core.
Say Y if you want support for the ARM740T processor.
Otherwise, say N.
# ARM9TDMI
config CPU_ARM9TDMI
bool "Support ARM9TDMI processor"
depends on !MMU
select CPU_32v4T
select CPU_ABRT_NOMMU
select CPU_PABRT_LEGACY
select CPU_CACHE_V4
help
A 32-bit RISC microprocessor based on the ARM9 processor core
which has no memory control unit and cache.
Say Y if you want support for the ARM9TDMI processor.
Otherwise, say N.
# ARM920T
config CPU_ARM920T
bool "Support ARM920T processor" if ARCH_INTEGRATOR
select CPU_32v4T
select CPU_ABRT_EV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V4WT
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU
select CPU_TLB_V4WBI if MMU
help
The ARM920T is licensed to be produced by numerous vendors,
and is used in the Cirrus EP93xx and the Samsung S3C2410.
Say Y if you want support for the ARM920T processor.
Otherwise, say N.
# ARM922T
config CPU_ARM922T
bool "Support ARM922T processor" if ARCH_INTEGRATOR
select CPU_32v4T
select CPU_ABRT_EV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V4WT
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU
select CPU_TLB_V4WBI if MMU
help
The ARM922T is a version of the ARM920T, but with smaller
instruction and data caches. It is used in Altera's
Excalibur XA device family and Micrel's KS8695 Centaur.
Say Y if you want support for the ARM922T processor.
Otherwise, say N.
# ARM925T
config CPU_ARM925T
bool "Support ARM925T processor" if ARCH_OMAP1
select CPU_32v4T
select CPU_ABRT_EV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V4WT
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU
select CPU_TLB_V4WBI if MMU
help
The ARM925T is a mix between the ARM920T and ARM926T, but with
different instruction and data caches. It is used in TI's OMAP
device family.
Say Y if you want support for the ARM925T processor.
Otherwise, say N.
# ARM926T
config CPU_ARM926T
bool "Support ARM926T processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB
select CPU_32v5
select CPU_ABRT_EV5TJ
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU
select CPU_TLB_V4WBI if MMU
help
This is a variant of the ARM920. It has slightly different
instruction sequences for cache and TLB operations. Curiously,
there is no documentation on it at the ARM corporate website.
Say Y if you want support for the ARM926T processor.
Otherwise, say N.
# FA526
config CPU_FA526
bool
select CPU_32v4
select CPU_ABRT_EV4
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_CACHE_FA
select CPU_COPY_FA if MMU
select CPU_TLB_FA if MMU
help
The FA526 is a version of the ARMv4 compatible processor with
Branch Target Buffer, Unified TLB and cache line size 16.
Say Y if you want support for the FA526 processor.
Otherwise, say N.
# ARM940T
config CPU_ARM940T
bool "Support ARM940T processor" if ARCH_INTEGRATOR
depends on !MMU
select CPU_32v4T
select CPU_ABRT_NOMMU
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MPU
help
ARM940T is a member of the ARM9TDMI family of general-
purpose microprocessors with MPU and separate 4KB
instruction and 4KB data cases, each with a 4-word line
length.
Say Y if you want support for the ARM940T processor.
Otherwise, say N.
# ARM946E-S
config CPU_ARM946E
bool "Support ARM946E-S processor" if ARCH_INTEGRATOR
depends on !MMU
select CPU_32v5
select CPU_ABRT_NOMMU
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MPU
help
ARM946E-S is a member of the ARM9E-S family of high-
performance, 32-bit system-on-chip processor solutions.
The TCM and ARMv5TE 32-bit instruction set is supported.
Say Y if you want support for the ARM946E-S processor.
Otherwise, say N.
# ARM1020 - needs validating
config CPU_ARM1020
bool "Support ARM1020T (rev 0) processor" if ARCH_INTEGRATOR
select CPU_32v5
select CPU_ABRT_EV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V4WT
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU
select CPU_TLB_V4WBI if MMU
help
The ARM1020 is the 32K cached version of the ARM10 processor,
with an addition of a floating-point unit.
Say Y if you want support for the ARM1020 processor.
Otherwise, say N.
# ARM1020E - needs validating
config CPU_ARM1020E
bool "Support ARM1020E processor" if ARCH_INTEGRATOR
select CPU_32v5
select CPU_ABRT_EV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_V4WT
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU
select CPU_TLB_V4WBI if MMU
depends on n
# ARM1022E
config CPU_ARM1022
bool "Support ARM1022E processor" if ARCH_INTEGRATOR
select CPU_32v5
select CPU_ABRT_EV4T
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU # can probably do better
select CPU_TLB_V4WBI if MMU
help
The ARM1022E is an implementation of the ARMv5TE architecture
based upon the ARM10 integer core with a 16KiB L1 Harvard cache,
embedded trace macrocell, and a floating-point unit.
Say Y if you want support for the ARM1022E processor.
Otherwise, say N.
# ARM1026EJ-S
config CPU_ARM1026
bool "Support ARM1026EJ-S processor" if ARCH_INTEGRATOR
select CPU_32v5
select CPU_ABRT_EV5T # But need Jazelle, but EV5TJ ignores bit 10
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU # can probably do better
select CPU_TLB_V4WBI if MMU
help
The ARM1026EJ-S is an implementation of the ARMv5TEJ architecture
based upon the ARM10 integer core.
Say Y if you want support for the ARM1026EJ-S processor.
Otherwise, say N.
# SA110
config CPU_SA110
bool "Support StrongARM(R) SA-110 processor" if ARCH_RPC
select CPU_32v3 if ARCH_RPC
select CPU_32v4 if !ARCH_RPC
select CPU_ABRT_EV4
select CPU_PABRT_LEGACY
select CPU_CACHE_V4WB
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_V4WB if MMU
select CPU_TLB_V4WB if MMU
help
The Intel StrongARM(R) SA-110 is a 32-bit microprocessor and
is available at five speeds ranging from 100 MHz to 233 MHz.
More information is available at
<http://developer.intel.com/design/strong/sa110.htm>.
Say Y if you want support for the SA-110 processor.
Otherwise, say N.
# SA1100
config CPU_SA1100
bool
select CPU_32v4
select CPU_ABRT_EV4
select CPU_PABRT_LEGACY
select CPU_CACHE_V4WB
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_TLB_V4WB if MMU
# XScale
config CPU_XSCALE
bool
select CPU_32v5
select CPU_ABRT_EV5T
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_TLB_V4WBI if MMU
# XScale Core Version 3
config CPU_XSC3
bool
select CPU_32v5
select CPU_ABRT_EV5T
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_TLB_V4WBI if MMU
select IO_36
2009-01-20 06:15:18 +00:00
# Marvell PJ1 (Mohawk)
config CPU_MOHAWK
bool
select CPU_32v5
select CPU_ABRT_EV5T
select CPU_PABRT_LEGACY
2009-01-20 06:15:18 +00:00
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_TLB_V4WBI if MMU
select CPU_COPY_V4WB if MMU
# Feroceon
config CPU_FEROCEON
bool
select CPU_32v5
select CPU_ABRT_EV5T
select CPU_PABRT_LEGACY
select CPU_CACHE_VIVT
select CPU_CP15_MMU
select CPU_COPY_FEROCEON if MMU
select CPU_TLB_FEROCEON if MMU
config CPU_FEROCEON_OLD_ID
bool "Accept early Feroceon cores with an ARM926 ID"
depends on CPU_FEROCEON && !CPU_ARM926T
default y
help
This enables the usage of some old Feroceon cores
for which the CPU ID is equal to the ARM926 ID.
Relevant for Feroceon-1850 and early Feroceon-2850.
# ARMv6
config CPU_V6
bool "Support ARM V6 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX || ARCH_DOVE
select CPU_32v6
select CPU_ABRT_EV6
select CPU_PABRT_V6
select CPU_CACHE_V6
select CPU_CACHE_VIPT
select CPU_CP15_MMU
select CPU_HAS_ASID if MMU
select CPU_COPY_V6 if MMU
select CPU_TLB_V6 if MMU
# ARMv6k
config CPU_32v6K
bool "Support ARM V6K processor extensions" if !SMP
depends on CPU_V6
default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
help
Say Y here if your ARMv6 processor supports the 'K' extension.
This enables the kernel to use some instructions not present
on previous processors, and as such a kernel build with this
enabled will not boot on processors with do not support these
instructions.
# ARMv7
config CPU_V7
bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB || MACH_REALVIEW_PBX
select CPU_32v6K if !ARCH_OMAP2
select CPU_32v7
select CPU_ABRT_EV7
select CPU_PABRT_V7
select CPU_CACHE_V7
select CPU_CACHE_VIPT
select CPU_CP15_MMU
select CPU_HAS_ASID if MMU
select CPU_COPY_V6 if MMU
select CPU_TLB_V7 if MMU
# Figure out what processor architecture version we should be using.
# This defines the compiler instruction set which depends on the machine type.
config CPU_32v3
bool
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
config CPU_32v4
bool
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
config CPU_32v4T
bool
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
config CPU_32v5
bool
select TLS_REG_EMUL if SMP || !MMU
select NEEDS_SYSCALL_FOR_CMPXCHG if SMP
config CPU_32v6
bool
select TLS_REG_EMUL if !CPU_32v6K && !MMU
config CPU_32v7
bool
# The abort model
config CPU_ABRT_NOMMU
bool
config CPU_ABRT_EV4
bool
config CPU_ABRT_EV4T
bool
config CPU_ABRT_LV4T
bool
config CPU_ABRT_EV5T
bool
config CPU_ABRT_EV5TJ
bool
config CPU_ABRT_EV6
bool
config CPU_ABRT_EV7
bool
config CPU_PABRT_LEGACY
bool
config CPU_PABRT_V6
bool
config CPU_PABRT_V7
bool
# The cache model
config CPU_CACHE_V3
bool
config CPU_CACHE_V4
bool
config CPU_CACHE_V4WT
bool
config CPU_CACHE_V4WB
bool
config CPU_CACHE_V6
bool
config CPU_CACHE_V7
bool
config CPU_CACHE_VIVT
bool
config CPU_CACHE_VIPT
bool
config CPU_CACHE_FA
bool
if MMU
# The copy-page model
config CPU_COPY_V3
bool
config CPU_COPY_V4WT
bool
config CPU_COPY_V4WB
bool
config CPU_COPY_FEROCEON
bool
config CPU_COPY_FA
bool
config CPU_COPY_V6
bool
# This selects the TLB model
config CPU_TLB_V3
bool
help
ARM Architecture Version 3 TLB.
config CPU_TLB_V4WT
bool
help
ARM Architecture Version 4 TLB with writethrough cache.
config CPU_TLB_V4WB
bool
help
ARM Architecture Version 4 TLB with writeback cache.
config CPU_TLB_V4WBI
bool
help
ARM Architecture Version 4 TLB with writeback cache and invalidate
instruction cache entry.
config CPU_TLB_FEROCEON
bool
help
Feroceon TLB (v4wbi with non-outer-cachable page table walks).
config CPU_TLB_FA
bool
help
Faraday ARM FA526 architecture, unified TLB with writeback cache
and invalidate instruction cache entry. Branch target buffer is
also supported.
config CPU_TLB_V6
bool
config CPU_TLB_V7
bool
config VERIFY_PERMISSION_FAULT
bool
endif
config CPU_HAS_ASID
bool
help
This indicates whether the CPU has the ASID register; used to
tag TLB and possibly cache entries.
config CPU_CP15
bool
help
Processor has the CP15 register.
config CPU_CP15_MMU
bool
select CPU_CP15
help
Processor has the CP15 register, which has MMU related registers.
config CPU_CP15_MPU
bool
select CPU_CP15
help
Processor has the CP15 register, which has MPU related registers.
#
# CPU supports 36-bit I/O
#
config IO_36
bool
comment "Processor Features"
config ARM_THUMB
bool "Support Thumb user binaries"
2009-01-20 06:15:18 +00:00
depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_ARM1020E || CPU_ARM1022 || CPU_ARM1026 || CPU_XSCALE || CPU_XSC3 || CPU_MOHAWK || CPU_V6 || CPU_V7 || CPU_FEROCEON
default y
help
Say Y if you want to include kernel support for running user space
Thumb binaries.
The Thumb instruction set is a compressed form of the standard ARM
instruction set resulting in smaller binaries at the expense of
slightly less efficient code.
If you don't know what this all is, saying Y is a safe choice.
config ARM_THUMBEE
bool "Enable ThumbEE CPU extension"
depends on CPU_V7
help
Say Y here if you have a CPU with the ThumbEE extension and code to
make use of it. Say N for code that can run on CPUs without ThumbEE.
config CPU_BIG_ENDIAN
bool "Build big-endian kernel"
depends on ARCH_SUPPORTS_BIG_ENDIAN
help
Say Y if you plan on running a kernel in big-endian mode.
Note that your board must be properly built and your board
port must properly enable any big-endian related features
of your chipset/board/processor.
config CPU_ENDIAN_BE8
bool
depends on CPU_BIG_ENDIAN
default CPU_V6 || CPU_V7
help
Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
config CPU_ENDIAN_BE32
bool
depends on CPU_BIG_ENDIAN
default !CPU_ENDIAN_BE8
help
Support for the BE-32 (big-endian) mode on pre-ARMv6 processors.
config CPU_HIGH_VECTOR
depends on !MMU && CPU_CP15 && !CPU_ARM740T
bool "Select the High exception vector"
help
Say Y here to select high exception vector(0xFFFF0000~).
The exception vector can be vary depending on the platform
design in nommu mode. If your platform needs to select
high exception vector, say Y.
Otherwise or if you are unsure, say N, and the low exception
vector (0x00000000~) will be used.
config CPU_ICACHE_DISABLE
bool "Disable I-Cache (I-bit)"
depends on CPU_CP15 && !(CPU_ARM610 || CPU_ARM710 || CPU_ARM720T || CPU_ARM740T || CPU_XSCALE || CPU_XSC3)
help
Say Y here to disable the processor instruction cache. Unless
you have a reason not to or are unsure, say N.
config CPU_DCACHE_DISABLE
bool "Disable D-Cache (C-bit)"
depends on CPU_CP15
help
Say Y here to disable the processor data cache. Unless
you have a reason not to or are unsure, say N.
config CPU_DCACHE_SIZE
hex
depends on CPU_ARM740T || CPU_ARM946E
default 0x00001000 if CPU_ARM740T
default 0x00002000 # default size for ARM946E-S
help
Some cores are synthesizable to have various sized cache. For
ARM946E-S case, it can vary from 0KB to 1MB.
To support such cache operations, it is efficient to know the size
before compile time.
If your SoC is configured to have a different size, define the value
here with proper conditions.
config CPU_DCACHE_WRITETHROUGH
bool "Force write through D-cache"
depends on (CPU_ARM740T || CPU_ARM920T || CPU_ARM922T || CPU_ARM925T || CPU_ARM926T || CPU_ARM940T || CPU_ARM946E || CPU_ARM1020 || CPU_FA526) && !CPU_DCACHE_DISABLE
default y if CPU_ARM925T
help
Say Y here to use the data cache in writethrough mode. Unless you
specifically require this or are unsure, say N.
config CPU_CACHE_ROUND_ROBIN
bool "Round robin I and D cache replacement algorithm"
depends on (CPU_ARM926T || CPU_ARM946E || CPU_ARM1020) && (!CPU_ICACHE_DISABLE || !CPU_DCACHE_DISABLE)
help
Say Y here to use the predictable round-robin cache replacement
policy. Unless you specifically require this or are unsure, say N.
config CPU_BPREDICT_DISABLE
bool "Disable branch prediction"
depends on CPU_ARM1020 || CPU_V6 || CPU_MOHAWK || CPU_XSC3 || CPU_V7 || CPU_FA526
help
Say Y here to disable branch prediction. If unsure, say N.
[PATCH] ARM: 2651/3: kernel helpers for NPTL support Patch from Nicolas Pitre This patch entirely reworks the kernel assistance for NPTL on ARM. In particular this provides an efficient way to retrieve the TLS value and perform atomic operations without any instruction emulation nor special system call. This even allows for pre ARMv6 binaries to be forward compatible with SMP systems without any penalty. The problematic and performance critical operations are performed through segment of kernel provided user code reachable from user space at a fixed address in kernel memory. Those fixed entry points are within the vector page so we basically get it for free as no extra memory page is required and nothing else may be mapped at that location anyway. This is different from (but doesn't preclude) a full blown VDSO implementation, however a VDSO would prevent some assembly tricks with constants that allows for efficient branching to those code segments. And since those code segments only use a few cycles before returning to user code, the overhead of a VDSO far call would add a significant overhead to such minimalistic operations. The ARM_NR_set_tls syscall also changed number. This is done for two reasons: 1) this patch changes the way the TLS value was previously meant to be retrieved, therefore we ensure whatever library using the old way gets fixed (they only exist in private tree at the moment since the NPTL work is still progressing). 2) the previous number was allocated in a range causing an undefined instruction trap on kernels not supporting that syscall and it was determined that allocating it in a range returning -ENOSYS would be much nicer for libraries trying to determine if the feature is present or not. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29 21:08:33 +00:00
config TLS_REG_EMUL
bool
help
An SMP system using a pre-ARMv6 processor (there are apparently
a few prototypes like that in existence) and therefore access to
that required register must be emulated.
[PATCH] ARM: 2651/3: kernel helpers for NPTL support Patch from Nicolas Pitre This patch entirely reworks the kernel assistance for NPTL on ARM. In particular this provides an efficient way to retrieve the TLS value and perform atomic operations without any instruction emulation nor special system call. This even allows for pre ARMv6 binaries to be forward compatible with SMP systems without any penalty. The problematic and performance critical operations are performed through segment of kernel provided user code reachable from user space at a fixed address in kernel memory. Those fixed entry points are within the vector page so we basically get it for free as no extra memory page is required and nothing else may be mapped at that location anyway. This is different from (but doesn't preclude) a full blown VDSO implementation, however a VDSO would prevent some assembly tricks with constants that allows for efficient branching to those code segments. And since those code segments only use a few cycles before returning to user code, the overhead of a VDSO far call would add a significant overhead to such minimalistic operations. The ARM_NR_set_tls syscall also changed number. This is done for two reasons: 1) this patch changes the way the TLS value was previously meant to be retrieved, therefore we ensure whatever library using the old way gets fixed (they only exist in private tree at the moment since the NPTL work is still progressing). 2) the previous number was allocated in a range causing an undefined instruction trap on kernels not supporting that syscall and it was determined that allocating it in a range returning -ENOSYS would be much nicer for libraries trying to determine if the feature is present or not. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29 21:08:33 +00:00
config HAS_TLS_REG
bool
depends on !TLS_REG_EMUL
default y if SMP || CPU_32v7
[PATCH] ARM: 2651/3: kernel helpers for NPTL support Patch from Nicolas Pitre This patch entirely reworks the kernel assistance for NPTL on ARM. In particular this provides an efficient way to retrieve the TLS value and perform atomic operations without any instruction emulation nor special system call. This even allows for pre ARMv6 binaries to be forward compatible with SMP systems without any penalty. The problematic and performance critical operations are performed through segment of kernel provided user code reachable from user space at a fixed address in kernel memory. Those fixed entry points are within the vector page so we basically get it for free as no extra memory page is required and nothing else may be mapped at that location anyway. This is different from (but doesn't preclude) a full blown VDSO implementation, however a VDSO would prevent some assembly tricks with constants that allows for efficient branching to those code segments. And since those code segments only use a few cycles before returning to user code, the overhead of a VDSO far call would add a significant overhead to such minimalistic operations. The ARM_NR_set_tls syscall also changed number. This is done for two reasons: 1) this patch changes the way the TLS value was previously meant to be retrieved, therefore we ensure whatever library using the old way gets fixed (they only exist in private tree at the moment since the NPTL work is still progressing). 2) the previous number was allocated in a range causing an undefined instruction trap on kernels not supporting that syscall and it was determined that allocating it in a range returning -ENOSYS would be much nicer for libraries trying to determine if the feature is present or not. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29 21:08:33 +00:00
help
This selects support for the CP15 thread register.
It is defined to be available on some ARMv6 processors (including
all SMP capable ARMv6's) or later processors. User space may
assume directly accessing that register and always obtain the
expected value only on ARMv7 and above.
[PATCH] ARM: 2651/3: kernel helpers for NPTL support Patch from Nicolas Pitre This patch entirely reworks the kernel assistance for NPTL on ARM. In particular this provides an efficient way to retrieve the TLS value and perform atomic operations without any instruction emulation nor special system call. This even allows for pre ARMv6 binaries to be forward compatible with SMP systems without any penalty. The problematic and performance critical operations are performed through segment of kernel provided user code reachable from user space at a fixed address in kernel memory. Those fixed entry points are within the vector page so we basically get it for free as no extra memory page is required and nothing else may be mapped at that location anyway. This is different from (but doesn't preclude) a full blown VDSO implementation, however a VDSO would prevent some assembly tricks with constants that allows for efficient branching to those code segments. And since those code segments only use a few cycles before returning to user code, the overhead of a VDSO far call would add a significant overhead to such minimalistic operations. The ARM_NR_set_tls syscall also changed number. This is done for two reasons: 1) this patch changes the way the TLS value was previously meant to be retrieved, therefore we ensure whatever library using the old way gets fixed (they only exist in private tree at the moment since the NPTL work is still progressing). 2) the previous number was allocated in a range causing an undefined instruction trap on kernels not supporting that syscall and it was determined that allocating it in a range returning -ENOSYS would be much nicer for libraries trying to determine if the feature is present or not. Signed-off-by: Nicolas Pitre Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-29 21:08:33 +00:00
config NEEDS_SYSCALL_FOR_CMPXCHG
bool
help
SMP on a pre-ARMv6 processor? Well OK then.
Forget about fast user space cmpxchg support.
It is just not possible.
config OUTER_CACHE
bool
config OUTER_CACHE_SYNC
bool
help
The outer cache has a outer_cache_fns.sync function pointer
that can be used to drain the write buffer of the outer cache.
config CACHE_FEROCEON_L2
bool "Enable the Feroceon L2 cache controller"
depends on ARCH_KIRKWOOD || ARCH_MV78XX0
default y
select OUTER_CACHE
help
This option enables the Feroceon L2 cache controller.
config CACHE_FEROCEON_L2_WRITETHROUGH
bool "Force Feroceon L2 cache write through"
depends on CACHE_FEROCEON_L2
help
Say Y here to use the Feroceon L2 cache in writethrough mode.
Unless you specifically require this, say N for writeback mode.
config CACHE_L2X0
bool "Enable the L2x0 outer cache controller"
depends on REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || MACH_REALVIEW_PB1176 || \
REALVIEW_EB_A9MP || ARCH_MX35 || ARCH_MX31 || MACH_REALVIEW_PBX || \
ARCH_NOMADIK || ARCH_OMAP4 || ARCH_U8500 || ARCH_VEXPRESS_CA9X4
default y
select OUTER_CACHE
select OUTER_CACHE_SYNC
help
This option enables the L2x0 PrimeCell.
[ARM] pxa: add support for L2 outer cache on XScale3 (attempt 2) (20072fd0c93349e19527dd2fa9588b4335960e62 lost most of its changes somehow, came from a mbox archive applied with git-am. No idea what happened. This puts back the missing bits. --rmk) The initial patch from Lothar, and Lennert make it into a cleaner one, modified and tested on PXA320 by Eric Miao. This patch moves the L2 cache operations out of proc-xsc3.S into dedicated outer cache support code. CACHE_XSC3L2 can be deselected so no L2 cache specific code will be linked in, and that L2 enable bit will not be set, this applies to the following cases: a. _only_ PXA300/PXA310 support included and no L2 cache wanted b. PXA320 support included, but want L2 be disabled So the enabling of L2 depends on two things: - CACHE_XSC3L2 is selected - and L2 cache is present Where the latter is only a safeguard (previous testing shows it works OK even when this bit is turned on). IXP series of processors with XScale3 cannot disable L2 cache for the moment since they depend on the L2 cache for its coherent memory, so IXP may always select CACHE_XSC3L2. Other L2 relevant bits are always turned on (i.e. the original code enclosed by #if L2_CACHE_ENABLED .. #endif), as they showed no side effects. Specifically, these bits are: - OC bits in TTBASE register (table walk outer cache attributes) - LLR Outer Cache Attributes (OC) in Auxiliary Control Register Signed-off-by: Lothar WaÃ<9f>mann <LW@KARO-electronics.de> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-06-06 08:34:03 +00:00
config CACHE_TAUROS2
bool "Enable the Tauros2 L2 cache controller"
depends on (ARCH_DOVE || ARCH_MMP)
default y
select OUTER_CACHE
help
This option enables the Tauros2 L2 cache controller (as
found on PJ1/PJ4).
[ARM] pxa: add support for L2 outer cache on XScale3 (attempt 2) (20072fd0c93349e19527dd2fa9588b4335960e62 lost most of its changes somehow, came from a mbox archive applied with git-am. No idea what happened. This puts back the missing bits. --rmk) The initial patch from Lothar, and Lennert make it into a cleaner one, modified and tested on PXA320 by Eric Miao. This patch moves the L2 cache operations out of proc-xsc3.S into dedicated outer cache support code. CACHE_XSC3L2 can be deselected so no L2 cache specific code will be linked in, and that L2 enable bit will not be set, this applies to the following cases: a. _only_ PXA300/PXA310 support included and no L2 cache wanted b. PXA320 support included, but want L2 be disabled So the enabling of L2 depends on two things: - CACHE_XSC3L2 is selected - and L2 cache is present Where the latter is only a safeguard (previous testing shows it works OK even when this bit is turned on). IXP series of processors with XScale3 cannot disable L2 cache for the moment since they depend on the L2 cache for its coherent memory, so IXP may always select CACHE_XSC3L2. Other L2 relevant bits are always turned on (i.e. the original code enclosed by #if L2_CACHE_ENABLED .. #endif), as they showed no side effects. Specifically, these bits are: - OC bits in TTBASE register (table walk outer cache attributes) - LLR Outer Cache Attributes (OC) in Auxiliary Control Register Signed-off-by: Lothar WaÃ<9f>mann <LW@KARO-electronics.de> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-06-06 08:34:03 +00:00
config CACHE_XSC3L2
bool "Enable the L2 cache on XScale3"
depends on CPU_XSC3
default y
select OUTER_CACHE
help
This option enables the L2 cache on XScale3.
config ARM_L1_CACHE_SHIFT
int
default 6 if ARM_L1_CACHE_SHIFT_6
default 5
config ARM_DMA_MEM_BUFFERABLE
bool "Use non-cacheable memory for DMA" if CPU_V6 && !CPU_V7
default y if CPU_V6 || CPU_V7
help
Historically, the kernel has used strongly ordered mappings to
provide DMA coherent memory. With the advent of ARMv7, mapping
memory with differing types results in unpredictable behaviour,
so on these CPUs, this option is forced on.
Multiple mappings with differing attributes is also unpredictable
on ARMv6 CPUs, but since they do not have aggressive speculative
prefetch, no harm appears to occur.
However, drivers may be missing the necessary barriers for ARMv6,
and therefore turning this on may result in unpredictable driver
behaviour. Therefore, we offer this as an option.
You are recommended say 'Y' here and debug any affected drivers.
config ARCH_HAS_BARRIERS
bool
help
This option allows the use of custom mandatory barriers
included via the mach/barriers.h file.