Summit support for 2.5 [0/4]
PATCH 1/1 Summit support for 2.5 [0/4]
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.
Quoted 3 lines · 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?
thanks,
greg k-h
Quoted 6 lines
Quoted 3 lines
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.
Quoted 4 lines · Martin J. Bligh
Quoted 4 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 2 lines
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
Quoted 10 lines · Greg KH
Quoted 2 lines
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
Signature · 1 line
| Dave Jones. http://www.codemonkey.org.uk
Quoted 2 lines · Martin J. Bligh
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
Quoted 7 lines · Martin J. Bligh
Quoted 2 lines
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.
------------
arch/i386/Config.help +6 -0
@@ -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
arch/i386/Makefile +5 -1
@@ -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
arch/i386/config.in +0 -0
@@ -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
arch/i386/kernel/apic.c +1 -0
@@ -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));
}
/*
arch/i386/kernel/io_apic.c +0 -0
@@ -35,6 +35,7 @@ #include
<asm/io.h>
#include <asm/smp.h>
#include <asm/desc.h>
+#include "mach_apic.h"
#undef APIC_LOCKUP_DEBUG
arch/i386/mach-generic/mach_apic.h +15 -0
@@ -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 */
arch/i386/mach-summit/mach_apic.h +17 -0
@@ -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 */
include/asm-i386/apicdef.h +2 -0
@@ -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
include/asm-i386/smp.h +2 -10
@@ -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
Quoted 3 lines · Martin J. Bligh
PS. This distros want Summit to autodetect for their install kernels, which is what the
x86_summitswitch 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?
arch/i386/Config.help CONFIG_X86_CYCLONE · line 76
Quoted 8 lines
diff -urpN -X
/home/fletch/.diff.excludevirgin/arch/i386/Config.help subarch-1/arch/i386/Config.helparch/i386/Config.help +1
-0@@ -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 :(
Quoted 4 lines
/home/fletch/.diff.excludevirgin/arch/i386/Makefile subarch-1/arch/i386/Makefile
arch/i386/Makefile CFLAGS += $(cflags-y) · line 54
Quoted 10 lines
arch/i386/Makefile +5
-1@@ -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):
Makefile renamed from arch/i386/Makefile +8 -4
@@ -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
Quoted 5 lines · Greg KH
Makefile renamed from arch/i386/Makefile +2
-0+ifeq ($(CONFIG_SUMMIT),y) +MACHINE = mach-summit endifCan make handle reassigning a variable?
Sure.
You could even do
machine-y := mach-generic machine-$(CONFIG_SUMMIT) := mach-summit ... MACHINE := $(machine-y)
--Kai
Quoted 10 lines · Kai Germaschewski
Quoted 5 lines · Greg KH
Makefile renamed from arch/i386/Makefile +2
-0+ifeq ($(CONFIG_SUMMIT),y) +MACHINE = mach-summit endifCan make handle reassigning a variable?
Sure.
Quoted 6 lines
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
Quoted 10 lines · Kai Germaschewski
Quoted 5 lines · Greg KH
Makefile renamed from arch/i386/Makefile +2
-0+ifeq ($(CONFIG_SUMMIT),y) +MACHINE = mach-summit endifCan make handle reassigning a variable?
Sure.
Quoted 6 lines
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
Quoted 6 lines
Quoted 2 lines
PS. This distros want Summit to autodetect for their install kernels, which is what the
x86_summitswitch 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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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.