Le vendredi 11 novembre 2011 18:20:39, Ralf Baechle a écrit : > 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? BCM63xx and BCM47xx use BMIPS CPUs and can already take advantage of this core CPU support code. -- Florian
