+ /*
+ * Switch to Physical destination mode in case of generic
+ * more than 8 CPU system, which has xAPIC support
+ */
+#define FLAT_APIC_CPU_MAX 8
+ if ((clustered_apic_mode == CLUSTERED_APIC_NONE) &&
+ (xapic_support) &&
+ (num_processors > FLAT_APIC_CPU_MAX)) {
+ clustered_apic_mode = CLUSTERED_APIC_XAPIC;
+ apic_broadcast_id = APIC_BROADCAST_ID_XAPIC;
+ int_dest_addr_mode = APIC_DEST_PHYSICAL;
+ int_delivery_mode = dest_Fixed;
+ esr_disable = 1;
+ }
+#endif
+
Venkatesh,
I could not find the definition for CLUSTERED_APIC_NONE. Is this an attempt
to set up the clustered mode right in case if it was not compiled with
CLUSTERED_..._XAPIC on the system with > 8 cpu?
>There is already some code in base that does this. For NUMAQ specifically
>this check happens and clustered mode is selected for APIC. My patch has
this
>additinal check (after the initial IBM OEM check), for non-NUMAQ systems
with
>more than 8 CPUs and xAPIC support. These systems can not work with the
>default flat addressing mode. So, this patch sets up such systems in
physical
>mode.
In the systems like ES7000, all CPU (up to 32) and IO-APICs have 8-bit
hard-wired ID's according to their topological position. Therefore, the
apic_broadcast_id be has to be 0xFF (like summit's, I guess), and modes
should be clustered logical for Cascades, clustered physical for xAPIC. The
IO-APIC lines are programmed with the broadcast ID/lowest priority for
Cascades, and boot CPU ID/XTPR flag/Lowest priority for Fosters/Gallatins.
This is pretty much the only choices we have. If this is not what the patch
allows to do, we need a last chance architectural hook to be able to
accommodate our stuff.
Thanks,
--Natalie
>Thanks,
>-Venkatesh
-
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/
This archive was generated by hypermail 2b29 : Mon Dec 23 2002 - 22:00:32 EST