On Fri, Nov 11, 2011 at 4:58 AM, Ralf Baechle <email@example.com> 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
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
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.