DP queue is a lockless circular buffer
providing safe consumer/producer cached operations cross cores
prerequisites:
1) incoming and outgoing data rate MUST be the same
2) Both data consumer and data producer declare
max chunk sizes they want to use (IBS/OBS)
required Buffer size:
- 2*MAX(IBS,OBS) if the larger of IBS/OBS
is multiplication of smaller
- 3*MAX(IBS,OBS) otherwise
The queue may work in 2 modes
1) local mode
in case both receiver and sender are located on
the same core and cache coherency
does not matter. dp_queue structure is located in cached memory
In this case DP Queue is a simple ring buffer
2) shared mode
In this case we need to writeback cache when new data
arrive and invalidate cache on secondary core.
dp_queue structure is located in shared memory
dpQueue is a lockless consumer/producer safe buffer.
It is achieved by having only 2 shared variables:
write_offset - can be modified by data producer only
read_offset - can be modified by data consumer only
as 32 bit operations are atomic, it is multi-thread and multi-core save
There some explanation needed how free_space and
available_data are calculated
number of avail data in circular buffer may be calculated as:
data_avail = write_offset - read_offset
and check for wrap around
if (data_avail < 0) data_avail = buffer_size + data_avail
The problem is when write_offset == read_offset,
!!! it may mean either that the buffer is empty
or the buffer is completely filled !!!
To solve the above issue having only 2 variables mentioned before:
- allow both offsets to point from 0 to DOUBLE buffer_size
- when calculating pointers to data, use:
data_bufer[offset % buffer_size]
- use double buffer size in wrap around check when calculating
available data
And now:
- write_offset == read_offset
always means "buffer empty"
- write_offset == read_offset + buffer_size
always means "buffer full"
- data_avail = write_offset - read_offset
if (data_avail < 0) data_avail = 2 * buffer_size + data_avail
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Because module uses SYS_INIT defined in init.h. Things likely worked
because of indirect includes.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Module is using Zephyr SYS_INIT API, defined in init.h, not device.h.
Code relied on indirect includes.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The z_delayed_work field in struct task is a delayed work, so to go from
k_work to it safely there's an extra step. Add a
k_work_delayable_from_work to fix that.
This is harmless right now because k_work is the first field in
k_work_delayable but the extra step is the safe way of doing it.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This check in change eliminates the extra include isa.h header file
from the exp_fcn_hifi.c file, as it does in the exp_fcn.h file.
Signed-off-by: ShriramShastry <malladi.sastry@intel.com>
Add definitions for pipeline state change phases to be executed when a
PPL_STATE message is handled by a remote core.
The phase can be a combination of:
PREPARE and TRIGGER.
PREPARE will run a configuration (state change preparations) phase on the
pipeline
TRIGGER will run a a trigger on the pipeline
Set ONESHOT in ipc4_set_pipeline_state() to have both phases to be run in
order to avoid regression.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
In preparation to share the extension with an action, first introduce a
mask so that the idc code is prepared for a shared use of the extension.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Remove support for Intel cAVS Low Power Sequencer for Power Management.
This code is specific to XTOS builds for Tiger Lake (cAVS)
platforms and no longer used in Zephyr builds.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Remove all cmake rules to build SOF for Intel cAVS2.5 hardware
using non-native drivers (i.e. use XTOS drivers from SOF tree
instead of Zephyr native drivers). This is no longer supported
nor tested, so can be removed.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Memory window management has been moved to Zephyr drivers
for this platform, so building this file on SOF side is no
longer needed.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
By enable/disable COMPILER_INLINE_FUNCTION_OPTION to control
add or remove -fno-inline-functions build option for sof zephyr
code.
Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
When converting #ifdef CONFIG_ADSP_IMR_CONTEXT_SAVE to if(IS_ENABLE(
CONFIG_ADSP_IMR_CONTEXT_SAVE), we should use if (!IS_ENABLE() ||
Signed-off-by: Rander Wang <rander.wang@intel.com>
Fix multicore test issue on cavs platforms which don't support context
save now, so need to init cpu when the core boot up.
Signed-off-by: Rander Wang <rander.wang@intel.com>
Add virtual heap allocators that allocate on proper heaps and
map physical memory where nesscessary.
Add free function that frees up the virtual heap memory and
unmaps physical memory when possible.
Virtual heap allocator allows using virtual memory as a base
for allocation and booking memory. Physical memory banks
will be mapped when needed allowing for greater flexibility
with mapping.
Signed-off-by: Jakub Dabek <jakub.dabek@intel.com>
This will allow to correctly set multiple pipelines state
even if they are allocated on different cores.
ipc4_set_pipeline_state will check if several cores are involved
- set ppl state if only current core requested
- process IPC on another core if only single secondary core requested
- send IDC messages if several secondary cores involved
Signed-off-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com>
To support pipelines connection between cores, ipc4_create_buffer()
must be able to create buffer shared between source and sink
components created on different cores. ipc4_create_buffer() requires
source component obs size. When both source and sink components
created on same core, ipc4_create_buffer() is executed on that core,
otherwise it is executed of core 0 (IPC processing core). So for the
case when source and sink components are created on different cores
comp_get_attribute_remote() is used to receive source obs size.
Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
bind/unbind handler must be called from core on which component was
created.
When both source and sink components are created on same core,
bind/unbind IPC is processed on that core. However, when connected
source and sink are on different cores, IPC is processed on core 0.
Hence comp_bind_remote() and comp_unbide_remote() is added to call
bind/unbide from proper core.
Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
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>
Baofeng Tian