On Sat, Jan 08, Linux Kernel Mailing List wrote:
> ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, [email protected]
>
> [PATCH] raid6: altivec support
>
> This patch adds Altivec support for RAID-6, if appropriately configured on
> the ppc or ppc64 architectures. Note that it changes the compile flags for
> ppc64 in order to handle -maltivec correctly; this change was vetted on the
> ppc64 mailing list and OK'd by paulus.
This fails to compile on ppc, enable_kernel_altivec() is an exported but
undeclared function. cpu_features is also missing.
drivers/md/raid6altivec1.c: In function `raid6_altivec1_gen_syndrome':
drivers/md/raid6altivec1.c:99: warning: implicit declaration of function `enable_kernel_altivec'
drivers/md/raid6altivec1.c: In function `raid6_have_altivec':
drivers/md/raid6altivec1.c:111: error: request for member `cpu_features' in something not a structure or union
drivers/md/raid6altivec2.c: In function `raid6_altivec2_gen_syndrome':
drivers/md/raid6altivec2.c:110: warning: implicit declaration of function `enable_kernel_altivec'
There are a few more exported symbols without declaration:
__ashldi3
__ashrdi3
__lshrdi3
enable_kernel_spe
fec_register_ph
fec_unregister_ph
idma_pci9_read
idma_pci9_read_le
local_irq_disable_end
local_irq_enable_end
local_irq_restore_end
local_save_flags_ptr_end
ocp_bus_type
ppc4xx_set_dma_addr
I'm not sure if the EXPORT_SYMBOL should be dropped for them, they have
no users in the current kernel.
--- ../linux-2.6.10-bk12/include/asm-ppc/system.h 2004-12-24 22:34:32.000000000 +0100
+++ ./include/asm-ppc/system.h 2005-01-09 15:53:32.338569809 +0100
@@ -76,6 +76,7 @@ extern void giveup_fpu(struct task_struc
extern void enable_kernel_fp(void);
extern void giveup_altivec(struct task_struct *);
extern void load_up_altivec(struct task_struct *);
+extern void enable_kernel_altivec(void);
extern void giveup_spe(struct task_struct *);
extern void load_up_spe(struct task_struct *);
extern int fix_alignment(struct pt_regs *);
On Sun, 2005-01-09 at 16:13 +0100, Olaf Hering wrote:
>
> > ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, [email protected]
> >
> > [PATCH] raid6: altivec support
> >
> > This patch adds Altivec support for RAID-6, if appropriately configured on
> > the ppc or ppc64 architectures. Note that it changes the compile flags for
> > ppc64 in order to handle -maltivec correctly; this change was vetted on the
> > ppc64 mailing list and OK'd by paulus.
>
> This fails to compile on ppc, enable_kernel_altivec() is an exported but
> undeclared function. cpu_features is also missing.
>
> drivers/md/raid6altivec1.c: In function `raid6_altivec1_gen_syndrome':
> drivers/md/raid6altivec1.c:99: warning: implicit declaration of function `enable_kernel_altivec'
> drivers/md/raid6altivec1.c: In function `raid6_have_altivec':
> drivers/md/raid6altivec1.c:111: error: request for member `cpu_features' in something not a structure or union
> drivers/md/raid6altivec2.c: In function `raid6_altivec2_gen_syndrome':
> drivers/md/raid6altivec2.c:110: warning: implicit declaration of function `enable_kernel_altivec'
This makes it compile on PPC, but highlights the difference between
'cur_cpu_spec' on ppc32 and ppc64. Why is 'cur_cpu_spec' an array on
ppc32? Isn't 'cur' supposed to imply 'current'?
===== drivers/md/raid6altivec.uc 1.1 vs edited =====
--- 1.1/drivers/md/raid6altivec.uc Sat Jan 8 05:44:07 2005
+++ edited/drivers/md/raid6altivec.uc Mon Jan 17 09:45:20 2005
@@ -108,7 +108,11 @@
int raid6_have_altivec(void)
{
/* This assumes either all CPUs have Altivec or none does */
+#ifdef CONFIG_PPC64
return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#else
+ return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#endif
}
#endif
--
dwmw2
[snip]
> This makes it compile on PPC, but highlights the difference between
> 'cur_cpu_spec' on ppc32 and ppc64. Why is 'cur_cpu_spec' an array on
> ppc32? Isn't 'cur' supposed to imply 'current'?
I can only guess to handle an SMP case with two different revs of the
same processor that might have slightly different errata.
- kumar
On Mon, 2005-01-17 at 10:16 +0000, David Woodhouse wrote:
> On Sun, 2005-01-09 at 16:13 +0100, Olaf Hering wrote:
> >
> > > ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, [email protected]
> > >
> > > [PATCH] raid6: altivec support
> > >
> > > This patch adds Altivec support for RAID-6, if appropriately configured on
> > > the ppc or ppc64 architectures. Note that it changes the compile flags for
> > > ppc64 in order to handle -maltivec correctly; this change was vetted on the
> > > ppc64 mailing list and OK'd by paulus.
> >
> > This fails to compile on ppc, enable_kernel_altivec() is an exported but
> > undeclared function. cpu_features is also missing.
> >
I sent Linus & Andrew a patch fixing the enable_kernel_altivec() thing
yesterday. cpu_features isn't missing, it's defined differently.
> > drivers/md/raid6altivec1.c: In function `raid6_altivec1_gen_syndrome':
> > drivers/md/raid6altivec1.c:99: warning: implicit declaration of function `enable_kernel_altivec'
> > drivers/md/raid6altivec1.c: In function `raid6_have_altivec':
> > drivers/md/raid6altivec1.c:111: error: request for member `cpu_features' in something not a structure or union
> > drivers/md/raid6altivec2.c: In function `raid6_altivec2_gen_syndrome':
> > drivers/md/raid6altivec2.c:110: warning: implicit declaration of function `enable_kernel_altivec'
>
> This makes it compile on PPC, but highlights the difference between
> 'cur_cpu_spec' on ppc32 and ppc64. Why is 'cur_cpu_spec' an array on
> ppc32? Isn't 'cur' supposed to imply 'current'?
It's history. When I wrote that on ppc in the first place, I decided to
leave room for having slightly different CPUs so I defined it as an
array of NR_CPUs.
When we ported this to ppc64, we figured out we never actually used that
"feature", and that the way the dynamic patching works with CPU features
makes it mandatory to have identical feature sets anyway.
We should probably "backport" that simplification to ppc32...
Ben.
On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> We should probably "backport" that simplification to ppc32...
Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
like mips/parisc/s390. Or would that get vetoed on the basis that we
don't have all that horrid non-OF platform support in ppc64 yet, and
we're still kidding ourselves that all those embedded vendors will
either not notice ppc64 or will use OF?
--
dwmw2
David,
We did talk about looking at using some work Ben did in ppc64 with OF
in ppc32. John Masters was looking into this, but I havent heard much
from him on it lately.
The firmware interface on the ppc32 embedded side is some what broken
in my mind.
- kumar
On Jan 19, 2005, at 1:43 AM, David Woodhouse wrote:
> On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> > We should probably "backport" that simplification to ppc32...
>
> Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
> like mips/parisc/s390. Or would that get vetoed on the basis that we
> don't have all that horrid non-OF platform support in ppc64 yet, and
> we're still kidding ourselves that all those embedded vendors will
> either not notice ppc64 or will use OF?
>
> --
> dwmw2
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at? http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at? http://www.tux.org/lkml/
On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
> We did talk about looking at using some work Ben did in ppc64 with OF
> in ppc32. John Masters was looking into this, but I havent heard much
> from him on it lately.
>
> The firmware interface on the ppc32 embedded side is some what broken
> in my mind.
The binary structure which changes every few weeks and which is shared
between the bootloader and the kernel? Yeah, "somewhat broken" is one
way of putting it :)
The ARM kernel does it a lot better with tag,value pairs.
--
dwmw2
On Jan 19, 2005, at 8:48 AM, David Woodhouse wrote:
> On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
> > We did talk about looking at using some work Ben did in ppc64 with
> OF
> > in ppc32.? John Masters was looking into this, but I havent heard
> much
> > from him on it lately.
> >
> > The firmware interface on the ppc32 embedded side is some what broken
> > in my mind.
>
> The binary structure which changes every few weeks and which is shared
> between the bootloader and the kernel? Yeah, "somewhat broken" is one
> way of putting it :)
>
> The ARM kernel does it a lot better with tag,value pairs.
The funny thing is that one of the variants on ppc32 supports tag,
value pairs
- kumar
On Wed, 19 Jan 2005, David Woodhouse wrote:
> On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
> > We did talk about looking at using some work Ben did in ppc64 with OF
> > in ppc32. John Masters was looking into this, but I havent heard much
> > from him on it lately.
> >
> > The firmware interface on the ppc32 embedded side is some what broken
> > in my mind.
>
> The binary structure which changes every few weeks and which is shared
> between the bootloader and the kernel? Yeah, "somewhat broken" is one
> way of putting it :)
>
> The ARM kernel does it a lot better with tag,value pairs.
As does m68k... That's why we never got beyond bootinfo major version 2.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Jan 19, 2005, at 9:08 AM, Geert Uytterhoeven wrote:
> On Wed, 19 Jan 2005, David Woodhouse wrote:
> > On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
> > > We did talk about looking at using some work Ben did in ppc64
> with OF
> > > in ppc32.? John Masters was looking into this, but I havent heard
> much
> > > from him on it lately.
> > >
> > > The firmware interface on the ppc32 embedded side is some what
> broken
> > > in my mind.
> >
> > The binary structure which changes every few weeks and which is
> shared
> > between the bootloader and the kernel? Yeah, "somewhat broken" is
> one
> > way of putting it :)
> >
> > The ARM kernel does it a lot better with tag,value pairs.
>
> As does m68k... That's why we never got beyond bootinfo major version
> 2.
Out of interest, on ARM & m68k I would assume that the list of tag's
gets added to over time?
- kumar
On Wed, 19 Jan 2005, Kumar Gala wrote:
> On Jan 19, 2005, at 9:08 AM, Geert Uytterhoeven wrote:
> > On Wed, 19 Jan 2005, David Woodhouse wrote:
> > > The binary structure which changes every few weeks and which is shared
> > > between the bootloader and the kernel? Yeah, "somewhat broken" is one
> > > way of putting it :)
> > >
> > > The ARM kernel does it a lot better with tag,value pairs.
> >
> > As does m68k... That's why we never got beyond bootinfo major version 2.
>
> Out of interest, on ARM & m68k I would assume that the list of tag's gets
> added to over time?
That's true. But besides the recent conversion of the HP9000/[34]00 code to
use bootinfo, not much has changed during the last 5 years.
If a tag is not recognized, it's just ignored. That means your new feature
cannot be used by the kernel, but it doesn't break the bootloader<->kernel
interface the hard way.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Kumar Gala wrote:
> We did talk about looking at using some work Ben did in ppc64 with OF in
> ppc32. John Masters was looking into this, but I havent heard much from
> him on it lately.
I went rather quiet since I had nothing new to add to the discussion.
But I did plan to get somewhere before FOSDEM (next month) so I could at
least talk to the guys there about it - this is really taking a backseat
as I've little time for it and no BDI2000/etc. at home :-)
> The firmware interface on the ppc32 embedded side is some what broken in
> my mind.
It's absolutely broken and needs fixing - perhaps if someone wants to
work with me on it, we'd get it sorted more quickly.
Cheers,
Jon.
David Woodhouse writes:
> Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
> like mips/parisc/s390. Or would that get vetoed on the basis that we
> don't have all that horrid non-OF platform support in ppc64 yet, and
> we're still kidding ourselves that all those embedded vendors will
> either not notice ppc64 or will use OF?
I'm going to insist that every new ppc64 platform supplies a device
tree. They don't have to have OF but they do need to have the booter
or wrapper supply a flattened device tree (which is just a few kB of
binary data as far as the booter/wrapper is concerned). It doesn't
have to include all the
As for merging ppc32 and ppc64, I think it would end up an awful ifdef
mess, but if you can see a clean way to do it, send me a patch. :)
Paul.
On Wed, 2005-01-19 at 07:43 +0000, David Woodhouse wrote:
> On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> > We should probably "backport" that simplification to ppc32...
>
> Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
> like mips/parisc/s390. Or would that get vetoed on the basis that we
> don't have all that horrid non-OF platform support in ppc64 yet, and
> we're still kidding ourselves that all those embedded vendors will
> either not notice ppc64 or will use OF?
Oh well... i've though about it too, and decided that I was not ready to
try it. For one, the problem you mention, with the pile of embedded
junk. I made the design decision to define an OF client interface as the
standard & mandatory entry mecanism to the ppc64 kernel (except legacy
iSeries of course, but I don't want that to multiply). That or the
kexec-like entrypoint passing a flattened device-tree in.
Also, there are other significant differences in other areas. At this
point, I think the differences are bigger than the common code.
What would be interesting would be to proceed incrementally, having a
directory somewhere to put the "common" ppc/ppc64 code, and slowly
moving things there.
Ben.
On Wed, 2005-01-19 at 14:48 +0000, David Woodhouse wrote:
> On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
> > We did talk about looking at using some work Ben did in ppc64 with OF
> > in ppc32. John Masters was looking into this, but I havent heard much
> > from him on it lately.
> >
> > The firmware interface on the ppc32 embedded side is some what broken
> > in my mind.
>
> The binary structure which changes every few weeks and which is shared
> between the bootloader and the kernel? Yeah, "somewhat broken" is one
> way of putting it :)
>
> The ARM kernel does it a lot better with tag,value pairs.
And ppc64 adds a flattened device-tree format, even better imho :)
Ben.
[excuse formatting, adhoc connectivity]
Ben writes:
> And ppc64 adds a flattened device-tree format, even better imho :)
This is exactly what I was looking at - pulling that in to ppc32, helps
with stuff like kexec too. Like everything else, it helps to have people
moaning at me to make me get on with it :-) I'll see if I can't spend a
few hours on the plane and ressurrect this instead of window gazing.
Jon.
On Wed, Jan 19, 2005 at 08:41:25PM +1100, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
> > like mips/parisc/s390. Or would that get vetoed on the basis that we
> > don't have all that horrid non-OF platform support in ppc64 yet, and
> > we're still kidding ourselves that all those embedded vendors will
> > either not notice ppc64 or will use OF?
>
> I'm going to insist that every new ppc64 platform supplies a device
> tree. They don't have to have OF but they do need to have the booter
> or wrapper supply a flattened device tree (which is just a few kB of
> binary data as far as the booter/wrapper is concerned). It doesn't
> have to include all the
*shurg*
It really is a great idea, but I think it will just move the ire from
(serial infos, IRQ table, ?) being in platforms/fooboard.[ch] to
platforms/fooboard.h or platforms/fooboard_bootinfos.h
So lets just hope ppc64 keeps getting ignored :)
--
Tom Rini
http://gate.crashing.org/~trini/
On Thu, Jan 20, 2005 at 10:22:18AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-01-19 at 07:43 +0000, David Woodhouse wrote:
> > On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
> > > We should probably "backport" that simplification to ppc32...
> >
> > Yeah.... I'm increasingly tempted to merge ppc32/ppc64 into one arch
> > like mips/parisc/s390. Or would that get vetoed on the basis that we
> > don't have all that horrid non-OF platform support in ppc64 yet, and
> > we're still kidding ourselves that all those embedded vendors will
> > either not notice ppc64 or will use OF?
>
> Oh well... i've though about it too, and decided that I was not ready to
> try it. For one, the problem you mention, with the pile of embedded
> junk. I made the design decision to define an OF client interface as the
> standard & mandatory entry mecanism to the ppc64 kernel (except legacy
> iSeries of course, but I don't want that to multiply). That or the
> kexec-like entrypoint passing a flattened device-tree in.
>
> Also, there are other significant differences in other areas. At this
> point, I think the differences are bigger than the common code.
>
> What would be interesting would be to proceed incrementally, having a
> directory somewhere to put the "common" ppc/ppc64 code, and slowly
> moving things there.
It may be too complicated, but what about letting the commong code in ppc, and
moving the ppc32 code into ppc32 ?
Friendly,
Sven Luther