waves: add support for IPC4 compilation, including as LLEXT#9775
waves: add support for IPC4 compilation, including as LLEXT#9775lgirdwood merged 2 commits intothesofproject:mainfrom
Conversation
Of course, 32 modules must be enough forever, until it isn't. With waves we've hit the limit. Let's raise it to 48, because that certainly will be enough forever. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
With this waves can be built as a part of IPC4 configuration - either linked into the base image or as a LLEXT module. Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
lyakh
requested review from
abonislawski,
dbaluta,
iuliana-prodan,
jxstelter,
kv2019i,
lbetlej,
lgirdwood,
mmaka1,
plbossart and
ranj063
as code owners
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
LGTM, just one open on max module count.
| #define EXTENDED_MANIFEST_VERSION_MINOR 0x0000 | ||
|
|
||
| #define FW_MAX_EXT_MODULE_NUM 32 | ||
| #define FW_MAX_EXT_MODULE_NUM 48 |
There was a problem hiding this comment.
What's the container size ? Lets just set this unlimited.
There was a problem hiding this comment.
@lgirdwood it is used for a fixed-size array inside a structure. So the only alternative would be to count and dynamically allocate
There was a problem hiding this comment.
ack, I think we need the dynamic alloc (with a sane max). Whats the array elem size ?
There was a problem hiding this comment.
@lgirdwood one element is 48 bytes large (if I counted correctly). Since this is rimage, running on a build machine with gigabytes of RAM, maybe this optimisation isn't very urgent and can be postponed to a later PR?
There was a problem hiding this comment.
ack - that's fine - no impact to FW foot print. Since its host I would make it high in a followup PR to future proof rimage for v2.13
3 participants
With this waves can be built as a part of IPC4 configuration - either linked into the base image or as a LLEXT module.