linux/arch/sparc/Kconfig

569 lines
13 KiB
Plaintext
Raw Normal View History

# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux/SPARC Kernel Configuration"
config 64BIT
bool "64-bit kernel" if ARCH = "sparc"
default ARCH = "sparc64"
help
SPARC is a family of RISC microprocessors designed and marketed by
Sun Microsystems, incorporated. They are very widely found in Sun
workstations and clones.
Say yes to build a 64-bit kernel - formerly known as sparc64
Say no to build a 32-bit kernel - formerly known as sparc
config SPARC
bool
default y
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_ARCH_KGDB if !SMP || SPARC64
select HAVE_ARCH_TRACEHOOK
select ARCH_WANT_OPTIONAL_GPIOLIB
select RTC_CLASS
select RTC_DRV_M48T59
perf: Do the big rename: Performance Counters -> Performance Events Bye-bye Performance Counters, welcome Performance Events! In the past few months the perfcounters subsystem has grown out its initial role of counting hardware events, and has become (and is becoming) a much broader generic event enumeration, reporting, logging, monitoring, analysis facility. Naming its core object 'perf_counter' and naming the subsystem 'perfcounters' has become more and more of a misnomer. With pending code like hw-breakpoints support the 'counter' name is less and less appropriate. All in one, we've decided to rename the subsystem to 'performance events' and to propagate this rename through all fields, variables and API names. (in an ABI compatible fashion) The word 'event' is also a bit shorter than 'counter' - which makes it slightly more convenient to write/handle as well. Thanks goes to Stephane Eranian who first observed this misnomer and suggested a rename. User-space tooling and ABI compatibility is not affected - this patch should be function-invariant. (Also, defconfigs were not touched to keep the size down.) This patch has been generated via the following script: FILES=$(find * -type f | grep -vE 'oprofile|[^K]config') sed -i \ -e 's/PERF_EVENT_/PERF_RECORD_/g' \ -e 's/PERF_COUNTER/PERF_EVENT/g' \ -e 's/perf_counter/perf_event/g' \ -e 's/nb_counters/nb_events/g' \ -e 's/swcounter/swevent/g' \ -e 's/tpcounter_event/tp_event/g' \ $FILES for N in $(find . -name perf_counter.[ch]); do M=$(echo $N | sed 's/perf_counter/perf_event/g') mv $N $M done FILES=$(find . -name perf_event.*) sed -i \ -e 's/COUNTER_MASK/REG_MASK/g' \ -e 's/COUNTER/EVENT/g' \ -e 's/\<event\>/event_id/g' \ -e 's/counter/event/g' \ -e 's/Counter/Event/g' \ $FILES ... to keep it as correct as possible. This script can also be used by anyone who has pending perfcounters patches - it converts a Linux kernel tree over to the new naming. We tried to time this change to the point in time where the amount of pending patches is the smallest: the end of the merge window. Namespace clashes were fixed up in a preparatory patch - and some stylistic fallout will be fixed up in a subsequent patch. ( NOTE: 'counters' are still the proper terminology when we deal with hardware registers - and these sed scripts are a bit over-eager in renaming them. I've undone some of that, but in case there's something left where 'counter' would be better than 'event' we can undo that on an individual basis instead of touching an otherwise nicely automated patch. ) Suggested-by: Stephane Eranian <eranian@google.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Paul Mackerras <paulus@samba.org> Reviewed-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David Howells <dhowells@redhat.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <linux-arch@vger.kernel.org> LKML-Reference: <new-submission> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-21 10:02:48 +00:00
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
config SPARC32
def_bool !64BIT
config SPARC64
def_bool 64BIT
select ARCH_SUPPORTS_MSI
select HAVE_FUNCTION_TRACER
select HAVE_KRETPROBES
select HAVE_KPROBES
select HAVE_LMB
select HAVE_SYSCALL_WRAPPERS
select HAVE_DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_SYSCALL_TRACEPOINTS
select USE_GENERIC_SMP_HELPERS if SMP
select RTC_DRV_CMOS
select RTC_DRV_BQ4802
select RTC_DRV_SUN4V
select RTC_DRV_STARFIRE
perf: Do the big rename: Performance Counters -> Performance Events Bye-bye Performance Counters, welcome Performance Events! In the past few months the perfcounters subsystem has grown out its initial role of counting hardware events, and has become (and is becoming) a much broader generic event enumeration, reporting, logging, monitoring, analysis facility. Naming its core object 'perf_counter' and naming the subsystem 'perfcounters' has become more and more of a misnomer. With pending code like hw-breakpoints support the 'counter' name is less and less appropriate. All in one, we've decided to rename the subsystem to 'performance events' and to propagate this rename through all fields, variables and API names. (in an ABI compatible fashion) The word 'event' is also a bit shorter than 'counter' - which makes it slightly more convenient to write/handle as well. Thanks goes to Stephane Eranian who first observed this misnomer and suggested a rename. User-space tooling and ABI compatibility is not affected - this patch should be function-invariant. (Also, defconfigs were not touched to keep the size down.) This patch has been generated via the following script: FILES=$(find * -type f | grep -vE 'oprofile|[^K]config') sed -i \ -e 's/PERF_EVENT_/PERF_RECORD_/g' \ -e 's/PERF_COUNTER/PERF_EVENT/g' \ -e 's/perf_counter/perf_event/g' \ -e 's/nb_counters/nb_events/g' \ -e 's/swcounter/swevent/g' \ -e 's/tpcounter_event/tp_event/g' \ $FILES for N in $(find . -name perf_counter.[ch]); do M=$(echo $N | sed 's/perf_counter/perf_event/g') mv $N $M done FILES=$(find . -name perf_event.*) sed -i \ -e 's/COUNTER_MASK/REG_MASK/g' \ -e 's/COUNTER/EVENT/g' \ -e 's/\<event\>/event_id/g' \ -e 's/counter/event/g' \ -e 's/Counter/Event/g' \ $FILES ... to keep it as correct as possible. This script can also be used by anyone who has pending perfcounters patches - it converts a Linux kernel tree over to the new naming. We tried to time this change to the point in time where the amount of pending patches is the smallest: the end of the merge window. Namespace clashes were fixed up in a preparatory patch - and some stylistic fallout will be fixed up in a subsequent patch. ( NOTE: 'counters' are still the proper terminology when we deal with hardware registers - and these sed scripts are a bit over-eager in renaming them. I've undone some of that, but in case there's something left where 'counter' would be better than 'event' we can undo that on an individual basis instead of touching an otherwise nicely automated patch. ) Suggested-by: Stephane Eranian <eranian@google.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Paul Mackerras <paulus@samba.org> Reviewed-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: David Howells <dhowells@redhat.com> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <linux-arch@vger.kernel.org> LKML-Reference: <new-submission> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-21 10:02:48 +00:00
select HAVE_PERF_EVENTS
select PERF_USE_VMALLOC
config ARCH_DEFCONFIG
string
default "arch/sparc/configs/sparc32_defconfig" if SPARC32
default "arch/sparc/configs/sparc64_defconfig" if SPARC64
# CONFIG_BITS can be used at source level to get 32/64 bits
config BITS
int
default 32 if SPARC32
default 64 if SPARC64
config GENERIC_TIME
def_bool y
config ARCH_USES_GETTIMEOFFSET
bool
default y if SPARC32
config GENERIC_CMOS_UPDATE
bool
default y if SPARC64
config GENERIC_CLOCKEVENTS
bool
default y if SPARC64
config IOMMU_HELPER
bool
default y if SPARC64
config QUICKLIST
bool
default y if SPARC64
config STACKTRACE_SUPPORT
bool
default y if SPARC64
config LOCKDEP_SUPPORT
bool
default y if SPARC64
config HAVE_LATENCYTOP_SUPPORT
bool
default y if SPARC64
config AUDIT_ARCH
bool
default y
config HAVE_SETUP_PER_CPU_AREA
def_bool y if SPARC64
config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool y if SPARC64
config NEED_PER_CPU_PAGE_FIRST_CHUNK
def_bool y if SPARC64
config GENERIC_HARDIRQS_NO__DO_IRQ
bool
def_bool y if SPARC64
config MMU
bool
default y
config HIGHMEM
bool
default y if SPARC32
config ZONE_DMA
bool
default y if SPARC32
config GENERIC_ISA_DMA
bool
default y if SPARC32
config GENERIC_GPIO
bool
help
Generic GPIO API support
config ARCH_NO_VIRT_TO_BUS
def_bool y
config OF
def_bool y
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y if SPARC64
source "init/Kconfig"
container freezer: implement freezer cgroup subsystem This patch implements a new freezer subsystem in the control groups framework. It provides a way to stop and resume execution of all tasks in a cgroup by writing in the cgroup filesystem. The freezer subsystem in the container filesystem defines a file named freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the cgroup. Subsequently writing "RUNNING" will unfreeze the tasks in the cgroup. Reading will return the current state. * Examples of usage : # mkdir /containers/freezer # mount -t cgroup -ofreezer freezer /containers # mkdir /containers/0 # echo $some_pid > /containers/0/tasks to get status of the freezer subsystem : # cat /containers/0/freezer.state RUNNING to freeze all tasks in the container : # echo FROZEN > /containers/0/freezer.state # cat /containers/0/freezer.state FREEZING # cat /containers/0/freezer.state FROZEN to unfreeze all tasks in the container : # echo RUNNING > /containers/0/freezer.state # cat /containers/0/freezer.state RUNNING This is the basic mechanism which should do the right thing for user space task in a simple scenario. It's important to note that freezing can be incomplete. In that case we return EBUSY. This means that some tasks in the cgroup are busy doing something that prevents us from completely freezing the cgroup at this time. After EBUSY, the cgroup will remain partially frozen -- reflected by freezer.state reporting "FREEZING" when read. The state will remain "FREEZING" until one of these things happens: 1) Userspace cancels the freezing operation by writing "RUNNING" to the freezer.state file 2) Userspace retries the freezing operation by writing "FROZEN" to the freezer.state file (writing "FREEZING" is not legal and returns EIO) 3) The tasks that blocked the cgroup from entering the "FROZEN" state disappear from the cgroup's set of tasks. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: export thaw_process] Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Matt Helsley <matthltc@us.ibm.com> Acked-by: Serge E. Hallyn <serue@us.ibm.com> Tested-by: Matt Helsley <matthltc@us.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-19 03:27:21 +00:00
source "kernel/Kconfig.freezer"
menu "Processor type and features"
config SMP
bool "Symmetric multi-processing support (does not work on sun4/sun4c)"
---help---
This enables support for systems with more than one CPU. If you have
a system with only one CPU, say N. If you have a system with more
than one CPU, say Y.
If you say N here, the kernel will run on single and multiprocessor
machines, but will use only one CPU of a multiprocessor machine. If
you say Y here, the kernel will run on many, but not all,
singleprocessor machines. On a singleprocessor machine, the kernel
will run faster if you say N here.
People using multiprocessor machines who say Y here should also say
Y to "Enhanced Real Time Clock Support", below. The "Advanced Power
Management" code will be disabled if you say Y here.
See also <file:Documentation/nmi_watchdog.txt> and the SMP-HOWTO
available at <http://www.tldp.org/docs.html#howto>.
If you don't know what to do here, say N.
config NR_CPUS
int "Maximum number of CPUs"
depends on SMP
range 2 32 if SPARC32
range 2 1024 if SPARC64
default 32 if SPARC32
default 64 if SPARC64
source kernel/Kconfig.hz
config RWSEM_GENERIC_SPINLOCK
bool
default y if SPARC32
config RWSEM_XCHGADD_ALGORITHM
bool
default y if SPARC64
config GENERIC_FIND_NEXT_BIT
bool
default y
config GENERIC_HWEIGHT
bool
default y if !ULTRA_HAS_POPULATION_COUNT
config GENERIC_CALIBRATE_DELAY
bool
default y
config ARCH_MAY_HAVE_PC_FDC
bool
default y
config EMULATED_CMPXCHG
bool
default y if SPARC32
help
Sparc32 does not have a CAS instruction like sparc64. cmpxchg()
is emulated, and therefore it is not completely atomic.
# Makefile helpers
config SPARC32_SMP
bool
default y
depends on SPARC32 && SMP
config SPARC64_SMP
bool
default y
depends on SPARC64 && SMP
config EARLYFB
bool "Support for early boot text console"
default y
depends on SPARC64
help
Say Y here to enable a faster early framebuffer boot console.
choice
prompt "Kernel page size" if SPARC64
default SPARC64_PAGE_SIZE_8KB
config SPARC64_PAGE_SIZE_8KB
bool "8KB"
help
This lets you select the page size of the kernel.
8KB and 64KB work quite well, since SPARC ELF sections
provide for up to 64KB alignment.
If you don't know what to do, choose 8KB.
config SPARC64_PAGE_SIZE_64KB
bool "64KB"
endchoice
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on SPARC64 && PROC_FS
default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
execution. By using pipes or other transports made available to
the process as file descriptors supporting the read/write
syscalls, it's possible to isolate those applications in
their own address space using seccomp. Once seccomp is
enabled via /proc/<pid>/seccomp, it cannot be disabled
and the task is only allowed to execute a few safe syscalls
defined by each seccomp mode.
If unsure, say Y. Only embedded should say N here.
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SPARC64 && SMP
select HOTPLUG
help
Say Y here to experiment with turning CPUs off and on. CPUs
can be controlled through /sys/devices/system/cpu/cpu#.
Say N if you want to disable CPU hotplug.
config GENERIC_HARDIRQS
bool
default y if SPARC64
source "kernel/time/Kconfig"
if SPARC64
source "drivers/cpufreq/Kconfig"
config US3_FREQ
tristate "UltraSPARC-III CPU Frequency driver"
depends on CPU_FREQ
select CPU_FREQ_TABLE
help
This adds the CPUFreq driver for UltraSPARC-III processors.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
config US2E_FREQ
tristate "UltraSPARC-IIe CPU Frequency driver"
depends on CPU_FREQ
select CPU_FREQ_TABLE
help
This adds the CPUFreq driver for UltraSPARC-IIe processors.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
endif
config US3_MC
tristate "UltraSPARC-III Memory Controller driver"
depends on SPARC64
default y
help
This adds a driver for the UltraSPARC-III memory controller.
Loading this driver allows exact mnemonic strings to be
printed in the event of a memory error, so that the faulty DIMM
on the motherboard can be matched to the error.
If in doubt, say Y, as this information can be very useful.
# Global things across all Sun machines.
config GENERIC_LOCKBREAK
bool
default y
depends on SPARC64 && SMP && PREEMPT
choice
prompt "SPARC64 Huge TLB Page Size"
depends on SPARC64 && HUGETLB_PAGE
default HUGETLB_PAGE_SIZE_4MB
config HUGETLB_PAGE_SIZE_4MB
bool "4MB"
config HUGETLB_PAGE_SIZE_512K
bool "512K"
config HUGETLB_PAGE_SIZE_64K
depends on !SPARC64_PAGE_SIZE_64KB
bool "64K"
endchoice
config NUMA
bool "NUMA support"
depends on SPARC64 && SMP
config NODES_SHIFT
int
default "4"
depends on NEED_MULTIPLE_NODES
# Some NUMA nodes have memory ranges that span
# other nodes. Even though a pfn is valid and
# between a node's start and end pfns, it may not
# reside on that node. See memmap_init_zone()
# for details.
config NODES_SPAN_OTHER_NODES
def_bool y
depends on NEED_MULTIPLE_NODES
config ARCH_POPULATES_NODE_MAP
def_bool y if SPARC64
config ARCH_SELECT_MEMORY_MODEL
def_bool y if SPARC64
config ARCH_SPARSEMEM_ENABLE
def_bool y if SPARC64
select SPARSEMEM_VMEMMAP_ENABLE
config ARCH_SPARSEMEM_DEFAULT
def_bool y if SPARC64
source "mm/Kconfig"
config SCHED_SMT
bool "SMT (Hyperthreading) scheduler support"
depends on SPARC64 && SMP
default y
help
SMT scheduler support improves the CPU scheduler's decision making
when dealing with SPARC cpus at a cost of slightly increased overhead
in some places. If unsure say N here.
config SCHED_MC
bool "Multi-core scheduler support"
depends on SPARC64 && SMP
default y
help
Multi-core scheduler support improves the CPU scheduler's decision
making when dealing with multi-core CPU chips at a cost of slightly
increased overhead in some places. If unsure say N here.
if SPARC64
source "kernel/Kconfig.preempt"
endif
config CMDLINE_BOOL
bool "Default bootloader kernel arguments"
depends on SPARC64
config CMDLINE
string "Initial kernel command string"
depends on CMDLINE_BOOL
default "console=ttyS0,9600 root=/dev/sda1"
help
Say Y here if you want to be able to pass default arguments to
the kernel. This will be overridden by the bootloader, if you
use one (such as SILO). This is most useful if you want to boot
a kernel from TFTP, and want default options to be available
with having them passed on the command line.
NOTE: This option WILL override the PROM bootargs setting!
config SUN_PM
bool
default y if SPARC32
help
Enable power management and CPU standby features on supported
SPARC platforms.
config SPARC_LED
tristate "Sun4m LED driver"
depends on SPARC32
help
This driver toggles the front-panel LED on sun4m systems
in a user-specifiable manner. Its state can be probed
by reading /proc/led and its blinking mode can be changed
via writes to /proc/led
config SERIAL_CONSOLE
bool
depends on SPARC32
default y
---help---
If you say Y here, it will be possible to use a serial port as the
system console (the system console is the device which receives all
kernel messages and warnings and which allows logins in single user
mode). This could be useful if some terminal or printer is connected
to that serial port.
Even if you say Y here, the currently visible virtual console
(/dev/tty0) will still be used as the system console by default, but
you can alter that using a kernel command line option such as
"console=ttyS1". (Try "man bootparam" or see the documentation of
your boot loader (silo) about how to pass options to the kernel at
boot time.)
If you don't have a graphics card installed and you say Y here, the
kernel will automatically use the first serial line, /dev/ttyS0, as
system console.
If unsure, say N.
config SPARC_LEON
bool "Sparc Leon processor family"
depends on SPARC32
---help---
If you say Y here if you are running on a SPARC-LEON processor.
The LEON processor is a synthesizable VHDL model of the
SPARC-v8 standard. LEON is part of the GRLIB collection of
IP cores that are distributed under GPL. GRLIB can be downloaded
from www.gaisler.com. You can download a sparc-linux cross-compilation
toolchain at www.gaisler.com.
endmenu
menu "Bus options (PCI etc.)"
config SBUS
bool
default y
config SBUSCHAR
bool
default y
config SUN_LDOMS
bool "Sun Logical Domains support"
depends on SPARC64
help
Say Y here is you want to support virtual devices via
Logical Domains.
config PCI
bool "Support for PCI and PS/2 keyboard/mouse"
help
Find out whether your system includes a PCI bus. PCI is the name of
a bus system, i.e. the way the CPU talks to the other stuff inside
your box. If you say Y here, the kernel will include drivers and
infrastructure code to support PCI bus devices.
CONFIG_PCI is needed for all JavaStation's (including MrCoffee),
CP-1200, JavaEngine-1, Corona, Red October, and Serengeti SGSC.
All of these platforms are extremely obscure, so say N if unsure.
config PCI_DOMAINS
def_bool PCI if SPARC64
config PCI_SYSCALL
def_bool PCI
source "drivers/pci/Kconfig"
source "drivers/pcmcia/Kconfig"
config SUN_OPENPROMFS
tristate "Openprom tree appears in /proc/openprom"
help
If you say Y, the OpenPROM device tree will be available as a
virtual file system, which you can mount to /proc/openprom by "mount
-t openpromfs none /proc/openprom".
To compile the /proc/openprom support as a module, choose M here: the
module will be called openpromfs.
Only choose N if you know in advance that you will not need to modify
OpenPROM settings on the running system.
# Makefile helpers
config SPARC32_PCI
bool
default y
depends on SPARC32 && PCI
config SPARC64_PCI
bool
default y
depends on SPARC64 && PCI
endmenu
menu "Executable file formats"
source "fs/Kconfig.binfmt"
config COMPAT
bool
depends on SPARC64
default y
select COMPAT_BINFMT_ELF
config SYSVIPC_COMPAT
bool
depends on COMPAT && SYSVIPC
default y
endmenu
source "net/Kconfig"
source "drivers/Kconfig"
source "drivers/sbus/char/Kconfig"
source "fs/Kconfig"
source "arch/sparc/Kconfig.debug"
source "security/Kconfig"
source "crypto/Kconfig"
source "lib/Kconfig"