Move and convert soc/xtensa/intel_adsp SoC family configurations
to HWMv2 with its SoC series:
`ace` (INTEL_ACE) and `cavs` (INTEL_ADSP_CAVS).
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
To un-block continuing of soc and board porting then move all socs and
boards which have not yet been ported to boards_legacy / soc_legacy
folders.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
Secondary dsp is idle and waiting for interrupt before it is totally
halted. The other active cores can trigger idc interrupt to this core,
this can wake it up and result to fw panic. Mask idc interrupt as timer
interrupt to prevent this case.
Signed-off-by: Rander Wang <rander.wang@intel.com>
Save secondary dsp context when it is powered off in idle thread
and restore it when the secondary dsp is powered up. The algorithm
is aligned with ace platform.
Tested on a tgl platform.
Signed-off-by: Rander Wang <rander.wang@intel.com>
Move runtime checks to use arch_num_cpus() and build checks
to use CONFIG_MP_MAX_NUM_CPUS. This is to allow runtime
determination of the number of CPUs in the future.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Change for loops of the form:
for (i = 0; i < CONFIG_MP_NUM_CPUS; i++)
...
to
unsigned int num_cpus = arch_num_cpus();
for (i = 0; i < num_cpus; i++)
...
We do the call outside of the for loop so that it only happens once,
rather than on every iteration.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Changes to code:
1. Renamed CAVS_IPC API from common/include/cavs_ipc.h to
common/include/intel_adsp_ipc.h. Renamed all API functions and structs -
added "intel_adsp_" prefix.
2. Moved definitions from intel-ipc-regs.h and ace-ipc-regs.g to SOC
specific headers include/<soc_name>/adsp_ipc_regs.h.
3. Added new common intel_adsp_ipc_devtree.h header with new
macros to retrieve IPC and IDC nodes and register addresses.
Put those new macros in code replacing hardcoded values outside of
devicetree.
4. Changed documentation of IDC and renamed IDC register struct
to have common name between all intel adsp socs.
5. Removed excessive docs description on cAVS IPC protocol.
Changes to Devicetree:
1. Renamed in all CAVS boards .dtsi files content in IPC nodes:
- "cavs_host_ipc" node labels to "adsp_ipc" labels.
- compatible "intel,cavs-host-ipc" renamed to
"intel,adsp-host-ipc".
2. Added (previously missing) yaml file for "intel,adsp-host-ipc"
compatible.
3. Renamed in all CAVS boards .dtsi files content in IDC nodes:
- "idc" node labels to "adsp_idc" labels.
- compatible "intel,cavs-idc" renamed to "intel-adsp-idc"
4. Renamed intel,cavs_idc.yaml file to intel,adsp_idc.yaml
so it is suitable for both CAVS and ACE SoC family.
Moved it from ipm bindings to ipc bindings where it belongs.
Changes to Kconfig:
1. Renamed existing Kconfig option CONFIG_CAVS_IPC to
INTEL_ADSP_IPC.
2. For renamed INTEL_ADSP_IPC addded default value based on
status of the "adsp-ipc" and "adsp-ipc" node.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
For intel adsp platforms we have a common multiprocessing.c file and
then another multiprocessing.c for ace and multiprocessing_cavs.c for
cavs. Rename the cavs specific implementation to follow the convention.
There is not need to "cavs" suffix since the file is already inside its
specific directory.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Inside the common directory there were files that are CAVS specific and
are not used by ACE_V1X. Lets create a subdir called cavs inside the
common to put files that are common for only cavs plaftorms.
Note that there are still remaining code that in the common folder that
are using cavs namespace like "cavs_ipc_*" that may need some additional
work.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Intel ADSP CAVS is now a proper series with all CAVS SoCs running under
it. This will give us to Intel ADSP series:
- CAVS
- ACE v1.x
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
using once single header to support multiple socs and product
generations is error prone and not easily maintained.
Over time we have been adding conditional code in headers and extending
structs to support new HW features which becomes a problem.
Goal is to keep platform headers in sync with hardware specification and
allow of introduction of new platforms and hardware features by just
introducing a new SoC with its own set of headers.
This is now just a copy of existing cavs-shim.h with slight changes,
goal is to clean this up long term and sync with hardware datasheets and
align on naming as well.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Do not duplicate code in new SoC and reuse code from intel_adsp/common.
Move SRAM code into own file in common code and setup SRAM in soc for
MTL platform.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Since the timer interrupt is delivered to all cores at the same
time, it needs to be disabled (or masked) to prevent it from
waking a suspended CPU core.
Note that there is no need to re-enable (unmask) timer
interrupt separately as it is being taken care of in
smp_timer_init() when the CPU re-inits itself.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
In order to bring consistency in-tree, migrate all soc code to the
new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Re-running the script that checks for the const qualifier missing on
ISR's parameter.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
On cAVS before 2.5, core power was controlled by the host. Add a
command to the cavstool.py script to allow us to do that under test
command so we can exercise multiprocessor startup/shutdown outside of
SOF.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Remove the soc_relaunch_cpu() API. There's now nothing that this does
that isn't already done by the kernel's own z_smp_start_cpu() API. We
don't need a SOC-level API for this anymore.
Rename soc_halt_cpu() to soc_adsp_halt_cpu() to clarify the domain,
simplify by removing the synchronization (there's nothing to
synchronize!). Also move its declaration and docs into the soc.h
header.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Things had gotten a little tangled in there so let's do some cleanup.
Remove the distressingly-special-purpose z_reinit_idle_thread() hook
(which existed to support secondary core bringup when
SMP_BOOT_DELAY=y), and just fold that into a generic z_init_cpu(),
which we can call in obvious and symmetric ways from main
initialization, z_smp_init(), and z_smp_start_cpu() (the now-official
programmatic hook for starting cpus).
Remove the "#if CONFIG_MP_NUM_CPUS > 1" exclusions. These weren't
saving any code size and were propagating themselves into platform
layers trying to avoid build failures.
There are some "special" APIs added for SOF which need to go away in
favor of the newer/generic z_smp_start_cpu(). Collect them in one
place and put them under a "#ifdef CONFIG_SOF" to prevent them from
being used in Zephyr apps.
Move some function declarations that didn't have homes into
<kernel/thread.h>.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This platform was stale for a long time and got a little left behind.
Basic OS stuff was working but secondary core bringup didn't. It has
a slightly different set of choices from the "weird hardware
quirks" menu:
+ Like cAVS 1.5, it boots from a ROM that needs a short delay after
power-up before it can receive the startup IDC.
+ But, like 2.5 and unlike 1.5, it doesn't start running until the
PWRCTL bit for the core gets set by DSP software (1.5 gets launched
by the host). So the delay needed to move down a bit.
+ It wants that PWRCTL bit to be set last, after CLKCTL enables the
clock. (Which makes sense I guess: EE classes always tell you hold
circuits in reset while an initial clock propagates). Not sure why
it was in the reverse order originally; this way works for
everything.
+ The ROM likes to scribble on the interrupt controller and mask its
own IDC interrupts after we've already set it up. They have to be
unmasked. We had code to do this already, thinking it was a
workaround for legecy SOF code (that we never actually located).
Now I'm thinking it was this behavior all along being detected by
SOF's more extensive hardware CI. Take out the test and do it
always, it's like nine instructions.
+ The host/loader-side behavior is a mix of 1.5 and 2.5. It won't
actually start the secondary cores under host command, but it does
need to see bits set for them in ADSPCS for the DSP-initiated
power-up to work (2.5 would just ignore all but core 0's bits).
+ Also, like 1.5, it needs the host DMA stream to be explicitly
stopped (and not just reset) or else further loads will be unstable.
Note that the loader changes now require more logic than just "1.5 or
not", so the platform detection has been enhanced to fully categorize
the device based on PCI ID (not quite: we don't have any 2.0 platform
hardware, so I left that alone for now).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Continue the previous work, moving the cAVS hardware dependencies into
a separate file, leaving soc_mp.c with only OS-generic details to
track.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Clean up soc_mp.c a bit. Put all cAVS register use in functions
dedicated to hardware details (e.g. "soc_start_core()"), leave the
Zephyr OS tracking (e.g. the CPU start record, the active cores array,
etc...) in generic code.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The MP startup code had a hardcoded INTLEVEL field of 5 in the initial
value of PS. That's needless, INTLEVEL is a full 4 bit field even if
the number of hardware interrupt levels is lower (and in fact 0xf is
the documented hardware reset state). Set that instead, so that this
code will work with any XEA2 hardware. This also matches the similar
code path in boot startup.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Now that we have access to IMR memory for non-bootloader tasks, let's
pick the low hanging fruit. SOC code that is only used at
initialization time (or things like core halt/restart which happen
only in non-realtime contexts) are now flagged __imr.
This is good for 808 bytes of code moved out of the main Zephyr image
on cavs_v25.
In the medium term, it would be good to define a system define for
this purpose (a-la Linux __init/__initdata) and start moving core
Zephyr init code too.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Startup on these devices was sort of a mess, with multiple variants of
Xtensa and platform initialization code from multiple ancestries being
invoked at different places for different purposes. Just use one code
path for everyone.
Bootloader entry starts with a minimal assembly stub that simply sets
WINDOW{START,BASE}, PS and a stack pointer and then jumps to C code.
That then uses the cpu_early_init() implementation from cAVS 2.5's
secondary cores to finish Xtensa initialization, and then flows
directly into the pre-existing bootloader C code to initialize cache
and memory and copy the HP-SRAM image, then it invokes Zephyr via a
simple C function call to z_cstart().
Likewise, remove the "reset vector" from Zephyr. This was never a
reset vector, reset on these devices goes to a fixed address in a ROM.
CPU initialization is handled explicitly and completely in the
bootloader now, in a way that can be unified between the main and
secondary cores. Entry from the bootloader now goes directly into
z_cstart() via a C call (via a single jump instruction placed at the
entry point address -- that's going away soon too once we're using a
unified link).
Now that vector table initialization happens in a uniform way, there's
no need to copy the VECBASE value during arch_start_cpu().
Finally note that this also reverts the
CONFIG_RESET_VECTOR_IN_BOOTLOADER kconfig variable added for these
platforms, because it's no longer a tunable and true always.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Move the very-early core initialization hooks (which are a mix of
Xtensa architectural features and Intel-specific hardwareisms) into a
separate header so they can be shared between the bootloader, main
core, and MP cores.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There is some legacy code that tries to mask IDC interrupts when
starting up cores. This is there because the IDC interrupt is both
the system IPI when Zephyr is running (and can thus be signaled
asynchronously to the code calling arch_start_cpu()) and the messaging
protocol to the boot ROM on the other CPU. So the idea is that we
mask interrupts after startup so nothing is confused.
But that's needless in the current architecture. We maintain a
synchronized cpus_active[] record that will show true/active for any
CPU between the end of its SMP startup sequence and the beginning of
the shutdown process in soc_halt_cpu(), and false at all other times.
An IPI will never be sent to a CPU that is running in the boot ROM,
because such a CPU will be flagged as inactive. Likewise a ROM
startup IDC will never be sent to a CPU running Zephyr code for the
converse reason. Remove all that code.
Unfortunately SOF itself still needs an interrupt unmask step at CPU
startup, because it's still doing its own masking (probably according
to the same algorithm that we imported). Leave that in place as a
minimal workaround until we get that fixed upstream.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
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>
These registers were defined in the new interface, but still being
used with bare bits (and in one spot a legacy field access macro).
Clean things up and use macros pervasively. To be fair: in this
particular case the field names aren't particularly descriptive...
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The IDC driver was written for Tiger Lake era devices, but works fine
on the earlier hardware too. Make it selectable; if you don't
configure IPM_CAVS_IDC, then you get the new driver.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was an attempt in the old code to express this as a formal
protocol with a proper field definitions, etc... But in fact no such
protocol really exists. This scheme is only used in one place to send
one specific message to code fixed in ROM on legacy devices that only
knows how to recognize this specific value. And 2.5 and later
hardware are moving away from it anyway.
Just express it directly, and explain in comments.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The CAVS_IDC_IPM driver happens to be used only on non-2.5 hardware,
but it's best to be clear in the conditional compilation when we're
talking about hardware-dependencies and when we mean software
configuration. This was mixed up in a few spots.
Also fix a warning that creeps in on non-default drivers choices about
an undeclared ipm function.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
All the in-use contents of these files have now been moved to the
intel_adsp core, and they are configured via devicetree and kconfig.
Remove the legacy headers.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The linker script (and a little bit of SOF) still has support for an
older mechanism for bootstrapping secondary cores by copying code into
lp-sram from a "manifest" emitted by the linker. This actually never
worked in Zephyr, and we've implemented a different scheme that uses a
small runtime-copied trampoline instead.
Remove.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Each platform was defining its own shim.h header, with slightly
variant field definitions, for a register block that is almost
completely compatible between versions. This is made worse by the
fact that these represent an API imported fairly early from SOF, the
upstream version of which has since diverged.
Move the existing shim struct into a header ("cavs-shim.h") of its
own, remove a bunch of unused symbols, fill in definitions for some
registers that were left out, correct naming to match the hardware
docs in a few places, make sure all hardware dependencies are source
from devicetree only, and modify existing usage to use the new API
exclusively.
Interestingly this leaves the older shim.h header in place, as it
turns out to contain definitions for a bunch of things that were never
part of the shim register block. Those will be unified in separate
patches.
Finally: note that the existing IPM_CAVS_IDC driver (soon to be
removed from all the intel_adsp soc's) is still using the old API, so
redeclare the minimal subset that it needs for the benefit of the
platforms in transition.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Misc cleanup, no non-trivial logic changes.
Swap in new ("rsr <reg>, REGISTER_NAME") syntax for Xtensa SR's in
place of inconsistent usage of the older one ("rsr.REGISTER_NAME
<reg>").
Remove the legacy handling of !KERNEL_COHERENCE cases for allocating
the cpu start record. That has long been a requirement of
multiprocessor code on this platform.
Remove the synchronous testing of the "alive" flag in
arch_start_cpu(). Nothign about that API is intended to be
synchronous, and in fact the Zephyr SMP layer is already doing the
same trick.
Remove some vestigial dead code at the end of z_mp_entry(). It was
apparently intended to handle the case where a CPU function returned,
but that's not legal anyway. And it was only enabled in the case
where there was only one CPU anyway, which was an impossible situation
(you can't evercall arch_start_cpu() successfully on a system with
only one core, for obvious reasons -- the only core is already
running!). Replace with an assertion.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This feature got written twice for two different purposes (to inform
the SOF app of which CPUs are running, and to predicate the delivery
of IPIs to the cores ready to receive the interrupt). Use only one.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
On pre-2.5 cAVS, the initial IDC interrupt to start the other core is
handled by software in the firmware ROM. That means that it has to be
unmasked for the mechanism to work (with 2.5, the interrupt is handled
by hardware regardless of what the masking state in the interrupt
controller is).
Similarly, the Xtensa Region Protection Option entries have already
been set by ROM code when we arrive in enable_l1_cache(), so we can
skip that part on older machines. Also removed because trying to
rewrite those entries was causing inexplicable hangs on cAVS 1.5,
plausibly because the region had active cache lines.
(This patch is separate for easier review in a long evolving PR.
Technically it represents a bisection problem as the "New IDC Driver"
patch before this was a regression. Seems like a safe enough thing to
handle if you land on this.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Fix various bugs with the new IDC layer that show up in edge cases
where code relies on correct timing of IPIs (unsurprisingly there is a
lot of code that recovers anyway even if the IPI doesn't arrive
promptly). Leaving this as a separate patch because the prior code in
the PR has already been reviewed and it "mostly" worked:
The unmasking of the L2 interrupt bit (remember there are three layers
of masking of the IDC interrupt) was always operating on CPU0 at CPU
startup because the code had been copied blindly. Unmask the CPU
we're actually launching. It turns out cAVS 2.x re-masks this on CPU
launch automatically.
The global init code to unmask all these interrupts at startup had the
same bug, even though it turned out to be needless (the initialization
state has it unmasked until it turns it back off). Do it right
anyway. Similarly add code to clear out existing interrupt latch
state by ACKing all IDC interrupts at startup. Seems needless, but
behavior isn't documented so let's be safe.
Flag CPU0 as always "active" for the purposes of IPIs. Forgot to do
this earlier, oops.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Dmitrii Golovanov
Jamie McCrae
Anas Nashif
Rander Wang
Jaska Uimonen
Kumar Gala
Gerard Marull-Paretas
Andrey Borisovich
Flavio Ceolin
Daniel Leung
Tomasz Bursztyka
Andy Ross