Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33 |
|
#
5487a7b6 |
| 07-Jun-2023 |
Jiaxun Yang <jiaxun.yang@flygoat.com> |
MIPS: cpu-features: Use boot_cpu_type for CPU type based features
Some CPU feature macros were using current_cpu_type to mark feature availability.
However current_cpu_type will use smp_processor_i
MIPS: cpu-features: Use boot_cpu_type for CPU type based features
Some CPU feature macros were using current_cpu_type to mark feature availability.
However current_cpu_type will use smp_processor_id, which is prohibited under preemptable context.
Since those features are all uniform on all CPUs in a SMP system, use boot_cpu_type instead of current_cpu_type to fix preemptable kernel.
Cc: stable@vger.kernel.org Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
Revision tags: v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23 |
|
#
f6415194 |
| 04-Apr-2023 |
Jiaxun Yang <jiaxun.yang@flygoat.com> |
MIPS: cpu-features: Enable octeon_cache by cpu_type
cpu_has_octeon_cache was tied to 0 for generic cpu-features, whith this generic kernel built for octeon CPU won't boot.
Just enable this flag by
MIPS: cpu-features: Enable octeon_cache by cpu_type
cpu_has_octeon_cache was tied to 0 for generic cpu-features, whith this generic kernel built for octeon CPU won't boot.
Just enable this flag by cpu_type. It won't hurt orther platforms because compiler will eliminate the code path on other processors.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
#
918d7795 |
| 04-Apr-2023 |
Jiaxun Yang <jiaxun.yang@flygoat.com> |
MIPS: Octeon: Opt-out 4k_cache feature
Octeon has a different cache interface with traditional R4K one, just opt-out this flag for octeon to avoid run R4K cache initialization code accidentally.
Al
MIPS: Octeon: Opt-out 4k_cache feature
Octeon has a different cache interface with traditional R4K one, just opt-out this flag for octeon to avoid run R4K cache initialization code accidentally.
Also remove ISA level assumption for 4k cache.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
Revision tags: v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38 |
|
#
912a4427 |
| 01-May-2022 |
Shida Zhang <zhangshida@kylinos.cn> |
MIPS: adding a safety check for cpu_has_fpu
There is a chance 'cpu_has_fpu' would still be overridden when the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. So add a safety check fo
MIPS: adding a safety check for cpu_has_fpu
There is a chance 'cpu_has_fpu' would still be overridden when the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. So add a safety check for 'cpu_has_fpu'.
Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Shida Zhang <zhangshida@kylinos.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
Revision tags: v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25 |
|
#
455481fc |
| 22-Feb-2022 |
Thomas Bogendoerfer <tsbogend@alpha.franken.de> |
MIPS: Remove TX39XX support
No (active) developer owns this hardware, so let's remove Linux support.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: Guenter Roeck <linux@ro
MIPS: Remove TX39XX support
No (active) developer owns this hardware, so let's remove Linux support.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
show more ...
|
Revision tags: v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13 |
|
#
cad065ed |
| 25-Jun-2021 |
Paul Cercueil <paul@crapouillou.net> |
MIPS: MT extensions are not available on MIPS32r1
MIPS MT extensions were added with the MIPS 34K processor, which was based on the MIPS32r2 ISA.
This fixes a build error when building a generic ke
MIPS: MT extensions are not available on MIPS32r1
MIPS MT extensions were added with the MIPS 34K processor, which was based on the MIPS32r2 ISA.
This fixes a build error when building a generic kernel for a MIPS32r1 CPU.
Fixes: c434b9f80b09 ("MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol") Cc: stable@vger.kernel.org # v5.9 Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
Revision tags: v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
6ce91ba8 |
| 19-Nov-2020 |
Tiezhu Yang <yangtiezhu@loongson.cn> |
MIPS: Remove cpu_has_6k_cache and cpu_has_8k_cache in cpu_cache_init()
Since commit 02cf2119684e ("Cleanup the mess in cpu_cache_init."), cpu_has_6k_cache and cpu_has_8k_cache have no user, r6k_cach
MIPS: Remove cpu_has_6k_cache and cpu_has_8k_cache in cpu_cache_init()
Since commit 02cf2119684e ("Cleanup the mess in cpu_cache_init."), cpu_has_6k_cache and cpu_has_8k_cache have no user, r6k_cache_init() and r8k_cache_init() are not defined for over 15 years, just remove them.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
#
9706c534 |
| 25-Jun-2021 |
Paul Cercueil <paul@crapouillou.net> |
MIPS: MT extensions are not available on MIPS32r1
commit cad065ed8d8831df67b9754cc4437ed55d8b48c0 upstream.
MIPS MT extensions were added with the MIPS 34K processor, which was based on the MIPS32r
MIPS: MT extensions are not available on MIPS32r1
commit cad065ed8d8831df67b9754cc4437ed55d8b48c0 upstream.
MIPS MT extensions were added with the MIPS 34K processor, which was based on the MIPS32r2 ISA.
This fixes a build error when building a generic kernel for a MIPS32r1 CPU.
Fixes: c434b9f80b09 ("MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol") Cc: stable@vger.kernel.org # v5.9 Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9 |
|
#
20cc5b64 |
| 09-Oct-2020 |
Thomas Bogendoerfer <tsbogend@alpha.franken.de> |
MIPS: cpu-probe: remove MIPS_CPU_BP_GHIST option bit
MIPS_CPU_BP_GHIST is only set two times and more or less immediately used in cpu-probe.c itself. Remove this option to make room in options word.
MIPS: cpu-probe: remove MIPS_CPU_BP_GHIST option bit
MIPS_CPU_BP_GHIST is only set two times and more or less immediately used in cpu-probe.c itself. Remove this option to make room in options word.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
Revision tags: v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55 |
|
#
bc6e8dc1 |
| 29-Jul-2020 |
WANG Xuerui <git@xen0n.name> |
MIPS: handle Loongson-specific GSExc exception
Newer Loongson cores (Loongson-3A R2 and newer) use the implementation-dependent ExcCode 16 to signal Loongson-specific exceptions. The extended cause
MIPS: handle Loongson-specific GSExc exception
Newer Loongson cores (Loongson-3A R2 and newer) use the implementation-dependent ExcCode 16 to signal Loongson-specific exceptions. The extended cause is put in the non-standard CP0.Diag1 register which is CP0 Register 22 Select 1, called GSCause in Loongson manuals. Inside is an exception code bitfield called GSExcCode, only codes 0 to 6 inclusive are documented (so far, in the Loongson 3A3000 User Manual, Volume 2).
During experiments, it was found that some undocumented unprivileged instructions can trigger the also-undocumented GSExcCode 8 on Loongson 3A4000. Processor state is not corrupted, but we cannot continue without further knowledge, and Loongson is not providing that information as of this writing. So we send SIGILL on seeing this exception code to thwart easy local DoS attacks.
Other exception codes are made fatal, partly because of insufficient knowledge, also partly because they are not as easily reproduced. None of them are encountered in the wild with upstream kernels and userspace so far.
Some older cores (Loongson-3A1000 and Loongson-3B1500) have ExcCode 16 too, but the semantic is equivalent to GSExcCode 0. Because the respective manuals did not mention the CP0.Diag1 register or its read behavior, these cores are not covered in this patch, as MFC0 from non-existent CP0 registers is UNDEFINED according to the MIPS architecture spec.
Reviewed-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: WANG Xuerui <git@xen0n.name> 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>
show more ...
|
#
efd1b4ad |
| 29-Jul-2020 |
WANG Xuerui <git@xen0n.name> |
MIPS: only register FTLBPar exception handler for supported models
Previously ExcCode 16 is unconditionally treated as the FTLB parity exception (FTLBPar), but in fact its semantic is implementation
MIPS: only register FTLBPar exception handler for supported models
Previously ExcCode 16 is unconditionally treated as the FTLB parity exception (FTLBPar), but in fact its semantic is implementation- dependent. Looking at various manuals it seems the FTLBPar exception is only present on some recent MIPS Technologies cores, so only register the handler on these.
Fixes: 75b5b5e0a262790f ("MIPS: Add support for FTLBs") Reviewed-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: WANG Xuerui <git@xen0n.name> Cc: Paul Burton <paulburton@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
Revision tags: v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
3210e2c2 |
| 23-May-2020 |
Huacai Chen <chenhc@lemote.com> |
KVM: MIPS: Introduce and use cpu_guest_has_ldpte
Loongson-3 has lddir/ldpte instructions and their related CP0 registers are the same as HTW. So we introduce a cpu_guest_has_ldpte flag and use it to
KVM: MIPS: Introduce and use cpu_guest_has_ldpte
Loongson-3 has lddir/ldpte instructions and their related CP0 registers are the same as HTW. So we introduce a cpu_guest_has_ldpte flag and use it to indicate whether we need to save/restore HTW related CP0 registers (PWBase, PWSize, PWField and PWCtl).
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> Signed-off-by: Huacai Chen <chenhc@lemote.com> Co-developed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Message-Id: <1590220602-3547-7-git-send-email-chenhc@lemote.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
show more ...
|
#
742318ad |
| 21-May-2020 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
mips: Add CP0 Write Merge config support
CP0 config register may indicate whether write-through merging is allowed. Currently there are two types of the merging available: SysAD Valid and Full modes
mips: Add CP0 Write Merge config support
CP0 config register may indicate whether write-through merging is allowed. Currently there are two types of the merging available: SysAD Valid and Full modes. Whether each of them are supported by the core is implementation dependent. Moreover whether the ability to change the mode also depends on the chip family instance. Taking into account all of this we created a dedicated mm_config() method to detect and enable merging if it's supported. It is called for MIPS-type processors at CPU-probe stage and attempts to detect whether the write merging is available. If it's known to be supported and switchable, then switch on the full mode. Otherwise just perform the CP0.Config.MM field analysis.
In addition there are platforms like InterAptiv/ProAptiv, which do have the MM bit field set by default, but having write-through cacheing unsupported makes write-merging also unsupported. In this case we just ignore the MM field value.
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>
show more ...
|
#
a2ac81c6 |
| 21-May-2020 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
mips: Fix cpu_has_mips64r1/2 activation for MIPS32 CPUs
Commit 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows") updated the cpu_has_mips* macro to be replaced with a constant ex
mips: Fix cpu_has_mips64r1/2 activation for MIPS32 CPUs
Commit 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows") updated the cpu_has_mips* macro to be replaced with a constant expression where it's possible. By mistake it wasn't done correctly for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to be replaced with conditional expression __isa_range_or_flag(), which means either ISA revision being within the range or the corresponding CPU options flag was set at the probe stage or both being true at the same time. But the ISA level value doesn't indicate whether the ISA is MIPS32 or MIPS64. Due to this if we select MIPS32r1 - MIPS32r5 architectures the __isa_range() macro will activate the cpu_has_mips64rX flags, which is incorrect. In order to fix the problem we make sure the 64bits CPU support is enabled by means of checking the flag cpu_has_64bits aside with proper ISA range and specific Revision flag being set.
Fixes: 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@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>
show more ...
|
#
ab7c01fd |
| 21-May-2020 |
Serge Semin <Sergey.Semin@baikalelectronics.ru> |
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 ma
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>
show more ...
|
Revision tags: v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33 |
|
#
b604d497 |
| 16-Apr-2020 |
Christoph Hellwig <hch@lst.de> |
MIPS: remove cpu_has_64bit_addresses
This macro is identical to CONFIG_64BIT, and using a Kconfig variable for the only places that checks them (the ioremap implementation) will simplify later patch
MIPS: remove cpu_has_64bit_addresses
This macro is identical to CONFIG_64BIT, and using a Kconfig variable for the only places that checks them (the ioremap implementation) will simplify later patches in this series.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
show more ...
|
Revision tags: v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12 |
|
#
ece276de |
| 13-Jan-2020 |
Jiaxun Yang <jiaxun.yang@flygoat.com> |
MIPS: Add MAC2008 Support
MAC2008 means the processor implemented IEEE754 style Fused MADD instruction. It was introduced in Release3 but removed in Release5.
The toolchain support of MAC2008 have
MIPS: Add MAC2008 Support
MAC2008 means the processor implemented IEEE754 style Fused MADD instruction. It was introduced in Release3 but removed in Release5.
The toolchain support of MAC2008 have never landed except for Loongson processors.
This patch aimed to disabled the MAC2008 if it's optional. For MAC2008 only processors, we corrected math-emu behavior to align with actual hardware behavior.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> [paulburton@kernel.org: Fixup MIPSr2-r5 check in cpu_set_fpu_2008.] Signed-off-by: Paul Burton <paulburton@kernel.org> Cc: linux-mips@vger.kernel.org Cc: chenhc@lemote.com Cc: paul.burton@mips.com Cc: linux-kernel@vger.kernel.org
show more ...
|
Revision tags: v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12 |
|
#
775b089a |
| 31-Aug-2019 |
Paul Burton <paul.burton@mips.com> |
MIPS: tlbex: Remove cpu_has_local_ebase
The cpu_has_local_ebase macro is, confusingly, not used to indicate whether the EBase register is local to a CPU or not. Instead it indicates whether we want
MIPS: tlbex: Remove cpu_has_local_ebase
The cpu_has_local_ebase macro is, confusingly, not used to indicate whether the EBase register is local to a CPU or not. Instead it indicates whether we want to generate the TLB refill exception vector each time a CPU is brought online. Doing this makes little sense on any system, since we always use the same value for EBase & thus we cannot have different TLB refill exception handlers per CPU.
Regenerating the code is not only pointless but also can be actively harmful, as commit 8759934e2b6b ("MIPS: Build uasm-generated code only once to avoid CPU Hotplug problem") described. That commit introduced cpu_has_local_ebase to disable the handler regeneration for Loongson machines, but this is by no means a Loongson-specific problem.
Remove cpu_has_local_ebase & simply generate the TLB refill handler once during boot, just like the rest of the TLB exception handlers.
Signed-off-by: Paul Burton <paul.burton@mips.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: linux-mips@vger.kernel.org
show more ...
|
Revision tags: v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
d2f96554 |
| 29-May-2019 |
Jiaxun Yang <jiaxun.yang@flygoat.com> |
MIPS: Treat Loongson Extensions as ASEs
Recently, binutils had split Loongson-3 Extensions into four ASEs: MMI, CAM, EXT, EXT2. This patch do the samething in kernel and expose them in cpuinfo so ap
MIPS: Treat Loongson Extensions as ASEs
Recently, binutils had split Loongson-3 Extensions into four ASEs: MMI, CAM, EXT, EXT2. This patch do the samething in kernel and expose them in cpuinfo so applications can probe supported ASEs at runtime.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: Yunqiang Su <ysu@wavecomp.com> Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20 |
|
#
c8790d65 |
| 01-Feb-2019 |
Paul Burton <paul.burton@mips.com> |
MIPS: MemoryMapID (MMID) Support
Introduce support for using MemoryMapIDs (MMIDs) as an alternative to Address Space IDs (ASIDs). The major difference between the two is that MMIDs are global - ie.
MIPS: MemoryMapID (MMID) Support
Introduce support for using MemoryMapIDs (MMIDs) as an alternative to Address Space IDs (ASIDs). The major difference between the two is that MMIDs are global - ie. an MMID uniquely identifies an address space across all coherent CPUs. In contrast ASIDs are non-global per-CPU IDs, wherein each address space is allocated a separate ASID for each CPU upon which it is used. This global namespace allows a new GINVT instruction be used to globally invalidate TLB entries associated with a particular MMID across all coherent CPUs in the system, removing the need for IPIs to invalidate entries with separate ASIDs on each CPU.
The allocation scheme used here is largely borrowed from arm64 (see arch/arm64/mm/context.c). In essence we maintain a bitmap to track available MMIDs, and MMIDs in active use at the time of a rollover to a new MMID version are preserved in the new version. The allocation scheme requires efficient 64 bit atomics in order to perform reasonably, so this support depends upon CONFIG_GENERIC_ATOMIC64=n (ie. currently it will only be included in MIPS64 kernels).
The first, and currently only, available CPU with support for MMIDs is the MIPS I6500. This CPU supports 16 bit MMIDs, and so for now we cap our MMIDs to 16 bits wide in order to prevent the bitmap growing to absurd sizes if any future CPU does implement 32 bit MMIDs as the architecture manuals suggest is recommended.
When MMIDs are in use we also make use of GINVT instruction which is available due to the global nature of MMIDs. By executing a sequence of GINVT & SYNC 0x14 instructions we can avoid the overhead of an IPI to each remote CPU in many cases. One complication is that GINVT will invalidate wired entries (in all cases apart from type 0, which targets the entire TLB). In order to avoid GINVT invalidating any wired TLB entries we set up, we make sure to create those entries using a reserved MMID (0) that we never associate with any address space.
Also of note is that KVM will require further work in order to support MMIDs & GINVT, since KVM is involved in allocating IDs for guests & in configuring the MMU. That work is not part of this patch, so for now when MMIDs are in use KVM is disabled.
Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org
show more ...
|
Revision tags: v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5 |
|
#
1aeba347 |
| 26-Nov-2018 |
Paul Burton <paul.burton@mips.com> |
MIPS: Hardcode cpu_has_mips* where target ISA allows
In the same vein as commit 93e01942a6eb ("MIPS: Hardcode cpu_has_* where known at compile time due to ISA"), we can use our knowledge of the ISA
MIPS: Hardcode cpu_has_mips* where target ISA allows
In the same vein as commit 93e01942a6eb ("MIPS: Hardcode cpu_has_* where known at compile time due to ISA"), we can use our knowledge of the ISA being targeted by the kernel build to make cpu_has_mips* macros compile-time constant in some cases. This allows the compiler greater opportunity to optimize out code which will never execute.
Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21245/ Cc: linux-mips@linux-mips.org
show more ...
|
Revision tags: v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18 |
|
#
57eeaced |
| 08-Nov-2018 |
Paul Burton <paul.burton@mips.com> |
MIPS: Use Kconfig to select CPU_NO_EFFICIENT_FFS
Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is configured for a pre-MIPS32r1 CPU, rather than defining its equivalent in asm/cpu-f
MIPS: Use Kconfig to select CPU_NO_EFFICIENT_FFS
Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is configured for a pre-MIPS32r1 CPU, rather than defining its equivalent in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.
The latter only works if a platform has an cpu-feature-overrides.h header which defines cpu_has_mips* macros, which are not generally needed. There are many cases where we know that the target ISA for a kernel build is MIPS32r1 or later & thus includes the CLZ instruction, without requiring any overrides from the platform. Using Kconfig allows us to take those into account, and more naturally make a decision about instruction support using information about the target ISA.
Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21045/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org
show more ...
|
#
b372e83b |
| 07-Nov-2018 |
Paul Burton <paul.burton@mips.com> |
MIPS: Hardcode cpu_has_fpu=0 when CONFIG_MIPS_FP_SUPPORT=n
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so there's no point in detecting presence of an FPU. Hardcode cpu_has_fpu=0
MIPS: Hardcode cpu_has_fpu=0 when CONFIG_MIPS_FP_SUPPORT=n
When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so there's no point in detecting presence of an FPU. Hardcode cpu_has_fpu=0 such that we optimize out code that makes use of the FPU.
Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21005/ Cc: linux-mips@linux-mips.org
show more ...
|
#
a013ba39 |
| 07-Nov-2018 |
Paul Burton <paul.burton@mips.com> |
MIPS: Hardcode cpu_has_mmips=1 for microMIPS kernels
If we built the kernel targeting the microMIPS ISA then the very fact that the kernel is running implies that the CPU supports microMIPS. Thus we
MIPS: Hardcode cpu_has_mmips=1 for microMIPS kernels
If we built the kernel targeting the microMIPS ISA then the very fact that the kernel is running implies that the CPU supports microMIPS. Thus we can hardcode cpu_has_mmips to 1 allowing the compiler greater scope for optimisation due to the compile-time constant.
Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/21022/ Cc: linux-mips@linux-mips.org
show more ...
|
Revision tags: v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12 |
|
#
93e01942 |
| 12-Jun-2017 |
Paul Burton <paul.burton@mips.com> |
MIPS: Hardcode cpu_has_* where known at compile time due to ISA
Many architectural features have over time moved from being optional to either be required or removed by newer architecture releases.
MIPS: Hardcode cpu_has_* where known at compile time due to ISA
Many architectural features have over time moved from being optional to either be required or removed by newer architecture releases. This means that in many cases we can know at compile time whether a feature will be supported or not purely due to the knowledge we have about the ISA the kernel build is targeting.
This patch introduces a bunch of utility macros for checking for supported options, ASEs & combinations of those with ISA revisions. It then makes use of these in the default definitions of cpu_has_* macros. The result is that many of the macros become compile-time constant, allowing more optimisation opportunities for the compiler - particularly with kernels built for later ISA revisions.
To demonstrate the effect of this patch, the following table shows the size in bytes of the kernel binary as reported by scripts/bloat-o-meter for v4.12-rc4 maltasmvp_defconfig kernels with & without this patch. A variant of maltasmvp_defconfig with CONFIG_CPU_MIPS32_R6 selected is also shown, to demonstrate that MIPSr6 systems benefit more due to extra features becoming required by that architecture revision. Builds of pistachio_defconfig are also shown, as although this is a MIPSr2 platform it doesn't hardcode any features in a machine-specific cpu-feature-overrides.h, which allows it to gain more from this patch than the equivalent Malta r2 build.
Config | Before | After | Change ----------------|---------|---------|--------- maltasmvp | 7248316 | 7247714 | -602 maltasmvp + r6 | 6955595 | 6950777 | -4818 pistachio | 8650977 | 8363898 | -287079
Signed-off-by: Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/16360/ Cc: Joshua Kinard <kumba@gentoo.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org
show more ...
|