1cc853d...
by
Seppo Ingalsuo <email address hidden>
Audio: SRC: Use only module API and fix IPC4 capture direction
This patch cleans up SRC component. There is no need to keep
IPC3 version build with legacy component interface. The patch
mainly removes code under CONFIG_IPC_MAJOR_3 and makes some
functions available for all builds from CONFIG_IPC_MAJOR_4.
The IPC4 capture issue is fixed by using the src_init()
IPC rates for source and sink rate initialize. It needs a
similar kernel update to always set those values. In practical
topologies in prepare the buffers may not contain the correct
stream information because the order of host copier and
dai copier pipeline prepare can be host first where capture
SRC is usually placed.
Signed-off-by: Seppo Ingalsuo <email address hidden>
1240cf0...
by
Seppo Ingalsuo <email address hidden>
Audio: Module adapter: Pass entire new() IPC to SRC
This patch differentiates SRC component from normal processing
component IPC. The corrected size allows the client component to
receive all of init() IPC.
Signed-off-by: Seppo Ingalsuo <email address hidden>
create another topology to test multicore since Currently we have done
too much work in cavs-nocodec and CI test will be failed for main branch
is not ready for multicore feature.
Signed-off-by: Rander Wang <email address hidden>
81060d9...
by
Seppo Ingalsuo <email address hidden>
Tools: Tune: Add to DMIC modes generate alsa-utils export
This patch adds export format for header file that alsa-utils
uses. Automatic generation is much more convenient than hand
editing when there is update need.
The patch also contains some cleanup of unused code and small
code improvement. There are no changes to exported coefficients
values.
Signed-off-by: Seppo Ingalsuo <email address hidden>
bf397bf...
by
Adrian Warecki <email address hidden>
dmic: Use the correct 24 bit conversion function
The DMIC interface places 24-bit samples on the most significant bits of
a 32-bit container. The correct conversion function for this gateway was
used.
Signed-off-by: Adrian Warecki <email address hidden>
Fuzzing produces (by design) an endless flood of protocol errors.
Quiet the top level ones when in use, because otherwise the log output
takes up most of the CPU time available that we'd rather spend on
fuzzing. Same trick from IPC3.
Don't use the IPC3 protocol whiteboxing for IPC4, the formats are
different.
Also IPC4 seems to send a LOT of zero-length empty replies. Those are
causing spurious errors (memcmp_s fails when you pass it a null
destination pointer, even when the length is zero), where the Intel
IPC driver will just drop them. Suppress handling to match behavior,
though this is probably a buglet worth investigating.
Add new APIs needed for CONFIG_IPC_MAJOR_4=y builds. Note that many
of these are fairly Intel-specific, meaning they probably don't belong
in the platform layer. But in this case (fuzzing) it's probably
worthwhile to enable as much code as possible vs. refactoring for
purity. Future IPC4 hardware platforms will need to do that
refactoring for us anyway.
The component model for IPC4 seems to be based on an array of manifest
headers at the start of the firmware image. Those are rimage data,
and not all platforms (in particular the fuzzer) are packing their
output with rimage.
Just stub this for now. In the source tree as it exists, there don't
seem to be any extra components to build, nor is there any support I
can see at the linker/rimage level to get them included anyway.
base_fw: No Intel register reads in non-platform code
This was trying to read hardware registers, which obviously doesn't
work on other platforms. Stub with zeros for now.
Longer term: this whole message ("basefw_mem_state_info") might want
some rework. In addition to being heavily hardware-specific, it seems
like a comparatively large block without self-describing data
(e.g. id/val pairs), nor with a struct definition to specify it, nor
with any documentation that I can find.
