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
|