[PATCH] powerpc: merge include/asm/cputable.h
kumar.gala at freescale.com
Fri Sep 16 12:22:08 EST 2005
On Sep 15, 2005, at 5:56 PM, Arnd Bergmann wrote:
> On Dunnersdag 15 September 2005 19:44, Kumar Gala wrote:
>> I get the idea now, how about we make CPU_FTR_ALWAYS &
>> CPU_FTR_POSSIBLE just #defines and leave it to various sub-archs to
>> define CPU_FTR_POSSIBLE if they want to.
> So you mean like:
> #ifdef CONFIG_PPC_PSERIES
> #define CPU_FTR_PSERIES_POSSIBLE (CPU_FTR_FOO | CPU_FTR_BAR)
> #define CPU_FTR_PSERIES_ALWAYS (CPU_FTR_FOO)
> #define CPU_FTR_PSERIES_POSSIBLE (0)
> #define CPU_FTR_PSERIES_ALWAYS (-1)
> #ifdef CONFIG_PPC_PMAC
> #define CPU_FTR_PMAC_POSSIBLE (CPU_FTR_BAR | CPU_FTR_BAZ)
> #define CPU_FTR_PMAL_ALWAYS (CPU_FTR_BAZ)
> #define CPU_FTR_PMAC_POSSIBLE (0)
> #define CPU_FTR_PMAC_ALWAYS (-1)
> #define CPU_FTR_POSSIBLE CPU_FTR_PSERIES_POSSIBLE |
> CPU_FTR_PMAC_POSSIBLE \
> | CPU_FTR_...
> #define CPU_FTR_ALWAYS CPU_FTR_POSSIBLE & CPU_FTR_PSERIES_ALWAYS \
> & CPU_FTR_PMAC_ALWAYS & CPU_FTR_ ...
Yes, something like that. Why do we need the CPU_FTR_ALWAYS. It
seems that CPU_FTR_POSSIBLE is sufficient. I may just not understand
the purpose of CPU_FTR_ALWAYS.
> That would of course avoid having to define the features per CPU type,
> but at the same time make the system more error prone, because every
> time you add a feature to some of the CPUs, you'd have to know exactly
> which platform defines to change as well, and they might get out of
Well if you are adding a new FTR you better know what CPUs it belongs
to otherwise how would you update the cputable today? However, I do
agree it could be error prone.
> I also don't think that using the #defines here makes it any more
> readable than the enums, because you cannot have compile-time
> inside of #define.
>> I see the classes of for FTR_POSSIBLE: CLASSIC_PPC, 8xx, 4xx, FSL-
>> BOOKE, PPC64 (maybe more subclasses here).
>> The hugh enum while useful, is just really ugly and I can't believe
>> it's worth it for the ~60 cases we are using cpu_has_feature() in.
> One point to consider is that we traditionally use #ifdef in the
> source for many places that could simply use cpu_has_feature(). E.g.
> most instances of #ifdef CONFIG_ALTIVEC could be replaced by
> cpu_has_feature(CPU_FTR_ALTIVEC) without additional run-time overhead.
These should stay as CONFIG options because to reduce the code size
of the kernel which is important to embedded people.
More information about the Linuxppc-dev