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
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,
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, could
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
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
>
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
>
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
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
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
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.
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
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
>
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
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
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 do
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
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
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_x - CPU_x makes it less obvious that
it's actually a cpu feature it's describing (i.e. CPU_ALTIVEC vs
CPU_FTR_ALTIVEC).
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_/g
or
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_feature, 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
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_feature, when a shorter and less TLA-ridden macro is more
readable.
This also takes care of the differences between PPC and PPC64 cpu
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 considered
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.
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, 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_feature, when a shorter and less TLA-ridden macro is more
readable.
This also takes care of
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 do think
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
Hi,
It's getting pretty old to have see and type cur_cpu_spec-cpu_features
CPU_FTR_feature, 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
30 matches
Mail list logo
