mbox series

[00/13] MIPS: Convert Ingenic to a generic board

Message ID 20200803170124.231110-1-paul@crapouillou.net (mailing list archive)
Headers show
Series MIPS: Convert Ingenic to a generic board | expand

Message

Paul Cercueil Aug. 3, 2020, 5:01 p.m. UTC
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

Comments

Zhou Yanjie Aug. 7, 2020, 4:23 p.m. UTC | #1
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
>
Paul Cercueil Aug. 7, 2020, 4:45 p.m. UTC | #2
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
>>
Zhou Yanjie Aug. 7, 2020, 5:20 p.m. UTC | #3
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
>>>
>
Jiaxun Yang Aug. 8, 2020, 2:39 a.m. UTC | #4
在 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
>
Maciej W. Rozycki Aug. 21, 2020, 7:23 p.m. UTC | #5
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
Paul Cercueil Aug. 21, 2020, 11:19 p.m. UTC | #6
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
Maciej W. Rozycki Aug. 22, 2020, 2:29 a.m. UTC | #7
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
Paul Cercueil Aug. 22, 2020, 1:17 p.m. UTC | #8
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
Maciej W. Rozycki Aug. 22, 2020, 2 p.m. UTC | #9
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
Zhou Yanjie Oct. 26, 2020, 2:25 p.m. UTC | #10
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