The value of CONFIG_SYS_CLOCK_TICKS_PER_SEC has side-effects that
are not expected with tickless kernel mode. In bug #46378, application
code is shown to run slower with higher sys clock tick value. In SOF
bug #5921, audio quality issues were root-caused to k_timer inaccuracy
with 50000 sys clock tick.
Set the the value to 15000 for all SOF applications. All existing
test cases pass with this value.
BugLink: https://github.com/zephyrproject-rtos/zephyr/issues/46378
BugLink: https://github.com/thesofproject/sof/issues/5921
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
In order to bring consistency in-tree, migrate all samples to the use
the new prefix <zephyr/...>. Note that the conversion has been scripted:
```python
from pathlib import Path
import re
EXTENSIONS = ("c", "h", "cpp", "rst")
for p in Path(".").glob("samples/**/*"):
if not p.is_file() or p.suffix and p.suffix[1:] not in EXTENSIONS:
continue
content = ""
with open(p) as f:
for line in f:
m = re.match(r"^(.*)#include <(.*)>(.*)$", line)
if (m and
not m.group(2).startswith("zephyr/") and
(Path(".") / "include" / "zephyr" / m.group(2)).exists()):
content += (
m.group(1) +
"#include <zephyr/" + m.group(2) +">" +
m.group(3) + "\n"
)
else:
content += line
with open(p, "w") as f:
f.write(content)
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Route printk()'s through logging subsystem. This is required
to get clean OS panics in log output. If this is not defined, e.g.
the stack backtrace is mixed with the Zephyr OS panic information.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The SOF System Agent is redundant under Zephyr, we're using different
performance monitors there.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Add a new board to support Intel Tiger Lake H PCH variant of cAVS2.5.
Move common Kconfig options for cavs25 to soc level. No need to
replicate these for every board.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Align compiler flags of SOF Zephyr build with the build SOF XTOS
and use -fstrict-overflow.
With -fno-strict-overflow, some versions of XCC compiler (e.g. xt-xcc
12.0.8) always emit a "bltu" instruction to check for overflow in loops
like:
unsigned int n;
for(n = 0; n < 1024; n++)
do_arithmetic();
With "-fno-strict-overflow", you'll have:
18: 068076 loop a0, 22 <dummy_dspload+0x22>
1b: 445a add.n a4, a4, a5
1d: 551b addi.n a5, a5, 1
1f: 023657 bltu a6, a5, 25 <dummy_dspload+0x25>
22: fffc86 j 18 <dummy_dspload+0x18>
With "-fstrict-overflow":
16: 038476 loop a4, 1d <dummy_dspload+0x1d>
19: 223a add.n a2, a2, a3
1b: 331b addi.n a3, a3, 1
As this is a common pattern in audio DSP code, change the default
for SOF builds to -fstrict-overflow.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
The inner loops of SOF audio algorithms benefit from
compiler optimizations. On Intel cAVS platforms, it was noted
zero-overhead loops ("loop" family of instructions) is not
used for fixed-size inner loops when using -Os (optimize for
size) and the XCC xtensa toolchain.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
cAVS 1.5 has little RAM, force COMP_SRC_TINY to fix SOF build
failures under Zephyr with XCC.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
As this makes no difference, it's misleading so let's remove it to stop
being misled. I don't know why initial commit efa794dbc5 added it but
the build directory is strictly identical with or without this line.
The SOF code is included in the build thanks to CONFIG_SOF in prj.conf,
not this.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Allow SMP processing for SOF on ADSP. Note, that after this
SOF will build with SMP support enabled on all cAVS versions,
but secondary cores will remain disabled unless an SMP
topology is loaded by the host.
Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Move samples under subsys/audio. We still do not have this as a
subsystem, but it is on the horizon.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
