Patches for 2.6.15

If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
they would like to see go upstream now that 2.6.14 is out, other than
patches that are already in the powerpc-merge tree, please let me
know.  I am planning to ask Linus to pull the powerpc-merge tree
shortly, and that will probably break your patches.

I think the merge tree is looking pretty good, although the merge is
by no means complete yet.  The powermac, pseries and iseries platforms
seem to be working fine with ARCH=powerpc.  32-bit chrp is mostly
there but needs a bit more work.

If possible, I'd like to get to the point where we can remove
arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.

Paul.

Paul Mackerras wrote:

If possible, I'd like to get to the point where we can remove
arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.

I haven't been following this seriously, so forgive me if this has 
already been asked.

Under the unified architecture, what is the machine type in the "uname" 
outout?

Chris

"Christopher Friesen" [off-list ref] writes:

Under the unified architecture, what is the machine type in the "uname" 
outout?

I don't think that should change in any way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

On Oct 28, 2005, at 11:00 AM, Christopher Friesen wrote:

Paul Mackerras wrote:

quoted

If possible, I'd like to get to the point where we can remove
arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.

I haven't been following this seriously, so forgive me if this has  
already been asked.

Under the unified architecture, what is the machine type in the  
"uname" outout?

When building the merge tree for a 32-bit cpu uname spits out:

Linux fred 2.6.14-rc5-g278144ed #9 Thu Oct 27 09:20:01 CDT 2005 ppc  
unknown


- kumar

Christopher Friesen writes:

Under the unified architecture, what is the machine type in the "uname" 
outout?

"ppc" on 32-bit machines, "ppc64" on 64-bit machines, same as before.

The intention is that the merge doesn't change the user/kernel ABI in
any way. :)

Paul.

On Oct 28, 2005, at 8:05 AM, Paul Mackerras wrote:

If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
they would like to see go upstream now that 2.6.14 is out, other than
patches that are already in the powerpc-merge tree, please let me
know.  I am planning to ask Linus to pull the powerpc-merge tree
shortly, and that will probably break your patches.

I think the merge tree is looking pretty good, although the merge is
by no means complete yet.  The powermac, pseries and iseries platforms
seem to be working fine with ARCH=powerpc.  32-bit chrp is mostly
there but needs a bit more work.

If possible, I'd like to get to the point where we can remove
arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.

Can you merge this in:

http://patchwork.ozlabs.org/linuxppc/patch?id=2931

- kumar

On Fri, 28 Oct 2005 13:49:26 -0500 Kumar Gala [off-list ref] wrote:

Can you merge this in:

http://patchwork.ozlabs.org/linuxppc/patch?id=2931

I can't find any use of mpc85xx_show_cpuinfo.  Is there something subtle here?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

On Sat, 29 Oct 2005, Stephen Rothwell wrote:

On Fri, 28 Oct 2005 13:49:26 -0500 Kumar Gala [off-list ref] wrote:

quoted

Can you merge this in:

http://patchwork.ozlabs.org/linuxppc/patch?id=2931

I can't find any use of mpc85xx_show_cpuinfo.  Is there something subtle here?

No, you are correct.  This was a bogus decleration before.  I will kill 
it and resend the patch.

- kumar

Kumar Gala writes:

Can you merge this in:

http://patchwork.ozlabs.org/linuxppc/patch?id=2931

Having the same extern declaration in several C files raises a red
flag.  Could we have that in a suitable header file instead please?

Paul.

On Freedag 28 Oktober 2005 15:05, Paul Mackerras wrote:

If anyone has patches for arch/ppc{,64} and include/asm-ppc{,64} that
they would like to see go upstream now that 2.6.14 is out, other than
patches that are already in the powerpc-merge tree, please let me
know. =A0I am planning to ask Linus to pull the powerpc-merge tree
shortly, and that will probably break your patches.

Out of my spufs patches, I'd like to have at least the reservation
for my two system call numbers in there so we don't get any conflicts
on that front. The patch follows in another mail.

=46rom my point of view, the spufs itself could go in at this point,
but I have the feeling that the real concerns from other people
will come up at the moment that I post them for inclusion.=20

Andrew, are you ok with including spufs in -mm when the merge
tree is upstream?

If possible, I'd like to get to the point where we can remove
arch/ppc64 entirely by the end of the 2-week merge window for 2.6.15.

Ok, I'll do a new patch to move over the BPA files then to get
my stuff out of the way ASAP.

	Arnd <><

This creates two powerpc specific dummy system calls that will
later be used on the Cell platform to manage SPUs.

Reserve the system call numbers now so we don't accidentally
use the same numbers for different system calls.

Signed-off-by: Arnd Bergmann <redacted>

---
Please apply to merge tree

--- a/kernel/sys_ni.c	2005-10-29 00:46:21.000000000 +0200
+++ b/kernel/sys_ni.c	2005-10-29 00:47:37.000000000 +0200

@@ -90,3 +90,5 @@
 cond_syscall(sys32_ipc);
 cond_syscall(sys32_sysctl);
 cond_syscall(ppc_rtas);
+cond_syscall(sys_spu_run);
+cond_syscall(sys_spu_create);
--- a/arch/powerpc/kernel/systbl.S	2005-10-29 00:39:49.000000000 +0200
+++ b/arch/powerpc/kernel/systbl.S	2005-10-29 00:44:48.000000000 +0200

@@ -319,3 +319,5 @@
 SYSCALL(inotify_init)
 SYSCALL(inotify_add_watch)
 SYSCALL(inotify_rm_watch)
+SYSCALL(spu_run)
+SYSCALL(spu_create)
--- a/include/asm-powerpc/unistd.h	2005-10-29 00:34:40.000000000 +0200
+++ b/include/asm-powerpc/unistd.h	2005-10-29 00:35:52.000000000 +0200

@@ -297,7 +297,9 @@
 #define __NR_inotify_add_watch	276
 #define __NR_inotify_rm_watch	277

-#define __NR_syscalls		278
+#define __NR_spu_run		278
+#define __NR_spu_create		279
+#define __NR_syscalls		280
 
 #ifdef __KERNEL__
 #define __NR__exit __NR_exit

Arnd Bergmann [off-list ref] wrote:

Andrew, are you ok with including spufs in -mm when the merge
tree is upstream?

Probably.  I haven't paid much attention to them thus far, sorry.