Hi Maciej,
Le ven. 21 août 2020 à 20:23, Maciej W. Rozycki
<macro@xxxxxxxxxxxxxx> a écrit :
On Fri, 7 Aug 2020, Paul Cercueil wrote:
> I'm not too sure if remove "cpu-feature-overrides.h" will cause
some
> problems for X2000, because according to my current test on
X2000, I found
> that it is somewhat different from the SoCs using XBurst1 CPU
core, with the
> kernel source code provided by Ingenic, for example, we must
configure
> "#define cpu_has_tlbinv 1" in "cpu-feature-overrides.h" to make
the X2000
> work normally, otherwise the kernel will get stuck. And X2000's
interrupt
> controller has also been redesigned. If these differences make it
impossible
> to share code, should we set a subdirectory of "xburst" and
"xburst2" in
> "arch/mips/ingenic"? (I am just worried about this situation, so
far I have
> not been able to successfully run the mainline kernel on X2000).
The <cpu-feature-overrides.h> is kind of a hack, to hardcode
settings in case
the CPU is not properly detected. The cpu-probe.c should be able to
auto-detect these settings, including the inverted TLB that the
X2000 has,
reading from the CPU config registers ("TLB INV" info should be in
config4).
Right now cpu_probe_ingenic() doesn't read config4 (not present on
older SoCs)
but that's trivial to add.
FAOD <cpu-feature-overrides.h> is not a hack, but an optimisation
measure
so that features known to be hardwired for a given machine/CPU do not
have
to be dynamically queried every time referred. In some cases that
results
in large portions of code being optimised away by the compiler as
well.
Fair enough. Bloat-o-meter reports about ~100 KiB saved when that file
is present. But we can't use it in a generic kernel, unfortunately.
The hardcoded value for a feature defined in
<cpu-feature-overrides.h>
always has to be the same as one in the corresponding bit of the
`options'
member of `struct cpuinfo_mips', in this case MIPS_CPU_TLBINV.
In theory yes, in practice the CPU detection code is lagging behind...
Cheers,
-Paul
