waves: add support for IPC4 compilation, including as LLEXT #9775
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 <[email protected]>
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 <[email protected]>
lyakh
requested review from
kv2019i,
iuliana-prodan,
dbaluta,
abonislawski,
ranj063,
jxstelter,
lgirdwood,
plbossart,
mmaka1 and
lbetlej
as code owners
| @@ -27,7 +27,7 @@ | |||
| #define EXTENDED_MANIFEST_VERSION_MAJOR 0x0001 | |||
| #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
With this waves can be built as a part of IPC4 configuration - either linked into the base image or as a LLEXT module.