On Fri, Nov 11, 2011 at 4:58 AM, Ralf Baechle <ralf@xxxxxxxxxxxxxx> wrote: > If BMIPS is just a MIPS32 with no relevant extensions to the instruction > set, why don't you just call it a MIPS32 processor and use something > like CPU_MIPS32_R2? > > It's small things like that which can sometimes avoid many unnecessary > recompilations which really saves times when rebuilding all defconfigs > on a way to slow machine :) At a high level, the CONFIG_CPU_BMIPS* settings are used to make compile-time decisions that differentiate BMIPS from standard MIPS32, and that differentiate the BMIPS CPUs from one another. Present and future uses include: Figuring out which set of proprietary BMIPS CP0 registers / core registers to use, where they are located, bit fields, etc. Per-BMIPS SMP operations and capabilities Per-BMIPS performance counter access cpu-feature-overrides.h HIGHMEM, SMP, and other basic features eDSP instruction set (different on each BMIPS, and BMIPS-specific) Cache architecture and BMIPS-specific cache optimizations Some of these could potentially be replaced with a "switch (current_cpu_type())" but others are a little trickier (i.e. they show up in low-level PM resume code, exception vectors, or other sensitive places). It is true that BMIPS uses -mips32 for compilation. If the criteria for adding a new CONFIG_CPU_* choice is whether it selects a new instruction set or compilation flags, do you think it makes sense to remove BMIPS* from the "CPU selection" menu, enable CONFIG_CPU_MIPS32_R1 for BMIPS platforms, and call our options something different? e.g. CONFIG_BMIPS CONFIG_BMIPS3300 CONFIG_BMIPS4350 CONFIG_BMIPS4380 CONFIG_BMIPS5000
