This will allow the fuzzer to probe deeper into the code while also
allowing CI to build test the adapter.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Add a stub for the Waves library for the fuzzer to build against. This
will also improve build tests in CI.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Zephyr uses MP_MAX_NUM_CPUS internally to represent the
number of cores available and consequently to allocate
resources. It is even expected, and checked through assert,
that these two symbols have the same value. Use different
value can lead to an undesired behavior, so lets use
MP_MAX_NUM_CPUS.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This is part of fw which helps loaded module in communication with adsp
Also it provides basic operations for creation of component driver
Common part for native loadable modules and iadk is put together and
remade into native API. That way system services are using generic
methods defined in native system service.
Signed-off-by: Dobrowolski, PawelX <pawelx.dobrowolski@intel.com>
Struct cascade_root & mn are used by xtos build only so remove them for
zephyr native driver. And these two items are too specific to intel
platforms. Remove these item also save memory.
Signed-off-by: Rander Wang <rander.wang@intel.com>
During PowerOff (D3) transition Zephyr Power Manager must have
a pointer in IMR to save the LP/HPSRAM memory before
powering off.
As zephyr has no access to IMR heap, the memory must
be allocated by SOF
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Make audio_stream capable of using pipeline2.0
sink and source API
This change makes integration of sink/src api
possible in incremental way
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
There are many operations on sink/source that may be put into a
common library. This is the place for it.
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
this is a definition of API to sink of audio data
THE SINK is any component that can store data somehow
and provide a buffer to be filled with data at request.
The sink API does not define how the data will be processed/used
The user - a module - sees this API as a destination
it must send data to
The IMPLEMENTATION - audio_stream, DP Queue -
sees this as a producer that PROVIDES data for processing
Examples of components that should expose SINK api
- /dev/null
all the data stored in sink buffer are just simply discarded
- I2S sender
Data stored in sink buffer will be sent to the external world
- a memory ring buffer
data stored in the buffer will be sent to another module
(usually using source API, but it does not matter in fact).
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
this is a definition of API to source of audio data
THE SOURCE is any component in the system that have data
stored somehow and can give the data outside at request.
The source API does not define who and how has produced
the data
The user - a module - sees this as a producer that
PROVIDES data for processing
The IMPLEMENTATION - audio_stream, DP Queue - sees
this API as a destination it must send data to
Examples of components that should expose source API:
- DMIC. Data are coming from the outside world,
stores in tmp buffer and can be presented
to the rest of the system using source_api
- a memory ring buffer
Data are coming from other module
(usually using sink_api, but it does not matter in fact)
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
The 32-bit HiFi4 exponential library function has an accuracy of 1e-4,
a unit in last place error of 5.60032793, and output ranges from
0.0067379470 to 148.4131591026 for inputs from -5 to +5 (Q4.28) (Q9.23).
Signed-off-by: ShriramShastry <malladi.sastry@intel.com>
There's really no reason to fall back on a default "platform" and pick
up a bunch of other, totally random settings.
Now the following command fails immediately with a useful `platform not
defined` error message instead of stopping with a cryptic
`platform/trace/trace.h: No such file or directory` after successfully
compiling half the .c files in a Frankenstein CONFIG_uration.
```
west build -p --board mimx8mm_evk_a53 modules/audio/sof/app
```
More context in #7192.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Follow the k_sys_fatal_error_handler implementation in fatal.c in
zephyr framework. Without this halt, our k_sys_fatal_error_handler
will be called copules time and result to many useless IPC messages
to host.
Signed-off-by: Rander Wang <rander.wang@intel.com>
Do not make the switch yet. Make the switch in a smaller commit that can
more easily be reverted in case of a bug or some missed dependency
somewhere.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The DSP cannot enter the power gating state if it has not yet received
an ack from host after sending an ipc message.
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Thanks to PR [1], Zephyr cache management API can now be
used on xtensa-based SoCs. As a consequence to this, there's
no longer a need to use SOF's arch/ layer for cache management.
This commit forces all SoCs which support Zephyr to use
its native cache management API.
[1]: https://github.com/zephyrproject-rtos/zephyr/pull/50136
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Every module which needs AMS for notifications uses the same flow when
configuring itself as a consumer or producer for such notifications.
Add AMS helper functions to avoid code repetition.
Signed-off-by: Ievgen Ganakov <ievgen.ganakov@intel.com>
Send panic notification message to host when panic happens. The panic
detail is built by Zephyr framework and included in debug memory window.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Rander Wang <rander.wang@intel.com>
Co-developed-by: Rander Wang <rander.wang@intel.com>
New Docker container tagged v0.26.4 contains new Zephyr SDK v0.16.1
needed to build with Zephyr main branch.
New Zephyr SDK is backward compatible with the older Zephyr revisions
so the upgrade is done for SOF manifest revisions too.
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
This implies the following changes:
1) domain_task_cancel() shall no longer receive the number
of tasks, but, instead, will receive the task to be cancelled.
2) zephyr_dma_domain_task_cancel() will do k_sem_give() if the
sched_comp associated with the given task is != COMP_STATE_ACTIVE.
3) SEM_LIMIT is changed to CONFIG_DMA_DOMAIN_SEM_LIMIT and can
be configured.
The reasoning for the changes are the following:
1) and 2): In the case of mixers, domain_task_cancel()'s
num_tasks is not a reliable way to determine if the DMA
IRQs got cut off. Let's consider the following scenario:
We have a mixer with 1 non-registrable pipeline task and
1 registrable pipeline task. Upon TRIGGER_STOP we'd have
the following flow (i.MX boards):
a) SAI_STOP => DMA IRQs get cut off.
b) Cancel non-registrable pipeline task.
c) Cancel registrable pipeline task.
During b) and c), domain_task_cancel() would get the following
arguments:
b) domain_task_cancel(sch, 1)
c) domain_task_cancel(sch, 1)
This is because the non-registrable pipeline task wasn't
dequeued before c) so, even though the DMA IRQs got cut
off during a), zephyr_dma_domain_task_cancel() does not give
resources to the semaphore so what happens is zephyr_ll_run()
will no longer execute and the pipeline tasks remain queued.
3) Since the semaphore can accumulate more than 1 resource
at a given time (and since it's safe to make SEM_LIMIT depend
on the load of the system), SEM_LIMIT was changed into a config.
This allows the user to change SEM_LIMIT based on the system
load. For example, if there's 2 non-registrable pipeline tasks
and 1 registrable pipeline task (same scheduling component),
an appropriate value for SEM_LIMIT should be 3 (since the
semaphore can be given at most 3 resources during the task
cancellation process). Of course, making SEM_LIMIT depend on
the system load is the worst case but this way we can make sure
that the cancelled tasks get dequeued properly.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
For the functions platform_interrupt_clear and platform_interrupt_set,
the existing definitions based on arch_interrupt_* do not compile with
the xt-clang 2023 toolchain for imx. Use the Zephyr wrapper
implementations for those for now.
Signed-off-by: Paul Olaru <paul.olaru@nxp.com>
Informing the primary core that the Idle thread on secondary core is
ready. During the D3 exit flow thread is not initialize again, but
restored from previously saved context.
This patch includes also zephyr version update to aba3b12e31 (total 15
commits). Changes related to intel_adsp contain refactor and fixes for
ACE secondary cores power flows.
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Idle thread should be initialize only when core it booting for the first
time. Doing this again would overwrite the kernel structs and the idle
thread stack.
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Split smart_amp_test.c to IPC3 version smart_amp_test_ipc3.c
and IPC4 version smart_amp_test_ipc4.c
Signed-off-by: Andrula Song <andrula.song@intel.com>
Due to the fact that on i.MX93 the host will initialize the
SOF_IPC_FW_READY sequence there's no need to call
platform_boot_complete() at the end of start_complete(). This
will be handled in the IPC3 handler.
This commit makes sure that aforementioned scenario won't
happen for i.MX93 while keeping the flow constant for the
other platforms.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Use zephyr cache APIs instead of xtensa specific ones.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
DP scheduler is intended to work on MTL and
future platforms only - has not been tested on
any legacy.
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
This commit introduces support in the CMakeLists.txt of Zephyr for
building SOF for i.MX93 platform.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
CMake seems to behave differently on Linux and Windows: it generates
different `-I` command line parameters. This results in spurious
`__FILE__` mismatches and non-reproducible builds when using
CONFIG_ASSERT, see example in #7428.
On Windows, '..' seem resolved more often which also seems to convert
forward slashes to backslashes.
They are also less readable and wasting a bit of space. Remove them
using cmake_path(SET ...)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
ARM64's GIC doesn't utilize cascaded interrupts so interrupt_get_irq
will have to return the given INTID.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
This commit removes all occurrences of the soc.h header file
since this is not used. This also fixes build problem on i.MX93
caused by the fact that i.MX93 doesn't have a soc.h.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
This is required by ARM64 platforms as they don't have
an arch/compiler_info.h so the compilation would fail.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
DMA domain with Zephyr works fine for i.MX platforms. So, remove
"experimental" from description and enable it by default for i.MX
platforms.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Start using zephyr pm_runtime, clk and dma glue code in cavs25 native
drivers build. Move the files from ace/lib into zephyr/lib.
Also update west.yaml to related zephyr commit as power related
files have been moved to zephyr side.
Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
Add HiFi3 implementation of dcblock processing functions.
Compared with generic C version, the 16 bit format can save
about 48.1% cycles, and 48.4% for 24 bit format and 52.6%
for 32 bit.
Signed-off-by: Andrula Song <andrula.song@intel.com>
The DP scheduler is a scheduler based on Zephyr preemptible
threads. It will start each SOF task as a separate Zephyr
thread.
At current implementation the scheduler can trigger each
task/thread periodically or on demand.
TODO: more sophisticated scheduling decisions, with deadline
and task budgets calculations.
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Curtis Malainey