cpu/x86/mp_init: reduce exposure of internal implementation

With all users converted to using the mp_ops callbacks there's
no need to expose that surface area. Therefore, keep it all
within the mp_init compilation unit.

Change-Id: Ia1cc5326c1fa5ffde86b90d805b8379f4e4f46cd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14598
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>

2 files changed, 75 insertions, 84 deletions

diff --git a/src/cpu/x86/mp_init.c b/src/cpu/x86/mp_init.c
index 362cda3bbd..b9084c789e 100644
--- a/src/cpu/x86/mp_init.c
+++ b/src/cpu/x86/mp_init.c
@@ -38,6 +38,57 @@
 #include <thread.h>
 
 #define MAX_APIC_IDS 256
+
+typedef void (*mp_callback_t)(void);
+
+/*
+ * A mp_flight_record details a sequence of calls for the APs to perform
+ * along with the BSP to coordinate sequencing. Each flight record either
+ * provides a barrier for each AP before calling the callback or the APs
+ * are allowed to perform the callback without waiting. Regardless, each
+ * record has the cpus_entered field incremented for each record. When
+ * the BSP observes that the cpus_entered matches the number of APs
+ * the bsp_call is called with bsp_arg and upon returning releases the
+ * barrier allowing the APs to make further progress.
+ *
+ * Note that ap_call() and bsp_call() can be NULL. In the NULL case the
+ * callback will just not be called.
+ */
+struct mp_flight_record {
+	atomic_t barrier;
+	atomic_t cpus_entered;
+	mp_callback_t ap_call;
+	mp_callback_t bsp_call;
+} __attribute__((aligned(CACHELINE_SIZE)));
+
+#define _MP_FLIGHT_RECORD(barrier_, ap_func_, bsp_func_) \
+	{							\
+		.barrier = ATOMIC_INIT(barrier_),		\
+		.cpus_entered = ATOMIC_INIT(0),			\
+		.ap_call = ap_func_,				\
+		.bsp_call = bsp_func_,				\
+	}
+
+#define MP_FR_BLOCK_APS(ap_func_, bsp_func_) \
+	_MP_FLIGHT_RECORD(0, ap_func_, bsp_func_)
+
+#define MP_FR_NOBLOCK_APS(ap_func_, bsp_func_) \
+	_MP_FLIGHT_RECORD(1, ap_func_, bsp_func_)
+
+/* The mp_params structure provides the arguments to the mp subsystem
+ * for bringing up APs. */
+struct mp_params {
+	int num_cpus; /* Total cpus include BSP */
+	int parallel_microcode_load;
+	const void *microcode_pointer;
+	/* adjust_apic_id() is called for every potential apic id in the
+	 * system up from 0 to CONFIG_MAX_CPUS. Return adjusted apic_id. */
+	int (*adjust_apic_id)(int index, int apic_id);
+	/* Flight plan  for APs and BSP. */
+	struct mp_flight_record *flight_plan;
+	int num_records;
+};
+
 /* This needs to match the layout in the .module_parametrs section. */
 struct sipi_params {
 	uint16_t gdtlimit;
@@ -514,7 +565,26 @@ static void init_bsp(struct bus *cpu_bus)
 	cpus[info->index].apic_id = cpu_path.apic.apic_id;
 }
 
-int mp_init(struct bus *cpu_bus, struct mp_params *p)
+/*
+ * mp_init() will set up the SIPI vector and bring up the APs according to
+ * mp_params. Each flight record will be executed according to the plan. Note
+ * that the MP infrastructure uses SMM default area without saving it. It's
+ * up to the chipset or mainboard to either e820 reserve this area or save this
+ * region prior to calling mp_init() and restoring it after mp_init returns.
+ *
+ * At the time mp_init() is called the MTRR MSRs are mirrored into APs then
+ * caching is enabled before running the flight plan.
+ *
+ * The MP initialization has the following properties:
+ * 1. APs are brought up in parallel.
+ * 2. The ordering of coreboot cpu number and APIC ids is not deterministic.
+ *    Therefore, one cannot rely on this property or the order of devices in
+ *    the device tree unless the chipset or mainboard know the APIC ids
+ *    a priori.
+ *
+ * mp_init() returns < 0 on error, 0 on success.
+ */
+static int mp_init(struct bus *cpu_bus, struct mp_params *p)
 {
 	int num_cpus;
 	int num_aps;
@@ -563,14 +633,16 @@ int mp_init(struct bus *cpu_bus, struct mp_params *p)
 	return bsp_do_flight_plan(p);
 }
 
-void mp_initialize_cpu(void)
+/* Calls cpu_initialize(info->index) which calls the coreboot CPU drivers. */
+static void mp_initialize_cpu(void)
 {
 	/* Call back into driver infrastructure for the AP initialization.   */
 	struct cpu_info *info = cpu_info();
 	cpu_initialize(info->index);
 }
 
-int mp_get_apic_id(int cpu_slot)
+/* Returns apic id for coreboot cpu number or < 0 on failure. */
+static int mp_get_apic_id(int cpu_slot)
 {
 	if (cpu_slot >= CONFIG_MAX_CPUS || cpu_slot < 0)
 		return -1;
diff --git a/src/include/cpu/x86/mp.h b/src/include/cpu/x86/mp.h
index ff88a20301..9742df08c1 100644
--- a/src/include/cpu/x86/mp.h
+++ b/src/include/cpu/x86/mp.h
@@ -29,56 +29,6 @@ static inline void mfence(void)
 	__asm__ __volatile__("mfence\t\n": : :"memory");
 }
 
-typedef void (*mp_callback_t)(void);
-
-/*
- * A mp_flight_record details a sequence of calls for the APs to perform
- * along with the BSP to coordinate sequencing. Each flight record either
- * provides a barrier for each AP before calling the callback or the APs
- * are allowed to perform the callback without waiting. Regardless, each
- * record has the cpus_entered field incremented for each record. When
- * the BSP observes that the cpus_entered matches the number of APs
- * the bsp_call is called with bsp_arg and upon returning releases the
- * barrier allowing the APs to make further progress.
- *
- * Note that ap_call() and bsp_call() can be NULL. In the NULL case the
- * callback will just not be called.
- */
-struct mp_flight_record {
-	atomic_t barrier;
-	atomic_t cpus_entered;
-	mp_callback_t ap_call;
-	mp_callback_t bsp_call;
-} __attribute__((aligned(CACHELINE_SIZE)));
-
-#define _MP_FLIGHT_RECORD(barrier_, ap_func_, bsp_func_) \
-	{							\
-		.barrier = ATOMIC_INIT(barrier_),		\
-		.cpus_entered = ATOMIC_INIT(0),			\
-		.ap_call = ap_func_,				\
-		.bsp_call = bsp_func_,				\
-	}
-
-#define MP_FR_BLOCK_APS(ap_func_, bsp_func_) \
-	_MP_FLIGHT_RECORD(0, ap_func_, bsp_func_)
-
-#define MP_FR_NOBLOCK_APS(ap_func_, bsp_func_) \
-	_MP_FLIGHT_RECORD(1, ap_func_, bsp_func_)
-
-/* The mp_params structure provides the arguments to the mp subsystem
- * for bringing up APs. */
-struct mp_params {
-	int num_cpus; /* Total cpus include BSP */
-	int parallel_microcode_load;
-	const void *microcode_pointer;
-	/* adjust_apic_id() is called for every potential apic id in the
-	 * system up from 0 to CONFIG_MAX_CPUS. Return adjusted apic_id. */
-	int (*adjust_apic_id)(int index, int apic_id);
-	/* Flight plan  for APs and BSP. */
-	struct mp_flight_record *flight_plan;
-	int num_records;
-};
-
 /* The sequence of the callbacks are in calling order. */
 struct mp_ops {
 	/*
@@ -175,37 +125,6 @@ struct mp_ops {
 int mp_init_with_smm(struct bus *cpu_bus, const struct mp_ops *mp_ops);
 
 /*
- * mp_init() will set up the SIPI vector and bring up the APs according to
- * mp_params. Each flight record will be executed according to the plan. Note
- * that the MP infrastructure uses SMM default area without saving it. It's
- * up to the chipset or mainboard to either e820 reserve this area or save this
- * region prior to calling mp_init() and restoring it after mp_init returns.
- *
- * At the time mp_init() is called the MTRR MSRs are mirrored into APs then
- * caching is enabled before running the flight plan.
- *
- * The MP initialization has the following properties:
- * 1. APs are brought up in parallel.
- * 2. The ordering of coreboot cpu number and APIC ids is not deterministic.
- *    Therefore, one cannot rely on this property or the order of devices in
- *    the device tree unless the chipset or mainboard know the APIC ids
- *    a priori.
- *
- * mp_init() returns < 0 on error, 0 on success.
- */
-int mp_init(struct bus *cpu_bus, struct mp_params *params);
-
-/*
- * Useful functions to use in flight records when sequencing APs.
- */
-
-/* Calls cpu_initialize(info->index) which calls the coreboot CPU drivers. */
-void mp_initialize_cpu(void);
-
-/* Returns apic id for coreboot cpu number or < 0 on failure. */
-int mp_get_apic_id(int cpu_slot);
-
-/*
  * SMM helpers to use with initializing CPUs.
  */