On Sünnavend 05 Februar 2005 02:34, Anton Blanchard wrote:
> Interesting :) However we already get bug reports with the current
> CONFIG_POWER4_ONLY option. I worry about adding more options that users
> could get wrong unless there is a noticeable improvement in performance.
>
The patch that I po
On Fri, 2005-02-04 at 11:20 -0600, Olof Johansson wrote:
> On Fri, Feb 04, 2005 at 10:17:48AM +0200, Pekka Enberg wrote:
> > Please drop the CPU_FTR_##x macro magic as it makes grepping more
> > complicated. If the enum names are too long, just do s/CPU_FTR_/CPU_/g
> > or something similar. Also, c
On Fri, 2005-02-04 at 11:20 -0600, Olof Johansson wrote:
> * cpu-has-feature(cpu-feature-foo) v cpu-has-feature(foo): I picked the
> latter for readability.
> * Renaming CPU_FTR_ -> CPU_ makes it less obvious that
> it's actually a cpu feature it's describing (i.e. CPU_ALTIVEC vs
> CPU_FTR_ALTIVEC)
Hi,
> This is the patch to evaluate CPU_HAS_FEATURE() at compile time whenever
> possible. Testing showed that vmlinux shrinks around 4000 bytes with
> g5_defconfig. I also checked that pSeries code is completely unaltered
> semantically when support for all CPU types is enabled, although a few
>
> This is the patch to evaluate CPU_HAS_FEATURE() at compile time whenever
> possible. Testing showed that vmlinux shrinks around 4000 bytes with
> g5_defconfig. I also checked that pSeries code is completely unaltered
> semantically when support for all CPU types is enabled, although a few
> inst
On Sünnavend 05 Februar 2005 00:49, Benjamin Herrenschmidt wrote:
> On Fri, 2005-02-04 at 13:36 +0100, Arnd Bergmann wrote:
> > I have a somewhat similar patch that does the same to the
> > systemcfg->platform checks. I'm not sure if we should use the same inline
> > function for both checks, but I
On Fri, 2005-02-04 at 12:35 -0600, Olof Johansson wrote:
> On Fri, Feb 04, 2005 at 01:36:55PM +0100, Arnd Bergmann wrote:
> > I have a somewhat similar patch that does the same to the
> > systemcfg->platform checks. I'm not sure if we should use the same inline
> > function for both checks, but I d
On Fri, 2005-02-04 at 13:36 +0100, Arnd Bergmann wrote:
> On Freedag 04 Februar 2005 08:22, Olof Johansson wrote:
> > It's getting pretty old to have see and type cur_cpu_spec->cpu_features
> > & CPU_FTR_, when a shorter and less TLA-ridden macro is more
> > readable.
> >
> > This also takes care
On Freedag 04 Februar 2005 19:35, Olof Johansson wrote:
> pSeries will need all cpus enabled since we have them all on various
> machines, etc. I guess Powermac/Maple could benefit from it.
Even on pSeries, we already have CONFIG_POWER4_ONLY, which could be
used to optimize away some of the checks
On Fri, Feb 04, 2005 at 01:36:55PM +0100, Arnd Bergmann wrote:
> I have a somewhat similar patch that does the same to the
> systemcfg->platform checks. I'm not sure if we should use the same inline
> function for both checks, but I do think that they should be used in a
> similar way, e.g. CPU_HAS
On Fri, Feb 04, 2005 at 10:17:48AM +0200, Pekka Enberg wrote:
> Please drop the CPU_FTR_##x macro magic as it makes grepping more
> complicated. If the enum names are too long, just do s/CPU_FTR_/CPU_/g
> or something similar. Also, could you please make this a static inline
> function?
I consider
On Fri, Feb 04, 2005 at 01:22:54AM -0600, Olof Johansson wrote:
> Hi,
>
> It's getting pretty old to have see and type cur_cpu_spec->cpu_features
> & CPU_FTR_, when a shorter and less TLA-ridden macro is more
> readable.
>
> This also takes care of the differences between PPC and PPC64 cpu
> fea
On Freedag 04 Februar 2005 08:22, Olof Johansson wrote:
> It's getting pretty old to have see and type cur_cpu_spec->cpu_features
> & CPU_FTR_, when a shorter and less TLA-ridden macro is more
> readable.
>
> This also takes care of the differences between PPC and PPC64 cpu
> features for the comm
Hi,
On Fri, 4 Feb 2005 01:22:54 -0600, Olof Johansson <[EMAIL PROTECTED]> wrote:
> +#define CPU_HAS_FEATURE(x) (cur_cpu_spec->cpu_features & CPU_FTR_##x)
> +
Please drop the CPU_FTR_##x macro magic as it makes grepping more
complicated. If the enum names are too long, just do s/CPU_FTR_/CPU_/
Hi,
It's getting pretty old to have see and type cur_cpu_spec->cpu_features
& CPU_FTR_, when a shorter and less TLA-ridden macro is more
readable.
This also takes care of the differences between PPC and PPC64 cpu
features for the common code; most places in PPC could be replaced with
the macro as
15 matches
Mail list logo
