linux-stable.git/arch/mips/kernel/cpu-probe.c, branch v5.10.78

MIPS: cpu-probe: Fix FPU detection on Ingenic JZ4760(B)

2021-07-19T07:44:44+00:00

[ Upstream commit fc52f92a653215fbd6bc522ac5311857b335e589 ]

Ingenic JZ4760 and JZ4760B do have a FPU, but the config registers don't
report it. Force the FPU detection in case the processor ID match the
JZ4760(B) one.

Signed-off-by: Paul Cercueil 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: Loongson64: Use _CACHE_UNCACHED instead of _CACHE_UNCACHED_ACCELERATED

2021-05-19T08:12:55+00:00

[ Upstream commit 5e65c52ec716af6e8f51dacdaeb4a4d872249af1 ]

Loongson64 processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times, after
commit 8a08e50cee66 ("drm: Permit video-buffers writecombine mapping
for MIPS"), there exists some errors such as blurred screen and lockup,
and so on.

[   60.958721] radeon 0000:03:00.0: ring 0 stalled for more than 10079msec
[   60.965315] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000112 last fence id 0x000000000000011d on ring 0)
[   60.976525] radeon 0000:03:00.0: ring 3 stalled for more than 10086msec
[   60.983156] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000374 last fence id 0x00000000000003a8 on ring 3)

As discussed earlier [1], it might be better to disable writecombine
on the CPU detection side because the root cause is unknown now.

Actually, this patch is a temporary solution to just make it work well,
it is not a proper and final solution, I hope someone will have a better
solution to fix this issue in the future.

[1] https://lore.kernel.org/patchwork/patch/1285542/

Signed-off-by: Tiezhu Yang 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: Ingenic: Disable HPTLB for D0 XBurst CPUs too

2021-03-04T10:38:25+00:00

commit a5360958a3cd1d876aae1f504ae014658513e1af upstream.

The JZ4760 has the HPTLB as well, but has a XBurst CPU with a D0 CPUID.

Disable the HPTLB for all XBurst CPUs with a D0 CPUID. In the case where
there is no HPTLB (e.g. for older SoCs), this won't have any side
effect.

Fixes: b02efeb05699 ("MIPS: Ingenic: Disable abandoned HPTLB function.")
Cc:  # 5.4
Signed-off-by: Paul Cercueil 
Reviewed-by: 周琰杰 (Zhou Yanjie) 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Greg Kroah-Hartman

MIPS: cpu-probe: remove MIPS_CPU_BP_GHIST option bit

2020-10-12T10:05:40+00:00

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

MIPS: cpu-probe: move fpu probing/handling into its own file

2020-10-12T10:04:50+00:00

cpu-probe.c has grown when supporting more and more CPUs and there
are use cases where probing for all the CPUs isn't useful like
running on a R3k system. But still the fpu handling is nearly
the same. For sharing put the fpu code into it's own file.

Signed-off-by: Thomas Bogendoerfer

MIPS: cpu-probe: ingenic: Fix broken BUG_ON

2020-09-18T14:27:32+00:00

The previous code was doing:
BUG_ON(!__builtin_constant_p(cpu_has_counter) || cpu_has_counter);

This only worked as the "cpu_has_counter" macro was overridden in
. The default "cpu_has_counter" macro is
non-constant, which triggered the BUG_ON() independently of the value
returned by the macro.

What we want to check here, is that *if* the macro was overridden to a
compile-time constant, then must be defined to zero, otherwise it's a
bug.

So the correct check is:
BUG_ON(__builtin_constant_p(cpu_has_counter) && cpu_has_counter);

Signed-off-by: Paul Cercueil 
Signed-off-by: Thomas Bogendoerfer

MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches

2020-09-18T14:27:00+00:00

XBurst CPUs present in Ingenic SoCs have virtually tagged caches,
according to the  header.

Add that information to cpu_probe_ingenic().

Signed-off-by: Paul Cercueil 
Signed-off-by: Thomas Bogendoerfer

MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA

2020-09-18T14:26:36+00:00

Previously, in cpu_probe_ingenic(), c->writecombine was set to
_CACHE_UNCACHED_ACCELERATED, but this macro was defined differently when
CONFIG_MACH_INGENIC was set. This made it impossible to support multiple
CPUs.

Address this issue by setting c->writecombine to _CACHE_CACHABLE_WA
directly and removing the dependency on CONFIG_MACH_INGENIC.

Signed-off-by: Paul Cercueil 
Signed-off-by: Thomas Bogendoerfer

MIPS: handle Loongson-specific GSExc exception

2020-07-31T15:52:47+00:00

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 
Signed-off-by: WANG Xuerui 
Cc: Huacai Chen 
Cc: Jiaxun Yang 
Cc: Tiezhu Yang 
Signed-off-by: Thomas Bogendoerfer

MIPS: only register FTLBPar exception handler for supported models

2020-07-31T15:52:10+00:00

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 
Signed-off-by: WANG Xuerui 
Cc: Paul Burton 
Signed-off-by: Thomas Bogendoerfer