soc/intel_adsp: Add MP startup delay on cAVS 1.5
Investigation by Kai Vehmanen has shown that there is a very short
delay needed before starting the secondary core on cAVS 1.5 hardware.
What we finally realized is happening is that on these devices,
secondary core power is managed by the host. The cavs-fw.py test
integration powers the second core on at system startup and lets
Zephyr start it later, but SOF will power it up and send an IPC to the
firmware immediately.
There is a period after power-up but before the ROM is available
(unclear whether this is a race vs. hardware, the ROM firmware, or the
kernel driver, or potentially some combination); interrupts latched
earlier than that seem to be cleared by CPU initialization.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
diff --git a/soc/xtensa/intel_adsp/common/soc_mp.c b/soc/xtensa/intel_adsp/common/soc_mp.c
index 0944e0d..274372c 100644
--- a/soc/xtensa/intel_adsp/common/soc_mp.c
+++ b/soc/xtensa/intel_adsp/common/soc_mp.c
@@ -39,6 +39,8 @@
#define IDC_ALL_CORES (BIT(CONFIG_MP_NUM_CPUS) - 1)
+#define CAVS15_ROM_IDC_DELAY 500
+
struct cpustart_rec {
uint32_t cpu;
arch_cpustart_t fn;
@@ -264,6 +266,18 @@
{
uint32_t vecbase, curr_cpu = prid();
+ __ASSERT_NO_MSG(!cpus_active[cpu_num]);
+
+#ifdef CONFIG_SOC_SERIES_INTEL_CAVS_V15
+ /* On the older hardware, core power is managed by the host
+ * and aren't able to poll for anything to know it's
+ * available. Need a delay here so that the hardware and ROM
+ * firmware can complete initialization and be waiting for the
+ * IDC we're about to send.
+ */
+ k_busy_wait(CAVS15_ROM_IDC_DELAY);
+#endif
+
#ifdef CONFIG_SOC_SERIES_INTEL_CAVS_V25
/* On cAVS v2.5, MP startup works differently. The core has
* no ROM, and starts running immediately upon receipt of an
