On Fri, Nov 11, 2011 at 08:57:39AM -0800, Kevin Cernekee wrote: > 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 Fair enough; sorting that kind of thing will need some effort across the tree at some point in the future. I notice there seems to be only CPU core support; are you planning to submit board support code as well? Ralf
