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
|