License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 17:07:57 +03:00
# SPDX-License-Identifier: GPL-2.0
2005-04-17 02:20:36 +04:00
config MIPS
bool
default y
32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
All new 32-bit architectures should have 64-bit userspace off_t type, but
existing architectures has 32-bit ones.
To enforce the rule, new config option is added to arch/Kconfig that defaults
ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
32-bit architectures enable it explicitly.
New option affects force_o_largefile() behaviour. Namely, if userspace
off_t is 64-bits long, we have no reason to reject user to open big files.
Note that even if architectures has only 64-bit off_t in the kernel
(arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
a libc may use 32-bit off_t, and therefore want to limit the file size
to 4GB unless specified differently in the open flags.
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yury Norov <ynorov@marvell.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-05-16 11:18:49 +03:00
select ARCH_32BIT_OFF_T if !64BIT
2018-11-08 02:14:09 +03:00
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
2020-01-22 13:58:51 +03:00
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
select ARCH_HAS_PTE_SPECIAL if !(32BIT && CPU_HAS_RIXI)
2017-05-15 12:46:35 +03:00
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
2018-11-20 03:49:37 +03:00
select ARCH_HAS_UBSAN_SANITIZE_ALL
2020-12-03 10:22:51 +03:00
select ARCH_HAS_GCOV_PROFILE_ALL
2020-12-07 15:21:42 +03:00
select ARCH_KEEP_MEMBLOCK if DEBUG_KERNEL
2017-05-15 12:46:35 +03:00
select ARCH_SUPPORTS_UPROBES
2015-09-29 13:19:48 +03:00
select ARCH_USE_BUILTIN_BSWAP
2017-05-15 12:46:35 +03:00
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
2017-06-10 03:26:42 +03:00
select ARCH_USE_QUEUED_RWLOCKS
2017-06-10 03:26:43 +03:00
select ARCH_USE_QUEUED_SPINLOCKS
2019-09-24 01:39:18 +03:00
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
2017-05-15 12:46:35 +03:00
select ARCH_WANT_IPC_PARSE_VERSION
2019-12-04 03:46:31 +03:00
select BUILDTIME_TABLE_SORT
2017-05-15 12:46:35 +03:00
select CLONE_BACKWARDS
2018-11-09 02:44:55 +03:00
select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1)
2017-05-15 12:46:35 +03:00
select CPU_PM if CPU_IDLE
select GENERIC_ATOMIC64 if !64BIT
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
2019-06-21 12:52:46 +03:00
select GENERIC_GETTIMEOFDAY
MIPS: Use GENERIC_IOMAP
MIPS has a copy of lib/iomap.c with minor alterations, none of which are
necessary given appropriate definitions of PIO_OFFSET, PIO_MASK &
PIO_RESERVED. Provide such definitions, select GENERIC_IOMAP & remove
arch/mips/lib/iomap.c to cut back on the needless duplication.
The one change this does make is to our mmio_{in,out}s[bwl] functions,
which began to deviate from their generic counterparts with commit
0845bb721ebb ("MIPS: iomap: Use __mem_{read,write}{b,w,l} for MMIO"). I
suspect that this commit was incorrect, and that the SEAD-3 platform
should have instead selected CONFIG_SWAP_IO_SPACE. Since the SEAD-3
platform code is now gone & the board is instead supported by the
generic platform (CONFIG_MIPS_GENERIC) which selects
CONFIG_SWAP_IO_SPACE anyway, this shouldn't be a problem any more.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/20342/
Cc: linux-mips@linux-mips.org
2018-08-30 00:54:00 +03:00
select GENERIC_IOMAP
2017-05-15 12:46:35 +03:00
select GENERIC_IRQ_PROBE
select GENERIC_IRQ_SHOW
2018-11-15 22:05:37 +03:00
select GENERIC_ISA_DMA if EISA
2018-04-11 10:50:19 +03:00
select GENERIC_LIB_ASHLDI3
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_CMPDI2
select GENERIC_LIB_LSHRDI3
select GENERIC_LIB_UCMPDI2
2017-05-15 12:46:35 +03:00
select GENERIC_SCHED_CLOCK if !CAVIUM_OCTEON_SOC
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
2019-07-12 06:56:52 +03:00
select GUP_GET_PTE_LOW_HIGH if CPU_MIPS32 && PHYS_ADDR_T_64BIT
2017-05-15 12:46:35 +03:00
select HANDLE_DOMAIN_IRQ
MIPS: Workaround GCC __builtin_unreachable reordering bug
Some versions of GCC for the MIPS architecture suffer from a bug which
can lead to instructions from beyond an unreachable statement being
incorrectly reordered into earlier branch delay slots if the unreachable
statement is the only content of a case in a switch statement. This can
lead to seemingly random behaviour, such as invalid memory accesses from
incorrectly reordered loads or stores, and link failures on microMIPS
builds.
See this potential GCC fix for details:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
Runtime problems resulting from this bug were initially observed using a
maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
SDK 2015.06-05 toolchain), with the result being an address exception
taken after log messages about the L1 caches (during probe of the L2
cache):
Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
VPE topology {2,2} total 4
Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
<AdEL exception here>
This is early enough that the kernel exception vectors are not in use,
so any further output depends upon the bootloader. This is reproducible
in QEMU where no further output occurs - ie. the system hangs here.
Given the nature of the bug it may potentially be hit with differing
symptoms. The bug is known to affect GCC versions as recent as 7.3, and
it is unclear whether GCC 8 fixed it or just happens not to encounter
the bug in the testcase found at the link above due to differing
optimizations.
This bug can be worked around by placing a volatile asm statement, which
GCC is prevented from reordering past, prior to the
__builtin_unreachable call.
That was actually done already for other reasons by commit 173a3efd3edb
("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
allows for interlinking with regular MIPS32 code by repurposing bit 0 of
the program counter as an ISA mode bit. To switch modes one changes the
value of this bit in the PC. However typical branch instructions encode
their offsets as multiples of 2-byte instruction halfwords, which means
they cannot change ISA mode - this must be done using either an indirect
branch (a jump-register in MIPS terminology) or a dedicated jalx
instruction. In order to ensure that regular branches don't attempt to
target code in a different ISA which they can't actually switch to, the
linker will check that branch targets are code in the same ISA as the
branch.
Unfortunately our empty asm volatile statements don't qualify as code,
and the link for microMIPS builds fails with errors such as:
arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode
arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode
Resolve this by adding a .insn directive within the asm statement which
declares that what comes next is code. This may or may not be true,
since we don't really know what comes next, but as this code is in an
unreachable path anyway that doesn't matter since we won't execute it.
We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
order to have this included by linux/compiler_types.h after
linux/compiler-gcc.h. This will result in asm/compiler.h being included
in all C compilations via the -include linux/compiler_types.h argument
in c_flags, which should be harmless.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes: 173a3efd3edb ("bug.h: work around GCC PR82365 in BUG()")
Patchwork: https://patchwork.linux-mips.org/patch/20270/
Cc: James Hogan <jhogan@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mips@linux-mips.org
2018-08-21 01:36:18 +03:00
select HAVE_ARCH_COMPILER_H
2017-05-15 12:46:35 +03:00
select HAVE_ARCH_JUMP_LABEL
2008-07-30 00:58:53 +04:00
select HAVE_ARCH_KGDB
2016-11-24 20:32:45 +03:00
select HAVE_ARCH_MMAP_RND_BITS if MMU
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT
2014-01-22 18:40:04 +04:00
select HAVE_ARCH_SECCOMP_FILTER
2012-08-17 10:22:04 +04:00
select HAVE_ARCH_TRACEHOOK
2019-07-16 00:40:01 +03:00
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES
2019-08-19 08:54:20 +03:00
select HAVE_ASM_MODVERSIONS
MIPS: BPF: Restore MIPS32 cBPF JIT
Commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32
architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has
previously only been availailable for MIPS64. It was my understanding at
the time that the BPF test suite was passing & JITing a comparable
number of tests to our cBPF JIT [1], but it turns out that was not the
case.
The eBPF JIT has a number of problems on MIPS32:
- Most notably various code paths still result in emission of MIPS64
instructions which will cause reserved instruction exceptions & kernel
panics when run on MIPS32 CPUs.
- The eBPF JIT doesn't account for differences between the O32 ABI used
by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably
arguments beyond the first 4 are passed on the stack in O32, and this
is entirely unhandled when JITing a BPF_CALL instruction. Stack space
must be reserved for arguments even if they all fit in registers, and
the callee is free to assume that stack space has been reserved for
its use - with the eBPF JIT this is not the case, so calling any
function can result in clobbering values on the stack & unpredictable
behaviour. Function arguments in eBPF are always 64-bit values which
is also entirely unhandled - the JIT still uses a single (32-bit)
register per argument. As a result all function arguments are always
passed incorrectly when JITing a BPF_CALL instruction, leading to
kernel crashes or strange behavior.
- The JIT attempts to bail our on use of ALU64 instructions or 64-bit
memory access instructions. The code doing this at the start of
build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW,
when it should really be checking BPF_SIZE() & only doing so when
BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false
positives that cause more bailouts than intended, and that in turns
hides some of the problems described above.
- The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF
instructions that the MIPS32 eBPF JIT bails out on, leading to most
cBPF programs not being JITed at all.
Until these problems are resolved, revert the removal of the cBPF JIT
performed by commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for
MIPS32 architecture."). Together with commit f8fffebdea75 ("MIPS: BPF:
Disable MIPS32 eBPF JIT") this restores MIPS32 BPF JIT behavior back to
the same state it was prior to the introduction of the broken eBPF JIT
support.
[1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/
Signed-off-by: Paul Burton <paulburton@kernel.org>
Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: Tony Ambardar <itugrok@yahoo.com>
Cc: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
2019-12-05 21:23:18 +03:00
select HAVE_CBPF_JIT if !64BIT && !CPU_MICROMIPS
2017-05-15 12:46:35 +03:00
select HAVE_CONTEXT_TRACKING
2020-01-27 18:41:52 +03:00
select HAVE_TIF_NOHZ
2017-05-15 12:46:35 +03:00
select HAVE_C_RECORDMCOUNT
select HAVE_DEBUG_KMEMLEAK
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_DMA_CONTIGUOUS
MIPS: Tracing: Add dynamic function tracer support
With dynamic function tracer, by default, _mcount is defined as an
"empty" function, it returns directly without any more action . When
enabling it in user-space, it will jump to a real tracing
function(ftrace_caller), and do the real job for us.
Differ from the static function tracer, dynamic function tracer provides
two functions ftrace_make_call()/ftrace_make_nop() to enable/disable the
tracing of some indicated kernel functions(set_ftrace_filter).
In the -v4 version, the implementation of this support is basically the same as
X86 version does: _mcount is implemented as an empty function and ftrace_caller
is implemented as a real tracing function respectively.
But in this version, to support module tracing with the help of
-mlong-calls in arch/mips/Makefile:
MODFLAGS += -mlong-calls.
The stuff becomes a little more complex. We need to cope with two
different type of calling to _mcount.
For the kernel part, the calling to _mcount(result of "objdump -hdr
vmlinux"). is like this:
108: 03e0082d move at,ra
10c: 0c000000 jal 0 <fpcsr_pending>
10c: R_MIPS_26 _mcount
10c: R_MIPS_NONE *ABS*
10c: R_MIPS_NONE *ABS*
110: 00020021 nop
For the module with -mlong-calls, it looks like this:
c: 3c030000 lui v1,0x0
c: R_MIPS_HI16 _mcount
c: R_MIPS_NONE *ABS*
c: R_MIPS_NONE *ABS*
10: 64630000 daddiu v1,v1,0
10: R_MIPS_LO16 _mcount
10: R_MIPS_NONE *ABS*
10: R_MIPS_NONE *ABS*
14: 03e0082d move at,ra
18: 0060f809 jalr v1
In the kernel version, there is only one "_mcount" string for every
kernel function, so, we just need to match this one in mcount_regex of
scripts/recordmcount.pl, but in the module version, we need to choose
one of the two to match. Herein, I choose the first one with
"R_MIPS_HI16 _mcount".
and In the kernel verion, without module tracing support, we just need
to replace "jal _mcount" by "jal ftrace_caller" to do real tracing, and
filter the tracing of some kernel functions via replacing it by a nop
instruction.
but as we have described before, the instruction "jal ftrace_caller" only left
32bit length for the address of ftrace_caller, it will fail when calling from
the module space. so, herein, we must replace something else.
the basic idea is loading the address of ftrace_caller to v1 via changing these
two instructions:
lui v1,0x0
addiu v1,v1,0
If we want to enable the tracing, we need to replace the above instructions to:
lui v1, HI_16BIT_ftrace_caller
addiu v1, v1, LOW_16BIT_ftrace_caller
If we want to stop the tracing of the indicated kernel functions, we
just need to replace the "jalr v1" to a nop instruction. but we need to
replace two instructions and encode the above two instructions
oursevles.
Is there a simpler solution? Yes! Here it is, in this version, we put _mcount
and ftrace_caller together, which means the address of _mcount and
ftrace_caller is the same:
_mcount:
ftrace_caller:
j ftrace_stub
nop
...(do real tracing here)...
ftrace_stub:
jr ra
move ra, at
By default, the kernel functions call _mcount, and then jump to ftrace_stub and
return. and when we want to do real tracing, we just need to remove that "j
ftrace_stub", and it will run through the two "nop" instructions and then do
the real tracing job.
what about filtering job? we just need to do this:
lui v1, hi_16bit_of_mcount <--> b 1f (0x10000004)
addiu v1, v1, low_16bit_of_mcount
move at, ra
jalr v1
nop
1f: (rec->ip + 12)
In linux-mips64, there will be some local symbols, whose name are
prefixed by $L, which need to be filtered. thanks goes to Steven for
writing the mips64-specific function_regex.
In a conclusion, with RISC, things becomes easier with such a "stupid"
trick, RISC is something like K.I.S.S, and also, there are lots of
"simple" tricks in the whole ftrace support, thanks goes to Steven and
the other folks for providing such a wonderful tracing framework!
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Nicholas Mc Guire <der.herr@hofr.at>
Cc: zhangfx@lemote.com
Cc: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/675/
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-11-20 15:34:32 +03:00
select HAVE_DYNAMIC_FTRACE
2020-01-22 13:58:51 +03:00
select HAVE_EBPF_JIT if 64BIT && !CPU_MICROMIPS && TARGET_ISA_REV >= 2
2017-05-15 12:46:35 +03:00
select HAVE_EXIT_THREAD
2019-07-12 06:57:14 +03:00
select HAVE_FAST_GUP
MIPS: Tracing: Add dynamic function tracer support
With dynamic function tracer, by default, _mcount is defined as an
"empty" function, it returns directly without any more action . When
enabling it in user-space, it will jump to a real tracing
function(ftrace_caller), and do the real job for us.
Differ from the static function tracer, dynamic function tracer provides
two functions ftrace_make_call()/ftrace_make_nop() to enable/disable the
tracing of some indicated kernel functions(set_ftrace_filter).
In the -v4 version, the implementation of this support is basically the same as
X86 version does: _mcount is implemented as an empty function and ftrace_caller
is implemented as a real tracing function respectively.
But in this version, to support module tracing with the help of
-mlong-calls in arch/mips/Makefile:
MODFLAGS += -mlong-calls.
The stuff becomes a little more complex. We need to cope with two
different type of calling to _mcount.
For the kernel part, the calling to _mcount(result of "objdump -hdr
vmlinux"). is like this:
108: 03e0082d move at,ra
10c: 0c000000 jal 0 <fpcsr_pending>
10c: R_MIPS_26 _mcount
10c: R_MIPS_NONE *ABS*
10c: R_MIPS_NONE *ABS*
110: 00020021 nop
For the module with -mlong-calls, it looks like this:
c: 3c030000 lui v1,0x0
c: R_MIPS_HI16 _mcount
c: R_MIPS_NONE *ABS*
c: R_MIPS_NONE *ABS*
10: 64630000 daddiu v1,v1,0
10: R_MIPS_LO16 _mcount
10: R_MIPS_NONE *ABS*
10: R_MIPS_NONE *ABS*
14: 03e0082d move at,ra
18: 0060f809 jalr v1
In the kernel version, there is only one "_mcount" string for every
kernel function, so, we just need to match this one in mcount_regex of
scripts/recordmcount.pl, but in the module version, we need to choose
one of the two to match. Herein, I choose the first one with
"R_MIPS_HI16 _mcount".
and In the kernel verion, without module tracing support, we just need
to replace "jal _mcount" by "jal ftrace_caller" to do real tracing, and
filter the tracing of some kernel functions via replacing it by a nop
instruction.
but as we have described before, the instruction "jal ftrace_caller" only left
32bit length for the address of ftrace_caller, it will fail when calling from
the module space. so, herein, we must replace something else.
the basic idea is loading the address of ftrace_caller to v1 via changing these
two instructions:
lui v1,0x0
addiu v1,v1,0
If we want to enable the tracing, we need to replace the above instructions to:
lui v1, HI_16BIT_ftrace_caller
addiu v1, v1, LOW_16BIT_ftrace_caller
If we want to stop the tracing of the indicated kernel functions, we
just need to replace the "jalr v1" to a nop instruction. but we need to
replace two instructions and encode the above two instructions
oursevles.
Is there a simpler solution? Yes! Here it is, in this version, we put _mcount
and ftrace_caller together, which means the address of _mcount and
ftrace_caller is the same:
_mcount:
ftrace_caller:
j ftrace_stub
nop
...(do real tracing here)...
ftrace_stub:
jr ra
move ra, at
By default, the kernel functions call _mcount, and then jump to ftrace_stub and
return. and when we want to do real tracing, we just need to remove that "j
ftrace_stub", and it will run through the two "nop" instructions and then do
the real tracing job.
what about filtering job? we just need to do this:
lui v1, hi_16bit_of_mcount <--> b 1f (0x10000004)
addiu v1, v1, low_16bit_of_mcount
move at, ra
jalr v1
nop
1f: (rec->ip + 12)
In linux-mips64, there will be some local symbols, whose name are
prefixed by $L, which need to be filtered. thanks goes to Steven for
writing the mips64-specific function_regex.
In a conclusion, with RISC, things becomes easier with such a "stupid"
trick, RISC is something like K.I.S.S, and also, there are lots of
"simple" tricks in the whole ftrace support, thanks goes to Steven and
the other folks for providing such a wonderful tracing framework!
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Nicholas Mc Guire <der.herr@hofr.at>
Cc: zhangfx@lemote.com
Cc: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/675/
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-11-20 15:34:32 +03:00
select HAVE_FTRACE_MCOUNT_RECORD
MIPS: Tracing: Add function graph tracer support for MIPS
The implementation of function graph tracer for MIPS is a little
different from X86.
in MIPS, gcc(with -pg) only transfer the caller's return address(at) and
the _mcount's return address(ra) to us.
For the kernel part without -mlong-calls:
move at, ra
jal _mcount
For the module part with -mlong-calls:
lui v1, hi16bit_of_mcount
addiu v1, v1, low16bit_of_mcount
move at, ra
jal _mcount
Without -mlong-calls,
if the function is a leaf, it will not save the return address(ra):
ffffffff80101298 <au1k_wait>:
ffffffff80101298: 67bdfff0 daddiu sp,sp,-16
ffffffff8010129c: ffbe0008 sd s8,8(sp)
ffffffff801012a0: 03a0f02d move s8,sp
ffffffff801012a4: 03e0082d move at,ra
ffffffff801012a8: 0c042930 jal ffffffff8010a4c0 <_mcount>
ffffffff801012ac: 00020021 nop
so, we can hijack it directly in _mcount, but if the function is non-leaf, the
return address is saved in the stack.
ffffffff80133030 <copy_process>:
ffffffff80133030: 67bdff50 daddiu sp,sp,-176
ffffffff80133034: ffbe00a0 sd s8,160(sp)
ffffffff80133038: 03a0f02d move s8,sp
ffffffff8013303c: ffbf00a8 sd ra,168(sp)
ffffffff80133040: ffb70098 sd s7,152(sp)
ffffffff80133044: ffb60090 sd s6,144(sp)
ffffffff80133048: ffb50088 sd s5,136(sp)
ffffffff8013304c: ffb40080 sd s4,128(sp)
ffffffff80133050: ffb30078 sd s3,120(sp)
ffffffff80133054: ffb20070 sd s2,112(sp)
ffffffff80133058: ffb10068 sd s1,104(sp)
ffffffff8013305c: ffb00060 sd s0,96(sp)
ffffffff80133060: 03e0082d move at,ra
ffffffff80133064: 0c042930 jal ffffffff8010a4c0 <_mcount>
ffffffff80133068: 00020021 nop
but we can not get the exact stack address(which saved ra) directly in
_mcount, we need to search the content of at register in the stack space
or search the "s{d,w} ra, offset(sp)" instruction in the text. 'Cause we
can not prove there is only a match in the stack space, so, we search
the text instead.
as we can see, if the first instruction above "move at, ra" is not a
store instruction, there should be a leaf function, so we hijack the at
register directly via putting &return_to_handler into it, otherwise, we
search the "s{d,w} ra, offset(sp)" instruction to get the stack offset,
and then the stack address. we use the above copy_process() as an
example, we at last find "ffbf00a8", 0xa8 is the stack offset, we plus
it with s8(fp), that is the stack address, we hijack the content via
writing the &return_to_handler in.
If with -mlong-calls, since there are two more instructions above "move
at, ra", so, we can move the pointer to the position above "lui v1,
hi16bit_of_mcount".
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Nicholas Mc Guire <der.herr@hofr.at>
Cc: zhangfx@lemote.com
Cc: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/677/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-11-20 15:34:34 +03:00
select HAVE_FUNCTION_GRAPH_TRACER
2017-05-15 12:46:35 +03:00
select HAVE_FUNCTION_TRACER
2020-01-22 13:58:51 +03:00
select HAVE_GCC_PLUGINS
select HAVE_GENERIC_VDSO
2017-05-15 12:46:35 +03:00
select HAVE_IDE
2018-10-30 04:27:41 +03:00
select HAVE_IOREMAP_PROT
2017-05-15 12:46:35 +03:00
select HAVE_IRQ_EXIT_ON_IRQ_STACK
select HAVE_IRQ_TIME_ACCOUNTING
2010-08-03 22:22:20 +04:00
select HAVE_KPROBES
select HAVE_KRETPROBES
2018-11-22 00:56:36 +03:00
select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
2012-09-28 09:01:03 +04:00
select HAVE_MOD_ARCH_SPECIFIC
2016-05-21 03:00:33 +03:00
select HAVE_NMI
2017-05-15 12:46:35 +03:00
select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
2018-06-14 20:13:53 +03:00
select HAVE_RSEQ
2019-11-16 02:44:49 +03:00
select HAVE_SPARSE_SYSCALL_NR
2018-06-14 13:36:45 +03:00
select HAVE_STACKPROTECTOR
2017-05-15 12:46:35 +03:00
select HAVE_SYSCALL_TRACEPOINTS
2017-10-04 05:46:14 +03:00
select HAVE_VIRT_CPU_ACCOUNTING_GEN if 64BIT || !SMP
2017-05-15 12:46:35 +03:00
select IRQ_FORCED_THREADING
2018-11-15 22:05:37 +03:00
select ISA if EISA
2017-05-15 12:46:35 +03:00
select MODULES_USE_ELF_REL if MODULES
2020-01-22 13:58:51 +03:00
select MODULES_USE_ELF_RELA if MODULES && 64BIT
2017-05-15 12:46:35 +03:00
select PERF_USE_VMALLOC
2020-09-28 13:13:07 +03:00
select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
2018-08-28 17:26:30 +03:00
select RTC_LIB
2020-09-03 17:22:35 +03:00
select SET_FS
2015-01-21 13:54:46 +03:00
select SYSCTL_EXCEPTION_TRACE
2017-05-15 12:46:35 +03:00
select VIRT_TO_BUS
2005-04-17 02:20:36 +04:00
2020-04-16 18:00:07 +03:00
config MIPS_FIXUP_BIGPHYS_ADDR
bool
2020-09-06 22:29:25 +03:00
config MIPS_GENERIC
bool
2020-09-06 22:29:31 +03:00
config MACH_INGENIC
bool
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_ZBOOT
select DMA_NONCOHERENT
select IRQ_MIPS_CPU
select PINCTRL
select GPIOLIB
select COMMON_CLK
select GENERIC_IRQ_CHIP
select BUILTIN_DTB if MIPS_NO_APPENDED_DTB
select USE_OF
select CPU_SUPPORTS_CPUFREQ
select MIPS_EXTERNAL_TIMER
2005-04-17 02:20:36 +04:00
menu "Machine selection"
2005-10-29 22:32:41 +04:00
choice
prompt "System type"
2020-09-06 22:29:25 +03:00
default MIPS_GENERIC_KERNEL
2005-04-17 02:20:36 +04:00
2020-09-06 22:29:25 +03:00
config MIPS_GENERIC_KERNEL
2016-10-05 20:18:20 +03:00
bool "Generic board-agnostic MIPS kernel"
2020-09-06 22:29:25 +03:00
select MIPS_GENERIC
2016-10-05 20:18:20 +03:00
select BOOT_RAW
select BUILTIN_DTB
select CEVT_R4K
select CLKSRC_MIPS_GIC
select COMMON_CLK
select CPU_MIPSR2_IRQ_EI
2020-01-22 13:58:51 +03:00
select CPU_MIPSR2_IRQ_VI
2016-10-05 20:18:20 +03:00
select CSRC_R4K
select DMA_PERDEV_COHERENT
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2016-10-05 20:18:20 +03:00
select IRQ_MIPS_CPU
2018-07-28 04:23:21 +03:00
select MIPS_AUTO_PFN_OFFSET
2016-10-05 20:18:20 +03:00
select MIPS_CPU_SCACHE
select MIPS_GIC
select MIPS_L1_CACHE_SHIFT_7
select NO_EXCEPT_FILL
select PCI_DRIVERS_GENERIC
select SMP_UP if SMP
2017-01-23 17:08:13 +03:00
select SWAP_IO_SPACE
2016-10-05 20:18:20 +03:00
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_HAS_CPU_MIPS32_R6
select SYS_HAS_CPU_MIPS64_R1
select SYS_HAS_CPU_MIPS64_R2
select SYS_HAS_CPU_MIPS64_R6
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MICROMIPS
select SYS_SUPPORTS_MIPS16
2020-01-22 13:58:51 +03:00
select SYS_SUPPORTS_MIPS_CPS
2016-10-05 20:18:20 +03:00
select SYS_SUPPORTS_MULTITHREADING
select SYS_SUPPORTS_RELOCATABLE
select SYS_SUPPORTS_SMARTMIPS
2020-09-06 22:29:29 +03:00
select SYS_SUPPORTS_ZBOOT
2020-01-22 13:58:51 +03:00
select UHI_BOOT
2018-01-17 21:56:38 +03:00
select USB_EHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_UHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
2016-10-05 20:18:20 +03:00
select USE_OF
help
Select this to build a kernel which aims to support multiple boards,
generally using a flattened device tree passed from the bootloader
using the boot protocol defined in the UHI (Unified Hosting
Interface) specification.
2010-07-15 23:45:04 +04:00
config MIPS_ALCHEMY
2007-05-11 15:44:30 +04:00
bool "Alchemy processor based machines"
2018-04-03 17:24:20 +03:00
select PHYS_ADDR_T_64BIT
2012-11-30 20:27:27 +04:00
select CEVT_R4K
2012-11-15 09:34:17 +04:00
select CSRC_R4K
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2014-02-20 17:59:23 +04:00
select DMA_MAYBE_COHERENT # Au1000,1500,1100 aren't, rest is
2020-04-16 18:00:07 +03:00
select MIPS_FIXUP_BIGPHYS_ADDR if PCI
2010-07-15 23:45:04 +04:00
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_APM_EMULATION
2016-04-19 12:23:22 +03:00
select GPIOLIB
2009-10-14 14:12:16 +04:00
select SYS_SUPPORTS_ZBOOT
2014-07-23 18:36:48 +04:00
select COMMON_CLK
2005-04-17 02:20:36 +04:00
2009-06-24 13:12:57 +04:00
config AR7
bool "Texas Instruments AR7"
select BOOT_ELF32
select DMA_NONCOHERENT
select CEVT_R4K
select CSRC_R4K
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2009-06-24 13:12:57 +04:00
select NO_EXCEPT_FILL
select SWAP_IO_SPACE
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
2014-04-29 03:49:24 +04:00
select SYS_SUPPORTS_MIPS16
2009-10-14 14:12:16 +04:00
select SYS_SUPPORTS_ZBOOT_UART16550
2016-04-19 12:23:22 +03:00
select GPIOLIB
2009-06-24 13:12:57 +04:00
select VLYNQ
2020-04-09 09:44:13 +03:00
select HAVE_LEGACY_CLK
2009-06-24 13:12:57 +04:00
help
Support for the Texas Instruments AR7 System-on-a-Chip
family: TNETD7100, 7200 and 7300.
2014-10-29 02:18:38 +03:00
config ATH25
bool "Atheros AR231x/AR531x SoC support"
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2014-10-29 02:18:41 +03:00
select IRQ_DOMAIN
2014-10-29 02:18:38 +03:00
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_32BIT_KERNEL
2014-10-29 02:18:42 +03:00
select SYS_HAS_EARLY_PRINTK
2014-10-29 02:18:38 +03:00
help
Support for Atheros AR231x and Atheros AR531x based boards
2011-01-04 23:28:14 +03:00
config ATH79
bool "Atheros AR71XX/AR724X/AR913X based boards"
2015-08-03 20:23:52 +03:00
select ARCH_HAS_RESET_CONTROLLER
2011-01-04 23:28:14 +03:00
select BOOT_RAW
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
2016-04-19 12:23:22 +03:00
select GPIOLIB
2018-07-20 14:58:20 +03:00
select PINCTRL
2015-04-19 15:30:04 +03:00
select COMMON_CLK
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2011-01-04 23:28:14 +03:00
select SYS_HAS_CPU_MIPS32_R2
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
2014-04-29 03:49:24 +04:00
select SYS_SUPPORTS_MIPS16
2016-01-26 11:38:29 +03:00
select SYS_SUPPORTS_ZBOOT_UART_PROM
2015-05-31 02:52:25 +03:00
select USE_OF
2018-03-25 01:47:22 +03:00
select USB_EHCI_ROOT_HUB_TT if USB_EHCI_HCD_PLATFORM
2011-01-04 23:28:14 +03:00
help
Support for the Atheros AR71XX/AR724X/AR913X SoCs.
2014-12-25 20:49:00 +03:00
config BMIPS_GENERIC
bool "Broadcom Generic BMIPS kernel"
2020-06-17 13:50:33 +03:00
select ARCH_HAS_RESET_CONTROLLER
2018-06-15 14:08:52 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU_ALL
select ARCH_HAS_PHYS_TO_DMA
2014-10-21 08:28:05 +04:00
select BOOT_RAW
select NO_EXCEPT_FILL
select USE_OF
select CEVT_R4K
select CSRC_R4K
select SYNC_R4K
select COMMON_CLK
2015-11-22 17:30:14 +03:00
select BCM6345_L1_IRQ
2014-12-25 20:49:17 +03:00
select BCM7038_L1_IRQ
select BCM7120_L2_IRQ
select BRCMSTB_L2_IRQ
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2014-12-25 20:49:17 +03:00
select DMA_NONCOHERENT
2014-10-21 08:28:05 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
2014-12-25 20:49:17 +03:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2014-10-21 08:28:05 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
2014-12-25 20:49:17 +03:00
select SYS_HAS_CPU_BMIPS32_3300
select SYS_HAS_CPU_BMIPS4350
select SYS_HAS_CPU_BMIPS4380
2014-10-21 08:28:05 +04:00
select SYS_HAS_CPU_BMIPS5000
select SWAP_IO_SPACE
2014-12-25 20:49:17 +03:00
select USB_EHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_DESC if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
2017-05-24 20:55:16 +03:00
select HARDIRQS_SW_RESEND
2014-10-21 08:28:05 +04:00
help
2014-12-25 20:49:00 +03:00
Build a generic DT-based kernel image that boots on select
BCM33xx cable modem chips, BCM63xx DSL chips, and BCM7xxx set-top
box chips. Note that CONFIG_CPU_BIG_ENDIAN/CONFIG_CPU_LITTLE_ENDIAN
must be set appropriately for your board.
2014-10-21 08:28:05 +04:00
2007-09-25 17:40:12 +04:00
config BCM47XX
2010-03-25 13:42:41 +03:00
bool "Broadcom BCM47XX based boards"
2012-12-27 00:06:17 +04:00
select BOOT_RAW
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2007-11-25 01:33:28 +03:00
select CSRC_R4K
2007-09-25 17:40:12 +04:00
select DMA_NONCOHERENT
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2013-07-23 18:40:37 +04:00
select SYS_HAS_CPU_MIPS32_R1
2012-12-27 00:06:18 +04:00
select NO_EXCEPT_FILL
2007-09-25 17:40:12 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
2014-04-29 03:49:24 +04:00
select SYS_SUPPORTS_MIPS16
2018-01-17 01:21:44 +03:00
select SYS_SUPPORTS_ZBOOT
2007-09-25 17:41:24 +04:00
select SYS_HAS_EARLY_PRINTK
2014-03-27 00:40:25 +04:00
select USE_GENERIC_EARLY_PRINTK_8250
2014-06-17 18:36:50 +04:00
select GPIOLIB
select LEDS_GPIO_REGISTER
2015-06-11 00:05:08 +03:00
select BCM47XX_NVRAM
2016-01-25 11:50:29 +03:00
select BCM47XX_SPROM
2017-11-14 20:16:27 +03:00
select BCM47XX_SSB if !BCM47XX_BCMA
2007-09-25 17:40:12 +04:00
help
2019-03-11 18:54:27 +03:00
Support for BCM47XX based boards
2007-09-25 17:40:12 +04:00
2009-08-18 16:23:37 +04:00
config BCM63XX
bool "Broadcom BCM63XX based boards"
2013-06-18 20:55:39 +04:00
select BOOT_RAW
2009-08-18 16:23:37 +04:00
select CEVT_R4K
select CSRC_R4K
2014-07-08 18:26:13 +04:00
select SYNC_R4K
2009-08-18 16:23:37 +04:00
select DMA_NONCOHERENT
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2009-08-18 16:23:37 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_HAS_EARLY_PRINTK
select SWAP_IO_SPACE
2016-04-19 12:23:22 +03:00
select GPIOLIB
2014-01-14 21:54:40 +04:00
select MIPS_L1_CACHE_SHIFT_4
2017-09-20 14:14:01 +03:00
select CLKDEV_LOOKUP
2020-04-09 09:44:13 +03:00
select HAVE_LEGACY_CLK
2009-08-18 16:23:37 +04:00
help
2019-03-11 18:54:27 +03:00
Support for BCM63XX based boards
2009-08-18 16:23:37 +04:00
2005-04-17 02:20:36 +04:00
config MIPS_COBALT
2006-05-10 01:34:53 +04:00
bool "Cobalt Server"
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2007-11-25 01:33:28 +03:00
select CSRC_R4K
2007-10-22 14:43:15 +04:00
select CEVT_GT641XX
2005-04-17 02:20:36 +04:00
select DMA_NONCOHERENT
2018-11-15 22:05:32 +03:00
select FORCE_PCI
2007-10-12 02:46:10 +04:00
select I8253
2005-04-17 02:20:36 +04:00
select I8259
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2007-09-13 18:51:26 +04:00
select IRQ_GT641XX
2007-03-14 15:51:26 +03:00
select PCI_GT64XXX_PCI0
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_NEVADA
2007-03-02 06:42:33 +03:00
select SYS_HAS_EARLY_PRINTK
2005-09-04 02:56:21 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
2008-01-15 21:42:57 +03:00
select SYS_SUPPORTS_64BIT_KERNEL
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2014-03-27 00:40:25 +04:00
select USE_GENERIC_EARLY_PRINTK_8250
2005-04-17 02:20:36 +04:00
config MACH_DECSTATION
2006-05-10 01:34:53 +04:00
bool "DECstations"
2005-04-17 02:20:36 +04:00
select BOOT_ELF32
2008-04-25 07:11:44 +04:00
select CEVT_DS1287
2014-04-07 00:46:05 +04:00
select CEVT_R4K if CPU_R4X00
2008-04-24 04:48:40 +04:00
select CSRC_IOASIC
2014-04-07 00:46:05 +04:00
select CSRC_R4K if CPU_R4X00
2007-10-23 15:43:11 +04:00
select CPU_DADDI_WORKAROUNDS if 64BIT
select CPU_R4000_WORKAROUNDS if 64BIT
select CPU_R4400_WORKAROUNDS if 64BIT
2005-04-17 02:20:36 +04:00
select DMA_NONCOHERENT
2014-04-08 02:39:19 +04:00
select NO_IOPORT_MAP
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_R3000
select SYS_HAS_CPU_R4X00
2005-09-04 02:56:21 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
2013-01-17 06:53:19 +04:00
select SYS_SUPPORTS_64BIT_KERNEL
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2006-06-19 19:19:13 +04:00
select SYS_SUPPORTS_128HZ
select SYS_SUPPORTS_256HZ
select SYS_SUPPORTS_1024HZ
2014-01-14 21:54:38 +04:00
select MIPS_L1_CACHE_SHIFT_4
2005-10-29 22:32:41 +04:00
help
2005-04-17 02:20:36 +04:00
This enables support for DEC's MIPS based workstations. For details
see the Linux/MIPS FAQ on <http://www.linux-mips.org/> and the
DECstation porting pages on <http://decstation.unix-ag.org/>.
If you have one of the following DECstation Models you definitely
want to choose R4xx0 for the CPU Type:
2007-08-29 17:21:45 +04:00
DECstation 5000/50
DECstation 5000/150
DECstation 5000/260
DECsystem 5900/260
2005-04-17 02:20:36 +04:00
otherwise choose R3000.
2005-10-29 22:32:41 +04:00
config MACH_JAZZ
2006-05-10 01:34:53 +04:00
bool "Jazz family of machines"
2019-10-09 16:27:14 +03:00
select ARC_MEMORY
select ARC_PROMLIB
2018-02-05 17:37:43 +03:00
select ARCH_MIGHT_HAVE_PC_PARPORT
2018-02-05 18:40:00 +03:00
select ARCH_MIGHT_HAVE_PC_SERIO
2020-07-08 10:30:00 +03:00
select DMA_OPS
2012-11-15 23:48:50 +04:00
select FW_ARC
select FW_ARC32
2005-10-29 22:32:41 +04:00
select ARCH_MAY_HAVE_PC_FDC
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2007-11-25 01:33:28 +03:00
select CSRC_R4K
2007-12-02 15:00:32 +03:00
select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN
2005-10-29 22:32:41 +04:00
select GENERIC_ISA_DMA
2011-06-01 22:05:10 +04:00
select HAVE_PCSPKR_PLATFORM
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2007-10-12 02:46:10 +04:00
select I8253
2005-10-29 22:32:41 +04:00
select I8259
select ISA
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_R4X00
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
2013-01-17 06:53:19 +04:00
select SYS_SUPPORTS_64BIT_KERNEL
2006-06-19 19:19:13 +04:00
select SYS_SUPPORTS_100HZ
2005-04-17 02:20:36 +04:00
help
2019-03-11 18:54:27 +03:00
This a family of machines based on the MIPS R4030 chipset which was
used by several vendors to build RISC/os and Windows NT workstations.
Members include the Acer PICA, MIPS Magnum 4000, MIPS Millennium and
Olivetti M700-10 workstations.
2005-10-29 22:32:41 +04:00
2020-09-06 22:29:31 +03:00
config MACH_INGENIC_SOC
2015-05-24 18:11:13 +03:00
bool "Ingenic SoC based machines"
2020-09-06 22:29:31 +03:00
select MIPS_GENERIC
select MACH_INGENIC
2012-03-30 18:48:05 +04:00
select SYS_SUPPORTS_ZBOOT_UART16550
2010-06-19 08:08:19 +04:00
2011-03-30 11:27:47 +04:00
config LANTIQ
bool "Lantiq based platforms"
select DMA_NONCOHERENT
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2011-03-30 11:27:47 +04:00
select CEVT_R4K
select CSRC_R4K
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_32BIT_KERNEL
2014-04-29 03:49:24 +04:00
select SYS_SUPPORTS_MIPS16
2011-03-30 11:27:47 +04:00
select SYS_SUPPORTS_MULTITHREADING
2018-01-15 23:54:35 +03:00
select SYS_SUPPORTS_VPE_LOADER
2011-03-30 11:27:47 +04:00
select SYS_HAS_EARLY_PRINTK
2016-04-19 12:23:22 +03:00
select GPIOLIB
2011-03-30 11:27:47 +04:00
select SWAP_IO_SPACE
select BOOT_RAW
2012-04-17 17:53:19 +04:00
select CLKDEV_LOOKUP
2020-04-09 09:44:13 +03:00
select HAVE_LEGACY_CLK
2012-04-13 22:56:13 +04:00
select USE_OF
2012-08-28 14:44:59 +04:00
select PINCTRL
select PINCTRL_LANTIQ
2013-09-03 15:18:12 +04:00
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
2011-03-30 11:27:47 +04:00
2015-04-21 05:00:35 +03:00
config MACH_LOONGSON32
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
bool "Loongson 32-bit family of machines"
2010-01-04 12:16:46 +03:00
select SYS_SUPPORTS_ZBOOT
2007-07-27 10:25:43 +04:00
help
2015-04-21 05:00:35 +03:00
This enables support for the Loongson-1 family of machines.
2009-07-02 19:26:45 +04:00
2015-04-21 05:00:35 +03:00
Loongson-1 is a family of 32-bit MIPS-compatible SoCs developed by
the Institute of Computing Technology (ICT), Chinese Academy of
Sciences (CAS).
2007-07-27 10:25:43 +04:00
2019-10-20 17:43:14 +03:00
config MACH_LOONGSON2EF
bool "Loongson-2E/F family of machines"
2012-07-25 18:17:24 +04:00
select SYS_SUPPORTS_ZBOOT
help
2019-10-20 17:43:14 +03:00
This enables the support of early Loongson-2E/F family of machines.
2012-07-25 18:17:24 +04:00
2019-10-20 17:43:14 +03:00
config MACH_LOONGSON64
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
bool "Loongson 64-bit family of machines"
2019-10-20 18:01:36 +03:00
select ARCH_SPARSEMEM_ENABLE
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select GENERIC_ISA_DMA_SUPPORT_BROKEN
select BOOT_ELF32
select BOARD_SCACHE
select CSRC_R4K
select CEVT_R4K
select CPU_HAS_WB
select FORCE_PCI
select ISA
select I8259
select IRQ_MIPS_CPU
2020-05-27 09:34:34 +03:00
select NO_EXCEPT_FILL
2020-03-31 10:00:06 +03:00
select NR_CPUS_DEFAULT_64
2019-10-20 18:01:36 +03:00
select USE_GENERIC_EARLY_PRINTK_8250
2020-05-26 12:21:16 +03:00
select PCI_DRIVERS_GENERIC
2019-10-20 18:01:36 +03:00
select SYS_HAS_CPU_LOONGSON64
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
select SYS_SUPPORTS_NUMA
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
2019-10-20 17:43:14 +03:00
select SYS_SUPPORTS_ZBOOT
2020-11-25 13:07:46 +03:00
select SYS_SUPPORTS_RELOCATABLE
2019-10-20 18:01:36 +03:00
select ZONE_DMA32
select NUMA
2020-10-11 02:47:51 +03:00
select SMP
2020-03-25 06:55:02 +03:00
select COMMON_CLK
select USE_OF
select BUILTIN_DTB
2020-07-29 09:58:37 +03:00
select PCI_HOST_GENERIC
2019-10-20 17:43:14 +03:00
help
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
This enables the support of Loongson-2/3 family of machines.
Loongson-2 and Loongson-3 are 64-bit general-purpose processors with
GS264/GS464/GS464E/GS464V microarchitecture (except old Loongson-2E
and Loongson-2F which will be removed), developed by the Institute
of Computing Technology (ICT), Chinese Academy of Sciences (CAS).
2012-07-25 18:17:24 +04:00
2015-03-17 00:43:10 +03:00
config MACH_PISTACHIO
bool "IMG Pistachio SoC based boards"
select BOOT_ELF32
select BOOT_RAW
select CEVT_R4K
select CLKSRC_MIPS_GIC
select COMMON_CLK
select CSRC_R4K
2016-06-03 11:35:00 +03:00
select DMA_NONCOHERENT
2016-04-19 12:23:22 +03:00
select GPIOLIB
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2015-03-17 00:43:10 +03:00
select MFD_SYSCON
select MIPS_CPU_SCACHE
select MIPS_GIC
select PINCTRL
select REGULATOR
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_MIPS_CPS
select SYS_SUPPORTS_MULTITHREADING
2016-05-25 14:58:40 +03:00
select SYS_SUPPORTS_RELOCATABLE
2015-03-17 00:43:10 +03:00
select SYS_SUPPORTS_ZBOOT
2015-04-29 01:08:35 +03:00
select SYS_HAS_EARLY_PRINTK
select USE_GENERIC_EARLY_PRINTK_8250
2015-03-17 00:43:10 +03:00
select USE_OF
help
This enables support for the IMG Pistachio SoC platform.
2005-04-17 02:20:36 +04:00
config MIPS_MALTA
2006-05-10 01:34:53 +04:00
bool "MIPS Malta board"
2005-09-15 12:52:34 +04:00
select ARCH_MAY_HAVE_PC_FDC
2018-02-05 17:37:43 +03:00
select ARCH_MIGHT_HAVE_PC_PARPORT
2018-02-05 18:40:00 +03:00
select ARCH_MIGHT_HAVE_PC_SERIO
2005-04-17 02:20:36 +04:00
select BOOT_ELF32
2008-01-29 13:15:00 +03:00
select BOOT_RAW
2015-05-22 18:51:02 +03:00
select BUILTIN_DTB
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2014-10-20 23:03:58 +04:00
select CLKSRC_MIPS_GIC
2015-08-22 12:40:41 +03:00
select COMMON_CLK
2018-11-12 20:00:59 +03:00
select CSRC_R4K
2013-09-27 16:41:44 +04:00
select DMA_MAYBE_COHERENT
2005-04-17 02:20:36 +04:00
select GENERIC_ISA_DMA
2011-06-01 22:05:10 +04:00
select HAVE_PCSPKR_PLATFORM
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2007-10-12 02:46:10 +04:00
select I8253
2005-04-17 02:20:36 +04:00
select I8259
2018-11-12 20:00:59 +03:00
select IRQ_MIPS_CPU
2005-10-29 22:32:41 +04:00
select MIPS_BONITO64
2006-06-20 20:15:20 +04:00
select MIPS_CPU_SCACHE
2018-11-12 20:00:59 +03:00
select MIPS_GIC
2014-10-21 08:27:57 +04:00
select MIPS_L1_CACHE_SHIFT_6
2005-10-29 22:32:41 +04:00
select MIPS_MSC
2018-11-12 20:00:59 +03:00
select PCI_GT64XXX_PCI0
2015-09-22 21:58:43 +03:00
select SMP_UP if SMP
2005-04-17 02:20:36 +04:00
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
2014-01-16 17:12:36 +04:00
select SYS_HAS_CPU_MIPS32_R3_5
2015-02-27 03:16:38 +03:00
select SYS_HAS_CPU_MIPS32_R5
2014-11-19 14:31:56 +03:00
select SYS_HAS_CPU_MIPS32_R6
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_MIPS64_R1
2012-07-19 11:11:15 +04:00
select SYS_HAS_CPU_MIPS64_R2
2014-11-19 14:31:56 +03:00
select SYS_HAS_CPU_MIPS64_R6
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_NEVADA
select SYS_HAS_CPU_RM7000
2005-09-04 02:56:21 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2015-02-27 03:16:38 +03:00
select SYS_SUPPORTS_HIGHMEM
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2014-11-16 01:07:07 +03:00
select SYS_SUPPORTS_MICROMIPS
2018-11-12 20:00:59 +03:00
select SYS_SUPPORTS_MIPS16
2009-06-18 03:22:53 +04:00
select SYS_SUPPORTS_MIPS_CMP
2014-01-15 14:31:56 +04:00
select SYS_SUPPORTS_MIPS_CPS
2006-06-05 20:24:46 +04:00
select SYS_SUPPORTS_MULTITHREADING
2018-11-12 20:00:59 +03:00
select SYS_SUPPORTS_RELOCATABLE
2007-02-02 19:41:47 +03:00
select SYS_SUPPORTS_SMARTMIPS
2018-01-15 23:54:35 +03:00
select SYS_SUPPORTS_VPE_LOADER
2009-10-14 14:12:16 +04:00
select SYS_SUPPORTS_ZBOOT
2015-05-22 18:51:02 +03:00
select USE_OF
2020-08-24 19:32:48 +03:00
select WAR_ICACHE_REFILLS
2015-04-27 17:07:19 +03:00
select ZONE_DMA32 if 64BIT
2005-04-17 02:20:36 +04:00
help
2005-02-03 01:23:46 +03:00
This enables support for the MIPS Technologies Malta evaluation
2005-04-17 02:20:36 +04:00
board.
2016-01-14 04:15:39 +03:00
config MACH_PIC32
bool "Microchip PIC32 Family"
help
This enables support for the Microchip PIC32 family of platforms.
Microchip PIC32 is a family of general-purpose 32 bit MIPS core
microcontrollers.
2005-10-29 22:32:41 +04:00
config MACH_VR41XX
2007-04-26 14:45:09 +04:00
bool "NEC VR4100 series based machines"
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2007-11-25 01:33:28 +03:00
select CSRC_R4K
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_VR41XX
2014-04-29 03:49:24 +04:00
select SYS_SUPPORTS_MIPS16
2016-04-19 12:23:22 +03:00
select GPIOLIB
2005-10-29 22:32:41 +04:00
2013-01-21 01:05:30 +04:00
config RALINK
bool "Ralink based machines"
select CEVT_R4K
select CSRC_R4K
select BOOT_RAW
select DMA_NONCOHERENT
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2013-01-21 01:05:30 +04:00
select USE_OF
select SYS_HAS_CPU_MIPS32_R1
select SYS_HAS_CPU_MIPS32_R2
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
2014-04-29 03:49:24 +04:00
select SYS_SUPPORTS_MIPS16
2020-10-13 05:05:47 +03:00
select SYS_SUPPORTS_ZBOOT
2013-01-21 01:05:30 +04:00
select SYS_HAS_EARLY_PRINTK
select CLKDEV_LOOKUP
2013-09-04 02:16:59 +04:00
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
2013-01-21 01:05:30 +04:00
2005-04-17 02:20:36 +04:00
config SGI_IP22
2006-05-10 01:34:53 +04:00
bool "SGI IP22 (Indy/Indigo2)"
2019-10-09 16:27:17 +03:00
select ARC_MEMORY
2019-10-09 16:27:14 +03:00
select ARC_PROMLIB
2012-11-15 23:48:50 +04:00
select FW_ARC
select FW_ARC32
2018-02-05 18:40:00 +03:00
select ARCH_MIGHT_HAVE_PC_SERIO
2005-04-17 02:20:36 +04:00
select BOOT_ELF32
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2007-11-25 01:33:28 +03:00
select CSRC_R4K
2007-12-02 15:00:32 +03:00
select DEFAULT_SGI_PARTITION
2005-04-17 02:20:36 +04:00
select DMA_NONCOHERENT
2018-11-15 22:05:37 +03:00
select HAVE_EISA
2007-10-12 02:46:10 +04:00
select I8253
2007-11-23 22:34:16 +03:00
select I8259
2005-04-17 02:20:36 +04:00
select IP22_CPU_SCACHE
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2006-11-30 04:14:51 +03:00
select GENERIC_ISA_DMA_SUPPORT_BROKEN
2007-12-02 15:00:32 +03:00
select SGI_HAS_I8042
select SGI_HAS_INDYDOG
2008-07-16 16:06:15 +04:00
select SGI_HAS_HAL2
2007-12-02 15:00:32 +03:00
select SGI_HAS_SEEQ
select SGI_HAS_WD93
select SGI_HAS_ZILOG
2005-04-17 02:20:36 +04:00
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_R4X00
select SYS_HAS_CPU_R5000
2019-10-09 16:27:17 +03:00
select SYS_HAS_EARLY_PRINTK
2005-09-04 02:56:21 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2020-08-24 19:32:43 +03:00
select WAR_R4600_V1_INDEX_ICACHEOP
2020-08-24 19:32:44 +03:00
select WAR_R4600_V1_HIT_CACHEOP
2020-08-24 19:32:45 +03:00
select WAR_R4600_V2_HIT_CACHEOP
2014-01-14 21:54:38 +04:00
select MIPS_L1_CACHE_SHIFT_7
2005-04-17 02:20:36 +04:00
help
This are the SGI Indy, Challenge S and Indigo2, as well as certain
OEM variants like the Tandem CMN B006S. To compile a Linux kernel
that runs on these, say Y here.
config SGI_IP27
2006-05-10 01:34:53 +04:00
bool "SGI IP27 (Origin200/2000)"
2018-06-15 14:08:44 +03:00
select ARCH_HAS_PHYS_TO_DMA
2019-09-16 14:13:10 +03:00
select ARCH_SPARSEMEM_ENABLE
2012-11-15 23:48:50 +04:00
select FW_ARC
select FW_ARC64
2019-10-22 19:13:15 +03:00
select ARC_CMDLINE_ONLY
2005-10-29 22:32:41 +04:00
select BOOT_ELF64
2007-12-02 15:00:32 +03:00
select DEFAULT_SGI_PARTITION
2007-03-01 14:56:43 +03:00
select SYS_HAS_EARLY_PRINTK
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2019-02-19 18:57:20 +03:00
select IRQ_MIPS_CPU
2019-05-08 00:09:15 +03:00
select IRQ_DOMAIN_HIERARCHY
2007-02-06 19:53:15 +03:00
select NR_CPUS_DEFAULT_64
2019-05-08 00:09:13 +03:00
select PCI_DRIVERS_GENERIC
select PCI_XTALK_BRIDGE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_R10000
2005-09-04 02:56:21 +04:00
select SYS_SUPPORTS_64BIT_KERNEL
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2006-06-12 02:03:08 +04:00
select SYS_SUPPORTS_NUMA
2006-11-02 20:23:33 +03:00
select SYS_SUPPORTS_SMP
2020-08-24 19:32:49 +03:00
select WAR_R10000_LLSC
2014-01-14 21:54:38 +04:00
select MIPS_L1_CACHE_SHIFT_7
MIPS: SGI-IP27: always enable NUMA in Kconfig
When a configuration has NUMA disabled and SGI_IP27 enabled, the build
fails:
CC kernel/bounds.s
CC arch/mips/kernel/asm-offsets.s
In file included from arch/mips/include/asm/topology.h:11,
from include/linux/topology.h:36,
from include/linux/gfp.h:9,
from include/linux/slab.h:15,
from include/linux/crypto.h:19,
from include/crypto/hash.h:11,
from include/linux/uio.h:10,
from include/linux/socket.h:8,
from include/linux/compat.h:15,
from arch/mips/kernel/asm-offsets.c:12:
include/linux/topology.h: In function 'numa_node_id':
arch/mips/include/asm/mach-ip27/topology.h:16:27: error: implicit declaration of function 'cputonasid'; did you mean 'cpu_vpe_id'? [-Werror=implicit-function-declaration]
#define cpu_to_node(cpu) (cputonasid(cpu))
^~~~~~~~~~
include/linux/topology.h:119:9: note: in expansion of macro 'cpu_to_node'
return cpu_to_node(raw_smp_processor_id());
^~~~~~~~~~~
include/linux/topology.h: In function 'cpu_cpu_mask':
arch/mips/include/asm/mach-ip27/topology.h:19:7: error: implicit declaration of function 'hub_data' [-Werror=implicit-function-declaration]
&hub_data(node)->h_cpus)
^~~~~~~~
include/linux/topology.h:210:9: note: in expansion of macro 'cpumask_of_node'
return cpumask_of_node(cpu_to_node(cpu));
^~~~~~~~~~~~~~~
arch/mips/include/asm/mach-ip27/topology.h:19:21: error: invalid type argument of '->' (have 'int')
&hub_data(node)->h_cpus)
^~
include/linux/topology.h:210:9: note: in expansion of macro 'cpumask_of_node'
return cpumask_of_node(cpu_to_node(cpu));
^~~~~~~~~~~~~~~
Before switch from discontigmem to sparsemem, there always was
CONFIG_NEED_MULTIPLE_NODES=y because it was selected by DISCONTIGMEM.
Without DISCONTIGMEM it is possible to have SPARSEMEM without NUMA for
SGI_IP27 and as many things there rely on custom node definition, the
build breaks.
As Thomas noted "... there are right now too many places in IP27 code,
which assumes NUMA enabled", the simplest solution would be to always
enable NUMA for SGI-IP27 builds.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 397dc00e249e ("mips: sgi-ip27: switch from DISCONTIGMEM to SPARSEMEM")
Cc: stable@vger.kernel.org
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-08-05 15:51:41 +03:00
select NUMA
2005-04-17 02:20:36 +04:00
help
This are the SGI Origin 200, Origin 2000 and Onyx 2 Graphics
workstations. To compile a Linux kernel that runs on these, say Y
here.
2007-12-02 15:00:32 +03:00
config SGI_IP28
2013-01-17 06:53:19 +04:00
bool "SGI IP28 (Indigo2 R10k)"
2019-10-09 16:27:17 +03:00
select ARC_MEMORY
2019-10-09 16:27:14 +03:00
select ARC_PROMLIB
2012-11-15 23:48:50 +04:00
select FW_ARC
select FW_ARC64
2018-02-05 18:40:00 +03:00
select ARCH_MIGHT_HAVE_PC_SERIO
2007-12-02 15:00:32 +03:00
select BOOT_ELF64
select CEVT_R4K
select CSRC_R4K
select DEFAULT_SGI_PARTITION
select DMA_NONCOHERENT
select GENERIC_ISA_DMA_SUPPORT_BROKEN
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2018-11-15 22:05:37 +03:00
select HAVE_EISA
2007-12-02 15:00:32 +03:00
select I8253
select I8259
select SGI_HAS_I8042
select SGI_HAS_INDYDOG
2008-07-10 22:29:55 +04:00
select SGI_HAS_HAL2
2007-12-02 15:00:32 +03:00
select SGI_HAS_SEEQ
select SGI_HAS_WD93
select SGI_HAS_ZILOG
select SWAP_IO_SPACE
select SYS_HAS_CPU_R10000
2019-10-09 16:27:17 +03:00
select SYS_HAS_EARLY_PRINTK
2007-12-02 15:00:32 +03:00
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
2020-08-24 19:32:49 +03:00
select WAR_R10000_LLSC
2014-08-20 00:00:07 +04:00
select MIPS_L1_CACHE_SHIFT_7
2019-03-11 18:54:27 +03:00
help
This is the SGI Indigo2 with R10000 processor. To compile a Linux
kernel that runs on these, say Y here.
2007-12-02 15:00:32 +03:00
2019-10-24 13:18:29 +03:00
config SGI_IP30
bool "SGI IP30 (Octane/Octane2)"
select ARCH_HAS_PHYS_TO_DMA
select FW_ARC
select FW_ARC64
select BOOT_ELF64
select CEVT_R4K
select CSRC_R4K
select SYNC_R4K if SMP
select ZONE_DMA32
select HAVE_PCI
select IRQ_MIPS_CPU
select IRQ_DOMAIN_HIERARCHY
select NR_CPUS_DEFAULT_2
select PCI_DRIVERS_GENERIC
select PCI_XTALK_BRIDGE
select SYS_HAS_EARLY_PRINTK
select SYS_HAS_CPU_R10000
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_SMP
2020-08-24 19:32:49 +03:00
select WAR_R10000_LLSC
2019-10-24 13:18:29 +03:00
select MIPS_L1_CACHE_SHIFT_7
select ARC_MEMORY
help
These are the SGI Octane and Octane2 graphics workstations. To
compile a Linux kernel that runs on these, say Y here.
2005-04-17 02:20:36 +04:00
config SGI_IP32
2007-07-10 20:33:00 +04:00
bool "SGI IP32 (O2)"
2019-10-09 16:27:14 +03:00
select ARC_MEMORY
select ARC_PROMLIB
2018-06-15 14:08:48 +03:00
select ARCH_HAS_PHYS_TO_DMA
2012-11-15 23:48:50 +04:00
select FW_ARC
select FW_ARC32
2005-04-17 02:20:36 +04:00
select BOOT_ELF32
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2007-11-25 01:33:28 +03:00
select CSRC_R4K
2005-04-17 02:20:36 +04:00
select DMA_NONCOHERENT
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2005-04-17 02:20:36 +04:00
select R5000_CPU_SCACHE
select RM7000_CPU_SCACHE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_R5000
select SYS_HAS_CPU_R10000 if BROKEN
select SYS_HAS_CPU_RM7000
2006-01-19 17:55:42 +03:00
select SYS_HAS_CPU_NEVADA
2005-09-04 02:56:21 +04:00
select SYS_SUPPORTS_64BIT_KERNEL
2005-07-26 02:45:45 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2020-08-24 19:32:48 +03:00
select WAR_ICACHE_REFILLS
2005-07-26 02:45:45 +04:00
help
2005-10-29 22:32:41 +04:00
If you want this kernel to run on SGI O2 workstation, say Y here.
2005-04-17 02:20:36 +04:00
2007-07-27 10:25:43 +04:00
config SIBYTE_CRHINE
bool "Sibyte BCM91120C-CRhine"
2005-10-20 10:57:11 +04:00
select BOOT_ELF32
2007-07-27 10:25:43 +04:00
select SIBYTE_BCM1120
2005-10-20 10:57:11 +04:00
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-10-20 10:57:11 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
2007-07-27 10:25:43 +04:00
config SIBYTE_CARMEL
bool "Sibyte BCM91120x-Carmel"
2005-10-29 22:32:41 +04:00
select BOOT_ELF32
2007-07-27 10:25:43 +04:00
select SIBYTE_BCM1120
2005-10-29 22:32:41 +04:00
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-06-05 07:57:20 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2005-04-17 02:20:36 +04:00
2007-07-27 10:25:43 +04:00
config SIBYTE_CRHONE
bool "Sibyte BCM91125C-CRhone"
2005-10-29 22:32:41 +04:00
select BOOT_ELF32
2007-07-27 10:25:43 +04:00
select SIBYTE_BCM1125
2005-10-29 22:32:41 +04:00
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2007-07-27 10:25:43 +04:00
select SYS_SUPPORTS_HIGHMEM
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2005-04-17 02:20:36 +04:00
2005-10-29 22:32:41 +04:00
config SIBYTE_RHONE
2006-05-10 01:34:53 +04:00
bool "Sibyte BCM91125E-Rhone"
2005-10-29 22:32:41 +04:00
select BOOT_ELF32
select SIBYTE_BCM1125H
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
2005-04-17 02:20:36 +04:00
2007-07-27 10:25:43 +04:00
config SIBYTE_SWARM
bool "Sibyte BCM91250A-SWARM"
2005-10-29 22:32:41 +04:00
select BOOT_ELF32
2010-04-18 17:26:36 +04:00
select HAVE_PATA_PLATFORM
2007-07-27 10:25:43 +04:00
select SIBYTE_SB1250
2005-10-29 22:32:41 +04:00
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2007-07-27 10:25:43 +04:00
select SYS_SUPPORTS_HIGHMEM
2005-03-01 09:33:16 +03:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2007-11-03 05:05:43 +03:00
select ZONE_DMA32 if 64BIT
MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit addressable limit[1]. Consequently if the maximum amount of
memory has been installed, then it will span up to 19GiB.
Many of the evaluation boards we support that are based on one of these
SOCs have their memory soldered and the amount present fits in the
32-bit address range. The BCM91250A SWARM board however has actual DIMM
slots and accepts, depending on the peripherals revision of the SOC, up
to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
I believe this is also the case with the BCM91250C2 LittleSur board.
This means that up to either 3GiB or 7GiB of memory requires 64-bit
addressing to access.
I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
accepts at least as much memory, although I have no documentation or
actual hardware available to verify that.
Both systems have PCI slots installed for use by any PCI option boards,
including ones that only support 32-bit addressing (additionally the
32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
addressing to 32-bits), and there is no IOMMU available. Therefore for
PCI DMA to work in the presence of memory beyond enable swiotlb for the
affected systems.
All the other SOC onchip DMA devices use 40-bit addressing and therefore
can address the whole memory, so only enable swiotlb if PCI support and
support for DMA beyond 4GiB have been both enabled in the configuration
of the kernel.
This shows up as follows:
Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
Determined physical RAM map:
memory: 000000000fe7fe00 @ 0000000000000000 (usable)
memory: 000000001ffffe00 @ 0000000080000000 (usable)
memory: 000000000ffffe00 @ 00000000c0000000 (usable)
memory: 0000000087fffe00 @ 0000000100000000 (usable)
software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)
in the bootstrap log and removes failures like these:
defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi0: Receive buffer allocation failed
fddi0: Adapter open failed!
IP-Config: Failed to open fddi0
defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi1: Receive buffer allocation failed
fddi1: Adapter open failed!
IP-Config: Failed to open fddi1
when memory beyond 4GiB is handed out to devices that can only do 32-bit
addressing.
This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need
DMA32.").
References:
[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
"Memory Map", pp. 34-38
[2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
Corporation, 18 May 2004, Section 3: "Physical Description",
"Supported DRAM", p. 23
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
[paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Patchwork: https://patchwork.linux-mips.org/patch/21108/
References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
2018-11-14 01:42:44 +03:00
select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
2005-03-01 09:33:16 +03:00
2007-07-27 10:25:43 +04:00
config SIBYTE_LITTLESUR
bool "Sibyte BCM91250C2-LittleSur"
2005-10-29 22:32:41 +04:00
select BOOT_ELF32
2010-04-18 17:26:36 +04:00
select HAVE_PATA_PLATFORM
2005-10-29 22:32:41 +04:00
select SIBYTE_SB1250
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
2018-11-14 01:42:37 +03:00
select ZONE_DMA32 if 64BIT
2005-04-17 02:20:36 +04:00
2007-07-27 10:25:43 +04:00
config SIBYTE_SENTOSA
bool "Sibyte BCM91250E-Sentosa"
2005-10-29 22:32:41 +04:00
select BOOT_ELF32
select SIBYTE_SB1250
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit addressable limit[1]. Consequently if the maximum amount of
memory has been installed, then it will span up to 19GiB.
Many of the evaluation boards we support that are based on one of these
SOCs have their memory soldered and the amount present fits in the
32-bit address range. The BCM91250A SWARM board however has actual DIMM
slots and accepts, depending on the peripherals revision of the SOC, up
to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
I believe this is also the case with the BCM91250C2 LittleSur board.
This means that up to either 3GiB or 7GiB of memory requires 64-bit
addressing to access.
I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
accepts at least as much memory, although I have no documentation or
actual hardware available to verify that.
Both systems have PCI slots installed for use by any PCI option boards,
including ones that only support 32-bit addressing (additionally the
32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
addressing to 32-bits), and there is no IOMMU available. Therefore for
PCI DMA to work in the presence of memory beyond enable swiotlb for the
affected systems.
All the other SOC onchip DMA devices use 40-bit addressing and therefore
can address the whole memory, so only enable swiotlb if PCI support and
support for DMA beyond 4GiB have been both enabled in the configuration
of the kernel.
This shows up as follows:
Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
Determined physical RAM map:
memory: 000000000fe7fe00 @ 0000000000000000 (usable)
memory: 000000001ffffe00 @ 0000000080000000 (usable)
memory: 000000000ffffe00 @ 00000000c0000000 (usable)
memory: 0000000087fffe00 @ 0000000100000000 (usable)
software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)
in the bootstrap log and removes failures like these:
defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi0: Receive buffer allocation failed
fddi0: Adapter open failed!
IP-Config: Failed to open fddi0
defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi1: Receive buffer allocation failed
fddi1: Adapter open failed!
IP-Config: Failed to open fddi1
when memory beyond 4GiB is handed out to devices that can only do 32-bit
addressing.
This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need
DMA32.").
References:
[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
"Memory Map", pp. 34-38
[2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
Corporation, 18 May 2004, Section 3: "Physical Description",
"Supported DRAM", p. 23
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
[paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Patchwork: https://patchwork.linux-mips.org/patch/21108/
References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
2018-11-14 01:42:44 +03:00
select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
2005-04-17 02:20:36 +04:00
2007-07-27 10:25:43 +04:00
config SIBYTE_BIGSUR
bool "Sibyte BCM91480B-BigSur"
2005-10-29 22:32:41 +04:00
select BOOT_ELF32
2007-07-27 10:25:43 +04:00
select NR_CPUS_DEFAULT_4
select SIBYTE_BCM1x80
2005-10-29 22:32:41 +04:00
select SWAP_IO_SPACE
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_SB1
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2007-11-02 00:55:39 +03:00
select SYS_SUPPORTS_HIGHMEM
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2007-11-03 05:05:43 +03:00
select ZONE_DMA32 if 64BIT
MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
DRAM controller that supports memory amounts of up to 16GiB, and due to
how the address decoder has been wired in the SOC any memory beyond 1GiB
is actually mapped starting from 4GiB physical up, that is beyond the
32-bit addressable limit[1]. Consequently if the maximum amount of
memory has been installed, then it will span up to 19GiB.
Many of the evaluation boards we support that are based on one of these
SOCs have their memory soldered and the amount present fits in the
32-bit address range. The BCM91250A SWARM board however has actual DIMM
slots and accepts, depending on the peripherals revision of the SOC, up
to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
I believe this is also the case with the BCM91250C2 LittleSur board.
This means that up to either 3GiB or 7GiB of memory requires 64-bit
addressing to access.
I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
accepts at least as much memory, although I have no documentation or
actual hardware available to verify that.
Both systems have PCI slots installed for use by any PCI option boards,
including ones that only support 32-bit addressing (additionally the
32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
addressing to 32-bits), and there is no IOMMU available. Therefore for
PCI DMA to work in the presence of memory beyond enable swiotlb for the
affected systems.
All the other SOC onchip DMA devices use 40-bit addressing and therefore
can address the whole memory, so only enable swiotlb if PCI support and
support for DMA beyond 4GiB have been both enabled in the configuration
of the kernel.
This shows up as follows:
Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
Determined physical RAM map:
memory: 000000000fe7fe00 @ 0000000000000000 (usable)
memory: 000000001ffffe00 @ 0000000080000000 (usable)
memory: 000000000ffffe00 @ 00000000c0000000 (usable)
memory: 0000000087fffe00 @ 0000000100000000 (usable)
software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)
in the bootstrap log and removes failures like these:
defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi0: Receive buffer allocation failed
fddi0: Adapter open failed!
IP-Config: Failed to open fddi0
defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
fddi1: Receive buffer allocation failed
fddi1: Adapter open failed!
IP-Config: Failed to open fddi1
when memory beyond 4GiB is handed out to devices that can only do 32-bit
addressing.
This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need
DMA32.").
References:
[1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
"Memory Map", pp. 34-38
[2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
Corporation, 18 May 2004, Section 3: "Physical Description",
"Supported DRAM", p. 23
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
[paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Patchwork: https://patchwork.linux-mips.org/patch/21108/
References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.")
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
2018-11-14 01:42:44 +03:00
select SWIOTLB if ARCH_DMA_ADDR_T_64BIT && PCI
2005-04-17 02:20:36 +04:00
2006-12-05 19:05:44 +03:00
config SNI_RM
bool "SNI RM200/300/400"
2019-10-09 16:27:14 +03:00
select ARC_MEMORY
select ARC_PROMLIB
2012-11-15 23:48:50 +04:00
select FW_ARC if CPU_LITTLE_ENDIAN
select FW_ARC32 if CPU_LITTLE_ENDIAN
2013-03-25 13:39:54 +04:00
select FW_SNIPROM if CPU_BIG_ENDIAN
2005-09-15 12:52:34 +04:00
select ARCH_MAY_HAVE_PC_FDC
2018-02-05 17:37:43 +03:00
select ARCH_MIGHT_HAVE_PC_PARPORT
2018-02-05 18:40:00 +03:00
select ARCH_MIGHT_HAVE_PC_SERIO
2005-04-17 02:20:36 +04:00
select BOOT_ELF32
2007-10-18 20:48:11 +04:00
select CEVT_R4K
2007-11-25 01:33:28 +03:00
select CSRC_R4K
2007-12-02 15:00:32 +03:00
select DEFAULT_SGI_PARTITION if CPU_BIG_ENDIAN
2005-04-17 02:20:36 +04:00
select DMA_NONCOHERENT
select GENERIC_ISA_DMA
2018-11-15 22:05:37 +03:00
select HAVE_EISA
2011-06-01 22:05:10 +04:00
select HAVE_PCSPKR_PLATFORM
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2007-10-12 02:46:10 +04:00
select I8253
2005-04-17 02:20:36 +04:00
select I8259
select ISA
2020-09-14 19:05:00 +03:00
select MIPS_L1_CACHE_SHIFT_6
2006-06-13 15:59:01 +04:00
select SWAP_IO_SPACE if CPU_BIG_ENDIAN
2005-10-21 01:33:09 +04:00
select SYS_HAS_CPU_R4X00
2006-06-13 15:59:01 +04:00
select SYS_HAS_CPU_R5000
2006-12-28 20:22:32 +03:00
select SYS_HAS_CPU_R10000
2006-06-13 15:59:01 +04:00
select R5000_CPU_SCACHE
2007-03-01 14:56:43 +03:00
select SYS_HAS_EARLY_PRINTK
2005-09-04 02:56:21 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
2013-01-17 06:53:19 +04:00
select SYS_SUPPORTS_64BIT_KERNEL
2006-06-13 15:59:01 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
2005-08-10 19:17:11 +04:00
select SYS_SUPPORTS_HIGHMEM
2005-10-29 22:32:41 +04:00
select SYS_SUPPORTS_LITTLE_ENDIAN
2020-08-24 19:32:45 +03:00
select WAR_R4600_V2_HIT_CACHEOP
2005-04-17 02:20:36 +04:00
help
2006-12-05 19:05:44 +03:00
The SNI RM200/300/400 are MIPS-based machines manufactured by
Siemens Nixdorf Informationssysteme (SNI), parent company of Pyramid
2005-04-17 02:20:36 +04:00
Technology and now in turn merged with Fujitsu. Say Y here to
support this machine type.
2008-07-11 18:27:54 +04:00
config MACH_TX39XX
bool "Toshiba TX39 series based machines"
2005-10-29 22:32:41 +04:00
2008-07-11 18:27:54 +04:00
config MACH_TX49XX
bool "Toshiba TX49 series based machines"
2020-08-24 19:32:47 +03:00
select WAR_TX49XX_ICACHE_INDEX_INV
2005-10-29 22:32:41 +04:00
2008-07-16 19:12:25 +04:00
config MIKROTIK_RB532
bool "Mikrotik RB532 boards"
select CEVT_R4K
select CSRC_R4K
select DMA_NONCOHERENT
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2008-07-16 19:12:25 +04:00
select SYS_HAS_CPU_MIPS32_R1
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SWAP_IO_SPACE
select BOOT_RAW
2016-04-19 12:23:22 +03:00
select GPIOLIB
2014-01-14 21:54:38 +04:00
select MIPS_L1_CACHE_SHIFT_4
2008-07-16 19:12:25 +04:00
help
Support the Mikrotik(tm) RouterBoard 532 series,
based on the IDT RC32434 SoC.
2013-05-22 19:10:46 +04:00
config CAVIUM_OCTEON_SOC
bool "Cavium Networks Octeon SoC based boards"
2008-12-12 02:33:38 +03:00
select CEVT_R4K
2018-01-10 18:21:13 +03:00
select ARCH_HAS_PHYS_TO_DMA
2018-11-15 22:05:36 +03:00
select HAVE_RAPIDIO
2018-04-03 17:24:20 +03:00
select PHYS_ADDR_T_64BIT
2008-12-12 02:33:38 +03:00
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_BIG_ENDIAN
2012-10-17 02:39:09 +04:00
select EDAC_SUPPORT
2015-05-21 20:59:31 +03:00
select EDAC_ATOMIC_SCRUB
2015-03-20 19:11:58 +03:00
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_HOTPLUG_CPU if CPU_BIG_ENDIAN
2008-12-12 02:33:38 +03:00
select SYS_HAS_EARLY_PRINTK
2009-02-02 22:30:59 +03:00
select SYS_HAS_CPU_CAVIUM_OCTEON
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2020-03-25 10:45:29 +03:00
select HAVE_PLAT_DELAY
select HAVE_PLAT_FW_INIT_CMDLINE
select HAVE_PLAT_MEMCPY
2010-10-02 00:27:30 +04:00
select ZONE_DMA32
2011-08-20 19:44:00 +04:00
select HOLES_IN_ZONE
2016-04-19 12:23:22 +03:00
select GPIOLIB
2014-05-29 01:52:05 +04:00
select USE_OF
select ARCH_SPARSEMEM_ENABLE
select SYS_SUPPORTS_SMP
2017-09-28 20:34:04 +03:00
select NR_CPUS_DEFAULT_64
select MIPS_NR_CPU_NR_MAP_1024
2014-08-22 00:04:22 +04:00
select BUILTIN_DTB
2015-03-05 17:31:30 +03:00
select MTD_COMPLEX_MAPPINGS
2018-04-24 10:00:54 +03:00
select SWIOTLB
2016-12-13 23:25:37 +03:00
select SYS_SUPPORTS_RELOCATABLE
2008-12-12 02:33:38 +03:00
help
This option supports all of the Octeon reference boards from Cavium
Networks. It builds a kernel that dynamically determines the Octeon
CPU type and supports all known board reference implementations.
Some of the supported boards are:
EBT3000
EBH3000
EBH3100
Thunder
Kodama
Hikari
Say Y here for most Octeon reference boards.
2011-05-07 00:06:57 +04:00
config NLM_XLR_BOARD
bool "Netlogic XLR/XLS based systems"
select BOOT_ELF32
select NLM_COMMON
select SYS_HAS_CPU_XLR
select SYS_SUPPORTS_SMP
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2011-05-07 00:06:57 +04:00
select SWAP_IO_SPACE
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
2018-04-03 17:24:20 +03:00
select PHYS_ADDR_T_64BIT
2011-05-07 00:06:57 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select NR_CPUS_DEFAULT_32
select CEVT_R4K
select CSRC_R4K
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2012-10-31 16:01:33 +04:00
select ZONE_DMA32 if 64BIT
2011-05-07 00:06:57 +04:00
select SYNC_R4K
select SYS_HAS_EARLY_PRINTK
2013-06-10 10:33:26 +04:00
select SYS_SUPPORTS_ZBOOT
select SYS_SUPPORTS_ZBOOT_UART16550
2011-05-07 00:06:57 +04:00
help
Support for systems based on Netlogic XLR and XLS processors.
Say Y here if you have a XLR or XLS based board.
2011-11-16 04:21:28 +04:00
config NLM_XLP_BOARD
bool "Netlogic XLP based systems"
select BOOT_ELF32
select NLM_COMMON
select SYS_HAS_CPU_XLP
select SYS_SUPPORTS_SMP
2018-11-15 22:05:32 +03:00
select HAVE_PCI
2011-11-16 04:21:28 +04:00
select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
2018-04-03 17:24:20 +03:00
select PHYS_ADDR_T_64BIT
2016-04-19 12:23:22 +03:00
select GPIOLIB
2011-11-16 04:21:28 +04:00
select SYS_SUPPORTS_BIG_ENDIAN
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_HIGHMEM
select NR_CPUS_DEFAULT_32
select CEVT_R4K
select CSRC_R4K
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2012-10-31 16:01:33 +04:00
select ZONE_DMA32 if 64BIT
2011-11-16 04:21:28 +04:00
select SYNC_R4K
select SYS_HAS_EARLY_PRINTK
2012-07-13 20:23:22 +04:00
select USE_OF
2013-06-10 10:33:26 +04:00
select SYS_SUPPORTS_ZBOOT
select SYS_SUPPORTS_ZBOOT_UART16550
2011-11-16 04:21:28 +04:00
help
This board is based on Netlogic XLP Processor.
Say Y here if you have a XLP based board.
2005-10-29 22:32:41 +04:00
endchoice
2005-04-17 02:20:36 +04:00
2008-09-16 21:12:16 +04:00
source "arch/mips/alchemy/Kconfig"
2014-10-29 02:18:39 +03:00
source "arch/mips/ath25/Kconfig"
2011-01-04 23:28:14 +03:00
source "arch/mips/ath79/Kconfig"
2011-07-23 03:20:13 +04:00
source "arch/mips/bcm47xx/Kconfig"
2009-08-18 16:23:37 +04:00
source "arch/mips/bcm63xx/Kconfig"
2014-12-25 20:49:20 +03:00
source "arch/mips/bmips/Kconfig"
2016-10-05 20:18:20 +03:00
source "arch/mips/generic/Kconfig"
2020-09-06 22:29:33 +03:00
source "arch/mips/ingenic/Kconfig"
2005-10-29 22:32:41 +04:00
source "arch/mips/jazz/Kconfig"
2011-03-30 11:27:48 +04:00
source "arch/mips/lantiq/Kconfig"
2016-01-14 04:15:39 +03:00
source "arch/mips/pic32/Kconfig"
2015-08-06 14:22:43 +03:00
source "arch/mips/pistachio/Kconfig"
2013-01-21 01:05:30 +04:00
source "arch/mips/ralink/Kconfig"
2005-02-07 04:27:14 +03:00
source "arch/mips/sgi-ip27/Kconfig"
2005-02-03 17:28:23 +03:00
source "arch/mips/sibyte/Kconfig"
2008-07-10 19:31:36 +04:00
source "arch/mips/txx9/Kconfig"
2005-10-29 22:32:41 +04:00
source "arch/mips/vr41xx/Kconfig"
2008-12-12 02:33:38 +03:00
source "arch/mips/cavium-octeon/Kconfig"
2019-10-20 17:43:14 +03:00
source "arch/mips/loongson2ef/Kconfig"
2015-04-21 05:00:35 +03:00
source "arch/mips/loongson32/Kconfig"
source "arch/mips/loongson64/Kconfig"
2011-05-07 00:06:57 +04:00
source "arch/mips/netlogic/Kconfig"
2005-02-03 17:28:23 +03:00
2005-10-29 22:32:41 +04:00
endmenu
[PATCH] bitops: mips: use generic bitops
- remove __{,test_and_}{set,clear,change}_bit() and test_bit()
- unless defined(CONFIG_CPU_MIPS32) or defined(CONFIG_CPU_MIPS64)
- remove __ffs()
- remove ffs()
- remove ffz()
- remove fls()
- remove fls64()
- remove find_{next,first}{,_zero}_bit()
- remove sched_find_first_bit()
- remove generic_hweight64()
- remove generic_hweight{32,16,8}()
- remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
- remove ext2_{set,clear}_bit_atomic()
- remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-26 13:39:30 +04:00
config GENERIC_HWEIGHT
bool
default y
2005-04-17 02:20:36 +04:00
config GENERIC_CALIBRATE_DELAY
bool
default y
2008-11-11 11:05:16 +03:00
config SCHED_OMIT_FRAME_POINTER
2006-04-04 08:11:45 +04:00
bool
default y
2005-04-17 02:20:36 +04:00
#
# Select some configuration options automatically based on user selections.
#
2012-11-15 23:48:50 +04:00
config FW_ARC
2005-04-17 02:20:36 +04:00
bool
2005-09-15 12:52:34 +04:00
config ARCH_MAY_HAVE_PC_FDC
bool
2007-06-15 01:55:31 +04:00
config BOOT_RAW
bool
2007-11-01 04:57:55 +03:00
config CEVT_BCM1480
bool
2008-04-25 07:11:44 +04:00
config CEVT_DS1287
bool
2007-10-22 14:43:15 +04:00
config CEVT_GT641XX
bool
2007-10-18 20:48:11 +04:00
config CEVT_R4K
bool
2007-11-01 04:57:55 +03:00
config CEVT_SB1250
bool
2007-10-24 20:34:09 +04:00
config CEVT_TXX9
bool
2007-11-01 04:57:55 +03:00
config CSRC_BCM1480
bool
2008-04-24 04:48:40 +04:00
config CSRC_IOASIC
bool
2007-11-25 01:33:28 +03:00
config CSRC_R4K
2020-05-21 17:07:23 +03:00
select CLOCKSOURCE_WATCHDOG if CPU_FREQ
2007-11-25 01:33:28 +03:00
bool
2007-11-01 04:57:55 +03:00
config CSRC_SB1250
bool
MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()
Add user-mode implementations of gettimeofday() and clock_gettime() to
the VDSO. This is currently usable with 2 clocksources: the CP0 count
register, which is accessible to user-mode via RDHWR on R2 and later
cores, or the MIPS Global Interrupt Controller (GIC) timer, which
provides a "user-mode visible" section containing a mirror of its
counter registers. This section must be mapped into user memory, which
is done below the VDSO data page.
When a supported clocksource is not in use, the VDSO functions will
return -ENOSYS, which causes libc to fall back on the standard syscall
path.
When support for neither of these clocksources is compiled into the
kernel at all, the VDSO still provides clock_gettime(), as the coarse
realtime/monotonic clocks can still be implemented. However,
gettimeofday() is not provided in this case as nothing can be done
without a suitable clocksource. This causes the symbol lookup to fail
in libc and it will then always use the standard syscall path.
This patch includes a workaround for a bug in QEMU which results in
RDHWR on the CP0 count register always returning a constant (incorrect)
value. A fix for this has been submitted, and the workaround can be
removed after the fix has been in stable releases for a reasonable
amount of time.
A simple performance test which calls gettimeofday() 1000 times in a
loop and calculates the average execution time gives the following
results on a Malta + I6400 (running at 20MHz):
- Syscall: ~31000 ns
- VDSO (GIC): ~15000 ns
- VDSO (CP0): ~9500 ns
[markos.chandras@imgtec.com:
- Minor code re-arrangements in order for mappings to be made
in the order they appear to the process' address space.
- Move do_{monotonic, realtime} outside of the MIPS_CLOCK_VSYSCALL ifdef
- Use gic_get_usm_range so we can do the GIC mapping in the
arch/mips/kernel/vdso instead of the GIC irqchip driver]
Signed-off-by: Alex Smith <alex.smith@imgtec.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11338/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-10-21 11:57:44 +03:00
config MIPS_CLOCK_VSYSCALL
def_bool CSRC_R4K || CLKSRC_MIPS_GIC
2008-04-04 19:55:41 +04:00
config GPIO_TXX9
2016-04-19 12:23:22 +03:00
select GPIOLIB
2008-04-04 19:55:41 +04:00
bool
2012-11-15 23:48:50 +04:00
config FW_CFE
2007-09-05 10:58:26 +04:00
bool
2015-07-29 23:44:53 +03:00
config ARCH_SUPPORTS_UPROBES
bool
2013-09-27 16:41:44 +04:00
config DMA_MAYBE_COHERENT
2018-08-19 15:53:20 +03:00
select ARCH_HAS_DMA_COHERENCE_H
2013-09-27 16:41:44 +04:00
select DMA_NONCOHERENT
bool
2016-10-05 20:18:16 +03:00
config DMA_PERDEV_COHERENT
bool
2019-01-07 21:36:20 +03:00
select ARCH_HAS_SETUP_DMA_OPS
2018-08-16 16:47:53 +03:00
select DMA_NONCOHERENT
2016-10-05 20:18:16 +03:00
2005-09-04 02:56:19 +04:00
config DMA_NONCOHERENT
bool
2019-08-26 10:22:13 +03:00
#
# MIPS allows mixing "slightly different" Cacheability and Coherency
# Attribute bits. It is believed that the uncached access through
# KSEG1 and the implementation specific "uncached accelerated" used
# by pgprot_writcombine can be mixed, and the latter sometimes provides
# significant advantages.
#
2019-08-26 10:03:44 +03:00
select ARCH_HAS_DMA_WRITE_COMBINE
2020-02-22 02:55:43 +03:00
select ARCH_HAS_DMA_PREP_COHERENT
2018-06-15 14:08:46 +03:00
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
2020-02-22 02:55:43 +03:00
select ARCH_HAS_DMA_SET_UNCACHED
2019-10-29 13:01:37 +03:00
select DMA_NONCOHERENT_MMAP
select NEED_DMA_MAP_STATE
2005-09-04 02:56:19 +04:00
2007-03-01 14:56:43 +03:00
config SYS_HAS_EARLY_PRINTK
2005-04-17 02:20:36 +04:00
bool
2009-06-23 13:00:31 +04:00
config SYS_SUPPORTS_HOTPLUG_CPU
2007-08-07 17:52:17 +04:00
bool
2005-04-17 02:20:36 +04:00
config MIPS_BONITO64
bool
config MIPS_MSC
bool
2008-04-28 20:14:26 +04:00
config SYNC_R4K
bool
2014-04-08 02:39:19 +04:00
config NO_IOPORT_MAP
2007-05-29 18:08:07 +04:00
def_bool n
2014-11-13 14:25:27 +03:00
config GENERIC_CSUM
2020-01-22 13:58:50 +03:00
def_bool CPU_NO_LOAD_STORE_LR
2014-11-13 14:25:27 +03:00
2007-08-24 19:48:30 +04:00
config GENERIC_ISA_DMA
bool
select ZONE_DMA if GENERIC_ISA_DMA_SUPPORT_BROKEN=n
2010-10-18 07:55:21 +04:00
select ISA_DMA_API
2007-08-24 19:48:30 +04:00
2006-11-30 04:14:51 +03:00
config GENERIC_ISA_DMA_SUPPORT_BROKEN
bool
2007-08-24 19:48:30 +04:00
select GENERIC_ISA_DMA
2006-11-30 04:14:51 +03:00
2020-03-25 10:45:29 +03:00
config HAVE_PLAT_DELAY
bool
config HAVE_PLAT_FW_INIT_CMDLINE
bool
config HAVE_PLAT_MEMCPY
bool
2010-10-18 07:55:21 +04:00
config ISA_DMA_API
bool
2011-08-20 19:44:00 +04:00
config HOLES_IN_ZONE
bool
2016-03-31 12:05:39 +03:00
config SYS_SUPPORTS_RELOCATABLE
bool
help
2019-03-11 18:54:27 +03:00
Selected if the platform supports relocating the kernel.
The platform must provide plat_get_fdt() if it selects CONFIG_USE_OF
to allow access to command line and entropy sources.
2016-03-31 12:05:39 +03:00
2017-06-14 01:28:46 +03:00
config MIPS_CBPF_JIT
def_bool y
depends on BPF_JIT && HAVE_CBPF_JIT
config MIPS_EBPF_JIT
def_bool y
depends on BPF_JIT && HAVE_EBPF_JIT
2005-10-29 22:32:41 +04:00
#
2012-04-13 19:14:11 +04:00
# Endianness selection. Sufficiently obscure so many users don't know what to
2005-10-29 22:32:41 +04:00
# answer,so we try hard to limit the available choices. Also the use of a
# choice statement should be more obvious to the user.
#
choice
2012-04-13 19:14:11 +04:00
prompt "Endianness selection"
2005-04-17 02:20:36 +04:00
help
Some MIPS machines can be configured for either little or big endian
2005-10-29 22:32:41 +04:00
byte order. These modes require different kernels and a different
2006-11-30 07:22:59 +03:00
Linux distribution. In general there is one preferred byteorder for a
2005-10-29 22:32:41 +04:00
particular system but some systems are just as commonly used in the
2007-05-09 09:12:20 +04:00
one or the other endianness.
2005-10-29 22:32:41 +04:00
config CPU_BIG_ENDIAN
bool "Big endian"
depends on SYS_SUPPORTS_BIG_ENDIAN
config CPU_LITTLE_ENDIAN
bool "Little endian"
depends on SYS_SUPPORTS_LITTLE_ENDIAN
endchoice
2010-07-24 05:41:43 +04:00
config EXPORT_UASM
bool
2007-02-09 20:08:58 +03:00
config SYS_SUPPORTS_APM_EMULATION
bool
2005-10-29 22:32:41 +04:00
config SYS_SUPPORTS_BIG_ENDIAN
bool
config SYS_SUPPORTS_LITTLE_ENDIAN
bool
2005-04-17 02:20:36 +04:00
2009-05-28 04:47:46 +04:00
config SYS_SUPPORTS_HUGETLBFS
bool
2019-07-16 00:40:01 +03:00
depends on CPU_SUPPORTS_HUGEPAGES
2009-05-28 04:47:46 +04:00
default y
2012-10-17 02:48:10 +04:00
config MIPS_HUGE_TLB_SUPPORT
def_bool HUGETLB_PAGE || TRANSPARENT_HUGEPAGE
2005-04-17 02:20:36 +04:00
config IRQ_CPU_RM7K
bool
2007-06-15 01:55:31 +04:00
config IRQ_MSP_SLP
bool
config IRQ_MSP_CIC
bool
2007-08-02 18:35:53 +04:00
config IRQ_TXX9
bool
2007-09-13 18:51:26 +04:00
config IRQ_GT641XX
bool
2007-03-14 15:51:26 +03:00
config PCI_GT64XXX_PCI0
2005-04-17 02:20:36 +04:00
bool
2019-05-08 00:09:13 +03:00
config PCI_XTALK_BRIDGE
bool
2007-06-15 01:55:31 +04:00
config NO_EXCEPT_FILL
bool
2014-11-13 16:32:03 +03:00
config MIPS_SPRAM
bool
2005-04-17 02:20:36 +04:00
config SWAP_IO_SPACE
bool
2007-12-02 15:00:32 +03:00
config SGI_HAS_INDYDOG
bool
2008-07-10 22:29:55 +04:00
config SGI_HAS_HAL2
bool
2007-12-02 15:00:32 +03:00
config SGI_HAS_SEEQ
bool
config SGI_HAS_WD93
bool
config SGI_HAS_ZILOG
bool
config SGI_HAS_I8042
bool
config DEFAULT_SGI_PARTITION
bool
2012-11-15 23:48:50 +04:00
config FW_ARC32
2005-10-29 22:32:41 +04:00
bool
2013-03-25 13:39:54 +04:00
config FW_SNIPROM
2008-01-05 01:31:07 +03:00
bool
2005-04-17 02:20:36 +04:00
config BOOT_ELF32
bool
2014-01-14 21:54:38 +04:00
config MIPS_L1_CACHE_SHIFT_4
bool
config MIPS_L1_CACHE_SHIFT_5
bool
config MIPS_L1_CACHE_SHIFT_6
bool
config MIPS_L1_CACHE_SHIFT_7
bool
2005-04-17 02:20:36 +04:00
config MIPS_L1_CACHE_SHIFT
int
2014-01-14 21:54:39 +04:00
default "7" if MIPS_L1_CACHE_SHIFT_7
2014-12-25 20:49:09 +03:00
default "6" if MIPS_L1_CACHE_SHIFT_6
default "5" if MIPS_L1_CACHE_SHIFT_5
default "4" if MIPS_L1_CACHE_SHIFT_4
2005-04-17 02:20:36 +04:00
default "5"
2019-10-22 19:13:15 +03:00
config ARC_CMDLINE_ONLY
bool
2005-04-17 02:20:36 +04:00
config ARC_CONSOLE
bool "ARC console support"
2007-12-02 15:00:32 +03:00
depends on SGI_IP22 || SGI_IP28 || (SNI_RM && CPU_LITTLE_ENDIAN)
2005-04-17 02:20:36 +04:00
config ARC_MEMORY
bool
config ARC_PROMLIB
bool
2012-11-15 23:48:50 +04:00
config FW_ARC64
2005-04-17 02:20:36 +04:00
bool
config BOOT_ELF64
bool
menu "CPU selection"
choice
prompt "CPU type"
default CPU_R4X00
2019-10-20 17:43:13 +03:00
config CPU_LOONGSON64
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
bool "Loongson 64-bit CPU"
2019-10-20 17:43:13 +03:00
depends on SYS_HAS_CPU_LOONGSON64
2018-06-15 14:08:41 +03:00
select ARCH_HAS_PHYS_TO_DMA
2020-01-13 13:15:00 +03:00
select CPU_MIPSR2
select CPU_HAS_PREFETCH
2014-03-21 14:44:07 +04:00
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
MIPS: Loongson: Add Loongson-3A R4 basic support
All Loongson-3 CPU family:
Code-name Brand-name PRId
Loongson-3A R1 Loongson-3A1000 0x6305
Loongson-3A R2 Loongson-3A2000 0x6308
Loongson-3A R2.1 Loongson-3A2000 0x630c
Loongson-3A R3 Loongson-3A3000 0x6309
Loongson-3A R3.1 Loongson-3A3000 0x630d
Loongson-3A R4 Loongson-3A4000 0xc000
Loongson-3B R1 Loongson-3B1000 0x6306
Loongson-3B R2 Loongson-3B1500 0x6307
Features of R4 revision of Loongson-3A:
- All R2/R3 features, including SFB, V-Cache, FTLB, RIXI, DSP, etc.
- Support variable ASID bits.
- Support MSA and VZ extensions.
- Support CPUCFG (CPU config) and CSR (Control and Status Register)
extensions.
- 64 entries of VTLB (classic TLB), 2048 entries of FTLB (8-way
set-associative).
Now 64-bit Loongson processors has three types of PRID.IMP: 0x6300 is
the classic one so we call it PRID_IMP_LOONGSON_64C (e.g., Loongson-2E/
2F/3A1000/3B1000/3B1500/3A2000/3A3000), 0x6100 is for some processors
which has reduced capabilities so we call it PRID_IMP_LOONGSON_64R
(e.g., Loongson-2K), 0xc000 is supposed to cover all new processors in
general (e.g., Loongson-3A4000+) so we call it PRID_IMP_LOONGSON_64G.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-09-21 16:50:27 +03:00
select CPU_SUPPORTS_MSA
2020-01-13 13:15:00 +03:00
select CPU_DIEI_BROKEN if !LOONGSON3_ENHANCEMENT
select CPU_MIPSR2_IRQ_VI
2014-03-21 14:44:07 +04:00
select WEAK_ORDERING
select WEAK_REORDERING_BEYOND_LLSC
MIPS: Loongson: Add Loongson-3A R4 basic support
All Loongson-3 CPU family:
Code-name Brand-name PRId
Loongson-3A R1 Loongson-3A1000 0x6305
Loongson-3A R2 Loongson-3A2000 0x6308
Loongson-3A R2.1 Loongson-3A2000 0x630c
Loongson-3A R3 Loongson-3A3000 0x6309
Loongson-3A R3.1 Loongson-3A3000 0x630d
Loongson-3A R4 Loongson-3A4000 0xc000
Loongson-3B R1 Loongson-3B1000 0x6306
Loongson-3B R2 Loongson-3B1500 0x6307
Features of R4 revision of Loongson-3A:
- All R2/R3 features, including SFB, V-Cache, FTLB, RIXI, DSP, etc.
- Support variable ASID bits.
- Support MSA and VZ extensions.
- Support CPUCFG (CPU config) and CSR (Control and Status Register)
extensions.
- 64 entries of VTLB (classic TLB), 2048 entries of FTLB (8-way
set-associative).
Now 64-bit Loongson processors has three types of PRID.IMP: 0x6300 is
the classic one so we call it PRID_IMP_LOONGSON_64C (e.g., Loongson-2E/
2F/3A1000/3B1000/3B1500/3A2000/3A3000), 0x6100 is for some processors
which has reduced capabilities so we call it PRID_IMP_LOONGSON_64R
(e.g., Loongson-2K), 0xc000 is supposed to cover all new processors in
general (e.g., Loongson-3A4000+) so we call it PRID_IMP_LOONGSON_64G.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-09-21 16:50:27 +03:00
select MIPS_ASID_BITS_VARIABLE
2016-03-03 04:45:09 +03:00
select MIPS_PGD_C0_CONTEXT
2017-03-16 16:00:28 +03:00
select MIPS_L1_CACHE_SHIFT_6
2016-04-19 12:23:22 +03:00
select GPIOLIB
2018-04-24 10:00:54 +03:00
select SWIOTLB
2020-05-23 10:56:41 +03:00
select HAVE_KVM
2014-03-21 14:44:07 +04:00
help
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
The Loongson GSx64(GS264/GS464/GS464E/GS464V) series of processor
cores implements the MIPS64R2 instruction set with many extensions,
including most 64-bit Loongson-2 (2H, 2K) and Loongson-3 (3A1000,
3B1000, 3B1500, 3A2000, 3A3000 and 3A4000) processors. However, old
Loongson-2E/2F is not covered here and will be removed in future.
config LOONGSON3_ENHANCEMENT
bool "New Loongson-3 CPU Enhancements"
MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT
New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A R1,
Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as FTLB,
L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPv2 ASE, User Local
register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer), Fast
TLB refill support, etc.
This patch introduce a config option, CONFIG_LOONGSON3_ENHANCEMENT, to
enable those enhancements which are not probed at run time. If you want
a generic kernel to run on all Loongson 3 machines, please say 'N'
here. If you want a high-performance kernel to run on new Loongson 3
machines only, please say 'Y' here.
Some additional explanations:
1) SFB locates between core and L1 cache, it causes memory access out
of order, so writel/outl (and other similar functions) need a I/O
reorder barrier.
2) Loongson 3 has a bug that di instruction can not save the irqflag,
so arch_local_irq_save() is modified. Since CPU_MIPSR2 is selected
by CONFIG_LOONGSON3_ENHANCEMENT, generic kernel doesn't use ei/di
at all.
3) CPU_HAS_PREFETCH is selected by CONFIG_LOONGSON3_ENHANCEMENT, so
MIPS_CPU_PREFETCH (used by uasm) probing is also put in this patch.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J . Hill <sjhill@realitydiluted.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12755/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-03-03 04:45:13 +03:00
default n
2019-10-20 17:43:13 +03:00
depends on CPU_LOONGSON64
MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT
New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A R1,
Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as FTLB,
L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPv2 ASE, User Local
register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer), Fast
TLB refill support, etc.
This patch introduce a config option, CONFIG_LOONGSON3_ENHANCEMENT, to
enable those enhancements which are not probed at run time. If you want
a generic kernel to run on all Loongson 3 machines, please say 'N'
here. If you want a high-performance kernel to run on new Loongson 3
machines only, please say 'Y' here.
Some additional explanations:
1) SFB locates between core and L1 cache, it causes memory access out
of order, so writel/outl (and other similar functions) need a I/O
reorder barrier.
2) Loongson 3 has a bug that di instruction can not save the irqflag,
so arch_local_irq_save() is modified. Since CPU_MIPSR2 is selected
by CONFIG_LOONGSON3_ENHANCEMENT, generic kernel doesn't use ei/di
at all.
3) CPU_HAS_PREFETCH is selected by CONFIG_LOONGSON3_ENHANCEMENT, so
MIPS_CPU_PREFETCH (used by uasm) probing is also put in this patch.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J . Hill <sjhill@realitydiluted.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12755/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-03-03 04:45:13 +03:00
help
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
New Loongson-3 cores (since Loongson-3A R2, as opposed to Loongson-3A
MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT
New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A R1,
Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as FTLB,
L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPv2 ASE, User Local
register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer), Fast
TLB refill support, etc.
This patch introduce a config option, CONFIG_LOONGSON3_ENHANCEMENT, to
enable those enhancements which are not probed at run time. If you want
a generic kernel to run on all Loongson 3 machines, please say 'N'
here. If you want a high-performance kernel to run on new Loongson 3
machines only, please say 'Y' here.
Some additional explanations:
1) SFB locates between core and L1 cache, it causes memory access out
of order, so writel/outl (and other similar functions) need a I/O
reorder barrier.
2) Loongson 3 has a bug that di instruction can not save the irqflag,
so arch_local_irq_save() is modified. Since CPU_MIPSR2 is selected
by CONFIG_LOONGSON3_ENHANCEMENT, generic kernel doesn't use ei/di
at all.
3) CPU_HAS_PREFETCH is selected by CONFIG_LOONGSON3_ENHANCEMENT, so
MIPS_CPU_PREFETCH (used by uasm) probing is also put in this patch.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J . Hill <sjhill@realitydiluted.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12755/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-03-03 04:45:13 +03:00
R1, Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as
2019-10-20 17:43:13 +03:00
FTLB, L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPr2 ASE, User
MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT
New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A R1,
Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as FTLB,
L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPv2 ASE, User Local
register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer), Fast
TLB refill support, etc.
This patch introduce a config option, CONFIG_LOONGSON3_ENHANCEMENT, to
enable those enhancements which are not probed at run time. If you want
a generic kernel to run on all Loongson 3 machines, please say 'N'
here. If you want a high-performance kernel to run on new Loongson 3
machines only, please say 'Y' here.
Some additional explanations:
1) SFB locates between core and L1 cache, it causes memory access out
of order, so writel/outl (and other similar functions) need a I/O
reorder barrier.
2) Loongson 3 has a bug that di instruction can not save the irqflag,
so arch_local_irq_save() is modified. Since CPU_MIPSR2 is selected
by CONFIG_LOONGSON3_ENHANCEMENT, generic kernel doesn't use ei/di
at all.
3) CPU_HAS_PREFETCH is selected by CONFIG_LOONGSON3_ENHANCEMENT, so
MIPS_CPU_PREFETCH (used by uasm) probing is also put in this patch.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J . Hill <sjhill@realitydiluted.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12755/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-03-03 04:45:13 +03:00
Local register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer),
Fast TLB refill support, etc.
This option enable those enhancements which are not probed at run
time. If you want a generic kernel to run on all Loongson 3 machines,
please say 'N' here. If you want a high-performance kernel to run on
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
new Loongson-3 machines only, please say 'Y' here.
MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT
New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A R1,
Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as FTLB,
L1-VCache, EI/DI/Wait/Prefetch instruction, DSP/DSPv2 ASE, User Local
register, Read-Inhibit/Execute-Inhibit, SFB (Store Fill Buffer), Fast
TLB refill support, etc.
This patch introduce a config option, CONFIG_LOONGSON3_ENHANCEMENT, to
enable those enhancements which are not probed at run time. If you want
a generic kernel to run on all Loongson 3 machines, please say 'N'
here. If you want a high-performance kernel to run on new Loongson 3
machines only, please say 'Y' here.
Some additional explanations:
1) SFB locates between core and L1 cache, it causes memory access out
of order, so writel/outl (and other similar functions) need a I/O
reorder barrier.
2) Loongson 3 has a bug that di instruction can not save the irqflag,
so arch_local_irq_save() is modified. Since CPU_MIPSR2 is selected
by CONFIG_LOONGSON3_ENHANCEMENT, generic kernel doesn't use ei/di
at all.
3) CPU_HAS_PREFETCH is selected by CONFIG_LOONGSON3_ENHANCEMENT, so
MIPS_CPU_PREFETCH (used by uasm) probing is also put in this patch.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Steven J . Hill <sjhill@realitydiluted.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12755/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-03-03 04:45:13 +03:00
MIPS: Loongson: Introduce and use loongson_llsc_mb()
On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
lld/scd is very weak ordering. We should add sync instructions "before
each ll/lld" and "at the branch-target between ll/sc" to workaround.
Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
heavy load test with LTP).
Below is the explaination of CPU designer:
"For Loongson 3 family, when a memory access instruction (load, store,
or prefetch)'s executing occurs between the execution of LL and SC, the
success or failure of SC is not predictable. Although programmer would
not insert memory access instructions between LL and SC, the memory
instructions before LL in program-order, may dynamically executed
between the execution of LL/SC, so a memory fence (SYNC) is needed
before LL/LLD to avoid this situation.
Since Loongson-3A R2 (3A2000), we have improved our hardware design to
handle this case. But we later deduce a rarely circumstance that some
speculatively executed memory instructions due to branch misprediction
between LL/SC still fall into the above case, so a memory fence (SYNC)
at branch-target (if its target is not between LL/SC) is needed for
Loongson 3A1000, 3B1500, 3A2000 and 3A3000.
Our processor is continually evolving and we aim to to remove all these
workaround-SYNCs around LL/SC for new-come processor."
Here is an example:
Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
time('sc' return 1), and the variable is only *added by 1*, sometimes,
which is wrong and unacceptable(it should be added by 2).
Why disable fix-loongson3-llsc in compiler?
Because compiler fix will cause problems in kernel's __ex_table section.
This patch fix all the cases in kernel, but:
+. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
the ll and branch-target coincidently such as atomic_sub_if_positive/
cmpxchg/xchg, just like this one.
+. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
edac.h
+. local_ops and cmpxchg_local should not be affected by this bug since
only the owner can write.
+. mips_atomic_set for syscall.c is deprecated and rarely used, just let
it go
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Huang Pei <huangpei@loongson.cn>
[paul.burton@mips.com:
- Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
a comment describing why it's there.
- Make loongson_llsc_mb() a no-op when
CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
barrier.
- Add a comment describing the bug & how loongson_llsc_mb() helps
in asm/barrier.h.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: ambrosehua@gmail.com
Cc: Steven J . Hill <Steven.Hill@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Li Xuefeng <lixuefeng@loongson.cn>
Cc: Xu Chenghua <xuchenghua@loongson.cn>
2019-01-15 11:04:54 +03:00
config CPU_LOONGSON3_WORKAROUNDS
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
bool "Old Loongson-3 LLSC Workarounds"
MIPS: Loongson: Introduce and use loongson_llsc_mb()
On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
lld/scd is very weak ordering. We should add sync instructions "before
each ll/lld" and "at the branch-target between ll/sc" to workaround.
Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
heavy load test with LTP).
Below is the explaination of CPU designer:
"For Loongson 3 family, when a memory access instruction (load, store,
or prefetch)'s executing occurs between the execution of LL and SC, the
success or failure of SC is not predictable. Although programmer would
not insert memory access instructions between LL and SC, the memory
instructions before LL in program-order, may dynamically executed
between the execution of LL/SC, so a memory fence (SYNC) is needed
before LL/LLD to avoid this situation.
Since Loongson-3A R2 (3A2000), we have improved our hardware design to
handle this case. But we later deduce a rarely circumstance that some
speculatively executed memory instructions due to branch misprediction
between LL/SC still fall into the above case, so a memory fence (SYNC)
at branch-target (if its target is not between LL/SC) is needed for
Loongson 3A1000, 3B1500, 3A2000 and 3A3000.
Our processor is continually evolving and we aim to to remove all these
workaround-SYNCs around LL/SC for new-come processor."
Here is an example:
Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
time('sc' return 1), and the variable is only *added by 1*, sometimes,
which is wrong and unacceptable(it should be added by 2).
Why disable fix-loongson3-llsc in compiler?
Because compiler fix will cause problems in kernel's __ex_table section.
This patch fix all the cases in kernel, but:
+. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
the ll and branch-target coincidently such as atomic_sub_if_positive/
cmpxchg/xchg, just like this one.
+. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
edac.h
+. local_ops and cmpxchg_local should not be affected by this bug since
only the owner can write.
+. mips_atomic_set for syscall.c is deprecated and rarely used, just let
it go
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Huang Pei <huangpei@loongson.cn>
[paul.burton@mips.com:
- Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
a comment describing why it's there.
- Make loongson_llsc_mb() a no-op when
CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
barrier.
- Add a comment describing the bug & how loongson_llsc_mb() helps
in asm/barrier.h.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: ambrosehua@gmail.com
Cc: Steven J . Hill <Steven.Hill@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Li Xuefeng <lixuefeng@loongson.cn>
Cc: Xu Chenghua <xuchenghua@loongson.cn>
2019-01-15 11:04:54 +03:00
default y if SMP
2019-10-20 17:43:13 +03:00
depends on CPU_LOONGSON64
MIPS: Loongson: Introduce and use loongson_llsc_mb()
On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
lld/scd is very weak ordering. We should add sync instructions "before
each ll/lld" and "at the branch-target between ll/sc" to workaround.
Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
heavy load test with LTP).
Below is the explaination of CPU designer:
"For Loongson 3 family, when a memory access instruction (load, store,
or prefetch)'s executing occurs between the execution of LL and SC, the
success or failure of SC is not predictable. Although programmer would
not insert memory access instructions between LL and SC, the memory
instructions before LL in program-order, may dynamically executed
between the execution of LL/SC, so a memory fence (SYNC) is needed
before LL/LLD to avoid this situation.
Since Loongson-3A R2 (3A2000), we have improved our hardware design to
handle this case. But we later deduce a rarely circumstance that some
speculatively executed memory instructions due to branch misprediction
between LL/SC still fall into the above case, so a memory fence (SYNC)
at branch-target (if its target is not between LL/SC) is needed for
Loongson 3A1000, 3B1500, 3A2000 and 3A3000.
Our processor is continually evolving and we aim to to remove all these
workaround-SYNCs around LL/SC for new-come processor."
Here is an example:
Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
time('sc' return 1), and the variable is only *added by 1*, sometimes,
which is wrong and unacceptable(it should be added by 2).
Why disable fix-loongson3-llsc in compiler?
Because compiler fix will cause problems in kernel's __ex_table section.
This patch fix all the cases in kernel, but:
+. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
the ll and branch-target coincidently such as atomic_sub_if_positive/
cmpxchg/xchg, just like this one.
+. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
edac.h
+. local_ops and cmpxchg_local should not be affected by this bug since
only the owner can write.
+. mips_atomic_set for syscall.c is deprecated and rarely used, just let
it go
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Huang Pei <huangpei@loongson.cn>
[paul.burton@mips.com:
- Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
a comment describing why it's there.
- Make loongson_llsc_mb() a no-op when
CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
barrier.
- Add a comment describing the bug & how loongson_llsc_mb() helps
in asm/barrier.h.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: ambrosehua@gmail.com
Cc: Steven J . Hill <Steven.Hill@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Li Xuefeng <lixuefeng@loongson.cn>
Cc: Xu Chenghua <xuchenghua@loongson.cn>
2019-01-15 11:04:54 +03:00
help
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
Loongson-3 processors have the llsc issues which require workarounds.
MIPS: Loongson: Introduce and use loongson_llsc_mb()
On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
lld/scd is very weak ordering. We should add sync instructions "before
each ll/lld" and "at the branch-target between ll/sc" to workaround.
Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
heavy load test with LTP).
Below is the explaination of CPU designer:
"For Loongson 3 family, when a memory access instruction (load, store,
or prefetch)'s executing occurs between the execution of LL and SC, the
success or failure of SC is not predictable. Although programmer would
not insert memory access instructions between LL and SC, the memory
instructions before LL in program-order, may dynamically executed
between the execution of LL/SC, so a memory fence (SYNC) is needed
before LL/LLD to avoid this situation.
Since Loongson-3A R2 (3A2000), we have improved our hardware design to
handle this case. But we later deduce a rarely circumstance that some
speculatively executed memory instructions due to branch misprediction
between LL/SC still fall into the above case, so a memory fence (SYNC)
at branch-target (if its target is not between LL/SC) is needed for
Loongson 3A1000, 3B1500, 3A2000 and 3A3000.
Our processor is continually evolving and we aim to to remove all these
workaround-SYNCs around LL/SC for new-come processor."
Here is an example:
Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
time('sc' return 1), and the variable is only *added by 1*, sometimes,
which is wrong and unacceptable(it should be added by 2).
Why disable fix-loongson3-llsc in compiler?
Because compiler fix will cause problems in kernel's __ex_table section.
This patch fix all the cases in kernel, but:
+. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
the ll and branch-target coincidently such as atomic_sub_if_positive/
cmpxchg/xchg, just like this one.
+. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
edac.h
+. local_ops and cmpxchg_local should not be affected by this bug since
only the owner can write.
+. mips_atomic_set for syscall.c is deprecated and rarely used, just let
it go
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Huang Pei <huangpei@loongson.cn>
[paul.burton@mips.com:
- Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
a comment describing why it's there.
- Make loongson_llsc_mb() a no-op when
CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
barrier.
- Add a comment describing the bug & how loongson_llsc_mb() helps
in asm/barrier.h.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: ambrosehua@gmail.com
Cc: Steven J . Hill <Steven.Hill@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Li Xuefeng <lixuefeng@loongson.cn>
Cc: Xu Chenghua <xuchenghua@loongson.cn>
2019-01-15 11:04:54 +03:00
Without workarounds the system may hang unexpectedly.
MIPS: Loongson: Unify LOONGSON3/LOONGSON64 Kconfig usage
There are mixed LOONGSON3/LOONGSON64 usages in recently changes, let's
establish some rules:
1, In Kconfig symbols, we only use CPU_LOONGSON64, MACH_LOONGSON64 and
SYS_HAS_CPU_LOONGSON64, all other derived symbols use "LOONGSON3" since
they all not widely-used symbols and sometimes not suitable for all
64-bit Loongson processors. E.g., we use symbols LOONGSON3_ENHANCEMENT,
CPU_LOONGSON3_WORKAROUNDS, etc.
2, Hide GSx64/GSx64E in Kconfig title since it is not useful for
general users. However, in the full description we use a more detailed
manner. E.g., GS264/GS464/GS464E/GS464V.
All Kconfig titles and descriptions of Loongson processors and machines
have also been updated in this patch for consistency.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mips@vger.kernel.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Huacai Chen <chenhuacai@gmail.com>
2019-11-04 09:11:21 +03:00
Newer Loongson-3 will fix these issues and no workarounds are needed.
MIPS: Loongson: Introduce and use loongson_llsc_mb()
On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
lld/scd is very weak ordering. We should add sync instructions "before
each ll/lld" and "at the branch-target between ll/sc" to workaround.
Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
heavy load test with LTP).
Below is the explaination of CPU designer:
"For Loongson 3 family, when a memory access instruction (load, store,
or prefetch)'s executing occurs between the execution of LL and SC, the
success or failure of SC is not predictable. Although programmer would
not insert memory access instructions between LL and SC, the memory
instructions before LL in program-order, may dynamically executed
between the execution of LL/SC, so a memory fence (SYNC) is needed
before LL/LLD to avoid this situation.
Since Loongson-3A R2 (3A2000), we have improved our hardware design to
handle this case. But we later deduce a rarely circumstance that some
speculatively executed memory instructions due to branch misprediction
between LL/SC still fall into the above case, so a memory fence (SYNC)
at branch-target (if its target is not between LL/SC) is needed for
Loongson 3A1000, 3B1500, 3A2000 and 3A3000.
Our processor is continually evolving and we aim to to remove all these
workaround-SYNCs around LL/SC for new-come processor."
Here is an example:
Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
time('sc' return 1), and the variable is only *added by 1*, sometimes,
which is wrong and unacceptable(it should be added by 2).
Why disable fix-loongson3-llsc in compiler?
Because compiler fix will cause problems in kernel's __ex_table section.
This patch fix all the cases in kernel, but:
+. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
the ll and branch-target coincidently such as atomic_sub_if_positive/
cmpxchg/xchg, just like this one.
+. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
edac.h
+. local_ops and cmpxchg_local should not be affected by this bug since
only the owner can write.
+. mips_atomic_set for syscall.c is deprecated and rarely used, just let
it go
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Huang Pei <huangpei@loongson.cn>
[paul.burton@mips.com:
- Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
a comment describing why it's there.
- Make loongson_llsc_mb() a no-op when
CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
barrier.
- Add a comment describing the bug & how loongson_llsc_mb() helps
in asm/barrier.h.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: ambrosehua@gmail.com
Cc: Steven J . Hill <Steven.Hill@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Li Xuefeng <lixuefeng@loongson.cn>
Cc: Xu Chenghua <xuchenghua@loongson.cn>
2019-01-15 11:04:54 +03:00
The workarounds have no significant side effect on them but may
decrease the performance of the system so this option should be
disabled unless the kernel is intended to be run on old systems.
If unsure, please say Y.
MIPS: emulate CPUCFG instruction on older Loongson64 cores
CPUCFG is the instruction for querying processor characteristics on
newer Loongson processors, much like CPUID of x86. Since the instruction
is supposedly designed to provide a unified way to do feature detection
(without having to, for example, parse /proc/cpuinfo which is too
heavyweight), it is important to provide compatibility for older cores
without native support. Fortunately, most of the fields can be
synthesized without changes to semantics. Performance is not really big
a concern, because feature detection logic is not expected to be
invoked very often in typical userland applications.
The instruction can't be emulated on LOONGSON_2EF cores, according to
FlyGoat's experiments. Because the LWC2 opcode is assigned to other
valid instructions on 2E and 2F, no RI exception is raised for us to
intercept. So compatibility is only extended back furthest to
Loongson-3A1000. Loongson-2K is covered too, as it is basically a remix
of various blocks from the 3A/3B models from a kernel perspective.
This is lightly based on Loongson's work on their Linux 3.10 fork, for
being the authority on the right feature flags to fill in, where things
aren't otherwise discoverable.
Signed-off-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-23 16:37:01 +03:00
config CPU_LOONGSON3_CPUCFG_EMULATION
bool "Emulate the CPUCFG instruction on older Loongson cores"
default y
depends on CPU_LOONGSON64
help
Loongson-3A R4 and newer have the CPUCFG instruction available for
userland to query CPU capabilities, much like CPUID on x86. This
option provides emulation of the instruction on older Loongson
cores, back to Loongson-3A1000.
If unsure, please say Y.
2009-07-02 19:27:41 +04:00
config CPU_LOONGSON2E
bool "Loongson 2E"
depends on SYS_HAS_CPU_LOONGSON2E
2019-10-20 17:43:13 +03:00
select CPU_LOONGSON2EF
2007-06-06 10:52:43 +04:00
help
The Loongson 2E processor implements the MIPS III instruction set
with many extensions.
2011-03-31 05:57:33 +04:00
It has an internal FPGA northbridge, which is compatible to
2009-11-06 13:45:05 +03:00
bonito64.
config CPU_LOONGSON2F
bool "Loongson 2F"
depends on SYS_HAS_CPU_LOONGSON2F
2019-10-20 17:43:13 +03:00
select CPU_LOONGSON2EF
2016-04-19 12:23:22 +03:00
select GPIOLIB
2009-11-06 13:45:05 +03:00
help
The Loongson 2F processor implements the MIPS III instruction set
with many extensions.
Loongson2F have built-in DDR2 and PCIX controller. The PCIX controller
have a similar programming interface with FPGA northbridge used in
Loongson2E.
2012-07-25 18:17:24 +04:00
config CPU_LOONGSON1B
bool "Loongson 1B"
depends on SYS_HAS_CPU_LOONGSON1B
2019-11-04 09:11:20 +03:00
select CPU_LOONGSON32
2016-04-06 15:34:54 +03:00
select LEDS_GPIO_REGISTER
2012-07-25 18:17:24 +04:00
help
The Loongson 1B is a 32-bit SoC, which implements the MIPS32
MIPS: Loongson: Set Loongson32 to MIPS32R1
LS232 (Loonson 2-issue 32-bit, also called GS232 (Godson 2-issue 32-bit))
is the CPU core (microarchitecture) of Loongson 1A/1B/1C.
According to "LS232 用户手册 (LS232 User Manual)", LS232 implements the
MIPS32 Release 1 instruction set, and part of the MIPS32 Release 2
instruction set.
In the manual, LS232 implements all of the MIPS32R2 instruction set
except the FPU instructions, and LS232 also implements 5 FPU
instructions of the MIPS32R2 instruction set: CEIL.L.fmt, CVT.L.fmt,
FLOOR.L.fmt, TRUNC.L.fmt, and ROUND.L.fmt.
But a bug of the DI instruction has been found during tests, the DI
instruction can not disable interrupts in arch_local_irq_disable() with
CONFIG_PREEMPT_NONE=y and CFLAGS='-mno-branch-likely' in some cases.
[paul.burton@mips.com:
- Remove the _MIPS_ISA redefinition to match the change made for the
generic MIPSr1 CPUs by commit 344ebf09949c ("MIPS: Always use
-march=<arch>, not -<arch> shortcuts").]
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/16155/
Cc: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
2017-06-01 13:41:34 +03:00
Release 1 instruction set and part of the MIPS32 Release 2
instruction set.
2012-07-25 18:17:24 +04:00
2016-05-19 07:29:30 +03:00
config CPU_LOONGSON1C
bool "Loongson 1C"
depends on SYS_HAS_CPU_LOONGSON1C
2019-11-04 09:11:20 +03:00
select CPU_LOONGSON32
2016-05-19 07:29:30 +03:00
select LEDS_GPIO_REGISTER
help
The Loongson 1C is a 32-bit SoC, which implements the MIPS32
MIPS: Loongson: Set Loongson32 to MIPS32R1
LS232 (Loonson 2-issue 32-bit, also called GS232 (Godson 2-issue 32-bit))
is the CPU core (microarchitecture) of Loongson 1A/1B/1C.
According to "LS232 用户手册 (LS232 User Manual)", LS232 implements the
MIPS32 Release 1 instruction set, and part of the MIPS32 Release 2
instruction set.
In the manual, LS232 implements all of the MIPS32R2 instruction set
except the FPU instructions, and LS232 also implements 5 FPU
instructions of the MIPS32R2 instruction set: CEIL.L.fmt, CVT.L.fmt,
FLOOR.L.fmt, TRUNC.L.fmt, and ROUND.L.fmt.
But a bug of the DI instruction has been found during tests, the DI
instruction can not disable interrupts in arch_local_irq_disable() with
CONFIG_PREEMPT_NONE=y and CFLAGS='-mno-branch-likely' in some cases.
[paul.burton@mips.com:
- Remove the _MIPS_ISA redefinition to match the change made for the
generic MIPSr1 CPUs by commit 344ebf09949c ("MIPS: Always use
-march=<arch>, not -<arch> shortcuts").]
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/16155/
Cc: linux-mips@linux-mips.org
Cc: ralf@linux-mips.org
2017-06-01 13:41:34 +03:00
Release 1 instruction set and part of the MIPS32 Release 2
instruction set.
2016-05-19 07:29:30 +03:00
2005-07-06 16:08:11 +04:00
config CPU_MIPS32_R1
bool "MIPS32 Release 1"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_MIPS32_R1
2005-07-06 16:08:11 +04:00
select CPU_HAS_PREFETCH
2005-08-10 19:17:11 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
2006-03-05 03:45:33 +03:00
select CPU_SUPPORTS_HIGHMEM
2005-07-12 18:51:22 +04:00
help
2005-10-29 22:32:41 +04:00
Choose this option to build a kernel for release 1 or later of the
2005-07-12 18:51:22 +04:00
MIPS32 architecture. Most modern embedded systems with a 32-bit
MIPS processor are based on a MIPS32 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system.
Release 2 of the MIPS32 architecture is available since several
years so chances are you even have a MIPS32 Release 2 processor
in which case you should choose CPU_MIPS32_R2 instead for better
performance.
config CPU_MIPS32_R2
bool "MIPS32 Release 2"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_MIPS32_R2
2005-07-12 18:51:22 +04:00
select CPU_HAS_PREFETCH
2005-08-10 19:17:11 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
2006-03-05 03:45:33 +03:00
select CPU_SUPPORTS_HIGHMEM
2014-01-27 19:23:10 +04:00
select CPU_SUPPORTS_MSA
2012-11-22 06:33:59 +04:00
select HAVE_KVM
2005-07-06 16:08:11 +04:00
help
2005-10-29 22:32:41 +04:00
Choose this option to build a kernel for release 2 or later of the
2005-07-06 16:08:11 +04:00
MIPS32 architecture. Most modern embedded systems with a 32-bit
MIPS processor are based on a MIPS32 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS32_R1 is a safe bet for any MIPS32 system.
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
config CPU_MIPS32_R5
bool "MIPS32 Release 5"
depends on SYS_HAS_CPU_MIPS32_R5
select CPU_HAS_PREFETCH
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_MSA
select HAVE_KVM
select MIPS_O32_FP64_SUPPORT
help
Choose this option to build a kernel for release 5 or later of the
MIPS32 architecture. New MIPS processors, starting with the Warrior
family, are based on a MIPS32r5 processor. If you own an older
processor, you probably need to select MIPS32r1 or MIPS32r2 instead.
2014-10-27 13:34:11 +03:00
config CPU_MIPS32_R6
2015-07-16 15:24:46 +03:00
bool "MIPS32 Release 6"
2014-10-27 13:34:11 +03:00
depends on SYS_HAS_CPU_MIPS32_R6
select CPU_HAS_PREFETCH
2020-01-22 13:58:50 +03:00
select CPU_NO_LOAD_STORE_LR
2014-10-27 13:34:11 +03:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_MSA
select HAVE_KVM
select MIPS_O32_FP64_SUPPORT
help
Choose this option to build a kernel for release 6 or later of the
MIPS32 architecture. New MIPS processors, starting with the Warrior
family, are based on a MIPS32r6 processor. If you own an older
processor, you probably need to select MIPS32r1 or MIPS32r2 instead.
2005-07-06 16:08:11 +04:00
config CPU_MIPS64_R1
bool "MIPS64 Release 1"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_MIPS64_R1
2005-08-10 19:17:11 +04:00
select CPU_HAS_PREFETCH
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2006-03-05 03:45:33 +03:00
select CPU_SUPPORTS_HIGHMEM
2009-05-28 04:47:46 +04:00
select CPU_SUPPORTS_HUGEPAGES
2005-07-06 16:08:11 +04:00
help
Choose this option to build a kernel for release 1 or later of the
MIPS64 architecture. Many modern embedded systems with a 64-bit
MIPS processor are based on a MIPS64 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system.
2005-07-12 18:51:22 +04:00
Release 2 of the MIPS64 architecture is available since several
years so chances are you even have a MIPS64 Release 2 processor
in which case you should choose CPU_MIPS64_R2 instead for better
performance.
config CPU_MIPS64_R2
bool "MIPS64 Release 2"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_MIPS64_R2
2005-08-10 19:17:11 +04:00
select CPU_HAS_PREFETCH
2005-07-12 18:51:22 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2006-03-05 03:45:33 +03:00
select CPU_SUPPORTS_HIGHMEM
2009-05-28 04:47:46 +04:00
select CPU_SUPPORTS_HUGEPAGES
2014-01-27 19:23:10 +04:00
select CPU_SUPPORTS_MSA
2016-07-08 13:53:31 +03:00
select HAVE_KVM
2005-07-12 18:51:22 +04:00
help
Choose this option to build a kernel for release 2 or later of the
MIPS64 architecture. Many modern embedded systems with a 64-bit
MIPS processor are based on a MIPS64 processor. If you know the
specific type of processor in your system, choose those that one
otherwise CPU_MIPS64_R1 is a safe bet for any MIPS64 system.
2005-04-17 02:20:36 +04:00
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
config CPU_MIPS64_R5
bool "MIPS64 Release 5"
depends on SYS_HAS_CPU_MIPS64_R5
select CPU_HAS_PREFETCH
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_HUGEPAGES
select CPU_SUPPORTS_MSA
select MIPS_O32_FP64_SUPPORT if 32BIT || MIPS32_O32
select HAVE_KVM
help
Choose this option to build a kernel for release 5 or later of the
MIPS64 architecture. This is a intermediate MIPS architecture
release partly implementing release 6 features. Though there is no
any hardware known to be based on this release.
2014-10-27 13:34:11 +03:00
config CPU_MIPS64_R6
2015-07-16 15:24:46 +03:00
bool "MIPS64 Release 6"
2014-10-27 13:34:11 +03:00
depends on SYS_HAS_CPU_MIPS64_R6
select CPU_HAS_PREFETCH
2020-01-22 13:58:50 +03:00
select CPU_NO_LOAD_STORE_LR
2014-10-27 13:34:11 +03:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
2019-02-02 05:21:53 +03:00
select CPU_SUPPORTS_HUGEPAGES
2014-10-27 13:34:11 +03:00
select CPU_SUPPORTS_MSA
2017-02-16 15:39:01 +03:00
select MIPS_O32_FP64_SUPPORT if 32BIT || MIPS32_O32
2016-07-08 13:53:31 +03:00
select HAVE_KVM
2014-10-27 13:34:11 +03:00
help
Choose this option to build a kernel for release 6 or later of the
MIPS64 architecture. New MIPS processors, starting with the Warrior
family, are based on a MIPS64r6 processor. If you own an older
processor, you probably need to select MIPS64r1 or MIPS64r2 instead.
mips: Add MIPS Warrior P5600 support
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
system-specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
As being MIPS32 Release 5 based core it provides all the features
available by the CPU_MIPS32_R5 config, while adding a few more like
UCA attribute support, availability of CPU-freq (by means of L2/CM
clock ratio setting), EI/VI GIC modes detection at runtime.
In addition to this if P5600 architecture is enabled modern GNU GCC
provides a specific tuning for P5600 processors with respect to the
classic MIPS32 Release 5. First of all branch-likely avoidance is
activated only when the code is compiled with the speed optimization
(avoidance is always enabled for the pure MIPS32 Release 5
architecture). Secondly the madd/msub avoidance is enabled since
madd/msub utilization isn't profitable due to overhead of getting the
result out of the HI/LO registers. Multiply-accumulate instructions are
activated and utilized together with the necessary code reorder when
multiply-add/multiply-subtract statements are met. Finally load/store
bonding is activated by default. All of these optimizations may make
the code relatively faster than if just MIP32 release 5 architecture
was requested.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:15 +03:00
config CPU_P5600
bool "MIPS Warrior P5600"
depends on SYS_HAS_CPU_P5600
select CPU_HAS_PREFETCH
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select CPU_SUPPORTS_MSA
select CPU_SUPPORTS_CPUFREQ
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
select HAVE_KVM
select MIPS_O32_FP64_SUPPORT
help
Choose this option to build a kernel for MIPS Warrior P5600 CPU.
It's based on MIPS32r5 ISA with XPA, EVA, dual/quad issue exec pipes,
MMU with two-levels TLB, UCA, MSA, MDU core level features and system
level features like up to six P5600 calculation cores, CM2 with L2
cache, IOCU/IOMMU (though might be unused depending on the system-
specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
2005-04-17 02:20:36 +04:00
config CPU_R3000
bool "R3000"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_R3000
2006-04-24 17:58:53 +04:00
select CPU_HAS_WB
2019-08-31 18:40:43 +03:00
select CPU_R3K_TLB
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
2005-08-10 19:17:11 +04:00
select CPU_SUPPORTS_HIGHMEM
2005-04-17 02:20:36 +04:00
help
Please make sure to pick the right CPU type. Linux/MIPS is not
designed to be generic, i.e. Kernels compiled for R3000 CPUs will
*not* work on R4000 machines and vice versa. However, since most
of the supported machines have an R4000 (or similar) CPU, R4x00
might be a safe bet. If the resulting kernel does not work,
try to recompile with R3000.
config CPU_TX39XX
bool "R39XX"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_TX39XX
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
2019-08-31 18:40:43 +03:00
select CPU_R3K_TLB
2005-04-17 02:20:36 +04:00
config CPU_VR41XX
bool "R41xx"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_VR41XX
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2005-04-17 02:20:36 +04:00
help
2005-10-29 22:32:41 +04:00
The options selects support for the NEC VR4100 series of processors.
2005-04-17 02:20:36 +04:00
Only choose this option if you have one of these processors as a
kernel built with this option will not run on any other type of
processor or vice versa.
config CPU_R4X00
bool "R4x00"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_R4X00
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2005-04-17 02:20:36 +04:00
help
MIPS Technologies R4000-series processors other than 4300, including
the R4000, R4400, R4600, and 4700.
config CPU_TX49XX
bool "R49XX"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_TX49XX
2006-03-17 06:59:22 +03:00
select CPU_HAS_PREFETCH
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2005-04-17 02:20:36 +04:00
config CPU_R5000
bool "R5000"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_R5000
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2005-04-17 02:20:36 +04:00
help
MIPS Technologies R5000-series processors other than the Nevada.
2008-10-23 20:27:57 +04:00
config CPU_R5500
bool "R5500"
depends on SYS_HAS_CPU_R5500
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2009-05-28 04:47:46 +04:00
select CPU_SUPPORTS_HUGEPAGES
2008-10-23 20:27:57 +04:00
help
NEC VR5500 and VR5500A series processors implement 64-bit MIPS IV
instruction set.
2005-04-17 02:20:36 +04:00
config CPU_NEVADA
bool "RM52xx"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_NEVADA
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2005-04-17 02:20:36 +04:00
help
QED / PMC-Sierra RM52xx-series ("Nevada") processors.
config CPU_R10000
bool "R10000"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_R10000
2005-10-29 22:32:41 +04:00
select CPU_HAS_PREFETCH
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2005-08-10 19:17:11 +04:00
select CPU_SUPPORTS_HIGHMEM
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2005-04-17 02:20:36 +04:00
help
MIPS Technologies R10000-series processors.
config CPU_RM7000
bool "RM7000"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_RM7000
2005-10-29 22:32:41 +04:00
select CPU_HAS_PREFETCH
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2005-08-10 19:17:11 +04:00
select CPU_SUPPORTS_HIGHMEM
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2005-04-17 02:20:36 +04:00
config CPU_SB1
bool "SB1"
2005-10-21 01:33:09 +04:00
depends on SYS_HAS_CPU_SB1
2005-09-04 02:56:21 +04:00
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
2005-08-10 19:17:11 +04:00
select CPU_SUPPORTS_HIGHMEM
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2006-10-31 06:45:07 +03:00
select WEAK_ORDERING
2005-04-17 02:20:36 +04:00
2008-12-12 02:33:38 +03:00
config CPU_CAVIUM_OCTEON
bool "Cavium Octeon processor"
2009-02-02 22:30:59 +03:00
depends on SYS_HAS_CPU_CAVIUM_OCTEON
2008-12-12 02:33:38 +03:00
select CPU_HAS_PREFETCH
select CPU_SUPPORTS_64BIT_KERNEL
select WEAK_ORDERING
select CPU_SUPPORTS_HIGHMEM
2009-05-28 04:47:46 +04:00
select CPU_SUPPORTS_HUGEPAGES
2015-05-25 22:27:29 +03:00
select USB_EHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO if CPU_BIG_ENDIAN
2014-01-14 21:54:38 +04:00
select MIPS_L1_CACHE_SHIFT_7
2017-03-14 13:25:51 +03:00
select HAVE_KVM
2008-12-12 02:33:38 +03:00
help
The Cavium Octeon processor is a highly integrated chip containing
many ethernet hardware widgets for networking tasks. The processor
can have up to 16 Mips64v2 cores and 8 integrated gigabit ethernets.
Full details can be found at http://www.caviumnetworks.com.
2013-12-18 17:12:02 +04:00
config CPU_BMIPS
bool "Broadcom BMIPS"
depends on SYS_HAS_CPU_BMIPS
select CPU_MIPS32
2013-12-18 17:12:05 +04:00
select CPU_BMIPS32_3300 if SYS_HAS_CPU_BMIPS32_3300
2013-12-18 17:12:02 +04:00
select CPU_BMIPS4350 if SYS_HAS_CPU_BMIPS4350
select CPU_BMIPS4380 if SYS_HAS_CPU_BMIPS4380
select CPU_BMIPS5000 if SYS_HAS_CPU_BMIPS5000
select CPU_SUPPORTS_32BIT_KERNEL
select DMA_NONCOHERENT
2015-05-26 19:20:06 +03:00
select IRQ_MIPS_CPU
2013-12-18 17:12:02 +04:00
select SWAP_IO_SPACE
select WEAK_ORDERING
2010-10-17 21:56:53 +04:00
select CPU_SUPPORTS_HIGHMEM
2013-12-18 17:12:04 +04:00
select CPU_HAS_PREFETCH
2017-02-08 00:58:54 +03:00
select CPU_SUPPORTS_CPUFREQ
select MIPS_EXTERNAL_TIMER
2010-10-17 21:56:53 +04:00
help
2013-12-18 17:12:05 +04:00
Support for BMIPS32/3300/4350/4380 and BMIPS5000 processors.
2010-10-17 21:56:53 +04:00
2011-05-07 00:06:57 +04:00
config CPU_XLR
bool "Netlogic XLR SoC"
depends on SYS_HAS_CPU_XLR
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2011-05-07 00:06:57 +04:00
select WEAK_ORDERING
select WEAK_REORDERING_BEYOND_LLSC
help
Netlogic Microsystems XLR/XLS processors.
2011-11-16 04:21:28 +04:00
config CPU_XLP
bool "Netlogic XLP SoC"
depends on SYS_HAS_CPU_XLP
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
select WEAK_ORDERING
select WEAK_REORDERING_BEYOND_LLSC
select CPU_HAS_PREFETCH
2012-10-31 16:01:29 +04:00
select CPU_MIPSR2
2015-01-07 14:28:32 +03:00
select CPU_SUPPORTS_HUGEPAGES
2016-05-06 16:36:24 +03:00
select MIPS_ASID_BITS_VARIABLE
2011-11-16 04:21:28 +04:00
help
Netlogic Microsystems XLP processors.
2005-04-17 02:20:36 +04:00
endchoice
2013-12-03 14:22:26 +04:00
config CPU_MIPS32_3_5_FEATURES
bool "MIPS32 Release 3.5 Features"
depends on SYS_HAS_CPU_MIPS32_R3_5
mips: Add MIPS Warrior P5600 support
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
system-specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
As being MIPS32 Release 5 based core it provides all the features
available by the CPU_MIPS32_R5 config, while adding a few more like
UCA attribute support, availability of CPU-freq (by means of L2/CM
clock ratio setting), EI/VI GIC modes detection at runtime.
In addition to this if P5600 architecture is enabled modern GNU GCC
provides a specific tuning for P5600 processors with respect to the
classic MIPS32 Release 5. First of all branch-likely avoidance is
activated only when the code is compiled with the speed optimization
(avoidance is always enabled for the pure MIPS32 Release 5
architecture). Secondly the madd/msub avoidance is enabled since
madd/msub utilization isn't profitable due to overhead of getting the
result out of the HI/LO registers. Multiply-accumulate instructions are
activated and utilized together with the necessary code reorder when
multiply-add/multiply-subtract statements are met. Finally load/store
bonding is activated by default. All of these optimizations may make
the code relatively faster than if just MIP32 release 5 architecture
was requested.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:15 +03:00
depends on CPU_MIPS32_R2 || CPU_MIPS32_R5 || CPU_MIPS32_R6 || \
CPU_P5600
2013-12-03 14:22:26 +04:00
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from the 3.5 release such as
support for Enhanced Virtual Addressing (EVA).
config CPU_MIPS32_3_5_EVA
bool "Enhanced Virtual Addressing (EVA)"
depends on CPU_MIPS32_3_5_FEATURES
select EVA
default y
help
Choose this option if you want to enable the Enhanced Virtual
Addressing (EVA) on your MIPS32 core (such as proAptiv).
One of its primary benefits is an increase in the maximum size
of lowmem (up to 3GB). If unsure, say 'N' here.
2015-02-27 03:16:38 +03:00
config CPU_MIPS32_R5_FEATURES
bool "MIPS32 Release 5 Features"
depends on SYS_HAS_CPU_MIPS32_R5
mips: Add MIPS Warrior P5600 support
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
system-specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
As being MIPS32 Release 5 based core it provides all the features
available by the CPU_MIPS32_R5 config, while adding a few more like
UCA attribute support, availability of CPU-freq (by means of L2/CM
clock ratio setting), EI/VI GIC modes detection at runtime.
In addition to this if P5600 architecture is enabled modern GNU GCC
provides a specific tuning for P5600 processors with respect to the
classic MIPS32 Release 5. First of all branch-likely avoidance is
activated only when the code is compiled with the speed optimization
(avoidance is always enabled for the pure MIPS32 Release 5
architecture). Secondly the madd/msub avoidance is enabled since
madd/msub utilization isn't profitable due to overhead of getting the
result out of the HI/LO registers. Multiply-accumulate instructions are
activated and utilized together with the necessary code reorder when
multiply-add/multiply-subtract statements are met. Finally load/store
bonding is activated by default. All of these optimizations may make
the code relatively faster than if just MIP32 release 5 architecture
was requested.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:15 +03:00
depends on CPU_MIPS32_R2 || CPU_MIPS32_R5 || CPU_P5600
2015-02-27 03:16:38 +03:00
help
Choose this option to build a kernel for release 2 or later of the
MIPS32 architecture including features from release 5 such as
support for Extended Physical Addressing (XPA).
config CPU_MIPS32_R5_XPA
bool "Extended Physical Addressing (XPA)"
depends on CPU_MIPS32_R5_FEATURES
depends on !EVA
depends on !PAGE_SIZE_4KB
depends on SYS_SUPPORTS_HIGHMEM
select XPA
select HIGHMEM
2018-04-03 17:24:20 +03:00
select PHYS_ADDR_T_64BIT
2015-02-27 03:16:38 +03:00
default n
help
Choose this option if you want to enable the Extended Physical
Addressing (XPA) on your MIPS32 core (such as P5600 series). The
benefit is to increase physical addressing equal to or greater
than 40 bits. Note that this has the side effect of turning on
64-bit addressing which in turn makes the PTEs 64-bit in size.
If unsure, say 'N' here.
2010-04-10 16:04:42 +04:00
if CPU_LOONGSON2F
config CPU_NOP_WORKAROUNDS
bool
config CPU_JUMP_WORKAROUNDS
bool
config CPU_LOONGSON2F_WORKAROUNDS
bool "Loongson 2F Workarounds"
default y
select CPU_NOP_WORKAROUNDS
select CPU_JUMP_WORKAROUNDS
help
Loongson 2F01 / 2F02 processors have the NOP & JUMP issues which
require workarounds. Without workarounds the system may hang
unexpectedly. For more information please refer to the gas
-mfix-loongson2f-nop and -mfix-loongson2f-jump options.
Loongson 2F03 and later have fixed these issues and no workarounds
are needed. The workarounds have no significant side effect on them
but may decrease the performance of the system so this option should
be disabled unless the kernel is intended to be run on 2F01 or 2F02
systems.
If unsure, please say Y.
endif # CPU_LOONGSON2F
2009-10-14 14:12:16 +04:00
config SYS_SUPPORTS_ZBOOT
bool
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_BZIP2
2013-09-16 19:55:20 +04:00
select HAVE_KERNEL_LZ4
2009-10-14 14:12:16 +04:00
select HAVE_KERNEL_LZMA
2010-01-15 15:34:46 +03:00
select HAVE_KERNEL_LZO
2013-09-11 14:51:41 +04:00
select HAVE_KERNEL_XZ
2020-09-01 17:26:51 +03:00
select HAVE_KERNEL_ZSTD
2009-10-14 14:12:16 +04:00
config SYS_SUPPORTS_ZBOOT_UART16550
bool
select SYS_SUPPORTS_ZBOOT
2015-12-10 12:57:21 +03:00
config SYS_SUPPORTS_ZBOOT_UART_PROM
bool
select SYS_SUPPORTS_ZBOOT
2019-10-20 17:43:13 +03:00
config CPU_LOONGSON2EF
2009-07-02 19:27:41 +04:00
bool
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_64BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
2012-10-18 15:54:15 +04:00
select CPU_SUPPORTS_HUGEPAGES
2018-06-20 10:11:15 +03:00
select ARCH_HAS_PHYS_TO_DMA
2009-07-02 19:27:41 +04:00
2019-11-04 09:11:20 +03:00
config CPU_LOONGSON32
2012-07-25 18:17:24 +04:00
bool
select CPU_MIPS32
2019-01-22 16:04:12 +03:00
select CPU_MIPSR2
2012-07-25 18:17:24 +04:00
select CPU_HAS_PREFETCH
select CPU_SUPPORTS_32BIT_KERNEL
select CPU_SUPPORTS_HIGHMEM
2014-10-10 07:40:01 +04:00
select CPU_SUPPORTS_CPUFREQ
2012-07-25 18:17:24 +04:00
2013-12-18 17:12:05 +04:00
config CPU_BMIPS32_3300
2013-12-18 17:12:06 +04:00
select SMP_UP if SMP
2011-11-11 10:30:24 +04:00
bool
2013-12-18 17:12:02 +04:00
config CPU_BMIPS4350
bool
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
config CPU_BMIPS4380
bool
2014-10-21 08:27:58 +04:00
select MIPS_L1_CACHE_SHIFT_6
2013-12-18 17:12:02 +04:00
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
2016-02-09 23:55:53 +03:00
select CPU_HAS_RIXI
2013-12-18 17:12:02 +04:00
config CPU_BMIPS5000
bool
select MIPS_CPU_SCACHE
2014-10-21 08:27:58 +04:00
select MIPS_L1_CACHE_SHIFT_7
2013-12-18 17:12:02 +04:00
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_HOTPLUG_CPU
2016-02-09 23:55:53 +03:00
select CPU_HAS_RIXI
2011-11-11 10:30:24 +04:00
2019-10-20 17:43:13 +03:00
config SYS_HAS_CPU_LOONGSON64
2014-03-21 14:44:07 +04:00
bool
select CPU_SUPPORTS_CPUFREQ
2016-03-03 04:45:09 +03:00
select CPU_HAS_RIXI
2014-03-21 14:44:07 +04:00
2009-07-02 19:27:41 +04:00
config SYS_HAS_CPU_LOONGSON2E
2007-06-06 10:52:43 +04:00
bool
2009-11-06 13:45:05 +03:00
config SYS_HAS_CPU_LOONGSON2F
bool
2009-11-11 08:39:12 +03:00
select CPU_SUPPORTS_CPUFREQ
select CPU_SUPPORTS_ADDRWINCFG if 64BIT
2009-11-06 13:45:05 +03:00
2012-07-25 18:17:24 +04:00
config SYS_HAS_CPU_LOONGSON1B
bool
2016-05-19 07:29:30 +03:00
config SYS_HAS_CPU_LOONGSON1C
bool
2005-10-21 01:33:09 +04:00
config SYS_HAS_CPU_MIPS32_R1
bool
config SYS_HAS_CPU_MIPS32_R2
bool
2013-12-03 14:22:26 +04:00
config SYS_HAS_CPU_MIPS32_R3_5
bool
2015-02-27 03:16:38 +03:00
config SYS_HAS_CPU_MIPS32_R5
bool
2019-02-05 00:52:58 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
2015-02-27 03:16:38 +03:00
2014-10-27 13:34:11 +03:00
config SYS_HAS_CPU_MIPS32_R6
bool
2019-02-05 00:52:58 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
2014-10-27 13:34:11 +03:00
2005-10-21 01:33:09 +04:00
config SYS_HAS_CPU_MIPS64_R1
bool
config SYS_HAS_CPU_MIPS64_R2
bool
2014-10-27 13:34:11 +03:00
config SYS_HAS_CPU_MIPS64_R6
bool
2019-02-05 00:52:58 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
2014-10-27 13:34:11 +03:00
mips: Add MIPS Warrior P5600 support
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
system-specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
As being MIPS32 Release 5 based core it provides all the features
available by the CPU_MIPS32_R5 config, while adding a few more like
UCA attribute support, availability of CPU-freq (by means of L2/CM
clock ratio setting), EI/VI GIC modes detection at runtime.
In addition to this if P5600 architecture is enabled modern GNU GCC
provides a specific tuning for P5600 processors with respect to the
classic MIPS32 Release 5. First of all branch-likely avoidance is
activated only when the code is compiled with the speed optimization
(avoidance is always enabled for the pure MIPS32 Release 5
architecture). Secondly the madd/msub avoidance is enabled since
madd/msub utilization isn't profitable due to overhead of getting the
result out of the HI/LO registers. Multiply-accumulate instructions are
activated and utilized together with the necessary code reorder when
multiply-add/multiply-subtract statements are met. Finally load/store
bonding is activated by default. All of these optimizations may make
the code relatively faster than if just MIP32 release 5 architecture
was requested.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:15 +03:00
config SYS_HAS_CPU_P5600
bool
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
2005-10-21 01:33:09 +04:00
config SYS_HAS_CPU_R3000
bool
config SYS_HAS_CPU_TX39XX
bool
config SYS_HAS_CPU_VR41XX
bool
config SYS_HAS_CPU_R4X00
bool
config SYS_HAS_CPU_TX49XX
bool
config SYS_HAS_CPU_R5000
bool
2008-10-23 20:27:57 +04:00
config SYS_HAS_CPU_R5500
bool
2005-10-21 01:33:09 +04:00
config SYS_HAS_CPU_NEVADA
bool
config SYS_HAS_CPU_R10000
bool
2019-02-05 00:52:58 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU if DMA_NONCOHERENT
2005-10-21 01:33:09 +04:00
config SYS_HAS_CPU_RM7000
bool
config SYS_HAS_CPU_SB1
bool
2009-02-02 22:30:59 +03:00
config SYS_HAS_CPU_CAVIUM_OCTEON
bool
2013-12-18 17:12:02 +04:00
config SYS_HAS_CPU_BMIPS
2010-10-17 21:56:53 +04:00
bool
2013-12-18 17:12:05 +04:00
config SYS_HAS_CPU_BMIPS32_3300
2010-10-17 21:56:53 +04:00
bool
2013-12-18 17:12:02 +04:00
select SYS_HAS_CPU_BMIPS
2010-10-17 21:56:53 +04:00
config SYS_HAS_CPU_BMIPS4350
bool
2013-12-18 17:12:02 +04:00
select SYS_HAS_CPU_BMIPS
2010-10-17 21:56:53 +04:00
config SYS_HAS_CPU_BMIPS4380
bool
2013-12-18 17:12:02 +04:00
select SYS_HAS_CPU_BMIPS
2010-10-17 21:56:53 +04:00
config SYS_HAS_CPU_BMIPS5000
bool
2013-12-18 17:12:02 +04:00
select SYS_HAS_CPU_BMIPS
2018-12-09 18:49:57 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU
2010-10-17 21:56:53 +04:00
2011-05-07 00:06:57 +04:00
config SYS_HAS_CPU_XLR
bool
2011-11-16 04:21:28 +04:00
config SYS_HAS_CPU_XLP
bool
2007-07-14 16:24:05 +04:00
#
# CPU may reorder R->R, R->W, W->R, W->W
# Reordering beyond LL and SC is handled in WEAK_REORDERING_BEYOND_LLSC
#
2006-10-31 06:45:07 +03:00
config WEAK_ORDERING
bool
2007-07-14 16:24:05 +04:00
#
# CPU may reorder reads and writes beyond LL/SC
# CPU may reorder R->LL, R->LL, W->LL, W->LL, R->SC, R->SC, W->SC, W->SC
#
config WEAK_REORDERING_BEYOND_LLSC
bool
2005-10-29 22:32:41 +04:00
endmenu
#
2006-06-20 20:15:20 +04:00
# These two indicate any level of the MIPS32 and MIPS64 architecture
2005-10-29 22:32:41 +04:00
#
config CPU_MIPS32
bool
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 || CPU_MIPS32_R5 || \
mips: Add MIPS Warrior P5600 support
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
system-specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
As being MIPS32 Release 5 based core it provides all the features
available by the CPU_MIPS32_R5 config, while adding a few more like
UCA attribute support, availability of CPU-freq (by means of L2/CM
clock ratio setting), EI/VI GIC modes detection at runtime.
In addition to this if P5600 architecture is enabled modern GNU GCC
provides a specific tuning for P5600 processors with respect to the
classic MIPS32 Release 5. First of all branch-likely avoidance is
activated only when the code is compiled with the speed optimization
(avoidance is always enabled for the pure MIPS32 Release 5
architecture). Secondly the madd/msub avoidance is enabled since
madd/msub utilization isn't profitable due to overhead of getting the
result out of the HI/LO registers. Multiply-accumulate instructions are
activated and utilized together with the necessary code reorder when
multiply-add/multiply-subtract statements are met. Finally load/store
bonding is activated by default. All of these optimizations may make
the code relatively faster than if just MIP32 release 5 architecture
was requested.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:15 +03:00
CPU_MIPS32_R6 || CPU_P5600
2005-10-29 22:32:41 +04:00
config CPU_MIPS64
bool
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \
CPU_MIPS64_R6
2005-10-29 22:32:41 +04:00
#
2018-11-09 02:44:55 +03:00
# These indicate the revision of the architecture
2005-10-29 22:32:41 +04:00
#
config CPU_MIPSR1
bool
default y if CPU_MIPS32_R1 || CPU_MIPS64_R1
config CPU_MIPSR2
bool
2008-12-12 02:33:38 +03:00
default y if CPU_MIPS32_R2 || CPU_MIPS64_R2 || CPU_CAVIUM_OCTEON
2016-02-09 23:55:51 +03:00
select CPU_HAS_RIXI
2020-01-13 13:14:59 +03:00
select CPU_HAS_DIEI if !CPU_DIEI_BROKEN
2014-11-13 16:32:03 +03:00
select MIPS_SPRAM
2005-10-29 22:32:41 +04:00
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
config CPU_MIPSR5
bool
mips: Add MIPS Warrior P5600 support
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue
exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features
and system level features like up to six P5600 calculation cores, CM2
with L2 cache, IOCU/IOMMU (though might be unused depending on the
system-specific IP core configuration), GIC, CPC, virtualisation module,
eJTAG and PDtrace.
As being MIPS32 Release 5 based core it provides all the features
available by the CPU_MIPS32_R5 config, while adding a few more like
UCA attribute support, availability of CPU-freq (by means of L2/CM
clock ratio setting), EI/VI GIC modes detection at runtime.
In addition to this if P5600 architecture is enabled modern GNU GCC
provides a specific tuning for P5600 processors with respect to the
classic MIPS32 Release 5. First of all branch-likely avoidance is
activated only when the code is compiled with the speed optimization
(avoidance is always enabled for the pure MIPS32 Release 5
architecture). Secondly the madd/msub avoidance is enabled since
madd/msub utilization isn't profitable due to overhead of getting the
result out of the HI/LO registers. Multiply-accumulate instructions are
activated and utilized together with the necessary code reorder when
multiply-add/multiply-subtract statements are met. Finally load/store
bonding is activated by default. All of these optimizations may make
the code relatively faster than if just MIP32 release 5 architecture
was requested.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:15 +03:00
default y if CPU_MIPS32_R5 || CPU_MIPS64_R5 || CPU_P5600
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
select CPU_HAS_RIXI
select CPU_HAS_DIEI if !CPU_DIEI_BROKEN
select MIPS_SPRAM
2014-10-27 13:34:11 +03:00
config CPU_MIPSR6
bool
default y if CPU_MIPS32_R6 || CPU_MIPS64_R6
2016-02-09 23:55:51 +03:00
select CPU_HAS_RIXI
2020-01-13 13:14:59 +03:00
select CPU_HAS_DIEI if !CPU_DIEI_BROKEN
2016-05-06 15:35:03 +03:00
select HAVE_ARCH_BITREVERSE
2016-05-06 16:36:24 +03:00
select MIPS_ASID_BITS_VARIABLE
2018-02-10 01:11:06 +03:00
select MIPS_CRC_SUPPORT
2014-11-13 16:32:03 +03:00
select MIPS_SPRAM
2005-10-29 22:32:41 +04:00
2018-11-09 02:44:55 +03:00
config TARGET_ISA_REV
int
default 1 if CPU_MIPSR1
default 2 if CPU_MIPSR2
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
default 5 if CPU_MIPSR5
2018-11-09 02:44:55 +03:00
default 6 if CPU_MIPSR6
default 0
help
Reflects the ISA revision being targeted by the kernel build. This
is effectively the Kconfig equivalent of MIPS_ISA_REV.
2013-12-03 14:22:26 +04:00
config EVA
bool
2015-02-27 03:16:38 +03:00
config XPA
bool
2005-10-29 22:32:41 +04:00
config SYS_SUPPORTS_32BIT_KERNEL
bool
config SYS_SUPPORTS_64BIT_KERNEL
bool
config CPU_SUPPORTS_32BIT_KERNEL
bool
config CPU_SUPPORTS_64BIT_KERNEL
bool
2009-11-11 08:39:12 +03:00
config CPU_SUPPORTS_CPUFREQ
bool
config CPU_SUPPORTS_ADDRWINCFG
bool
2009-05-28 04:47:46 +04:00
config CPU_SUPPORTS_HUGEPAGES
bool
2019-07-16 00:39:59 +03:00
depends on !(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))
2009-10-14 23:16:56 +04:00
config MIPS_PGD_C0_CONTEXT
bool
2017-06-03 01:38:03 +03:00
default y if 64BIT && (CPU_MIPSR2 || CPU_MIPSR6) && !CPU_XLP
2005-10-29 22:32:41 +04:00
2008-09-23 11:04:26 +04:00
#
# Set to y for ptrace access to watch registers.
#
config HARDWARE_WATCHPOINTS
2019-03-11 18:54:27 +03:00
bool
default y if CPU_MIPSR1 || CPU_MIPSR2 || CPU_MIPSR6
2008-09-23 11:04:26 +04:00
2005-10-29 22:32:41 +04:00
menu "Kernel type"
choice
prompt "Kernel code model"
help
You should only select this option if you have a workload that
actually benefits from 64-bit processing or if your machine has
large memory. You will only be presented a single option in this
menu if your system does not support both 32-bit and 64-bit kernels.
config 32BIT
bool "32-bit kernel"
depends on CPU_SUPPORTS_32BIT_KERNEL && SYS_SUPPORTS_32BIT_KERNEL
select TRAD_SIGNALS
help
Select this option if you want to build a 32-bit kernel.
2015-07-23 13:02:09 +03:00
2005-10-29 22:32:41 +04:00
config 64BIT
bool "64-bit kernel"
depends on CPU_SUPPORTS_64BIT_KERNEL && SYS_SUPPORTS_64BIT_KERNEL
help
Select this option if you want to build a 64-bit kernel.
endchoice
2012-11-22 06:33:59 +04:00
config KVM_GUEST
bool "KVM Guest Kernel"
2020-07-10 09:30:17 +03:00
depends on CPU_MIPS32_R2
2013-07-12 14:26:11 +04:00
depends on BROKEN_ON_SMP
2012-11-22 06:33:59 +04:00
help
2015-12-17 02:49:26 +03:00
Select this option if building a guest kernel for KVM (Trap & Emulate)
mode.
2012-11-22 06:33:59 +04:00
2014-05-29 13:16:36 +04:00
config KVM_GUEST_TIMER_FREQ
int "Count/Compare Timer Frequency (MHz)"
2012-11-22 06:33:59 +04:00
depends on KVM_GUEST
2014-05-29 13:16:36 +04:00
default 100
2012-11-22 06:33:59 +04:00
help
2014-05-29 13:16:36 +04:00
Set this to non-zero if building a guest kernel for KVM to skip RTC
emulation when determining guest CPU Frequency. Instead, the guest's
timer frequency is specified directly.
2012-11-22 06:33:59 +04:00
2015-05-15 04:34:43 +03:00
config MIPS_VA_BITS_48
bool "48 bits virtual memory"
depends on 64BIT
help
2017-02-17 04:27:34 +03:00
Support a maximum at least 48 bits of application virtual
memory. Default is 40 bits or less, depending on the CPU.
For page sizes 16k and above, this option results in a small
memory overhead for page tables. For 4k page size, a fourth
level of page tables is added which imposes both a memory
overhead as well as slower TLB fault handling.
2015-05-15 04:34:43 +03:00
If unsure, say N.
2005-04-17 02:20:36 +04:00
choice
prompt "Kernel page size"
default PAGE_SIZE_4KB
config PAGE_SIZE_4KB
bool "4kB"
2019-10-20 17:43:13 +03:00
depends on !CPU_LOONGSON2EF && !CPU_LOONGSON64
2005-04-17 02:20:36 +04:00
help
2019-03-11 18:54:27 +03:00
This option select the standard 4kB Linux page size. On some
R3000-family processors this is the only available page size. Using
4kB page size will minimize memory consumption and is therefore
recommended for low memory systems.
2005-04-17 02:20:36 +04:00
config PAGE_SIZE_8KB
bool "8kB"
2019-07-23 01:00:03 +03:00
depends on CPU_CAVIUM_OCTEON
2015-05-15 04:34:43 +03:00
depends on !MIPS_VA_BITS_48
2005-04-17 02:20:36 +04:00
help
Using 8kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available
2019-07-23 01:00:03 +03:00
only on cnMIPS processors. Note that you will need a suitable Linux
distribution to support this.
2005-04-17 02:20:36 +04:00
config PAGE_SIZE_16KB
bool "16kB"
2006-05-17 17:04:30 +04:00
depends on !CPU_R3000 && !CPU_TX39XX
2005-04-17 02:20:36 +04:00
help
Using 16kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available on
2006-05-17 17:04:30 +04:00
all non-R3000 family processors. Note that you will need a suitable
Linux distribution to support this.
2005-04-17 02:20:36 +04:00
2009-04-02 16:07:10 +04:00
config PAGE_SIZE_32KB
bool "32kB"
depends on CPU_CAVIUM_OCTEON
2015-05-15 04:34:43 +03:00
depends on !MIPS_VA_BITS_48
2009-04-02 16:07:10 +04:00
help
Using 32kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available
only on cnMIPS cores. Note that you will need a suitable Linux
distribution to support this.
2005-04-17 02:20:36 +04:00
config PAGE_SIZE_64KB
bool "64kB"
2017-06-05 21:21:27 +03:00
depends on !CPU_R3000 && !CPU_TX39XX
2005-04-17 02:20:36 +04:00
help
Using 64kB page size will result in higher performance kernel at
the price of higher memory consumption. This option is available on
all non-R3000 family processor. Not that at the time of this
2006-05-17 17:04:30 +04:00
writing this option is still high experimental.
2005-04-17 02:20:36 +04:00
endchoice
2010-10-12 01:52:45 +04:00
config FORCE_MAX_ZONEORDER
int "Maximum zone order"
2014-01-21 15:22:35 +04:00
range 14 64 if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_64KB
default "14" if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_64KB
range 13 64 if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_32KB
default "13" if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_32KB
range 12 64 if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_16KB
default "12" if MIPS_HUGE_TLB_SUPPORT && PAGE_SIZE_16KB
2020-09-17 16:35:28 +03:00
range 0 64
2010-10-12 01:52:45 +04:00
default "11"
help
The kernel memory allocator divides physically contiguous memory
blocks into "zones", where each zone is a power of two number of
pages. This option selects the largest power of two that the kernel
keeps in the memory allocator. If you need to allocate very large
blocks of physically contiguous memory, then you may need to
increase this value.
This config option is actually maximum order plus one. For example,
a value of 11 means that the largest free memory block is 2^10 pages.
The page size is not necessarily 4KB. Keep this in mind
when choosing a value for this option.
2005-04-17 02:20:36 +04:00
config BOARD_SCACHE
bool
config IP22_CPU_SCACHE
bool
select BOARD_SCACHE
2006-06-20 20:15:20 +04:00
#
# Support for a MIPS32 / MIPS64 style S-caches
#
config MIPS_CPU_SCACHE
bool
select BOARD_SCACHE
2005-04-17 02:20:36 +04:00
config R5000_CPU_SCACHE
bool
select BOARD_SCACHE
config RM7000_CPU_SCACHE
bool
select BOARD_SCACHE
config SIBYTE_DMA_PAGEOPS
bool "Use DMA to clear/copy pages"
depends on CPU_SB1
help
Instead of using the CPU to zero and copy pages, use a Data Mover
channel. These DMA channels are otherwise unused by the standard
SiByte Linux port. Seems to give a small performance benefit.
config CPU_HAS_PREFETCH
2005-08-05 18:28:54 +04:00
bool
2005-04-17 02:20:36 +04:00
2012-01-31 21:18:43 +04:00
config CPU_GENERIC_DUMP_TLB
bool
2019-07-23 01:00:03 +03:00
default y if !(CPU_R3000 || CPU_TX39XX)
2012-01-31 21:18:43 +04:00
2018-11-08 02:14:02 +03:00
config MIPS_FP_SUPPORT
2018-11-08 02:14:11 +03:00
bool "Floating Point support" if EXPERT
default y
help
Select y to include support for floating point in the kernel
including initialization of FPU hardware, FP context save & restore
and emulation of an FPU where necessary. Without this support any
userland program attempting to use floating point instructions will
receive a SIGILL.
If you know that your userland will not attempt to use floating point
instructions then you can say n here to shrink the kernel a little.
If unsure, say y.
2018-11-08 02:14:02 +03:00
2018-11-08 02:14:02 +03:00
config CPU_R2300_FPU
bool
2018-11-08 02:14:02 +03:00
depends on MIPS_FP_SUPPORT
2018-11-08 02:14:02 +03:00
default y if CPU_R3000 || CPU_TX39XX
2019-08-31 18:40:43 +03:00
config CPU_R3K_TLB
bool
2012-01-31 21:18:44 +04:00
config CPU_R4K_FPU
bool
2018-11-08 02:14:02 +03:00
depends on MIPS_FP_SUPPORT
2018-11-08 02:14:02 +03:00
default y if !CPU_R2300_FPU
2012-01-31 21:18:44 +04:00
2012-01-31 21:18:45 +04:00
config CPU_R4K_CACHE_TLB
bool
2019-08-31 18:40:43 +03:00
default y if !(CPU_R3K_TLB || CPU_SB1 || CPU_CAVIUM_OCTEON)
2012-01-31 21:18:45 +04:00
2006-10-06 20:36:20 +04:00
config MIPS_MT_SMP
2014-04-08 14:59:10 +04:00
bool "MIPS MT SMP support (1 TC on each available VPE)"
2017-08-08 02:01:16 +03:00
default y
2017-08-08 02:18:04 +03:00
depends on SYS_SUPPORTS_MULTITHREADING && !CPU_MIPSR6 && !CPU_MICROMIPS
2006-04-24 17:58:53 +04:00
select CPU_MIPSR2_IRQ_VI
2007-05-08 17:05:39 +04:00
select CPU_MIPSR2_IRQ_EI
2013-10-05 01:23:28 +04:00
select SYNC_R4K
2006-06-05 20:24:46 +04:00
select MIPS_MT
2006-04-05 12:45:45 +04:00
select SMP
2007-11-19 15:23:51 +03:00
select SMP_UP
2013-10-05 01:23:28 +04:00
select SYS_SUPPORTS_SMP
select SYS_SUPPORTS_SCHED_SMT
2012-07-14 00:44:53 +04:00
select MIPS_PERF_SHARED_TC_COUNTERS
2006-06-05 20:24:46 +04:00
help
2013-10-05 01:23:28 +04:00
This is a kernel model which is known as SMVP. This is supported
on cores with the MT ASE and uses the available VPEs to implement
virtual processors which supports SMP. This is equivalent to the
Intel Hyperthreading feature. For further information go to
<http://www.imgtec.com/mips/mips-multithreading.asp>.
2006-04-05 12:45:45 +04:00
2006-06-05 20:24:46 +04:00
config MIPS_MT
bool
2007-03-02 23:42:04 +03:00
config SCHED_SMT
bool "SMT (multithreading) scheduler support"
depends on SYS_SUPPORTS_SCHED_SMT
default n
help
SMT scheduler support improves the CPU scheduler's decision making
when dealing with MIPS MT enabled cores at a cost of slightly
increased overhead in some places. If unsure say N here.
config SYS_SUPPORTS_SCHED_SMT
bool
2006-06-05 20:24:46 +04:00
config SYS_SUPPORTS_MULTITHREADING
bool
2006-04-05 12:45:47 +04:00
config MIPS_MT_FPAFF
bool "Dynamic FPU affinity for FP-intensive threads"
default y
2014-05-23 18:29:44 +04:00
depends on MIPS_MT_SMP
2007-07-27 22:31:10 +04:00
2014-12-03 18:47:03 +03:00
config MIPSR2_TO_R6_EMULATOR
bool "MIPS R2-to-R6 emulator"
2016-10-17 17:34:37 +03:00
depends on CPU_MIPSR6
2018-11-08 02:14:02 +03:00
depends on MIPS_FP_SUPPORT
2014-12-03 18:47:03 +03:00
default y
help
Choose this option if you want to run non-R6 MIPS userland code.
Even if you say 'Y' here, the emulator will still be disabled by
2015-03-10 15:30:56 +03:00
default. You can enable it using the 'mipsr2emu' kernel option.
2014-12-03 18:47:03 +03:00
The only reason this is a build-time option is to save ~14K from the
final kernel image.
2018-01-15 23:54:35 +03:00
config SYS_SUPPORTS_VPE_LOADER
bool
depends on SYS_SUPPORTS_MULTITHREADING
help
Indicates that the platform supports the VPE loader, and provides
physical_memsize.
2007-07-27 22:31:10 +04:00
config MIPS_VPE_LOADER
bool "VPE loader support."
2018-01-15 23:54:35 +03:00
depends on SYS_SUPPORTS_VPE_LOADER && MODULES
2007-07-27 22:31:10 +04:00
select CPU_MIPSR2_IRQ_VI
select CPU_MIPSR2_IRQ_EI
select MIPS_MT
help
Includes a loader for loading an elf relocatable object
onto another VPE and running it.
2006-04-05 12:45:47 +04:00
2013-10-31 00:52:07 +04:00
config MIPS_VPE_LOADER_CMP
bool
default "y"
depends on MIPS_VPE_LOADER && MIPS_CMP
2013-10-31 00:52:06 +04:00
config MIPS_VPE_LOADER_MT
bool
default "y"
depends on MIPS_VPE_LOADER && !MIPS_CMP
2005-07-14 19:57:16 +04:00
config MIPS_VPE_LOADER_TOM
bool "Load VPE program into memory hidden from linux"
depends on MIPS_VPE_LOADER
default y
help
The loader can use memory that is present but has been hidden from
Linux using the kernel command line option "mem=xxMB". It's up to
you to ensure the amount you put in the option and the space your
program requires is less or equal to the amount physically present.
config MIPS_VPE_APSP_API
2005-10-29 22:32:41 +04:00
bool "Enable support for AP/SP API (RTLX)"
depends on MIPS_VPE_LOADER
2005-07-14 19:57:16 +04:00
2014-01-01 19:29:03 +04:00
config MIPS_VPE_APSP_API_CMP
bool
default "y"
depends on MIPS_VPE_APSP_API && MIPS_CMP
2014-01-01 19:26:46 +04:00
config MIPS_VPE_APSP_API_MT
bool
default "y"
depends on MIPS_VPE_APSP_API && !MIPS_CMP
2008-10-04 03:06:29 +04:00
config MIPS_CMP
2014-01-15 14:32:00 +04:00
bool "MIPS CMP framework support (DEPRECATED)"
2015-07-09 12:40:38 +03:00
depends on SYS_SUPPORTS_MIPS_CMP && !CPU_MIPSR6
2014-07-22 12:29:34 +04:00
select SMP
2009-06-18 03:40:34 +04:00
select SYNC_R4K
2014-07-22 12:29:34 +04:00
select SYS_SUPPORTS_SMP
2008-10-04 03:06:29 +04:00
select WEAK_ORDERING
default n
help
2014-01-15 14:31:58 +04:00
Select this if you are using a bootloader which implements the "CMP
framework" protocol (ie. YAMON) and want your kernel to make use of
its ability to start secondary CPUs.
2008-10-04 03:06:29 +04:00
2014-01-15 14:32:00 +04:00
Unless you have a specific need, you should use CONFIG_MIPS_CPS
instead of this.
2014-01-15 14:31:53 +04:00
config MIPS_CPS
bool "MIPS Coherent Processing System support"
2016-02-03 06:15:33 +03:00
depends on SYS_SUPPORTS_MIPS_CPS
2014-01-15 14:31:53 +04:00
select MIPS_CM
2014-04-14 17:13:57 +04:00
select MIPS_CPS_PM if HOTPLUG_CPU
2014-01-15 14:31:53 +04:00
select SMP
select SYNC_R4K if (CEVT_R4K || CSRC_R4K)
2014-04-14 17:13:57 +04:00
select SYS_SUPPORTS_HOTPLUG_CPU
2017-06-03 00:48:52 +03:00
select SYS_SUPPORTS_SCHED_SMT if CPU_MIPSR6
2014-01-15 14:31:53 +04:00
select SYS_SUPPORTS_SMP
select WEAK_ORDERING
2020-12-03 09:54:43 +03:00
select GENERIC_IRQ_MIGRATION if HOTPLUG_CPU
2014-01-15 14:31:53 +04:00
help
Select this if you wish to run an SMP kernel across multiple cores
within a MIPS Coherent Processing System. When this option is
enabled the kernel will probe for other cores and boot them with
no external assistance. It is safe to enable this when hardware
support is unavailable.
2014-04-14 14:00:56 +04:00
config MIPS_CPS_PM
2014-09-18 19:09:49 +04:00
depends on MIPS_CPS
2014-04-14 14:00:56 +04:00
bool
2014-01-15 14:31:51 +04:00
config MIPS_CM
bool
2017-08-13 05:49:42 +03:00
select MIPS_CPC
2014-01-15 14:31:51 +04:00
2014-01-15 14:31:52 +04:00
config MIPS_CPC
bool
2008-10-04 03:06:29 +04:00
2005-04-17 02:20:36 +04:00
config SB1_PASS_2_WORKAROUNDS
bool
depends on CPU_SB1 && (CPU_SB1_PASS_2_2 || CPU_SB1_PASS_2)
default y
config SB1_PASS_2_1_WORKAROUNDS
bool
depends on CPU_SB1 && CPU_SB1_PASS_2
default y
2014-07-21 11:46:14 +04:00
choice
prompt "SmartMIPS or microMIPS ASE support"
config CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS
bool "None"
help
Select this if you want neither microMIPS nor SmartMIPS support
2007-02-02 19:41:47 +03:00
config CPU_HAS_SMARTMIPS
depends on SYS_SUPPORTS_SMARTMIPS
2014-07-21 11:46:14 +04:00
bool "SmartMIPS"
2007-02-02 19:41:47 +03:00
help
SmartMIPS is a extension of the MIPS32 architecture aimed at
increased security at both hardware and software level for
smartcards. Enabling this option will allow proper use of the
SmartMIPS instructions by Linux applications. However a kernel with
this option will not work on a MIPS core without SmartMIPS core. If
you don't know you probably don't have SmartMIPS and should say N
here.
2013-03-25 22:27:11 +04:00
config CPU_MICROMIPS
2014-10-27 13:34:11 +03:00
depends on 32BIT && SYS_SUPPORTS_MICROMIPS && !CPU_MIPSR6
2014-07-21 11:46:14 +04:00
bool "microMIPS"
2013-03-25 22:27:11 +04:00
help
When this option is enabled the kernel will be built using the
microMIPS ISA
2014-07-21 11:46:14 +04:00
endchoice
2014-01-27 19:23:10 +04:00
config CPU_HAS_MSA
2015-07-27 22:58:27 +03:00
bool "Support for the MIPS SIMD Architecture"
2014-01-27 19:23:10 +04:00
depends on CPU_SUPPORTS_MSA
2018-11-08 02:14:02 +03:00
depends on MIPS_FP_SUPPORT
2014-07-11 19:47:14 +04:00
depends on 64BIT || MIPS_O32_FP64_SUPPORT
2014-01-27 19:23:10 +04:00
help
MIPS SIMD Architecture (MSA) introduces 128 bit wide vector registers
and a set of SIMD instructions to operate on them. When this option
2014-01-27 19:23:11 +04:00
is enabled the kernel will support allocating & switching MSA
vector register contexts. If you know that your kernel will only be
running on CPUs which do not support MSA or that your userland will
not be making use of it then you may wish to say N here to reduce
the size & complexity of your kernel.
2014-01-27 19:23:10 +04:00
If unsure, say Y.
2005-04-17 02:20:36 +04:00
config CPU_HAS_WB
2006-04-24 17:58:53 +04:00
bool
2005-07-14 19:57:16 +04:00
2011-11-16 05:25:45 +04:00
config XKS01
bool
2020-01-13 13:14:59 +03:00
config CPU_HAS_DIEI
depends on !CPU_DIEI_BROKEN
bool
config CPU_DIEI_BROKEN
bool
2016-02-09 23:55:51 +03:00
config CPU_HAS_RIXI
bool
2020-01-22 13:58:50 +03:00
config CPU_NO_LOAD_STORE_LR
MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions
MIPSR6 CPUs do not support unaligned load/store instructions
(LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit).
Currently the MIPS tree has some special cases to avoid these
instructions, and the code is testing for !CONFIG_CPU_MIPSR6.
This patch declares a new Kconfig variable:
CONFIG_CPU_HAS_LOAD_STORE_LR.
This variable indicates that the CPU supports these instructions.
Then, the patch does the following:
- Carefully selects this option on all CPUs except MIPSR6.
- Switches all the special cases to test for the new variable,
and inverts the logic:
'#ifndef CONFIG_CPU_MIPSR6' turns into
'#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR'
and vice-versa.
Also, when this variable is NOT selected (e.g. MIPSR6),
CONFIG_GENERIC_CSUM will default to 'y', to compile generic
C checksum code (instead of special assembly code that uses the
unsupported instructions).
This commit should not affect any existing CPU, and is required
for future Lexra CPU support, that misses these instructions too.
Signed-off-by: Yasha Cherikovsky <yasha.che3@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/20808/
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
2018-09-26 14:16:15 +03:00
bool
help
2020-01-22 13:58:50 +03:00
CPU lacks support for unaligned load and store instructions:
MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions
MIPSR6 CPUs do not support unaligned load/store instructions
(LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit).
Currently the MIPS tree has some special cases to avoid these
instructions, and the code is testing for !CONFIG_CPU_MIPSR6.
This patch declares a new Kconfig variable:
CONFIG_CPU_HAS_LOAD_STORE_LR.
This variable indicates that the CPU supports these instructions.
Then, the patch does the following:
- Carefully selects this option on all CPUs except MIPSR6.
- Switches all the special cases to test for the new variable,
and inverts the logic:
'#ifndef CONFIG_CPU_MIPSR6' turns into
'#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR'
and vice-versa.
Also, when this variable is NOT selected (e.g. MIPSR6),
CONFIG_GENERIC_CSUM will default to 'y', to compile generic
C checksum code (instead of special assembly code that uses the
unsupported instructions).
This commit should not affect any existing CPU, and is required
for future Lexra CPU support, that misses these instructions too.
Signed-off-by: Yasha Cherikovsky <yasha.che3@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/20808/
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
2018-09-26 14:16:15 +03:00
LWL, LWR, SWL, SWR (Load/store word left/right).
2020-01-22 13:58:50 +03:00
LDL, LDR, SDL, SDR (Load/store doubleword left/right, for 64bit
systems).
MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions
MIPSR6 CPUs do not support unaligned load/store instructions
(LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit).
Currently the MIPS tree has some special cases to avoid these
instructions, and the code is testing for !CONFIG_CPU_MIPSR6.
This patch declares a new Kconfig variable:
CONFIG_CPU_HAS_LOAD_STORE_LR.
This variable indicates that the CPU supports these instructions.
Then, the patch does the following:
- Carefully selects this option on all CPUs except MIPSR6.
- Switches all the special cases to test for the new variable,
and inverts the logic:
'#ifndef CONFIG_CPU_MIPSR6' turns into
'#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR'
and vice-versa.
Also, when this variable is NOT selected (e.g. MIPSR6),
CONFIG_GENERIC_CSUM will default to 'y', to compile generic
C checksum code (instead of special assembly code that uses the
unsupported instructions).
This commit should not affect any existing CPU, and is required
for future Lexra CPU support, that misses these instructions too.
Signed-off-by: Yasha Cherikovsky <yasha.che3@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Patchwork: https://patchwork.linux-mips.org/patch/20808/
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
2018-09-26 14:16:15 +03:00
2006-06-05 20:24:46 +04:00
#
# Vectored interrupt mode is an R2 feature
#
2005-07-14 19:57:16 +04:00
config CPU_MIPSR2_IRQ_VI
2006-06-05 20:24:46 +04:00
bool
2005-07-14 19:57:16 +04:00
2006-06-05 20:24:46 +04:00
#
# Extended interrupt mode is an R2 feature
#
2005-07-14 19:57:16 +04:00
config CPU_MIPSR2_IRQ_EI
2006-06-05 20:24:46 +04:00
bool
2005-07-14 19:57:16 +04:00
2005-04-17 02:20:36 +04:00
config CPU_HAS_SYNC
bool
depends on !CPU_R3000
default y
2007-10-23 15:43:11 +04:00
#
# CPU non-features
#
config CPU_DADDI_WORKAROUNDS
bool
config CPU_R4000_WORKAROUNDS
bool
select CPU_R4400_WORKAROUNDS
config CPU_R4400_WORKAROUNDS
bool
2019-10-02 02:04:32 +03:00
config CPU_R4X00_BUGS64
bool
default y if SYS_HAS_CPU_R4X00 && 64BIT && (TARGET_ISA_REV < 1)
2016-05-06 16:36:23 +03:00
config MIPS_ASID_SHIFT
int
default 6 if CPU_R3000 || CPU_TX39XX
default 0
config MIPS_ASID_BITS
int
2016-05-06 16:36:24 +03:00
default 0 if MIPS_ASID_BITS_VARIABLE
2016-05-06 16:36:23 +03:00
default 6 if CPU_R3000 || CPU_TX39XX
default 8
2016-05-06 16:36:24 +03:00
config MIPS_ASID_BITS_VARIABLE
bool
2018-02-10 01:11:06 +03:00
config MIPS_CRC_SUPPORT
bool
2020-08-24 19:32:43 +03:00
# R4600 erratum. Due to the lack of errata information the exact
# technical details aren't known. I've experimentally found that disabling
# interrupts during indexed I-cache flushes seems to be sufficient to deal
# with the issue.
config WAR_R4600_V1_INDEX_ICACHEOP
bool
2020-08-24 19:32:44 +03:00
# Pleasures of the R4600 V1.x. Cite from the IDT R4600 V1.7 errata:
#
# 18. The CACHE instructions Hit_Writeback_Invalidate_D, Hit_Writeback_D,
# Hit_Invalidate_D and Create_Dirty_Excl_D should only be
# executed if there is no other dcache activity. If the dcache is
2020-10-27 21:34:30 +03:00
# accessed for another instruction immediately preceding when these
2020-08-24 19:32:44 +03:00
# cache instructions are executing, it is possible that the dcache
# tag match outputs used by these cache instructions will be
# incorrect. These cache instructions should be preceded by at least
# four instructions that are not any kind of load or store
# instruction.
#
# This is not allowed: lw
# nop
# nop
# nop
# cache Hit_Writeback_Invalidate_D
#
# This is allowed: lw
# nop
# nop
# nop
# nop
# cache Hit_Writeback_Invalidate_D
config WAR_R4600_V1_HIT_CACHEOP
bool
2020-08-24 19:32:45 +03:00
# Writeback and invalidate the primary cache dcache before DMA.
#
# R4600 v2.0 bug: "The CACHE instructions Hit_Writeback_Inv_D,
# Hit_Writeback_D, Hit_Invalidate_D and Create_Dirty_Exclusive_D will only
# operate correctly if the internal data cache refill buffer is empty. These
# CACHE instructions should be separated from any potential data cache miss
# by a load instruction to an uncached address to empty the response buffer."
# (Revision 2.0 device errata from IDT available on https://www.idt.com/
# in .pdf format.)
config WAR_R4600_V2_HIT_CACHEOP
bool
2020-08-24 19:32:47 +03:00
# From TX49/H2 manual: "If the instruction (i.e. CACHE) is issued for
# the line which this instruction itself exists, the following
# operation is not guaranteed."
#
# Workaround: do two phase flushing for Index_Invalidate_I
config WAR_TX49XX_ICACHE_INDEX_INV
bool
2020-08-24 19:32:48 +03:00
# The RM7000 processors and the E9000 cores have a bug (though PMC-Sierra
# opposes it being called that) where invalid instructions in the same
# I-cache line worth of instructions being fetched may case spurious
# exceptions.
config WAR_ICACHE_REFILLS
bool
2020-08-24 19:32:49 +03:00
# On the R10000 up to version 2.6 (not sure about 2.7) there is a bug that
# may cause ll / sc and lld / scd sequences to execute non-atomically.
config WAR_R10000_LLSC
bool
2020-08-24 19:32:50 +03:00
# 34K core erratum: "Problems Executing the TLBR Instruction"
config WAR_MIPS34K_MISSED_ITLB
bool
2005-04-17 02:20:36 +04:00
#
# - Highmem only makes sense for the 32-bit kernel.
# - The current highmem code will only work properly on physically indexed
# caches such as R3000, SB1, R7000 or those that look like they're virtually
# indexed such as R4000/R4400 SC and MC versions or R10000. So for the
# moment we protect the user and offer the highmem option only on machines
# where it's known to be safe. This will not offer highmem on a few systems
# such as MIPS32 and MIPS64 CPUs which may have virtual and physically
# indexed CPUs but we're playing safe.
2005-08-10 19:17:11 +04:00
# - We use SYS_SUPPORTS_HIGHMEM to offer highmem only for systems where we
# know they might have memory configurations that could make use of highmem
# support.
2005-04-17 02:20:36 +04:00
#
config HIGHMEM
bool "High Memory Support"
2013-12-03 14:22:26 +04:00
depends on 32BIT && CPU_SUPPORTS_HIGHMEM && SYS_SUPPORTS_HIGHMEM && !CPU_MIPS32_3_5_EVA
2020-11-03 12:27:25 +03:00
select KMAP_LOCAL
2005-08-10 19:17:11 +04:00
config CPU_SUPPORTS_HIGHMEM
bool
config SYS_SUPPORTS_HIGHMEM
bool
2005-04-17 02:20:36 +04:00
2007-02-02 19:41:47 +03:00
config SYS_SUPPORTS_SMARTMIPS
bool
2013-02-06 02:52:02 +04:00
config SYS_SUPPORTS_MICROMIPS
bool
2014-04-29 03:49:24 +04:00
config SYS_SUPPORTS_MIPS16
bool
help
This option must be set if a kernel might be executed on a MIPS16-
enabled CPU even if MIPS16 is not actually being used. In other
words, it makes the kernel MIPS16-tolerant.
2014-01-27 19:23:10 +04:00
config CPU_SUPPORTS_MSA
bool
2005-06-26 01:54:31 +04:00
config ARCH_FLATMEM_ENABLE
def_bool y
2019-10-20 17:43:13 +03:00
depends on !NUMA && !CPU_LOONGSON2EF
2005-06-26 01:54:31 +04:00
2006-07-02 19:09:47 +04:00
config ARCH_SPARSEMEM_ENABLE
bool
2019-09-16 14:13:10 +03:00
select SPARSEMEM_STATIC if !SGI_IP27
2006-07-02 19:09:47 +04:00
2006-06-12 02:03:08 +04:00
config NUMA
bool "NUMA Support"
depends on SYS_SUPPORTS_NUMA
help
Say Y to compile the kernel to support NUMA (Non-Uniform Memory
Access). This option improves performance on systems with more
than two nodes; on two node systems it is generally better to
2020-02-01 04:55:43 +03:00
leave it disabled; on single node systems leave this option
2006-06-12 02:03:08 +04:00
disabled.
config SYS_SUPPORTS_NUMA
bool
2020-01-09 15:23:31 +03:00
config HAVE_SETUP_PER_CPU_AREA
def_bool y
depends on NUMA
config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool y
depends on NUMA
2016-03-31 12:05:39 +03:00
config RELOCATABLE
bool "Relocatable kernel"
mips: Add MIPS Release 5 support
There are five MIPS32/64 architecture releases currently available:
from 1 to 6 except fourth one, which was intentionally skipped.
Three of them can be called as major: 1st, 2nd and 6th, that not only
have some system level alterations, but also introduced significant
core/ISA level updates. The rest of the MIPS architecture releases are
minor.
Even though they don't have as much ISA/system/core level changes
as the major ones with respect to the previous releases, they still
provide a set of updates (I'd say they were intended to be the
intermediate releases before a major one) that might be useful for the
kernel and user-level code, when activated by the kernel or compiler.
In particular the following features were introduced or ended up being
available at/after MIPS32/64 Release 5 architecture:
+ the last release of the misaligned memory access instructions,
+ virtualisation - VZ ASE - is optional component of the arch,
+ SIMD - MSA ASE - is optional component of the arch,
+ DSP ASE is optional component of the arch,
+ CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers)
must be available if FPU is implemented,
+ CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits
are available.
+ UFR/UNFR aliases to access CP0.Status.FR from user-space by means of
ctc1/cfc1 instructions (enabled by CP0.Config5.UFR),
+ CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without
accidentally clearing LL-bit when returning from an interrupt,
exception, or error trap,
+ XPA feature together with extended versions of CPx registers is
introduced, which needs to have mfhc0/mthc0 instructions available.
So due to these changes GNU GCC provides an extended instructions set
support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even
though the architecture alteration isn't that big, it still worth to be
taken into account by the kernel software. Finally we can't deny that
some optimization/limitations might be found in future and implemented
on some level in kernel or compiler. In this case having even
intermediate MIPS architecture releases support would be more than
useful.
So the most of the changes provided by this commit can be split into
either compile- or runtime configs related. The compile-time related
changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5
configs and concern the code activating MIPSR2 or MIPSR6 already
implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition
CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based
platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes
concerns the features which are handled with respect to the MIPS ISA
revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas
these fields can be used to detect either r1 or r2 or r6 releases.
But since we know which CPUs in fact support the R5 arch, we can manually
set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then
use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate.
Since XPA/EVA provide too complex alterationss and to have them used with
MIPS32 Release 2 charged kernels (for compatibility with current platform
configs) they are left to be setup as a separate kernel configs.
Co-developed-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-05-21 17:07:14 +03:00
depends on SYS_SUPPORTS_RELOCATABLE
depends on CPU_MIPS32_R2 || CPU_MIPS64_R2 || \
CPU_MIPS32_R5 || CPU_MIPS64_R5 || \
CPU_MIPS32_R6 || CPU_MIPS64_R6 || \
2020-11-25 13:07:46 +03:00
CPU_P5600 || CAVIUM_OCTEON_SOC || \
CPU_LOONGSON64
2016-03-31 12:05:39 +03:00
help
This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.
The relocations make the kernel binary about 15% larger,
but are discarded at runtime
2016-03-31 12:05:34 +03:00
config RELOCATION_TABLE_SIZE
hex "Relocation table size"
depends on RELOCATABLE
range 0x0 0x01000000
2020-11-25 13:07:46 +03:00
default "0x00200000" if CPU_LOONGSON64
2016-03-31 12:05:34 +03:00
default "0x00100000"
2020-06-13 19:50:22 +03:00
help
2016-03-31 12:05:34 +03:00
A table of relocation data will be appended to the kernel binary
and parsed at boot to fix up the relocated kernel.
This option allows the amount of space reserved for the table to be
adjusted, although the default of 1Mb should be ok in most cases.
The build will fail and a valid size suggested if this is too small.
If unsure, leave at the default value.
2016-03-31 12:05:41 +03:00
config RANDOMIZE_BASE
bool "Randomize the address of the kernel image"
depends on RELOCATABLE
2020-06-13 19:50:22 +03:00
help
2019-03-11 18:54:27 +03:00
Randomizes the physical and virtual address at which the
kernel image is loaded, as a security feature that
deters exploit attempts relying on knowledge of the location
of kernel internals.
2016-03-31 12:05:41 +03:00
2019-03-11 18:54:27 +03:00
Entropy is generated using any coprocessor 0 registers available.
2016-03-31 12:05:41 +03:00
2019-03-11 18:54:27 +03:00
The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET.
2016-03-31 12:05:41 +03:00
2019-03-11 18:54:27 +03:00
If unsure, say N.
2016-03-31 12:05:41 +03:00
config RANDOMIZE_BASE_MAX_OFFSET
hex "Maximum kASLR offset" if EXPERT
depends on RANDOMIZE_BASE
range 0x0 0x40000000 if EVA || 64BIT
range 0x0 0x08000000
default "0x01000000"
2020-06-13 19:50:22 +03:00
help
2016-03-31 12:05:41 +03:00
When kASLR is active, this provides the maximum offset that will
be applied to the kernel image. It should be set according to the
amount of physical RAM available in the target system minus
PHYSICAL_START and must be a power of 2.
This is limited by the size of KSEG0, 256Mb on 32-bit or 1Gb with
EVA or 64-bit. The default is 16Mb.
2006-04-11 09:53:53 +04:00
config NODES_SHIFT
int
default "6"
depends on NEED_MULTIPLE_NODES
2010-10-12 15:37:22 +04:00
config HW_PERF_EVENTS
bool "Enable hardware performance counter support for perf events"
2019-10-20 17:43:13 +03:00
depends on PERF_EVENTS && !OPROFILE && (CPU_MIPS32 || CPU_MIPS64 || CPU_R10000 || CPU_SB1 || CPU_CAVIUM_OCTEON || CPU_XLP || CPU_LOONGSON64)
2010-10-12 15:37:22 +04:00
default y
help
Enable hardware performance counter support for perf events. If
disabled, perf events will use software events only.
2020-02-05 07:08:33 +03:00
config DMI
bool "Enable DMI scanning"
depends on MACH_LOONGSON64
select DMI_SCAN_MACHINE_NON_EFI_FALLBACK
default y
help
Enabled scanning of DMI to identify machine quirks. Say Y
here unless you have verified that your setup is not
affected by entries in the DMI blacklist. Required by PNP
BIOS code.
2005-04-17 02:20:36 +04:00
config SMP
bool "Multi-Processing support"
2006-06-04 14:51:46 +04:00
depends on SYS_SUPPORTS_SMP
help
2005-04-17 02:20:36 +04:00
This enables support for systems with more than one CPU. If you have
2014-01-24 03:55:29 +04:00
a system with only one CPU, say N. If you have a system with more
than one CPU, say Y.
2005-04-17 02:20:36 +04:00
2014-01-24 03:55:29 +04:00
If you say N here, the kernel will run on uni- and multiprocessor
2005-04-17 02:20:36 +04:00
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,
2014-01-24 03:55:29 +04:00
uniprocessor machines. On a uniprocessor machine, the kernel
2005-04-17 02:20:36 +04:00
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.
2008-02-03 16:50:21 +03:00
See also the SMP-HOWTO available at
2020-07-14 22:12:26 +03:00
<https://www.tldp.org/docs.html#howto>.
2005-04-17 02:20:36 +04:00
If you don't know what to do here, say N.
2016-07-07 10:50:40 +03:00
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP && SYS_SUPPORTS_HOTPLUG_CPU
help
Say Y here to allow turning CPUs off and on. CPUs can be
controlled through /sys/devices/system/cpu.
(Note: power management support will enable this option
automatically on SMP systems. )
Say N if you want to disable CPU hotplug.
2007-11-19 15:23:51 +03:00
config SMP_UP
bool
2008-10-04 03:06:29 +04:00
config SYS_SUPPORTS_MIPS_CMP
bool
2014-01-15 14:31:53 +04:00
config SYS_SUPPORTS_MIPS_CPS
bool
2006-06-04 14:51:46 +04:00
config SYS_SUPPORTS_SMP
bool
2007-02-06 19:53:15 +03:00
config NR_CPUS_DEFAULT_4
bool
config NR_CPUS_DEFAULT_8
bool
config NR_CPUS_DEFAULT_16
bool
config NR_CPUS_DEFAULT_32
bool
config NR_CPUS_DEFAULT_64
bool
2005-04-17 02:20:36 +04:00
config NR_CPUS
2014-04-29 18:37:40 +04:00
int "Maximum number of CPUs (2-256)"
range 2 256
2005-04-17 02:20:36 +04:00
depends on SMP
2007-02-06 19:53:15 +03:00
default "4" if NR_CPUS_DEFAULT_4
default "8" if NR_CPUS_DEFAULT_8
default "16" if NR_CPUS_DEFAULT_16
default "32" if NR_CPUS_DEFAULT_32
default "64" if NR_CPUS_DEFAULT_64
2005-04-17 02:20:36 +04:00
help
This allows you to specify the maximum number of CPUs which this
kernel will support. The maximum supported value is 32 for 32-bit
kernel and 64 for 64-bit kernels; the minimum value which makes
2007-03-17 19:01:39 +03:00
sense is 1 for Qemu (useful only for kernel debugging purposes)
and 2 for all others.
2005-04-17 02:20:36 +04:00
This is purely to save memory - each supported CPU adds
2007-03-17 19:01:39 +03:00
approximately eight kilobytes to the kernel image. For best
performance should round up your number of processors to the next
power of two.
2005-04-17 02:20:36 +04:00
2012-07-14 00:44:53 +04:00
config MIPS_PERF_SHARED_TC_COUNTERS
bool
2017-09-28 20:34:04 +03:00
config MIPS_NR_CPU_NR_MAP_1024
bool
config MIPS_NR_CPU_NR_MAP
int
depends on SMP
default 1024 if MIPS_NR_CPU_NR_MAP_1024
default NR_CPUS if !MIPS_NR_CPU_NR_MAP_1024
2012-07-14 00:44:53 +04:00
2006-06-19 19:19:13 +04:00
#
# Timer Interrupt Frequency Configuration
#
choice
prompt "Timer frequency"
default HZ_250
help
2019-03-11 18:54:27 +03:00
Allows the configuration of the timer frequency.
2006-06-19 19:19:13 +04:00
2015-09-22 20:16:39 +03:00
config HZ_24
bool "24 HZ" if SYS_SUPPORTS_24HZ || SYS_SUPPORTS_ARBIT_HZ
2006-06-19 19:19:13 +04:00
config HZ_48
2008-02-25 19:55:29 +03:00
bool "48 HZ" if SYS_SUPPORTS_48HZ || SYS_SUPPORTS_ARBIT_HZ
2006-06-19 19:19:13 +04:00
config HZ_100
bool "100 HZ" if SYS_SUPPORTS_100HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_128
bool "128 HZ" if SYS_SUPPORTS_128HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_250
bool "250 HZ" if SYS_SUPPORTS_250HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_256
bool "256 HZ" if SYS_SUPPORTS_256HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_1000
bool "1000 HZ" if SYS_SUPPORTS_1000HZ || SYS_SUPPORTS_ARBIT_HZ
config HZ_1024
bool "1024 HZ" if SYS_SUPPORTS_1024HZ || SYS_SUPPORTS_ARBIT_HZ
endchoice
2015-09-22 20:16:39 +03:00
config SYS_SUPPORTS_24HZ
bool
2006-06-19 19:19:13 +04:00
config SYS_SUPPORTS_48HZ
bool
config SYS_SUPPORTS_100HZ
bool
config SYS_SUPPORTS_128HZ
bool
config SYS_SUPPORTS_250HZ
bool
config SYS_SUPPORTS_256HZ
bool
config SYS_SUPPORTS_1000HZ
bool
config SYS_SUPPORTS_1024HZ
bool
config SYS_SUPPORTS_ARBIT_HZ
bool
2015-09-22 20:16:39 +03:00
default y if !SYS_SUPPORTS_24HZ && \
!SYS_SUPPORTS_48HZ && \
!SYS_SUPPORTS_100HZ && \
!SYS_SUPPORTS_128HZ && \
!SYS_SUPPORTS_250HZ && \
!SYS_SUPPORTS_256HZ && \
!SYS_SUPPORTS_1000HZ && \
2006-06-19 19:19:13 +04:00
!SYS_SUPPORTS_1024HZ
config HZ
int
2015-09-22 20:16:39 +03:00
default 24 if HZ_24
2006-06-19 19:19:13 +04:00
default 48 if HZ_48
default 100 if HZ_100
default 128 if HZ_128
default 250 if HZ_250
default 256 if HZ_256
default 1000 if HZ_1000
default 1024 if HZ_1024
2015-03-07 21:30:19 +03:00
config SCHED_HRTICK
def_bool HIGH_RES_TIMERS
2007-01-16 17:29:11 +03:00
config KEXEC
2013-01-17 06:53:19 +04:00
bool "Kexec system call"
2015-09-10 01:38:55 +03:00
select KEXEC_CORE
2007-01-16 17:29:11 +03:00
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
2007-05-09 09:12:20 +04:00
but it is independent of the system firmware. And like a reboot
2007-01-16 17:29:11 +03:00
you can start any kernel with it, not just Linux.
2007-10-20 03:34:40 +04:00
The name comes from the similarity to the exec system call.
2007-01-16 17:29:11 +03:00
It is an ongoing process to be certain the hardware in a machine
is properly shutdown, so do not be surprised if this code does not
2013-08-20 23:38:03 +04:00
initially work for you. As of this writing the exact hardware
interface is strongly in flux, so no good recommendation can be
made.
2007-01-16 17:29:11 +03:00
2012-10-11 20:14:58 +04:00
config CRASH_DUMP
2016-12-02 11:58:29 +03:00
bool "Kernel crash dumps"
help
2012-10-11 20:14:58 +04:00
Generate crash dump after being started by kexec.
This should be normally only set in special crash dump kernels
which are loaded in the main kernel with kexec-tools into
a specially reserved region and then later executed after
a crash by kdump/kexec. The crash dump kernel must be compiled
to a memory address not used by the main kernel or firmware using
PHYSICAL_START.
config PHYSICAL_START
2016-12-02 11:58:29 +03:00
hex "Physical address where the kernel is loaded"
2018-03-26 21:11:51 +03:00
default "0xffffffff84000000"
2016-12-02 11:58:29 +03:00
depends on CRASH_DUMP
help
2012-10-11 20:14:58 +04:00
This gives the CKSEG0 or KSEG0 address where the kernel is loaded.
If you plan to use kernel for capturing the crash dump change
this value to start of the reserved region (the "X" value as
specified in the "crashkernel=YM@XM" command line boot parameter
passed to the panic-ed kernel).
2013-11-22 17:12:07 +04:00
config MIPS_O32_FP64_SUPPORT
2018-11-08 02:13:58 +03:00
bool "Support for O32 binaries using 64-bit FP" if !CPU_MIPSR6
2013-11-22 17:12:07 +04:00
depends on 32BIT || MIPS32_O32
help
When this is enabled, the kernel will support use of 64-bit floating
point registers with binaries using the O32 ABI along with the
EF_MIPS_FP64 ELF header flag (typically built with -mfp64). On
32-bit MIPS systems this support is at the cost of increasing the
size and complexity of the compiled FPU emulator. Thus if you are
running a MIPS32 system and know that none of your userland binaries
will require 64-bit floating point, you may wish to reduce the size
of your kernel & potentially improve FP emulation performance by
saying N here.
2014-02-14 21:55:18 +04:00
Although binutils currently supports use of this flag the details
concerning its effect upon the O32 ABI in userland are still being
2020-10-27 21:34:30 +03:00
worked on. In order to avoid userland becoming dependent upon current
2014-02-14 21:55:18 +04:00
behaviour before the details have been finalised, this option should
be considered experimental and only enabled by those working upon
said details.
If unsure, say N.
2013-11-22 17:12:07 +04:00
2010-10-13 10:52:46 +04:00
config USE_OF
2012-09-18 13:28:54 +04:00
bool
2010-10-13 10:52:46 +04:00
select OF
2010-11-19 02:54:56 +03:00
select OF_EARLY_FLATTREE
2012-02-24 19:07:06 +04:00
select IRQ_DOMAIN
2010-10-13 10:52:46 +04:00
2018-09-12 00:49:24 +03:00
config UHI_BOOT
bool
2014-08-22 00:04:20 +04:00
config BUILTIN_DTB
bool
2015-04-12 13:24:58 +03:00
choice
2015-10-12 14:13:01 +03:00
prompt "Kernel appended dtb support" if USE_OF
2015-04-12 13:24:58 +03:00
default MIPS_NO_APPENDED_DTB
config MIPS_NO_APPENDED_DTB
bool "None"
help
Do not enable appended dtb support.
2015-09-11 17:46:14 +03:00
config MIPS_ELF_APPENDED_DTB
bool "vmlinux"
help
With this option, the boot code will look for a device tree binary
DTB) included in the vmlinux ELF section .appended_dtb. By default
it is empty and the DTB can be appended using binutils command
objcopy:
objcopy --update-section .appended_dtb=<filename>.dtb vmlinux
2020-10-27 21:34:30 +03:00
This is meant as a backward compatibility convenience for those
2015-09-11 17:46:14 +03:00
systems with a bootloader that can't be upgraded to accommodate
the documented boot protocol using a device tree.
2015-04-12 13:24:58 +03:00
config MIPS_RAW_APPENDED_DTB
2016-06-20 12:27:36 +03:00
bool "vmlinux.bin or vmlinuz.bin"
2015-04-12 13:24:58 +03:00
help
With this option, the boot code will look for a device tree binary
2016-06-20 12:27:36 +03:00
DTB) appended to raw vmlinux.bin or vmlinuz.bin.
2015-04-12 13:24:58 +03:00
(e.g. cat vmlinux.bin <filename>.dtb > vmlinux_w_dtb).
This is meant as a backward compatibility convenience for those
systems with a bootloader that can't be upgraded to accommodate
the documented boot protocol using a device tree.
Beware that there is very little in terms of protection against
this option being confused by leftover garbage in memory that might
look like a DTB header after a reboot if no actual DTB is appended
to vmlinux.bin. Do not leave this option active in a production kernel
if you don't intend to always append a DTB.
endchoice
2015-10-12 14:13:02 +03:00
choice
prompt "Kernel command line type" if !CMDLINE_OVERRIDE
2015-10-12 14:13:03 +03:00
default MIPS_CMDLINE_FROM_DTB if USE_OF && !ATH79 && !MACH_INGENIC && \
2020-03-25 06:55:02 +03:00
!MACH_LOONGSON64 && !MIPS_MALTA && \
2015-10-12 14:13:03 +03:00
!CAVIUM_OCTEON_SOC
2015-10-12 14:13:02 +03:00
default MIPS_CMDLINE_FROM_BOOTLOADER
config MIPS_CMDLINE_FROM_DTB
depends on USE_OF
bool "Dtb kernel arguments if available"
config MIPS_CMDLINE_DTB_EXTEND
depends on USE_OF
bool "Extend dtb kernel arguments with bootloader arguments"
config MIPS_CMDLINE_FROM_BOOTLOADER
bool "Bootloader kernel arguments if available"
2016-04-28 12:03:09 +03:00
config MIPS_CMDLINE_BUILTIN_EXTEND
depends on CMDLINE_BOOL
bool "Extend builtin kernel arguments with bootloader arguments"
2015-10-12 14:13:02 +03:00
endchoice
2005-10-29 22:32:41 +04:00
endmenu
2006-09-26 18:44:01 +04:00
config LOCKDEP_SUPPORT
bool
default y
config STACKTRACE_SUPPORT
bool
default y
2015-04-15 01:45:51 +03:00
config PGTABLE_LEVELS
int
2017-02-17 04:27:34 +03:00
default 4 if PAGE_SIZE_4KB && MIPS_VA_BITS_48
2015-04-15 01:45:51 +03:00
default 3 if 64BIT && !PAGE_SIZE_64KB
default 2
2018-07-28 04:23:20 +03:00
config MIPS_AUTO_PFN_OFFSET
bool
2005-04-17 02:20:36 +04:00
menu "Bus options (PCI, PCMCIA, EISA, ISA, TC)"
2016-10-05 20:18:12 +03:00
config PCI_DRIVERS_GENERIC
2018-11-15 22:05:33 +03:00
select PCI_DOMAINS_GENERIC if PCI
2016-10-05 20:18:12 +03:00
bool
config PCI_DRIVERS_LEGACY
def_bool !PCI_DRIVERS_GENERIC
select NO_GENERIC_PCI_IOPORT_MAP
2018-11-15 22:05:33 +03:00
select PCI_DOMAINS if PCI
2005-04-17 02:20:36 +04:00
#
# ISA support is now enabled via select. Too many systems still have the one
# or other ISA chip on the board that users don't know about so don't expect
# users to choose the right thing ...
#
config ISA
bool
config TC
bool "TURBOchannel support"
depends on MACH_DECSTATION
help
2010-10-16 21:36:23 +04:00
TURBOchannel is a DEC (now Compaq (now HP)) bus for Alpha and MIPS
processors. TURBOchannel programming specifications are available
at:
<ftp://ftp.hp.com/pub/alphaserver/archive/triadd/>
and:
<http://www.computer-refuge.org/classiccmp/ftp.digital.com/pub/DEC/TriAdd/>
Linux driver support status is documented at:
<http://www.linux-mips.org/wiki/DECstation>
2005-04-17 02:20:36 +04:00
config MMU
bool
default y
2016-11-24 20:32:45 +03:00
config ARCH_MMAP_RND_BITS_MIN
default 12 if 64BIT
default 8
config ARCH_MMAP_RND_BITS_MAX
default 18 if 64BIT
default 15
config ARCH_MMAP_RND_COMPAT_BITS_MIN
2019-03-11 18:54:27 +03:00
default 8
2016-11-24 20:32:45 +03:00
config ARCH_MMAP_RND_COMPAT_BITS_MAX
2019-03-11 18:54:27 +03:00
default 15
2016-11-24 20:32:45 +03:00
2007-10-12 02:46:10 +04:00
config I8253
bool
2011-05-08 22:03:03 +04:00
select CLKSRC_I8253
2011-06-09 17:08:27 +04:00
select CLKEVT_I8253
2009-11-16 20:32:58 +03:00
select MIPS_EXTERNAL_TIMER
2007-10-12 02:46:10 +04:00
2013-06-12 12:54:11 +04:00
config ZONE_DMA
bool
2007-11-03 05:05:43 +03:00
config ZONE_DMA32
bool
2005-04-17 02:20:36 +04:00
endmenu
config TRAD_SIGNALS
bool
config MIPS32_COMPAT
MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.
In that case nor __NR_seccomp_*_32 symbols will be defined in
<asm/unistd.h> so the attempt to use it in kernel.seccomp.c will fail
with:
kernel/seccomp.c:565:2: error: '__NR_seccomp_read_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:24: error: '__NR_seccomp_write_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:47: error: '__NR_seccomp_exit_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:69: error: '__NR_seccomp_sigreturn_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
Solved by changing the compat ABIs in kconfig to select MIPS32_COMPAT
directly. This also means the user no longer has to select MIPS32_COMPAT
before being able to see the ABI options.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-12-19 03:18:03 +03:00
bool
2005-04-17 02:20:36 +04:00
config COMPAT
bool
2006-11-07 12:02:44 +03:00
config SYSVIPC_COMPAT
bool
2005-04-17 02:20:36 +04:00
config MIPS32_O32
bool "Kernel support for o32 binaries"
MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.
In that case nor __NR_seccomp_*_32 symbols will be defined in
<asm/unistd.h> so the attempt to use it in kernel.seccomp.c will fail
with:
kernel/seccomp.c:565:2: error: '__NR_seccomp_read_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:24: error: '__NR_seccomp_write_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:47: error: '__NR_seccomp_exit_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:69: error: '__NR_seccomp_sigreturn_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
Solved by changing the compat ABIs in kconfig to select MIPS32_COMPAT
directly. This also means the user no longer has to select MIPS32_COMPAT
before being able to see the ABI options.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-12-19 03:18:03 +03:00
depends on 64BIT
select ARCH_WANT_OLD_COMPAT_IPC
select COMPAT
select MIPS32_COMPAT
select SYSVIPC_COMPAT if SYSVIPC
2005-04-17 02:20:36 +04:00
help
Select this option if you want to run o32 binaries. These are pure
32-bit binaries as used by the 32-bit Linux/MIPS port. Most of
existing binaries are in this format.
If unsure, say Y.
config MIPS32_N32
bool "Kernel support for n32 binaries"
2015-01-03 14:10:23 +03:00
depends on 64BIT
2019-01-10 19:24:31 +03:00
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
MIPS: Compat: Fix build error if CONFIG_MIPS32_COMPAT but no compat ABI.
In that case nor __NR_seccomp_*_32 symbols will be defined in
<asm/unistd.h> so the attempt to use it in kernel.seccomp.c will fail
with:
kernel/seccomp.c:565:2: error: '__NR_seccomp_read_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:24: error: '__NR_seccomp_write_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:47: error: '__NR_seccomp_exit_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
^
kernel/seccomp.c:565:69: error: '__NR_seccomp_sigreturn_32' undeclared here (not in a function)
__NR_seccomp_read_32, __NR_seccomp_write_32, __NR_seccomp_exit_32, __NR_seccomp_sigreturn_32,
Solved by changing the compat ABIs in kconfig to select MIPS32_COMPAT
directly. This also means the user no longer has to select MIPS32_COMPAT
before being able to see the ABI options.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2014-12-19 03:18:03 +03:00
select COMPAT
select MIPS32_COMPAT
select SYSVIPC_COMPAT if SYSVIPC
2005-04-17 02:20:36 +04:00
help
Select this option if you want to run n32 binaries. These are
64-bit binaries using 32-bit quantities for addressing and certain
data that would normally be 64-bit. They are used in special
cases.
If unsure, say N.
config BINFMT_ELF32
bool
default y if MIPS32_O32 || MIPS32_N32
2016-05-24 02:22:26 +03:00
select ELFCORE
2005-04-17 02:20:36 +04:00
2007-02-09 20:08:58 +03:00
menu "Power management options"
2009-06-04 16:27:10 +04:00
config ARCH_HIBERNATION_POSSIBLE
def_bool y
2009-07-02 14:48:07 +04:00
depends on SYS_SUPPORTS_HOTPLUG_CPU || !SMP
2009-06-04 16:27:10 +04:00
2007-12-08 04:14:00 +03:00
config ARCH_SUSPEND_POSSIBLE
def_bool y
2009-07-02 14:48:07 +04:00
depends on SYS_SUPPORTS_HOTPLUG_CPU || !SMP
2007-12-08 04:14:00 +03:00
2007-02-09 20:08:58 +03:00
source "kernel/power/Kconfig"
2006-06-05 19:43:10 +04:00
2005-04-17 02:20:36 +04:00
endmenu
2013-04-04 16:54:21 +04:00
config MIPS_EXTERNAL_TIMER
bool
menu "CPU Power Management"
2014-04-14 19:24:22 +04:00
if CPU_SUPPORTS_CPUFREQ && MIPS_EXTERNAL_TIMER
2013-04-04 16:54:21 +04:00
source "drivers/cpufreq/Kconfig"
endif
2009-11-16 20:32:58 +03:00
2014-04-14 19:24:22 +04:00
source "drivers/cpuidle/Kconfig"
endmenu
2012-11-15 13:35:42 +04:00
source "drivers/firmware/Kconfig"
2012-11-22 06:33:59 +04:00
source "arch/mips/kvm/Kconfig"
2020-04-29 01:14:16 +03:00
source "arch/mips/vdso/Kconfig"