Message ID | 20200803170124.231110-1-paul@crapouillou.net (mailing list archive) |
---|---|
Headers | show |
Series | MIPS: Convert Ingenic to a generic board | expand |
Hi Paul, 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). I have added some related engineers from Ingenic to CC Thanks and best regards! 在 2020/8/4 上午1:01, Paul Cercueil 写道: > Hi Thomas & list, > > Here is a set of patches for 5.10 (no rush) to move Ingenic support from > arch/mips/jz4740/ to arch/mips/generic/. > > There are some Kconfig changes that I think should be reviewed in detail > to avoid breakages elsewhere. The idea behind these changes is to allow > the Ingenic "generic" code to be built in a non-generic kernel, since > generic kernels bring lots of dependencies which result in a +7% size > increase. > > Support for booting the generic kernel with a built-in and/or appended > devicetree, as well as support for compressed (vmlinuz) kernels, has > been added as well. > > Cheers, > -Paul > > Paul Cercueil (13): > MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA > MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches > MIPS: cpu-probe: ingenic: Fix broken BUG_ON > MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol > MIPS: machine: Add get_system_type callback > MIPS: generic: Call the machine's .get_system_type callback if > provided > MIPS: generic: Support booting with built-in or appended DTB > MIPS: generic: Add support for zboot > MIPS: generic: Increase NR_IRQS to 256 > MIPS: generic: Add support for Ingenic SoCs > MIPS: jz4740: Drop folder > MIPS: configs: Regenerate configs of Ingenic boards > MAINTAINERS: Update paths to Ingenic platform code > > MAINTAINERS | 4 +- > arch/mips/Kbuild.platforms | 1 - > arch/mips/Kconfig | 43 ++++-- > arch/mips/configs/ci20_defconfig | 4 +- > arch/mips/configs/cu1000-neo_defconfig | 16 +- > arch/mips/configs/gcw0_defconfig | 2 +- > arch/mips/configs/qi_lb60_defconfig | 5 +- > arch/mips/configs/rs90_defconfig | 4 +- > arch/mips/generic/Kconfig | 8 +- > arch/mips/generic/Makefile | 2 +- > arch/mips/generic/Platform | 1 + > arch/mips/generic/board-ingenic.c | 108 +++++++++++++ > arch/mips/generic/init.c | 28 +++- > arch/mips/generic/proc.c | 25 --- > arch/mips/include/asm/mach-generic/irq.h | 2 +- > .../asm/mach-jz4740/cpu-feature-overrides.h | 50 ------ > arch/mips/include/asm/mach-jz4740/irq.h | 13 -- > arch/mips/include/asm/machine.h | 1 + > arch/mips/include/asm/pgtable-bits.h | 5 - > arch/mips/{jz4740 => ingenic}/Kconfig | 16 +- > arch/mips/jz4740/Makefile | 9 -- > arch/mips/jz4740/Platform | 3 - > arch/mips/jz4740/setup.c | 145 ------------------ > arch/mips/kernel/cpu-probe.c | 8 +- > 24 files changed, 198 insertions(+), 305 deletions(-) > create mode 100644 arch/mips/generic/board-ingenic.c > delete mode 100644 arch/mips/generic/proc.c > delete mode 100644 arch/mips/include/asm/mach-jz4740/cpu-feature-overrides.h > delete mode 100644 arch/mips/include/asm/mach-jz4740/irq.h > rename arch/mips/{jz4740 => ingenic}/Kconfig (91%) > delete mode 100644 arch/mips/jz4740/Makefile > delete mode 100644 arch/mips/jz4740/Platform > delete mode 100644 arch/mips/jz4740/setup.c >
Hi Zhou, Le sam. 8 août 2020 à 0:23, Zhou Yanjie <zhouyanjie@wanyeetech.com> a écrit : > Hi Paul, > > 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. As for your other question, I don't see any reason why we wouldn't be able to support the X2000 aside the others in a generic kernel, so don't worry :) Cheers, -Paul > > I have added some related engineers from Ingenic to CC > > Thanks and best regards! > > 在 2020/8/4 上午1:01, Paul Cercueil 写道: >> Hi Thomas & list, >> >> Here is a set of patches for 5.10 (no rush) to move Ingenic support >> from >> arch/mips/jz4740/ to arch/mips/generic/. >> >> There are some Kconfig changes that I think should be reviewed in >> detail >> to avoid breakages elsewhere. The idea behind these changes is to >> allow >> the Ingenic "generic" code to be built in a non-generic kernel, since >> generic kernels bring lots of dependencies which result in a +7% size >> increase. >> >> Support for booting the generic kernel with a built-in and/or >> appended >> devicetree, as well as support for compressed (vmlinuz) kernels, has >> been added as well. >> >> Cheers, >> -Paul >> >> Paul Cercueil (13): >> MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA >> MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches >> MIPS: cpu-probe: ingenic: Fix broken BUG_ON >> MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol >> MIPS: machine: Add get_system_type callback >> MIPS: generic: Call the machine's .get_system_type callback if >> provided >> MIPS: generic: Support booting with built-in or appended DTB >> MIPS: generic: Add support for zboot >> MIPS: generic: Increase NR_IRQS to 256 >> MIPS: generic: Add support for Ingenic SoCs >> MIPS: jz4740: Drop folder >> MIPS: configs: Regenerate configs of Ingenic boards >> MAINTAINERS: Update paths to Ingenic platform code >> >> MAINTAINERS | 4 +- >> arch/mips/Kbuild.platforms | 1 - >> arch/mips/Kconfig | 43 ++++-- >> arch/mips/configs/ci20_defconfig | 4 +- >> arch/mips/configs/cu1000-neo_defconfig | 16 +- >> arch/mips/configs/gcw0_defconfig | 2 +- >> arch/mips/configs/qi_lb60_defconfig | 5 +- >> arch/mips/configs/rs90_defconfig | 4 +- >> arch/mips/generic/Kconfig | 8 +- >> arch/mips/generic/Makefile | 2 +- >> arch/mips/generic/Platform | 1 + >> arch/mips/generic/board-ingenic.c | 108 +++++++++++++ >> arch/mips/generic/init.c | 28 +++- >> arch/mips/generic/proc.c | 25 --- >> arch/mips/include/asm/mach-generic/irq.h | 2 +- >> .../asm/mach-jz4740/cpu-feature-overrides.h | 50 ------ >> arch/mips/include/asm/mach-jz4740/irq.h | 13 -- >> arch/mips/include/asm/machine.h | 1 + >> arch/mips/include/asm/pgtable-bits.h | 5 - >> arch/mips/{jz4740 => ingenic}/Kconfig | 16 +- >> arch/mips/jz4740/Makefile | 9 -- >> arch/mips/jz4740/Platform | 3 - >> arch/mips/jz4740/setup.c | 145 >> ------------------ >> arch/mips/kernel/cpu-probe.c | 8 +- >> 24 files changed, 198 insertions(+), 305 deletions(-) >> create mode 100644 arch/mips/generic/board-ingenic.c >> delete mode 100644 arch/mips/generic/proc.c >> delete mode 100644 >> arch/mips/include/asm/mach-jz4740/cpu-feature-overrides.h >> delete mode 100644 arch/mips/include/asm/mach-jz4740/irq.h >> rename arch/mips/{jz4740 => ingenic}/Kconfig (91%) >> delete mode 100644 arch/mips/jz4740/Makefile >> delete mode 100644 arch/mips/jz4740/Platform >> delete mode 100644 arch/mips/jz4740/setup.c >>
Hi Paul, 在 2020/8/8 上午12:45, Paul Cercueil 写道: > Hi Zhou, > > Le sam. 8 août 2020 à 0:23, Zhou Yanjie <zhouyanjie@wanyeetech.com> a > écrit : >> Hi Paul, >> >> 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. > > As for your other question, I don't see any reason why we wouldn't be > able to support the X2000 aside the others in a generic kernel, so > don't worry :) > OK, this is good news for me. > Cheers, > -Paul > >> >> I have added some related engineers from Ingenic to CC >> >> Thanks and best regards! >> >> 在 2020/8/4 上午1:01, Paul Cercueil 写道: >>> Hi Thomas & list, >>> >>> Here is a set of patches for 5.10 (no rush) to move Ingenic support >>> from >>> arch/mips/jz4740/ to arch/mips/generic/. >>> >>> There are some Kconfig changes that I think should be reviewed in >>> detail >>> to avoid breakages elsewhere. The idea behind these changes is to allow >>> the Ingenic "generic" code to be built in a non-generic kernel, since >>> generic kernels bring lots of dependencies which result in a +7% size >>> increase. >>> >>> Support for booting the generic kernel with a built-in and/or appended >>> devicetree, as well as support for compressed (vmlinuz) kernels, has >>> been added as well. >>> >>> Cheers, >>> -Paul >>> >>> Paul Cercueil (13): >>> MIPS: cpu-probe: Set Ingenic's writecombine to _CACHE_CACHABLE_WA >>> MIPS: cpu-probe: Mark XBurst CPU as having vtagged caches >>> MIPS: cpu-probe: ingenic: Fix broken BUG_ON >>> MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol >>> MIPS: machine: Add get_system_type callback >>> MIPS: generic: Call the machine's .get_system_type callback if >>> provided >>> MIPS: generic: Support booting with built-in or appended DTB >>> MIPS: generic: Add support for zboot >>> MIPS: generic: Increase NR_IRQS to 256 >>> MIPS: generic: Add support for Ingenic SoCs >>> MIPS: jz4740: Drop folder >>> MIPS: configs: Regenerate configs of Ingenic boards >>> MAINTAINERS: Update paths to Ingenic platform code >>> >>> MAINTAINERS | 4 +- >>> arch/mips/Kbuild.platforms | 1 - >>> arch/mips/Kconfig | 43 ++++-- >>> arch/mips/configs/ci20_defconfig | 4 +- >>> arch/mips/configs/cu1000-neo_defconfig | 16 +- >>> arch/mips/configs/gcw0_defconfig | 2 +- >>> arch/mips/configs/qi_lb60_defconfig | 5 +- >>> arch/mips/configs/rs90_defconfig | 4 +- >>> arch/mips/generic/Kconfig | 8 +- >>> arch/mips/generic/Makefile | 2 +- >>> arch/mips/generic/Platform | 1 + >>> arch/mips/generic/board-ingenic.c | 108 +++++++++++++ >>> arch/mips/generic/init.c | 28 +++- >>> arch/mips/generic/proc.c | 25 --- >>> arch/mips/include/asm/mach-generic/irq.h | 2 +- >>> .../asm/mach-jz4740/cpu-feature-overrides.h | 50 ------ >>> arch/mips/include/asm/mach-jz4740/irq.h | 13 -- >>> arch/mips/include/asm/machine.h | 1 + >>> arch/mips/include/asm/pgtable-bits.h | 5 - >>> arch/mips/{jz4740 => ingenic}/Kconfig | 16 +- >>> arch/mips/jz4740/Makefile | 9 -- >>> arch/mips/jz4740/Platform | 3 - >>> arch/mips/jz4740/setup.c | 145 >>> ------------------ >>> arch/mips/kernel/cpu-probe.c | 8 +- >>> 24 files changed, 198 insertions(+), 305 deletions(-) >>> create mode 100644 arch/mips/generic/board-ingenic.c >>> delete mode 100644 arch/mips/generic/proc.c >>> delete mode 100644 >>> arch/mips/include/asm/mach-jz4740/cpu-feature-overrides.h >>> delete mode 100644 arch/mips/include/asm/mach-jz4740/irq.h >>> rename arch/mips/{jz4740 => ingenic}/Kconfig (91%) >>> delete mode 100644 arch/mips/jz4740/Makefile >>> delete mode 100644 arch/mips/jz4740/Platform >>> delete mode 100644 arch/mips/jz4740/setup.c >>> >
在 2020/8/8 上午12:45, Paul Cercueil 写道: > Hi Zhou, > > Le sam. 8 août 2020 à 0:23, Zhou Yanjie <zhouyanjie@wanyeetech.com> a > écrit : >> Hi Paul, >> >> 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). Hi Yanjie, TLBINV is a optional feature. We can always invalidate TLB via rewrite TLB entry. If X2000 can't work without TLBINV it means there are some thing went wrong with TLB. You'd better investigate in detail. Refined interrupt controller can be enabled via DeviceTree, you only have to write a new irqchip driver for it. Btw: My X2000 EVB is on the way thanks to Taobao~ Thanks. > > 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. > > As for your other question, I don't see any reason why we wouldn't be > able to support the X2000 aside the others in a generic kernel, so > don't worry :) > > Cheers, > -Paul >
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. 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. Maciej
Hi Maciej, Le ven. 21 août 2020 à 20:23, Maciej W. Rozycki <macro@linux-mips.org> 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
Hi Paul, > > 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. Well, run-time patching might be an alternative to get the best of both worlds, but someone would have to reimplement our feature selection system to use it. > > 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... I wasn't aware of that. In that case it has been a design abuse which has been missed by the maintainer when accepting patches. It used to be the case that run-time detection was accurate and overrides were rather lazily added. Also I note Ingenic must have had a CPU erratum if our `decode_configs' doesn't just work, as the interpretation of CP0.Config[5:0] registers has been architectural and mandatory, and that for a reason. It's only legacy MIPS I-IV processors that should require special attention here. Maciej
Le sam. 22 août 2020 à 3:29, Maciej W. Rozycki <macro@linux-mips.org> a écrit : > Hi Paul, > >> > 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. > > Well, run-time patching might be an alternative to get the best of > both > worlds, but someone would have to reimplement our feature selection > system > to use it. Would run-time patching allow to drop dead code? >> > 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... > > I wasn't aware of that. In that case it has been a design abuse > which > has been missed by the maintainer when accepting patches. It used to > be > the case that run-time detection was accurate and overrides were > rather > lazily added. > > Also I note Ingenic must have had a CPU erratum if our > `decode_configs' > doesn't just work, as the interpretation of CP0.Config[5:0] registers > has > been architectural and mandatory, and that for a reason. It's only > legacy > MIPS I-IV processors that should require special attention here. Yes, Ingenic CPUs have a few bloopers here and there... -Paul
On Sat, 22 Aug 2020, Paul Cercueil wrote: > > Well, run-time patching might be an alternative to get the best of both > > worlds, but someone would have to reimplement our feature selection system > > to use it. > > Would run-time patching allow to drop dead code? I don't know offhand. In principle it should be doable like with init sections, but that requires out of line code, so there'd still be some performance hit compared to a kernel configuration dedicated to a single platform. Maciej
Hello Maciej & Paul, 在 2020/8/22 上午10:29, Maciej W. Rozycki 写道: > Hi Paul, > >>> 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. > Well, run-time patching might be an alternative to get the best of both > worlds, but someone would have to reimplement our feature selection system > to use it. > >>> 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... > I wasn't aware of that. In that case it has been a design abuse which > has been missed by the maintainer when accepting patches. It used to be > the case that run-time detection was accurate and overrides were rather > lazily added. > > Also I note Ingenic must have had a CPU erratum if our `decode_configs' > doesn't just work, as the interpretation of CP0.Config[5:0] registers has > been architectural and mandatory, and that for a reason. It's only legacy > MIPS I-IV processors that should require special attention here. I think I found the cause of the problem. Ingenic XBurst2's TLBINV is operate on entire MMU, according to the description of the MD00090 document, the IE value in cp0 config4 should be 3 (Ingenic's XBurst2 Core PM document also shows that the IE value is indeed 3). But the code in cpu-probe.c only detects the case where the IE value is equal to 2 (TLBINV only operate on one TLB entry). Therefore, the kernel mistakenly believes that X2000 does not support TLBINV during detection. Thanks and best regards! > Maciej