- 17 Apr, 2008 40 commits
-
-
Glauber de Oliveira Costa authored
it is redundant, since it is already done by set_cpu_sibling_map() Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
this does not exist, so it will be an empty macro Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
With this, remove its late_initcall marker from nmi_32.c Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Two more files goes away. nmi_64.h and nmi_32.h gives birth to nmi.h Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
use mach_traps when it is supposed to be used. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
By this time, they are already set in init routines Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
We move it to apic_32.c, since it's irq related anyway, and only called from that file. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
We do it and also fix conflicts, which makes x86_64 automatically closer to i386 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Do it and also fix conflicts, which automatically makes x86_64 look closer to i386 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
this patch allows x86_64 to use subarch mach_ headers in practice, since x86_64 does not have any subarch, it will use mach_default. But it will allow for substantially less code duplication Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
the cpu count is changed accordingly: now, what matters is online cpus. Also, we add those functions for x86_64 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
It will ease integration for x86_64 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Impressing friends is a very important thing. Do it in a separate function to make it even more explicit, and ease integration. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
weighting a map will do. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
This is the way x86_64 does, and complement the already present patch that does the bios cpu to apicid mapping here Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
We fill the per-cpu (or array) that maps bios cpu id to apicid in mpparse_32.c, the way x86_64 does Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
We use the same routing as x86_64, moved now to setup.c. Just with a few ifdefs inside. Note that this routing uses prefill_possible_map(). It has the very nice side effect of allowing hotplugging of cpus that are marked as present but disabled by acpi bios. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
missing a semicolon Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Instead of declaring them inside of X86_64 ifdef, do it unconditionally Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
this will serve as a reference as to whether or not to use the per_cpu variables in mpparse. Done the same way as x86_64 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
This mapping already exists in x86_64, just provide it for i386 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
take them off smp_{32,64}.h and move to smp.h Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Done to match x86_64 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
We have already removed the only condition that could fail here. so just don't test for any return value Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Do tests before do_boot_cpu in native_cpu_up for i386. Tests are a little bit broader than originally, and are the same as x86_64. Test for smp_callin is not applicable right now and is deferred. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Put it in a disable_smp() function, as x86_64 does Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Isolate all sanity checking in a smp_sanity_check() function as x86_64 does. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
goal is to have i386 and x86_64 closer, so we add barriers to match Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
This patch does not change the behaviour of x86_64, since APIC_INTEGRATED is always defined as (1). But the code now matches exactly i386 version (well, this part of the code, at least) Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
it is always integrated, so define as 1. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
it does not need to be inside lock. Do the way i386 does. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
This is done so we call setup_secondary_clock() in the same place x86_64 does. A separate patch for this is appearantly not needed. But clock initialization is such a delicate thing, that it's safer to do this way Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
the call to idle is guaranteed to do it. Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
This matches x86_64 behaviour, which is a superior one IMHO Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
now that it is the same between arches, put it into smpboot.c Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Call it conditionally for secondary cpus. This behaviour matches i386 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
Call this function instead of identify_cpu in bugs_64.c Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
provide two specialized identify_secondary_cpu() and identify_boot_cpu() routines for x86_64. Although not strictly needed, they are functionally correct, and will ease integration with i386 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Glauber de Oliveira Costa authored
This will ease integration with i386 Signed-off-by: Glauber Costa <gcosta@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-