oops, forgot to update interface so build was silently not linking the
passthrough interface to the adapter
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Required by #3459 / #3975 "elfsize" proof of concept and probably by
other things too in the future - we use both ELF and Python
everywhere; it's surprising they haven't met each other yet.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Add some useful information logs about the task scheduling point with
ll_scheduler, which will help to capture logs once we hit scheduling
issue on some specific task.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
Request for owner has gone unacknowledged, ToT adapter is broken
suggesting we likely need additional reviewers given we have no existing
code owner.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
There could be some codecs which require 0 byte library configure, e.g.
the passthrough one, change to make this possible.
Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
For at least two reasons:
- exposes sneaky change(s) performed by automation if/when any
- solves the mystery of the Source content hash (printed on the next
line) changing while the git version does not.
Example, at https://sof-ci.01.org/sofpr/PR3941/build8429/build/bdw_gcc.txt
-- Found Git: /usr/bin/git (found version "2.17.1")
-- GIT_TAG / GIT_LOG_HASH : v1.7-rc1-151-g023c4abacde1 / 023c4abac
-- Source content hash: 91f261ea
whereas at https://github.com/thesofproject/sof/runs/2166298087,
xtensa-build-all:
-- Found Git: /usr/bin/git (found version "2.17.1")
-- GIT_TAG / GIT_LOG_HASH : v1.7-rc1-151-g023c4abacde1 / 023c4abac
-- Source content hash: 67f31697
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
ESAI allocates private data and retrieves this data using
dai_get_drvdata().
But this is never set using dai_set_drvdata() and sometimes
dai_get_drvdata() returns NULL.
So, after private data is allocated, set it using dai_set_drvdata().
Without this fix, on i.MX8QM, on playback we get:
root@imx8qmmek:~# aplay -Dhw:1,0 -f S16_LE -c 2 -r 48000 -d 5 -t raw /dev/urandom
Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
[ 197.478128] sof-audio-of 556e8000.dsp: error : DSP panic!
[ 197.483547] sof-audio-of 556e8000.dsp: error: runtime exception
[ 197.489473] sof-audio-of 556e8000.dsp: error: trace point 0dead006
[ 197.495658] sof-audio-of 556e8000.dsp: error: panic at :0
[ 197.501064] sof-audio-of 556e8000.dsp: error: DSP Firmware Oops
[...]
Fixes: f40222a1ea ("drivers: imx: esai: use rate from topology")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
buffer_unlock() does not use flags.
Silences this gcc 8.1.0 (and valid) warning in
src/audio/pipeline.c#pipeline_for_each_comp(). For some strange reason
it shows up only with CONFIG_OPTIMIZE_FOR_DEBUG=y. Heuristics?
In file included from sof/src/include/sof/audio/pipeline.h:16,
from sof/src/include/sof/audio/buffer.h:12,
from sof/src/audio/pipeline.c:8:
src/audio/pipeline.c: In function 'pipeline_for_each_comp':
src/include/sof/spinlock.h:200:38: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized]
src/audio/pipeline.c:182:11: note: 'flags' was declared here
uint32_t flags;
^~~~~
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
The configuration names with _2017 are a consequence of the way I did
the internal configuration update. To keep it simple I update these
build scripts.
Signed-off-by: Paul Olaru <paul.olaru@nxp.com>
Implement a kwd function based on small
neural network able to detect yes/no
keywords. This represents an alternative
to the default kwd function and is
implemented in a separate file. Enabling
the usage of this kwd nn functionality is
done by enabling KWD_NN_SAMPLE_KEYPHRASE.
The inference function of the neural network
operates on 990 ms which are gathered in the
acquisition input buffer exposed by the detection
component.
Signed-off-by: Cristina Feies (ilie) <cristina.ilie@nxp.com>
Define & allocate acquisition buffer where
collecting the necessary amount of input data
required by the detection algorithm. In our
case the kwd_nn detection algorithm requires
~1s of data once which is more than what
the current configuration of the pipeline
offers once: 20ms of data.
Signed-off-by: Cristina Feies (ilie) <cristina.ilie@nxp.com>
Expose detect_test_notify function for
other modules which would implement
an alternative of default kwd detection
Signed-off-by: Cristina Feies (ilie) <cristina.ilie@nxp.com>
GCC configuration for ct-NG uses newlibc libc versions of common
memcpy() and memset(). Check this in makefile and lib.c so we can use
the correct versions.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Following move of open source to remove oppressive language from open
source, dummy is one of the terms to avoid. Also the term does a poor
job of describing what the adapter actually does.
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
During the initialization of a decoder, the initialization task reads the
input stream to discover the parameters of the encoding.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
This function should be called before processing. It searches
for a valid header, does header decoding to get the parameters
and initializes state and configuration structures.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
We need to save initialization status to a persistent (between calls)
variable in order to check it each time we want to do processing.
Initialization only takes place once before first frames are decoded.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Init process function searches for valid header, does header
decoding to get the parameters and initializes state and configuration
structures.
In order for this to work we need to set the input bytes and also
update consumed bytes.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Initialization of the processing shouldn't be done in the prepare
function as the decoder needs some input frames in order to figure
out decoding parameters.
First step is to just factour out the init process code into
a function and move it to the proper place later.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
With decoders, usually, consumed bytes is not equal
with produced bytes. We need to take this into account
in order to copy the entire produced bytes by the processing algorithm.
- consumed bytes -> number of bytes consumed from the input buffer.
- produced bytes -> number of bytes produced into the output buffer.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Looking at the timestamps from sof-logger it looks like
the DSP core frequency on i.MX8X is wrong.
Documentation confirms this. It should be 640Mhz.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Adapt the apl KWD topology to imx8m by switching to
SCHEDULE_TIME_DOMAIN_DMA on capture pipeline and
creating a no LP capture file for KFBM component.
Signed-off-by: Cristina Feies (ilie) <cristina.ilie@nxp.com>
On start W1C the Work Start Flag, Sync Error Flag and
FIFO Error Flag.
Write a logic 1 to this field to clear each of this
flags and have a clean start for SAI.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
For SAI, we have the synchronous mode enabled: the transmitter is
configured for asynchronous operation and the receiver for
synchronous operation.
In this case, transmitter bit clock and frame sync are used by both
the transmitter and receiver. So, when enabling RX we need to enable TX
(if not already enabled).
Therefore, for a clear start, we first do a software reset for the current
direction, but checking the state of RX and TX.
This will reset the internal transmitter/receiver logic including the FIFO
pointers.
For capture we can disable the receiver data channel, but on playback,
we can disable the transmitter only if the RX has the DMA requests
disabled.
Also, for capture, there's no need to enable the transmit data channel.
It's sufficient to enable only the transmitter, which enables the bit
clock (shared with RX).
On stop, we just need to disable the DMA request, the transmit/receive data
channel, the interrupts and the receiver and/or the transmitter.
Fixes: #3809
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Set SAI watermark only once, on sai_set_config().
There is no need to set it each time, on start().
SAI watermark is kept on half FIFO size.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
To stop/suspend an active DMA channel:
1. Stop the DMA service request at the peripheral first (stop the DAI);
2. Disable the hardware service request on the appropriate DMA channel.
For start/resume:
1. Enable the DMA service request on the appropriate channel;
2. Enable the DMA service request at the peripheral (enable DAI).
When the start/stop order for DMA and DAI is different, on multiple
start/stop runs for playback or record or combined, we get an
underrun/overflow.
That's because the DAI makes a DMA request, before the DMA channel is
enabled.
Some platforms cannot just simple disable DMA channel during
the transfer, because it will hang the whole DMA controller.
Therefore, for DMA_SUSPEND_DRAIN, stop the DMA first
and let the DAI drain the FIFO in order to stop the channel
as soon as possible.
Fixes: #3809
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
In kpb force_copy_type is declared as enum comp_copy_type,
but later on is initialized and compared with an integer
constant.
We should use everywhere only enum comp_copy_type.
Therefore add an invalid copy_type, COMP_COPY_INVALID in
enum comp_copy_type.
Use this one to initialize and compare force_copy_type.
Fixes: 7e46996c96 ("kpb: Introduce force_copy_type")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Building "sof" does not rebuild the .ri firmware file. Switch to the
"bin" target which is what ./scripts/xtensa-build-all.sh builds.
Fixes: 479809663e ("installer: (re)build firmware, topologies and user
space tools)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Gets the length of a no-op "make topologies" from 380 down to 140
lines. From 300 to 200 for one "make signed" platform.
Ninja is more quiet by default.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
XTOBJCOPY and XTOBJDUMP were added in June 2018 by
commit 27795ece0f ("scripts: fix xt-xcc build with wrong config") for
`./configure CC=$XCC OBJCOPY=$XTOBJCOPY OBJDUMP=$XTOBJDUMP ...` that was
used at the time.
The build system was switched to CMake in January 2019, notably with
commit 9840ecbbfe ("cmake: update xtensa-build-all.sh") and
commit 0fd97adfb0 ("cmake: add utility scripts") that defined
CMAKE_OBJCOPY and CMAKE_OBJDUMP)
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
$ARCH was introduced in 2018 by commit b5af84deaa ("scripts: add smp
builds to xtensa-build-all.sh"). At the time used autotools and
`./configure --with-arch=$ARCH` were used.
In January 2019 the build system was migrated to CMake over several
commits, notably commit 9840ecbbfe ("cmake: update
xtensa-build-all.sh") that switched xtensa-build-all.sh to CMake and
removed its only use of ARCH. Also note commit 82b4da291b ("cmake:
defconfigs support") which added a few CONFIG_SMP defconfigs and
commit 905bad4252 ("scripts: xtensa-build-all: Add support to force
build UP Arch") using override.config.
Much more recently in June 2020: commit fd506970cc ("zephyr: kconfig:
rename CONFIG_SMP -> CONFIG_MULTICORE")
Zawinski's Law of Software Envelopment: adding lines of code is much
easier than removing the same amount and would be very impractical
without git. This one was easy enough.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As CMake forks one compiler process for each source file, the XTensa
compiler spends much more time idle waiting for the license server over
the network than actually using CPU or disk.
On my VM with 16 virtual cores, rebuilding one platform from scratch
with this commit goes down from 12s to less than 9s: more than 25%
faster. With Ninja it goes down from 11s to less than 8s. My license
server is 25ms away: a closer server does not need as many threads while
a more distant server would obviously benefit for even more
threads... while already getting an even better improvement than 25%
from just 3 times more threads! It's complicated and we probably don't
want to start the build by measuring latency to the license server.
The entire, purely local _gcc_ build is so fast (~ 1s) that observing any
the difference between -j nproc and -j nproc*N is practically impossible
so let's not waste RAM when building with gcc.
Also: log the $XTENSA_SYSTEM variable as it is required for incremental
builds; remove one apostrophe in the here-doc usage as it breaks the
parser of some editor (jed).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Notably:
- Log error and default MEU_OFFSET when meu -ver is not found.
- Explain rimage -s option
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Avoids the following redirection and warning:
warning: redirecting to https://github.com/thesofproject/sof/
Fixes: f59bb62e31 (".github: add shallow checkpatch to Github
Actions")
Also try to fix the display of one step name in the web UI.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Curtis Malainey