* Re: [PATCH] raid6: altivec support [not found] <200501082324.j08NOIva030415@hera.kernel.org> @ 2005-01-09 15:13 ` Olaf Hering 2005-01-17 10:16 ` David Woodhouse 0 siblings, 1 reply; 18+ messages in thread From: Olaf Hering @ 2005-01-09 15:13 UTC (permalink / raw) To: linux-kernel; +Cc: linuxppc-dev 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. --- ../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 *); ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-09 15:13 ` [PATCH] raid6: altivec support Olaf Hering @ 2005-01-17 10:16 ` David Woodhouse 2005-01-17 14:58 ` Kumar Gala 2005-01-19 4:11 ` Benjamin Herrenschmidt 0 siblings, 2 replies; 18+ messages in thread From: David Woodhouse @ 2005-01-17 10:16 UTC (permalink / raw) To: Olaf Hering; +Cc: linux-kernel, linuxppc-dev, hpa, torvalds On Sun, 2005-01-09 at 16:13 +0100, Olaf Hering 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' 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-17 10:16 ` David Woodhouse @ 2005-01-17 14:58 ` Kumar Gala 2005-01-19 4:11 ` Benjamin Herrenschmidt 1 sibling, 0 replies; 18+ messages in thread From: Kumar Gala @ 2005-01-17 14:58 UTC (permalink / raw) To: David Woodhouse; +Cc: hpa, Olaf Hering, linux-kernel, torvalds, linuxppc-dev [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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-17 10:16 ` David Woodhouse 2005-01-17 14:58 ` Kumar Gala @ 2005-01-19 4:11 ` Benjamin Herrenschmidt 2005-01-19 7:43 ` David Woodhouse 1 sibling, 1 reply; 18+ messages in thread From: Benjamin Herrenschmidt @ 2005-01-19 4:11 UTC (permalink / raw) To: David Woodhouse Cc: Olaf Hering, linuxppc-dev list, Linus Torvalds, Linux Kernel list, H. Peter Anvin 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, 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. > > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 4:11 ` Benjamin Herrenschmidt @ 2005-01-19 7:43 ` David Woodhouse 2005-01-19 9:41 ` Paul Mackerras ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: David Woodhouse @ 2005-01-19 7:43 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Olaf Hering, linuxppc-dev list, Linus Torvalds, Linux Kernel list, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 7:43 ` David Woodhouse @ 2005-01-19 9:41 ` Paul Mackerras 2005-01-20 17:55 ` Tom Rini 2005-01-19 14:45 ` Kumar Gala 2005-01-19 23:22 ` Benjamin Herrenschmidt 2 siblings, 1 reply; 18+ messages in thread From: Paul Mackerras @ 2005-01-19 9:41 UTC (permalink / raw) To: David Woodhouse Cc: Benjamin Herrenschmidt, Olaf Hering, linuxppc-dev list, Linus Torvalds, Linux Kernel list, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 9:41 ` Paul Mackerras @ 2005-01-20 17:55 ` Tom Rini 0 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2005-01-20 17:55 UTC (permalink / raw) To: Paul Mackerras Cc: David Woodhouse, Linux Kernel list, linuxppc-dev list, Linus Torvalds, H. Peter Anvin 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/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 7:43 ` David Woodhouse 2005-01-19 9:41 ` Paul Mackerras @ 2005-01-19 14:45 ` Kumar Gala 2005-01-19 14:48 ` David Woodhouse 2005-01-19 18:07 ` Jon Masters 2005-01-19 23:22 ` Benjamin Herrenschmidt 2 siblings, 2 replies; 18+ messages in thread From: Kumar Gala @ 2005-01-19 14:45 UTC (permalink / raw) To: David Woodhouse Cc: Paul Mackerras, Jon Masters, Olaf Hering, Linus Torvalds, linuxppc-dev list, H. Peter Anvin, Benjamin Herrenschmidt, Linux Kernel list 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 14:45 ` Kumar Gala @ 2005-01-19 14:48 ` David Woodhouse 2005-01-19 14:54 ` Kumar Gala ` (2 more replies) 2005-01-19 18:07 ` Jon Masters 1 sibling, 3 replies; 18+ messages in thread From: David Woodhouse @ 2005-01-19 14:48 UTC (permalink / raw) To: Kumar Gala Cc: Paul Mackerras, Jon Masters, Olaf Hering, Linus Torvalds, linuxppc-dev list, H. Peter Anvin, Benjamin Herrenschmidt, Linux Kernel list 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 14:48 ` David Woodhouse @ 2005-01-19 14:54 ` Kumar Gala 2005-01-19 15:08 ` Geert Uytterhoeven 2005-01-19 23:25 ` Benjamin Herrenschmidt 2 siblings, 0 replies; 18+ messages in thread From: Kumar Gala @ 2005-01-19 14:54 UTC (permalink / raw) To: David Woodhouse Cc: Paul Mackerras, Linus Torvalds, Jon Masters, Olaf Hering, Benjamin Herrenschmidt, linuxppc-dev list, Linux Kernel list, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 14:48 ` David Woodhouse 2005-01-19 14:54 ` Kumar Gala @ 2005-01-19 15:08 ` Geert Uytterhoeven 2005-01-19 15:15 ` Kumar Gala 2005-01-19 23:25 ` Benjamin Herrenschmidt 2 siblings, 1 reply; 18+ messages in thread From: Geert Uytterhoeven @ 2005-01-19 15:08 UTC (permalink / raw) To: David Woodhouse Cc: Kumar Gala, Linux Kernel list, linuxppc-dev list, Linus Torvalds, Paul Mackerras, H. Peter Anvin 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 -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 15:08 ` Geert Uytterhoeven @ 2005-01-19 15:15 ` Kumar Gala 2005-01-19 15:27 ` Geert Uytterhoeven 0 siblings, 1 reply; 18+ messages in thread From: Kumar Gala @ 2005-01-19 15:15 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Paul Mackerras, Linus Torvalds, Linux Kernel list, linuxppc-dev list, David Woodhouse, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 15:15 ` Kumar Gala @ 2005-01-19 15:27 ` Geert Uytterhoeven 0 siblings, 0 replies; 18+ messages in thread From: Geert Uytterhoeven @ 2005-01-19 15:27 UTC (permalink / raw) To: Kumar Gala Cc: Paul Mackerras, Linus Torvalds, Linux Kernel list, linuxppc-dev list, David Woodhouse, H. Peter Anvin 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 -- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 14:48 ` David Woodhouse 2005-01-19 14:54 ` Kumar Gala 2005-01-19 15:08 ` Geert Uytterhoeven @ 2005-01-19 23:25 ` Benjamin Herrenschmidt 2005-01-20 7:40 ` [Lists-linux-kernel-news] " Jon Masters 2 siblings, 1 reply; 18+ messages in thread From: Benjamin Herrenschmidt @ 2005-01-19 23:25 UTC (permalink / raw) To: David Woodhouse Cc: Kumar Gala, Paul Mackerras, Jon Masters, Olaf Hering, Linus Torvalds, linuxppc-dev list, H. Peter Anvin, Linux Kernel list 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Lists-linux-kernel-news] Re: [PATCH] raid6: altivec support 2005-01-19 23:25 ` Benjamin Herrenschmidt @ 2005-01-20 7:40 ` Jon Masters 0 siblings, 0 replies; 18+ messages in thread From: Jon Masters @ 2005-01-20 7:40 UTC (permalink / raw) To: benh Cc: dwmw2, linuxppc-dev, torvalds, paulus, olh, jonathan, kumar.gala, hpa, linux-kernel [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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 14:45 ` Kumar Gala 2005-01-19 14:48 ` David Woodhouse @ 2005-01-19 18:07 ` Jon Masters 1 sibling, 0 replies; 18+ messages in thread From: Jon Masters @ 2005-01-19 18:07 UTC (permalink / raw) To: Kumar Gala Cc: David Woodhouse, Paul Mackerras, Olaf Hering, Linus Torvalds, linuxppc-dev list, H. Peter Anvin, Benjamin Herrenschmidt, Linux Kernel list 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 7:43 ` David Woodhouse 2005-01-19 9:41 ` Paul Mackerras 2005-01-19 14:45 ` Kumar Gala @ 2005-01-19 23:22 ` Benjamin Herrenschmidt 2005-01-23 11:17 ` Sven Luther 2 siblings, 1 reply; 18+ messages in thread From: Benjamin Herrenschmidt @ 2005-01-19 23:22 UTC (permalink / raw) To: David Woodhouse Cc: Olaf Hering, linuxppc-dev list, Linus Torvalds, Linux Kernel list, H. Peter Anvin 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] raid6: altivec support 2005-01-19 23:22 ` Benjamin Herrenschmidt @ 2005-01-23 11:17 ` Sven Luther 0 siblings, 0 replies; 18+ messages in thread From: Sven Luther @ 2005-01-23 11:17 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: David Woodhouse, linuxppc-dev list, Linus Torvalds, H. Peter Anvin, Linux Kernel list 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-01-23 11:18 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200501082324.j08NOIva030415@hera.kernel.org> 2005-01-09 15:13 ` [PATCH] raid6: altivec support Olaf Hering 2005-01-17 10:16 ` David Woodhouse 2005-01-17 14:58 ` Kumar Gala 2005-01-19 4:11 ` Benjamin Herrenschmidt 2005-01-19 7:43 ` David Woodhouse 2005-01-19 9:41 ` Paul Mackerras 2005-01-20 17:55 ` Tom Rini 2005-01-19 14:45 ` Kumar Gala 2005-01-19 14:48 ` David Woodhouse 2005-01-19 14:54 ` Kumar Gala 2005-01-19 15:08 ` Geert Uytterhoeven 2005-01-19 15:15 ` Kumar Gala 2005-01-19 15:27 ` Geert Uytterhoeven 2005-01-19 23:25 ` Benjamin Herrenschmidt 2005-01-20 7:40 ` [Lists-linux-kernel-news] " Jon Masters 2005-01-19 18:07 ` Jon Masters 2005-01-19 23:22 ` Benjamin Herrenschmidt 2005-01-23 11:17 ` Sven Luther
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).