From: Olaf Hering <hidden> Date: 2005-01-09 15:13:57
On Sat, Jan 08, Linux Kernel Mailing List wrote:
ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, hpa@zytor.com
[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.
From: David Woodhouse <dwmw2@infradead.org> Date: 2005-01-17 10:16:52
On Sun, 2005-01-09 at 16:13 +0100, Olaf Hering wrote:
quoted
ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, hpa@zytor.com
[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
From: Kumar Gala <hidden> Date: 2005-01-17 14:59:14
[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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-01-19 04:15:58
On Mon, 2005-01-17 at 10:16 +0000, David Woodhouse wrote:
On Sun, 2005-01-09 at 16:13 +0100, Olaf Hering wrote:
quoted
quoted
ChangeSet 1.2347, 2005/01/08 14:02:27-08:00, hpa@zytor.com
[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.
quoted
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.
From: David Woodhouse <dwmw2@infradead.org> Date: 2005-01-19 08:14:23
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
From: Kumar Gala <hidden> Date: 2005-01-19 14:48:25
David,
We did talk about looking at using some work Ben did in ppc64 with OF=20
in ppc32. John Masters was looking into this, but I havent heard much=20=
from him on it lately.
The firmware interface on the ppc32 embedded side is some what broken=20
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?
--=20
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe=20
linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at=A0 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at=A0 http://www.tux.org/lkml/
From: David Woodhouse <dwmw2@infradead.org> Date: 2005-01-19 14:50:18
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
From: Kumar Gala <hidden> Date: 2005-01-19 14:55:15
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=20=
OF
quoted
in ppc32.=A0 John Masters was looking into this, but I havent heard=20=
much
> from him on it lately.
>
quoted
The firmware interface on the ppc32 embedded side is some what =
broken
quoted
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,=20
value pairs
- kumar=
On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
quoted
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 -- geert@linux-m68k.org
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
From: Kumar Gala <hidden> Date: 2005-01-19 15:15:51
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=20
with OF
quoted
quoted
in ppc32.=A0 John Masters was looking into this, but I havent =
heard=20
much
> > from him on it lately.
> >
quoted
quoted
The firmware interface on the ppc32 embedded side is some what=20
broken
quoted
quoted
in my mind.
The binary structure which changes every few weeks and which is=20
shared
> between the bootloader and the kernel? Yeah, "somewhat broken" is=20=
one
quoted
way of putting it :)
>
quoted
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=20=
2.
Out of interest, on ARM & m68k I would assume that the list of tag's=20
gets added to over time?
- kumar
On Jan 19, 2005, at 9:08 AM, Geert Uytterhoeven wrote:
quoted
On Wed, 19 Jan 2005, David Woodhouse wrote:
quoted
The binary structure which changes every few weeks and which is shared
> between the bootloader and the kernel? Yeah, "somewhat broken" is one
quoted
way of putting it :)
>
quoted
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 -- geert@linux-m68k.org
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
From: Jon Masters <hidden> Date: 2005-01-19 18:07:59
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.
From: Paul Mackerras <hidden> Date: 2005-01-19 21:12:30
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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-01-19 23:27:03
On Wed, 2005-01-19 at 07:43 +0000, David Woodhouse wrote:
On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
quoted
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.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2005-01-19 23:31:01
On Wed, 2005-01-19 at 14:48 +0000, David Woodhouse wrote:
On Wed, 2005-01-19 at 08:45 -0600, Kumar Gala wrote:
quoted
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.
From: Jon Masters <hidden> Date: 2005-01-20 07:43:06
[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:
quoted
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/
From: Sven Luther <hidden> Date: 2005-01-23 11:18:37
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:
quoted
On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote:
quoted
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