2010-05-29 03:09:12 +00:00
|
|
|
# For a description of the syntax of this configuration file,
|
2011-02-28 20:58:39 +00:00
|
|
|
# see Documentation/kbuild/kconfig-language.txt.
|
2010-05-29 03:09:12 +00:00
|
|
|
|
2011-01-19 19:44:43 +00:00
|
|
|
config TILE
|
2010-05-29 03:09:12 +00:00
|
|
|
def_bool y
|
2012-06-15 19:23:06 +00:00
|
|
|
select HAVE_DMA_ATTRS
|
|
|
|
|
select HAVE_DMA_API_DEBUG
|
2011-01-19 19:44:43 +00:00
|
|
|
select HAVE_KVM if !TILEGX
|
|
|
|
|
select GENERIC_FIND_FIRST_BIT
|
2012-10-08 23:28:16 +00:00
|
|
|
select SYSCTL_EXCEPTION_TRACE
|
2011-01-19 19:44:43 +00:00
|
|
|
select USE_GENERIC_SMP_HELPERS
|
|
|
|
|
select CC_OPTIMIZE_FOR_SIZE
|
2012-10-08 23:28:11 +00:00
|
|
|
select HAVE_DEBUG_KMEMLEAK
|
2011-01-19 19:44:43 +00:00
|
|
|
select HAVE_GENERIC_HARDIRQS
|
|
|
|
|
select GENERIC_IRQ_PROBE
|
|
|
|
|
select GENERIC_PENDING_IRQ if SMP
|
2011-03-25 14:21:17 +00:00
|
|
|
select GENERIC_IRQ_SHOW
|
2012-10-08 23:28:13 +00:00
|
|
|
select HAVE_DEBUG_BUGVERBOSE
|
2013-03-07 04:48:16 +00:00
|
|
|
select VIRT_TO_BUS
|
arch/tile: more /proc and /sys file support
This change introduces a few of the less controversial /proc and
/proc/sys interfaces for tile, along with sysfs attributes for
various things that were originally proposed as /proc/tile files.
It also adjusts the "hardwall" proc API.
Arnd Bergmann reviewed the initial arch/tile submission, which
included a complete set of all the /proc/tile and /proc/sys/tile
knobs that we had added in a somewhat ad hoc way during initial
development, and provided feedback on where most of them should go.
One knob turned out to be similar enough to the existing
/proc/sys/debug/exception-trace that it was re-implemented to use
that model instead.
Another knob was /proc/tile/grid, which reported the "grid" dimensions
of a tile chip (e.g. 8x8 processors = 64-core chip). Arnd suggested
looking at sysfs for that, so this change moves that information
to a pair of sysfs attributes (chip_width and chip_height) in the
/sys/devices/system/cpu directory. We also put the "chip_serial"
and "chip_revision" information from our old /proc/tile/board file
as attributes in /sys/devices/system/cpu.
Other information collected via hypervisor APIs is now placed in
/sys/hypervisor. We create a /sys/hypervisor/type file (holding the
constant string "tilera") to be parallel with the Xen use of
/sys/hypervisor/type holding "xen". We create three top-level files,
"version" (the hypervisor's own version), "config_version" (the
version of the configuration file), and "hvconfig" (the contents of
the configuration file). The remaining information from our old
/proc/tile/board and /proc/tile/switch files becomes an attribute
group appearing under /sys/hypervisor/board/.
Finally, after some feedback from Arnd Bergmann for the previous
version of this patch, the /proc/tile/hardwall file is split up into
two conceptual parts. First, a directory /proc/tile/hardwall/ which
contains one file per active hardwall, each file named after the
hardwall's ID and holding a cpulist that says which cpus are enclosed by
the hardwall. Second, a /proc/PID file "hardwall" that is either
empty (for non-hardwall-using processes) or contains the hardwall ID.
Finally, this change pushes the /proc/sys/tile/unaligned_fixup/
directory, with knobs controlling the kernel code for handling the
fixup of unaligned exceptions.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2011-05-26 16:40:09 +00:00
|
|
|
select SYS_HYPERVISOR
|
2013-04-30 22:28:42 +00:00
|
|
|
select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
|
2012-03-27 17:47:57 +00:00
|
|
|
select ARCH_HAVE_NMI_SAFE_CMPXCHG
|
2012-05-18 16:45:54 +00:00
|
|
|
select GENERIC_CLOCKEVENTS
|
2012-09-28 05:01:03 +00:00
|
|
|
select MODULES_USE_ELF_RELA
|
2012-12-22 05:21:12 +00:00
|
|
|
select HAVE_ARCH_TRACEHOOK
|
2013-01-22 00:54:57 +00:00
|
|
|
select HAVE_SYSCALL_TRACEPOINTS
|
2013-02-01 17:37:48 +00:00
|
|
|
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
|
2010-05-29 03:09:12 +00:00
|
|
|
|
2011-01-19 19:44:43 +00:00
|
|
|
# FIXME: investigate whether we need/want these options.
|
|
|
|
|
# select HAVE_IOREMAP_PROT
|
2011-02-28 20:58:39 +00:00
|
|
|
# select HAVE_OPTPROBES
|
|
|
|
|
# select HAVE_REGS_AND_STACK_ACCESS_API
|
|
|
|
|
# select HAVE_HW_BREAKPOINT
|
|
|
|
|
# select PERF_EVENTS
|
|
|
|
|
# select HAVE_USER_RETURN_NOTIFIER
|
|
|
|
|
# config NO_BOOTMEM
|
|
|
|
|
# config ARCH_SUPPORTS_DEBUG_PAGEALLOC
|
|
|
|
|
# config HUGETLB_PAGE_SIZE_VARIABLE
|
2010-05-29 03:09:12 +00:00
|
|
|
|
2011-01-19 19:44:43 +00:00
|
|
|
config MMU
|
2010-05-29 03:09:12 +00:00
|
|
|
def_bool y
|
|
|
|
|
|
2011-01-19 19:44:43 +00:00
|
|
|
config GENERIC_CSUM
|
2010-05-29 03:09:12 +00:00
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config HAVE_ARCH_ALLOC_REMAP
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config HAVE_SETUP_PER_CPU_AREA
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config NEED_PER_CPU_PAGE_FIRST_CHUNK
|
2011-02-28 20:58:39 +00:00
|
|
|
def_bool y
|
2010-05-29 03:09:12 +00:00
|
|
|
|
|
|
|
|
config SYS_SUPPORTS_HUGETLBFS
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2012-04-01 18:04:21 +00:00
|
|
|
# Support for additional huge page sizes besides HPAGE_SIZE.
|
|
|
|
|
# The software support is currently only present in the TILE-Gx
|
|
|
|
|
# hypervisor. TILEPro in any case does not support page sizes
|
|
|
|
|
# larger than the default HPAGE_SIZE.
|
|
|
|
|
config HUGETLB_SUPER_PAGES
|
|
|
|
|
depends on HUGETLB_PAGE && TILEGX
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2011-03-31 01:57:33 +00:00
|
|
|
# FIXME: tilegx can implement a more efficient rwsem.
|
2010-05-29 03:09:12 +00:00
|
|
|
config RWSEM_GENERIC_SPINLOCK
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
# We only support gcc 4.4 and above, so this should work.
|
|
|
|
|
config ARCH_SUPPORTS_OPTIMIZED_INLINING
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config ARCH_PHYS_ADDR_T_64BIT
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2010-10-27 22:32:58 +00:00
|
|
|
config ARCH_DMA_ADDR_T_64BIT
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2012-03-27 17:53:30 +00:00
|
|
|
config NEED_DMA_MAP_STATE
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2012-06-15 19:23:06 +00:00
|
|
|
config ARCH_HAS_DMA_SET_COHERENT_MASK
|
|
|
|
|
bool
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
config LOCKDEP_SUPPORT
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config STACKTRACE_SUPPORT
|
|
|
|
|
def_bool y
|
|
|
|
|
select STACKTRACE
|
|
|
|
|
|
|
|
|
|
# We use discontigmem for now; at some point we may want to switch
|
|
|
|
|
# to sparsemem (Tilera bug 7996).
|
|
|
|
|
config ARCH_DISCONTIGMEM_ENABLE
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config ARCH_DISCONTIGMEM_DEFAULT
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config TRACE_IRQFLAGS_SUPPORT
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config STRICT_DEVMEM
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
# SMP is required for Tilera Linux.
|
|
|
|
|
config SMP
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config HVC_TILE
|
2013-01-18 06:44:22 +00:00
|
|
|
depends on TTY
|
2010-05-29 03:09:12 +00:00
|
|
|
select HVC_DRIVER
|
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
|
|
config TILEGX
|
|
|
|
|
bool "Building with TILE-Gx (64-bit) compiler and toolchain"
|
|
|
|
|
|
2012-04-07 19:58:24 +00:00
|
|
|
config TILEPRO
|
|
|
|
|
def_bool !TILEGX
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
config 64BIT
|
2012-04-07 19:58:24 +00:00
|
|
|
def_bool TILEGX
|
2010-05-29 03:09:12 +00:00
|
|
|
|
|
|
|
|
config ARCH_DEFCONFIG
|
|
|
|
|
string
|
2012-03-27 17:53:30 +00:00
|
|
|
default "arch/tile/configs/tilepro_defconfig" if !TILEGX
|
2010-05-29 03:09:12 +00:00
|
|
|
default "arch/tile/configs/tilegx_defconfig" if TILEGX
|
|
|
|
|
|
|
|
|
|
source "init/Kconfig"
|
|
|
|
|
|
2013-02-01 02:21:36 +00:00
|
|
|
source "kernel/Kconfig.freezer"
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
menu "Tilera-specific configuration"
|
|
|
|
|
|
|
|
|
|
config NR_CPUS
|
|
|
|
|
int "Maximum number of tiles (2-255)"
|
|
|
|
|
range 2 255
|
|
|
|
|
depends on SMP
|
|
|
|
|
default "64"
|
|
|
|
|
---help---
|
|
|
|
|
Building with 64 is the recommended value, but a slightly
|
|
|
|
|
smaller kernel memory footprint results from using a smaller
|
|
|
|
|
value on chips with fewer tiles.
|
|
|
|
|
|
2012-03-29 17:58:43 +00:00
|
|
|
if TILEGX
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
prompt "Kernel page size"
|
|
|
|
|
default PAGE_SIZE_64KB
|
|
|
|
|
help
|
|
|
|
|
This lets you select the page size of the kernel. For best
|
|
|
|
|
performance on memory-intensive applications, a page size of 64KB
|
|
|
|
|
is recommended. For workloads involving many small files, many
|
|
|
|
|
connections, etc., it may be better to select 16KB, which uses
|
|
|
|
|
memory more efficiently at some cost in TLB performance.
|
|
|
|
|
|
|
|
|
|
Note that this option is TILE-Gx specific; currently
|
|
|
|
|
TILEPro page size is set by rebuilding the hypervisor.
|
|
|
|
|
|
|
|
|
|
config PAGE_SIZE_16KB
|
|
|
|
|
bool "16KB"
|
|
|
|
|
|
|
|
|
|
config PAGE_SIZE_64KB
|
|
|
|
|
bool "64KB"
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
source "kernel/Kconfig.hz"
|
|
|
|
|
|
|
|
|
|
config KEXEC
|
|
|
|
|
bool "kexec system call"
|
|
|
|
|
---help---
|
|
|
|
|
kexec is a system call that implements the ability to shutdown your
|
|
|
|
|
current kernel, and to start another kernel. It is like a reboot
|
|
|
|
|
but it is independent of the system firmware. It is used
|
|
|
|
|
to implement the "mboot" Tilera booter.
|
|
|
|
|
|
|
|
|
|
The name comes from the similarity to the exec system call.
|
|
|
|
|
|
|
|
|
|
config COMPAT
|
|
|
|
|
bool "Support 32-bit TILE-Gx binaries in addition to 64-bit"
|
|
|
|
|
depends on TILEGX
|
|
|
|
|
select COMPAT_BINFMT_ELF
|
|
|
|
|
default y
|
|
|
|
|
---help---
|
|
|
|
|
If enabled, the kernel will support running TILE-Gx binaries
|
|
|
|
|
that were built with the -m32 option.
|
|
|
|
|
|
|
|
|
|
config SYSVIPC_COMPAT
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on COMPAT && SYSVIPC
|
|
|
|
|
|
|
|
|
|
# We do not currently support disabling HIGHMEM on tile64 and tilepro.
|
|
|
|
|
config HIGHMEM
|
|
|
|
|
bool # "Support for more than 512 MB of RAM"
|
|
|
|
|
default !TILEGX
|
|
|
|
|
---help---
|
|
|
|
|
Linux can use the full amount of RAM in the system by
|
|
|
|
|
default. However, the address space of TILE processors is
|
|
|
|
|
only 4 Gigabytes large. That means that, if you have a large
|
|
|
|
|
amount of physical memory, not all of it can be "permanently
|
|
|
|
|
mapped" by the kernel. The physical memory that's not
|
|
|
|
|
permanently mapped is called "high memory".
|
|
|
|
|
|
|
|
|
|
If you are compiling a kernel which will never run on a
|
|
|
|
|
machine with more than 512 MB total physical RAM, answer
|
|
|
|
|
"false" here. This will result in the kernel mapping all of
|
|
|
|
|
physical memory into the top 1 GB of virtual memory space.
|
|
|
|
|
|
|
|
|
|
If unsure, say "true".
|
|
|
|
|
|
2012-05-09 16:26:30 +00:00
|
|
|
config ZONE_DMA
|
|
|
|
|
def_bool y
|
|
|
|
|
|
2012-06-15 19:23:06 +00:00
|
|
|
config IOMMU_HELPER
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config NEED_SG_DMA_LENGTH
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config SWIOTLB
|
|
|
|
|
bool
|
|
|
|
|
default TILEGX
|
|
|
|
|
select IOMMU_HELPER
|
|
|
|
|
select NEED_SG_DMA_LENGTH
|
|
|
|
|
select ARCH_HAS_DMA_SET_COHERENT_MASK
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
# We do not currently support disabling NUMA.
|
|
|
|
|
config NUMA
|
|
|
|
|
bool # "NUMA Memory Allocation and Scheduler Support"
|
|
|
|
|
depends on SMP && DISCONTIGMEM
|
|
|
|
|
default y
|
|
|
|
|
---help---
|
|
|
|
|
NUMA memory allocation is required for TILE processors
|
|
|
|
|
unless booting with memory striping enabled in the
|
|
|
|
|
hypervisor, or with only a single memory controller.
|
|
|
|
|
It is recommended that this option always be enabled.
|
|
|
|
|
|
|
|
|
|
config NODES_SHIFT
|
|
|
|
|
int "Log base 2 of the max number of memory controllers"
|
|
|
|
|
default 2
|
|
|
|
|
depends on NEED_MULTIPLE_NODES
|
|
|
|
|
---help---
|
|
|
|
|
By default, 2, i.e. 2^2 == 4 DDR2 controllers.
|
|
|
|
|
In a system with more controllers, this value should be raised.
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
depends on !TILEGX
|
2011-01-20 22:44:16 +00:00
|
|
|
prompt "Memory split" if EXPERT
|
2010-05-29 03:09:12 +00:00
|
|
|
default VMSPLIT_3G
|
|
|
|
|
---help---
|
|
|
|
|
Select the desired split between kernel and user memory.
|
|
|
|
|
|
|
|
|
|
If the address range available to the kernel is less than the
|
|
|
|
|
physical memory installed, the remaining memory will be available
|
|
|
|
|
as "high memory". Accessing high memory is a little more costly
|
|
|
|
|
than low memory, as it needs to be mapped into the kernel first.
|
|
|
|
|
Note that increasing the kernel address space limits the range
|
|
|
|
|
available to user programs, making the address space there
|
|
|
|
|
tighter. Selecting anything other than the default 3G/1G split
|
|
|
|
|
will also likely make your kernel incompatible with binary-only
|
|
|
|
|
kernel modules.
|
|
|
|
|
|
|
|
|
|
If you are not absolutely sure what you are doing, leave this
|
|
|
|
|
option alone!
|
|
|
|
|
|
2010-09-13 12:50:09 +00:00
|
|
|
config VMSPLIT_3_75G
|
2010-05-29 03:09:12 +00:00
|
|
|
bool "3.75G/0.25G user/kernel split (no kernel networking)"
|
2010-09-13 12:50:09 +00:00
|
|
|
config VMSPLIT_3_5G
|
2010-05-29 03:09:12 +00:00
|
|
|
bool "3.5G/0.5G user/kernel split"
|
|
|
|
|
config VMSPLIT_3G
|
|
|
|
|
bool "3G/1G user/kernel split"
|
2011-02-28 21:01:09 +00:00
|
|
|
config VMSPLIT_2_75G
|
|
|
|
|
bool "2.75G/1.25G user/kernel split (for full 1G low memory)"
|
|
|
|
|
config VMSPLIT_2_5G
|
|
|
|
|
bool "2.5G/1.5G user/kernel split"
|
|
|
|
|
config VMSPLIT_2_25G
|
|
|
|
|
bool "2.25G/1.75G user/kernel split"
|
2010-05-29 03:09:12 +00:00
|
|
|
config VMSPLIT_2G
|
|
|
|
|
bool "2G/2G user/kernel split"
|
|
|
|
|
config VMSPLIT_1G
|
|
|
|
|
bool "1G/3G user/kernel split"
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
config PAGE_OFFSET
|
|
|
|
|
hex
|
2012-03-27 17:56:04 +00:00
|
|
|
depends on !64BIT
|
2010-09-13 12:50:09 +00:00
|
|
|
default 0xF0000000 if VMSPLIT_3_75G
|
|
|
|
|
default 0xE0000000 if VMSPLIT_3_5G
|
2011-02-28 21:01:09 +00:00
|
|
|
default 0xB0000000 if VMSPLIT_2_75G
|
|
|
|
|
default 0xA0000000 if VMSPLIT_2_5G
|
|
|
|
|
default 0x90000000 if VMSPLIT_2_25G
|
2010-05-29 03:09:12 +00:00
|
|
|
default 0x80000000 if VMSPLIT_2G
|
|
|
|
|
default 0x40000000 if VMSPLIT_1G
|
|
|
|
|
default 0xC0000000
|
|
|
|
|
|
|
|
|
|
source "mm/Kconfig"
|
|
|
|
|
|
|
|
|
|
config CMDLINE_BOOL
|
|
|
|
|
bool "Built-in kernel command line"
|
|
|
|
|
default n
|
|
|
|
|
---help---
|
|
|
|
|
Allow for specifying boot arguments to the kernel at
|
|
|
|
|
build time. On some systems (e.g. embedded ones), it is
|
|
|
|
|
necessary or convenient to provide some or all of the
|
|
|
|
|
kernel boot arguments with the kernel itself (that is,
|
|
|
|
|
to not rely on the boot loader to provide them.)
|
|
|
|
|
|
|
|
|
|
To compile command line arguments into the kernel,
|
|
|
|
|
set this option to 'Y', then fill in the
|
|
|
|
|
the boot arguments in CONFIG_CMDLINE.
|
|
|
|
|
|
|
|
|
|
Systems with fully functional boot loaders (e.g. mboot, or
|
|
|
|
|
if booting over PCI) should leave this option set to 'N'.
|
|
|
|
|
|
|
|
|
|
config CMDLINE
|
|
|
|
|
string "Built-in kernel command string"
|
|
|
|
|
depends on CMDLINE_BOOL
|
|
|
|
|
default ""
|
|
|
|
|
---help---
|
|
|
|
|
Enter arguments here that should be compiled into the kernel
|
|
|
|
|
image and used at boot time. If the boot loader provides a
|
|
|
|
|
command line at boot time, it is appended to this string to
|
|
|
|
|
form the full kernel command line, when the system boots.
|
|
|
|
|
|
|
|
|
|
However, you can use the CONFIG_CMDLINE_OVERRIDE option to
|
|
|
|
|
change this behavior.
|
|
|
|
|
|
|
|
|
|
In most cases, the command line (whether built-in or provided
|
|
|
|
|
by the boot loader) should specify the device for the root
|
|
|
|
|
file system.
|
|
|
|
|
|
|
|
|
|
config CMDLINE_OVERRIDE
|
|
|
|
|
bool "Built-in command line overrides boot loader arguments"
|
|
|
|
|
default n
|
|
|
|
|
depends on CMDLINE_BOOL
|
|
|
|
|
---help---
|
|
|
|
|
Set this option to 'Y' to have the kernel ignore the boot loader
|
|
|
|
|
command line, and use ONLY the built-in command line.
|
|
|
|
|
|
|
|
|
|
This is used to work around broken boot loaders. This should
|
|
|
|
|
be set to 'N' under normal conditions.
|
|
|
|
|
|
|
|
|
|
config VMALLOC_RESERVE
|
|
|
|
|
hex
|
|
|
|
|
default 0x1000000
|
|
|
|
|
|
arch/tile: Add driver to enable access to the user dynamic network.
This network (the "UDN") connects all the cpus on the chip in a
wormhole-routed dynamic network. Subrectangles of the chip can
be allocated by a "create" ioctl on /dev/hardwall, and then to access the
UDN in that rectangle, tasks must perform an "activate" ioctl on that
same file object after affinitizing themselves to a single cpu in
the region. Sending a wormhole-routed message that tries to leave
that subrectangle causes all activated tasks to receive a SIGILL
(just as they would if they tried to access the UDN without first
activating themselves to a hardwall rectangle).
The original submission of this code to LKML had the driver
instantiated under /proc/tile/hardwall. Now we just use a character
device for this, conventionally /dev/hardwall. Some futures planning
for the TILE-Gx chip suggests that we may want to have other types of
devices that share the general model of "bind a task to a cpu, then
'activate' a file descriptor on a pseudo-device that gives access to
some hardware resource". As such, we are using a device rather
than, for example, a syscall, to set up and activate this code.
As part of this change, the compat_ptr() declaration was fixed and used
to pass the compat_ioctl argument to the normal ioctl. So far we limit
compat code to 2GB, so the difference between zero-extend and sign-extend
(the latter being correct, eventually) had been overlooked.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
2010-06-25 21:00:56 +00:00
|
|
|
config HARDWALL
|
|
|
|
|
bool "Hardwall support to allow access to user dynamic network"
|
|
|
|
|
default y
|
|
|
|
|
|
2010-10-14 20:23:03 +00:00
|
|
|
config KERNEL_PL
|
|
|
|
|
int "Processor protection level for kernel"
|
|
|
|
|
range 1 2
|
2013-05-02 19:29:04 +00:00
|
|
|
default 2 if TILEGX
|
|
|
|
|
default 1 if !TILEGX
|
2010-10-14 20:23:03 +00:00
|
|
|
---help---
|
2013-05-02 19:29:04 +00:00
|
|
|
Since MDE 4.2, the Tilera hypervisor runs the kernel
|
|
|
|
|
at PL2 by default. If running under an older hypervisor,
|
|
|
|
|
or as a KVM guest, you must run at PL1. (The current
|
|
|
|
|
hypervisor may also be recompiled with "make HV_PL=2" to
|
|
|
|
|
allow it to run a kernel at PL1, but clients running at PL1
|
|
|
|
|
are not expected to be supported indefinitely.)
|
|
|
|
|
|
|
|
|
|
If you're not sure, don't change the default.
|
2010-10-14 20:23:03 +00:00
|
|
|
|
arch/tile: introduce GXIO IORPC framework for tilegx
The GXIO I/O RPC subsystem handles exporting I/O hardware resources to
Linux and to applications running under Linux.
For instance, memory which is made available for I/O DMA must be mapped
by an I/O TLB; that means that such memory must be locked down by Linux,
so that it is not swapped or otherwise reused, as long as those I/O
TLB entries are active. Similarly, configuring direct hardware access
introduces new validation requirements. If a user application registers
memory, Linux must ensure that the supplied virtual addresses are valid,
and turn them into client physical addresses. Similarly, when Linux then
supplies those client physical addresses to the Tilera hypervisor, it
must in turn validate those before turning them into the real physical
addresses which are required by the hardware.
To the extent that these sorts of activities were required on previous
TILE architecture processors, they were implemented in a device-specific
fashion. This meant that every I/O device had its own Tilera hypervisor
driver, its own Linux driver, and in some cases its own user-level
library support. There was a large amount of more-or-less functionally
identical code in different places, particularly in the different Linux
drivers. For TILE-Gx, this support has been generalized into a common
framework, known as the I/O RPC framework or just IORPC.
The two "gxio" directories (one for headers, one for sources) start
with just a few files in each with this infrastructure commit, but
after adding support for the on-board I/O shims for networking, PCI,
USB, crypto, compression, I2CS, etc., there end up being about 20 files
in each directory.
More information on the IORPC framework is in the <hv/iorpc.h> header,
included in this commit.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2012-04-04 20:39:58 +00:00
|
|
|
source "arch/tile/gxio/Kconfig"
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
endmenu # Tilera-specific configuration
|
|
|
|
|
|
|
|
|
|
menu "Bus options"
|
|
|
|
|
|
2010-11-02 16:05:10 +00:00
|
|
|
config PCI
|
|
|
|
|
bool "PCI support"
|
|
|
|
|
default y
|
|
|
|
|
select PCI_DOMAINS
|
2011-11-29 18:42:56 +00:00
|
|
|
select GENERIC_PCI_IOMAP
|
2012-04-07 21:10:17 +00:00
|
|
|
select TILE_GXIO_TRIO if TILEGX
|
|
|
|
|
select ARCH_SUPPORTS_MSI if TILEGX
|
|
|
|
|
select PCI_MSI if TILEGX
|
2010-11-02 16:05:10 +00:00
|
|
|
---help---
|
|
|
|
|
Enable PCI root complex support, so PCIe endpoint devices can
|
|
|
|
|
be attached to the Tile chip. Many, but not all, PCI devices
|
|
|
|
|
are supported under Tilera's root complex driver.
|
|
|
|
|
|
|
|
|
|
config PCI_DOMAINS
|
|
|
|
|
bool
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
config NO_IOMEM
|
|
|
|
|
def_bool !PCI
|
|
|
|
|
|
|
|
|
|
config NO_IOPORT
|
|
|
|
|
def_bool !PCI
|
|
|
|
|
|
|
|
|
|
source "drivers/pci/Kconfig"
|
|
|
|
|
|
2012-05-09 17:58:14 +00:00
|
|
|
config TILE_USB
|
|
|
|
|
tristate "Tilera USB host adapter support"
|
|
|
|
|
default y
|
|
|
|
|
depends on USB
|
|
|
|
|
depends on TILEGX
|
|
|
|
|
select TILE_GXIO_USB_HOST
|
|
|
|
|
---help---
|
|
|
|
|
Provides USB host adapter support for the built-in EHCI and OHCI
|
|
|
|
|
interfaces on TILE-Gx chips.
|
|
|
|
|
|
2010-05-29 03:09:12 +00:00
|
|
|
source "drivers/pci/hotplug/Kconfig"
|
|
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
|
|
menu "Executable file formats"
|
|
|
|
|
|
|
|
|
|
source "fs/Kconfig.binfmt"
|
|
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
|
|
source "net/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "drivers/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "fs/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "arch/tile/Kconfig.debug"
|
|
|
|
|
|
|
|
|
|
source "security/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "crypto/Kconfig"
|
|
|
|
|
|
|
|
|
|
source "lib/Kconfig"
|
2010-10-14 20:23:03 +00:00
|
|
|
|
|
|
|
|
source "arch/tile/kvm/Kconfig"
|
