[PATCH] Summit support for 2.5 [0/4]

[PATCH] Summit support for 2.5 [0/4]

[Martin J. Bligh]

This set of 4 patches puts in the core support for the Summit chipset
used by IBM x440 machines - this is a major new platform for IBM, and
we'd really like to have it supported in 2.6 ... the changes are actually
pretty small, it keys off a lot of the same stuff as the NUMA-Q.

I've taken James Cleverdon's patches (he did all the hard work on this)
and split it into bite-sized chunks, where each patch is small, confined
and (IMHO) easily readable, and it should be easy to see it won't break
anything else. 

I've dropped some cleanup work that he did - you seem to like that seperate 
from features, and I agree ... it's much easier to read the patches like this.
I will invest some serious effort and time in cleanup after the feature freeze,
including investigating using the subarch support which I know some people
would like to see done.

I've also tested these on a standard desktop PC, a standard 4-way SMP box,
and a 16-way NUMA-Q (against 2.5.42). No problems found.

Please apply!

Thanks,

Martin.

Re: [PATCH] Summit support for 2.5 [0/4]

[Greg KH]

On Sun, Oct 13, 2002 at 01:41:41PM -0700, Martin J. Bligh wrote:
> I will invest some serious effort and time in cleanup after the feature freeze,
> including investigating using the subarch support which I know some people
> would like to see done.

Any reason why most of these changes couldn't be moved to the subarch
code now?

thanks,

greg k-h

Re: [PATCH] Summit support for 2.5 [0/4]

[Martin J. Bligh]

>> I will invest some serious effort and time in cleanup after the feature freeze,
>> including investigating using the subarch support which I know some people
>> would like to see done.
> 
> Any reason why most of these changes couldn't be moved to the subarch
> code now?

1. Time
2. It'd make the patches much bigger and harder to read.

I *will* do that. Just not in time for the freeze. IMHO, that's a cleanup (and yes,
a needed one).

M.

Re: [PATCH] Summit support for 2.5 [0/4]

[Greg KH]

On Sun, Oct 13, 2002 at 02:06:15PM -0700, Martin J. Bligh wrote:
> >> I will invest some serious effort and time in cleanup after the feature freeze,
> >> including investigating using the subarch support which I know some people
> >> would like to see done.
> > 
> > Any reason why most of these changes couldn't be moved to the subarch
> > code now?
> 
> 1. Time
> 2. It'd make the patches much bigger and harder to read.
> 
> I *will* do that. Just not in time for the freeze. IMHO, that's a cleanup (and yes,
> a needed one).

Hm, IMVHO I think this should be done correctly, as a subarch, instead
of just patches (although your patches are split up very nicely, good
job, that couldn't have been very easy.)  I don't know if "Time" is a
good excuse to put things like this in the tree, in the format that it
shouldn't be.

But as I'm not the i386 maintainer, I'll let Linus decide that one :)

thanks,

greg k-h

Re: [PATCH] Summit support for 2.5 [0/4]

[Dave Jones]

On Sun, Oct 13, 2002 at 02:17:40PM -0700, Greg KH wrote:

 > > I *will* do that. Just not in time for the freeze. IMHO, that's a cleanup (and yes,
 > > a needed one).
 > 
 > Hm, IMVHO I think this should be done correctly, as a subarch, instead
 > of just patches (although your patches are split up very nicely, good
 > job, that couldn't have been very easy.)  I don't know if "Time" is a
 > good excuse to put things like this in the tree, in the format that it
 > shouldn't be.
 > 
 > But as I'm not the i386 maintainer, I'll let Linus decide that one :)

If half-arsed stuff is going to get merged just to beat the freeze,
maybe it should go in with the constraint "get it cleaned by xxx
or it gets dropped".

Personally, I agree with Greg, and that it should get fixed up
_before_ the freeze. Fixing this up to work with subarch's shouldn't
take *that* long, and there's *counts* a whole week remaining before
Linus goes on hols 8-)

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: [PATCH] Summit support for 2.5 [0/4]

[Linus Torvalds]

On Sun, 13 Oct 2002, Martin J. Bligh wrote:
> 1. Time
> 2. It'd make the patches much bigger and harder to read.

Hmm.. I'd actually rather have the code split up in the proper location,
even if it would mean that summit support wouldn't work (or even
necessarily compile) by the feature-freeze.

		Linus

Re: [PATCH] Summit support for 2.5 [0/4]

[Martin J. Bligh]

> On Sun, 13 Oct 2002, Martin J. Bligh wrote:
>> 1. Time
>> 2. It'd make the patches much bigger and harder to read.
> 
> Hmm.. I'd actually rather have the code split up in the proper location,
> even if it would mean that summit support wouldn't work (or even
> necessarily compile) by the feature-freeze.

OK. Having looked at this, it actuallly looks easy enough, and
cleaner if I can just stick to the Summit stuff for now. The
patches will actually be smaller, and the only disadvantage seems
to be that I'll end up with less hair ;-) 

Below is a brief proof-of-concept I did, please cluebat me now if 
this isn't the type of thing you want before I burn hours and blood 
pressure fixing up the rest of it.

Consider me "re-aligned" ;-)

M.

PS. This distros want Summit to autodetect for their install kernels,
which is what the x86_summit switch is for.

------------

diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/Config.help subarch-1/arch/i386/Config.help
--- virgin/arch/i386/Config.help	Fri Oct 11 21:21:31 2002
+++ subarch-1/arch/i386/Config.help	Sun Oct 13 18:40:30 2002
@@ -73,6 +73,12 @@ CONFIG_X86_CYCLONE
   If you are suffering from time skew using a multi-CEC system, say YES.
   Otherwise it is safe to say NO.
 
+CONFIG_X86_SUMMIT
+  This option is needed for IBM systems that use the Summit/EXA chipset.
+  In particular, it is needed for the x440.
+
+  If you don't have one of these computers, you should say N here.
+
 CONFIG_X86_UP_IOAPIC
   An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an
   SMP-capable replacement for PC-style interrupt controllers. Most
diff -urpN -X
/home/fletch/.diff.exclude virgin/arch/i386/Makefile subarch-1/arch/i386/Makefile
--- virgin/arch/i386/Makefile	Fri Oct 11 21:21:39 2002
+++ subarch-1/arch/i386/Makefile	Sun Oct 13 17:54:32 2002
@@ -46,7 +46,11 @@ CFLAGS += $(cflags-y)
 ifdef CONFIG_VISWS
 MACHINE	:= mach-visws
 else
-MACHINE	:= mach-generic
+ ifdef CONFIG_X86_SUMMIT
+  MACHINE	:= mach-summit
+ else
+  MACHINE	:= mach-generic
+ endif
 endif
 
 HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/config.in subarch-1/arch/i386/config.in
--- virgin/arch/i386/config.in	Fri Oct 11 21:21:38 2002
+++ subarch-1/arch/i386/config.in	Sun Oct 13 18:40:30 2002
@@ -172,7 +172,8 @@ else
   if [ "$CONFIG_X86_NUMA" = "y" ]; then

#Platform Choices
      bool 'Multiquad (IBM/Sequent) NUMAQ support' CONFIG_X86_NUMAQ
-     if [ "$CONFIG_X86_NUMAQ" = "y" ]; then
+     bool 'IBM x440 (Summit/EXA) support' CONFIG_X86_SUMMIT
+     if [ "$CONFIG_X86_NUMAQ" = "y" -o "$CONFIG_X86_SUMMIT" = "y" ]; then
         define_bool CONFIG_CLUSTERED_APIC y
      fi
      # Common NUMA Features
diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/kernel/apic.c subarch-1/arch/i386/kernel/apic.c
--- virgin/arch/i386/kernel/apic.c	Fri Oct 11 21:22:46 2002
+++ subarch-1/arch/i386/kernel/apic.c	Sun Oct 13 18:34:45 2002
@@ -31,6 +31,7 @@
 #include <asm/pgalloc.h>
 #include <asm/desc.h>
 #include <asm/arch_hooks.h>
+#include "mach_apic.h"
 
 void __init apic_intr_init(void)
 {
@@ -328,15 +329,13 @@
void __init setup_local_APIC (void)
 		 * Put the APIC into flat delivery mode.
 		 * Must be "all ones" explicitly for 82489DX.
 		 */
-		apic_write_around(APIC_DFR, 0xffffffff);
+		apic_write_around(APIC_DFR, APIC_DFR_VALUE);
 
 		/*
 		 * Set up the logical destination ID.
 		 */
 		value = apic_read(APIC_LDR);
-		value &= ~APIC_LDR_MASK;
-		value |= (1<<(smp_processor_id()+24));
-		apic_write_around(APIC_LDR, value);
+		apic_write_around(APIC_LDR, calculate_ldr(value));
 	}
 
 	/*
diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/kernel/io_apic.c subarch-1/arch/i386/kernel/io_apic.c
--- virgin/arch/i386/kernel/io_apic.c	Fri Oct 11 21:21:38 2002
+++ subarch-1/arch/i386/kernel/io_apic.c	Sun Oct 13 18:33:53 2002
@@ -35,6 +35,7 @@
 #include
<asm/io.h>
 #include <asm/smp.h>
 #include <asm/desc.h>
+#include "mach_apic.h"
 
 #undef APIC_LOCKUP_DEBUG
 
diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/mach-generic/mach_apic.h subarch-1/arch/i386/mach-generic/mach_apic.h
--- virgin/arch/i386/mach-generic/mach_apic.h	Wed Dec 31 16:00:00 1969
+++ subarch-1/arch/i386/mach-generic/mach_apic.h	Sun Oct 13 18:29:40 2002
@@ -0,0 +1,20 @@
+#ifndef __ASM_MACH_APICDEF_H
+#define __ASM_MACH_APICDEF_H
+
+static inline unsigned long calculate_ldr(unsigned long old)
+{
+	unsigned long id;
+
+	id = 1UL << smp_processor_id();
+	return ((old & ~APIC_LDR_MASK) | SET_APIC_LOGICAL_ID(id));
+}
+
+#define APIC_DFR_VALUE	(APIC_DFR_FLAT)
+
+#ifdef CONFIG_SMP
+ #define TARGET_CPUS (clustered_apic_mode ? 0xf
: cpu_online_map)
+#else
+ #define TARGET_CPUS 0x01
+#endif
+
+#endif /* __ASM_MACH_APICDEF_H */
diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/mach-summit/mach_apic.h subarch-1/arch/i386/mach-summit/mach_apic.h
--- virgin/arch/i386/mach-summit/mach_apic.h	Wed Dec 31 16:00:00 1969
+++ subarch-1/arch/i386/mach-summit/mach_apic.h	Sun Oct 13 18:14:32 2002
@@ -0,0 +1,20 @@
+#ifndef __ASM_MACH_APICDEF_H
+#define __ASM_MACH_APICDEF_H
+
+extern int x86_summit;
+
+static inline unsigned long calculate_ldr(unsigned long old)
+{
+	unsigned long id;
+
+	if (x86_summit)
+		id = xapic_phys_to_log_apicid(hard_smp_processor_id());
+	else
+		id = 1UL << smp_processor_id();
+	return ((old & ~APIC_LDR_MASK) | SET_APIC_LOGICAL_ID(id));
+}
+
+#define
APIC_DFR_VALUE	(x86_summit ? APIC_DFR_CLUSTER : APIC_DFR_FLAT)
+#define TARGET_CPUS	(x86_summit ? XAPIC_DEST_CPUS_MASK : cpu_online_map)
+
+#endif /* __ASM_MACH_APICDEF_H */
diff -urpN -X /home/fletch/.diff.exclude virgin/include/asm-i386/apicdef.h subarch-1/include/asm-i386/apicdef.h
--- virgin/include/asm-i386/apicdef.h	Fri Oct 11 21:22:09 2002
+++ subarch-1/include/asm-i386/apicdef.h	Sun Oct 13 18:40:30 2002
@@ -32,6 +32,8 @@
 #define			SET_APIC_LOGICAL_ID(x)	(((x)<<24))
 #define			APIC_ALL_CPUS		0xFF
 #define		APIC_DFR	0xE0
+#define			APIC_DFR_CLUSTER		0x0FFFFFFFul
+#define			APIC_DFR_FLAT			0xFFFFFFFFul
 #define		APIC_SPIV	0xF0
 #define			APIC_SPIV_FOCUS_DISABLED	(1<<9)
 #define			APIC_SPIV_APIC_ENABLED		(1<<8)
diff -urpN -X
/home/fletch/.diff.exclude virgin/include/asm-i386/smp.h subarch-1/include/asm-i386/smp.h
--- virgin/include/asm-i386/smp.h	Fri Oct 11 21:22:09 2002
+++ subarch-1/include/asm-i386/smp.h	Sun Oct 13 18:31:05 2002
@@ -21,17 +21,10 @@
 #endif
 #endif
 
-#ifdef CONFIG_SMP
-# ifdef CONFIG_CLUSTERED_APIC
-#  define TARGET_CPUS 0xf     /* all CPUs in *THIS* quad */
-#  define INT_DELIVERY_MODE 0     /* physical delivery on LOCAL quad */
-# else
-#  define TARGET_CPUS cpu_online_map
-#  define INT_DELIVERY_MODE 1     /* logical delivery broadcast to all procs */
-# endif
+#ifdef CONFIG_CLUSTERED_APIC
+ #define INT_DELIVERY_MODE 0     /* physical delivery on LOCAL quad */
 #else
-# define INT_DELIVERY_MODE 1     /* logical delivery */
-# define TARGET_CPUS
0x01
+ #define INT_DELIVERY_MODE 1     /* logical delivery broadcast to all procs */
 #endif
 
 #ifndef clustered_apic_mode

Re: [PATCH] Summit support for 2.5 [0/4]

[Greg KH]

On Sun, Oct 13, 2002 at 07:02:18PM -0700, Martin J. Bligh wrote:
> 
> PS. This distros want Summit to autodetect for their install kernels,
> which is what the x86_summit switch is for.

Why?  Can't summit boot just fine on a i386 UP kernel?  Then they can
look at the chipset id and determine that they should install a
summit-built kernel, right?

> diff -urpN -X /home/fletch/.diff.exclude virgin/arch/i386/Config.help subarch-1/arch/i386/Config.help
> --- virgin/arch/i386/Config.help	Fri Oct 11 21:21:31 2002
> +++ subarch-1/arch/i386/Config.help	Sun Oct 13 18:40:30 2002
> @@ -73,6 +73,12 @@ CONFIG_X86_CYCLONE
>    If you are suffering from time skew using a multi-CEC system, say YES.
>    Otherwise it is safe to say NO.
>  
> +CONFIG_X86_SUMMIT

Can this just be CONFIG_SUMMIT?  I think most of these fixes need to be
around for the ia64 version too :(

> /home/fletch/.diff.exclude virgin/arch/i386/Makefile subarch-1/arch/i386/Makefile
> --- virgin/arch/i386/Makefile	Fri Oct 11 21:21:39 2002
> +++ subarch-1/arch/i386/Makefile	Sun Oct 13 17:54:32 2002
> @@ -46,7 +46,11 @@ CFLAGS += $(cflags-y)
>  ifdef CONFIG_VISWS
>  MACHINE	:= mach-visws
>  else
> -MACHINE	:= mach-generic
> + ifdef CONFIG_X86_SUMMIT
> +  MACHINE	:= mach-summit
> + else
> +  MACHINE	:= mach-generic
> + endif
>  endif

As we're going to end up with a mess of a ifdef nest over time with new
archs added, how about something like this (completly untested):


--- 1.12/arch/i386/Makefile	Fri Oct 11 14:22:55 2002
+++ edited/Makefile	Sun Oct 13 19:26:18 2002
@@ -43,10 +43,14 @@
 
 CFLAGS += $(cflags-y)
 
-ifdef CONFIG_VISWS
-MACHINE	:= mach-visws
-else
-MACHINE	:= mach-generic
+MACHINE	= mach-generic
+
+ifeq ($(CONFIG_VISWS),y)
+MACHINE	= mach-visws
+endif
+
+ifeq ($(CONFIG_SUMMIT),y)
+MACHINE	= mach-summit
 endif
 
 HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o


Can make handle reassigning a variable?

Other than that, looks like a good start to me (oh your email client is
wrapping lines of the patch...)

thanks,

greg k-h

Re: [PATCH] Summit support for 2.5 [0/4]

[Kai Germaschewski]

On Sun, 13 Oct 2002, Greg KH wrote:

> +ifeq ($(CONFIG_SUMMIT),y)
> +MACHINE	= mach-summit
>  endif
>  
> Can make handle reassigning a variable?

Sure.

You could even do

	machine-y 			:= mach-generic
	machine-$(CONFIG_SUMMIT)	:= mach-summit
	...
	MACHINE				:= $(machine-y)

--Kai

Re: [PATCH] Summit support for 2.5 [0/4]

[Greg KH]

On Sun, Oct 13, 2002 at 09:49:33PM -0500, Kai Germaschewski wrote:
> On Sun, 13 Oct 2002, Greg KH wrote:
> 
> > +ifeq ($(CONFIG_SUMMIT),y)
> > +MACHINE	= mach-summit
> >  endif
> >  
> > Can make handle reassigning a variable?
> 
> Sure.
> 
> You could even do
> 
> 	machine-y 			:= mach-generic
> 	machine-$(CONFIG_SUMMIT)	:= mach-summit
> 	...
> 	MACHINE				:= $(machine-y)

Oooh, nice.  You might want to go fix up arch/arm/Makefile, as that's
where I took my above example from :)

thanks,

greg k-h

Re: [PATCH] Summit support for 2.5 [0/4]

[Martin J. Bligh]

>> PS. This distros want Summit to autodetect for their install kernels,
>> which is what the x86_summit switch is for.
> 
> Why?  Can't summit boot just fine on a i386 UP kernel?  Then they can
> look at the chipset id and determine that they should install a
> summit-built kernel, right?

Probably could, but that's what they asked for. Maybe they don't mean
install kernel, but just running kernel in general. I presume they
don't want to maintain a seperate kernel just for Summit.
 
> Can this just be CONFIG_SUMMIT?  I think most of these fixes need to be
> around for the ia64 version too :(

Nope, this is all under the i386 arch tree. ia64 can do what they
please, as far as I'm concerned.

> As we're going to end up with a mess of a ifdef nest over time with new
> archs added, how about something like this (completly untested):

Yeah, that was a quick hack by some idiot who doesn't speak much make ;-)
I'll steal Kai's thing from later in this thread.

> Other than that, looks like a good start to me (oh your email client is
> wrapping lines of the patch...)

Yeah, home email is borked for that, sorry. I'll do it properly when I
submit it.

M.

Re: [PATCH] Summit support for 2.5 [0/4]

[Eric W. Biederman]

Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> writes:

> On Sun, 13 Oct 2002, Greg KH wrote:
> 
> > +ifeq ($(CONFIG_SUMMIT),y)
> > +MACHINE	= mach-summit
> >  endif
> >  
> > Can make handle reassigning a variable?
> 
> Sure.
> 
> You could even do
> 
> 	machine-y 			:= mach-generic
> 	machine-$(CONFIG_SUMMIT)	:= mach-summit
> 	...
> 	MACHINE				:= $(machine-y)

Cool.  With a setup that clean I think I can break the multiple firmware
code out easily as well.

        firmware-y			:= firmware-pcbios
        firmware-$(CONFIG_LINUXBIOS)	:= firmware-linuxbios
        ...
        FIRMWARE			:= $(firmware-y)

I had it broken out cleanly earlier, but everyone was concentrating
on other things and I just haven't been able to get back to that
stuff until this week.  It will be a little tight coming in under
the wire with working code but we will see.

Unless someone has some objections...

Eric