2010-06-01 18:29:04 +08:00
|
|
|
#
|
|
|
|
|
# Loongson Processors' Support
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
|
2019-10-20 22:43:13 +08:00
|
|
|
cflags-$(CONFIG_CPU_LOONGSON64) += -Wa,--trap
|
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 16:04:54 +08:00
|
|
|
|
2016-01-21 21:09:48 +08:00
|
|
|
#
|
|
|
|
|
# binutils from v2.25 on and gcc starting from v4.9.0 treat -march=loongson3a
|
|
|
|
|
# as MIPS64 R2; older versions as just R1. This leaves the possibility open
|
|
|
|
|
# that GCC might generate R2 code for -march=loongson3a which then is rejected
|
|
|
|
|
# by GAS. The cc-option can't probe for this behaviour so -march=loongson3a
|
|
|
|
|
# can't easily be used safely within the kbuild framework.
|
|
|
|
|
#
|
|
|
|
|
ifeq ($(call cc-ifversion, -ge, 0409, y), y)
|
kbuild: LD_VERSION redenomination
Commit ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion
macros") introduced scripts/ld-version.sh for GCC LTO.
At that time, this script handled 5 version fields because GCC LTO
needed the downstream binutils. (https://lkml.org/lkml/2014/4/8/272)
The code snippet from the submitted patch was as follows:
# We need HJ Lu's Linux binutils because mainline binutils does not
# support mixing assembler and LTO code in the same ld -r object.
# XXX check if the gcc plugin ld is the expected one too
# XXX some Fedora binutils should also support it. How to check for that?
ifeq ($(call ld-ifversion,-ge,22710001,y),y)
...
However, GCC LTO was not merged into the mainline after all.
(https://lkml.org/lkml/2014/4/8/272)
So, the 4th and 5th fields were never used, and finally removed by
commit 0d61ed17dd30 ("ld-version: Drop the 4th and 5th version
components").
Since then, the last 4-digits returned by this script is always zeros.
Remove the meaningless last 4-digits. This makes the version format
consistent with GCC_VERSION, CLANG_VERSION, LLD_VERSION.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-12-13 00:54:30 +08:00
|
|
|
ifeq ($(call ld-ifversion, -ge, 22500, y), y)
|
2019-10-20 22:43:13 +08:00
|
|
|
cflags-$(CONFIG_CPU_LOONGSON64) += \
|
2016-01-21 21:09:48 +08:00
|
|
|
$(call cc-option,-march=loongson3a -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64)
|
|
|
|
|
else
|
2019-10-20 22:43:13 +08:00
|
|
|
cflags-$(CONFIG_CPU_LOONGSON64) += \
|
2016-01-21 21:09:48 +08:00
|
|
|
$(call cc-option,-march=mips64r2,-mips64r2 -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64)
|
|
|
|
|
endif
|
|
|
|
|
else
|
2019-10-20 22:43:13 +08:00
|
|
|
cflags-$(CONFIG_CPU_LOONGSON64) += \
|
2016-01-21 21:09:48 +08:00
|
|
|
$(call cc-option,-march=mips64r2,-mips64r2 -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64)
|
|
|
|
|
endif
|
|
|
|
|
|
2019-10-11 02:54:03 +08:00
|
|
|
# Some -march= flags enable MMI instructions, and GCC complains about that
|
|
|
|
|
# support being enabled alongside -msoft-float. Thus explicitly disable MMI.
|
|
|
|
|
cflags-y += $(call cc-option,-mno-loongson-mmi)
|
|
|
|
|
|
2010-06-01 18:29:04 +08:00
|
|
|
#
|
|
|
|
|
# Loongson Machines' Support
|
|
|
|
|
#
|
|
|
|
|
|
2015-04-21 10:00:35 +08:00
|
|
|
cflags-$(CONFIG_MACH_LOONGSON64) += -I$(srctree)/arch/mips/include/asm/mach-loongson64 -mno-branch-likely
|
2019-10-20 23:01:35 +08:00
|
|
|
load-$(CONFIG_CPU_LOONGSON64) += 0xffffffff80200000
|
