-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rimage: add ipc4 extended module config introduction #451
base: master
Are you sure you want to change the base?
rimage: add ipc4 extended module config introduction #451
Conversation
1fca027
to
e035b0a
Compare
@cujomalainey this is the document for thesofproject/rimage#125 |
| **uuid**: uuid of the module | ||
| **affinity_mask**: usable dsp core mask, bit N is for core N, 0x3 means core 0 and 1 can be used | ||
| **instance_count**: max module instance count can be active in fw | ||
| **domain_types**: two schedule domains: domain ll (0), and dp (1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd assume these are indexes of bits in the mask since you may define a module that works in both domains? But you provided value of "0" in the example above which suggests these are mutually exclusive modes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find "domain_types LL DP" in real case.
Let's use index of bit. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should give a bit more guidance here about which to choose for developers who may just building a standalone module are not SOF developers. LL and DP mean nothing to outsiders. To be honest I only know edf and ll, I have no clue what dp is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cujomalainey Some of this is referring to ongoing work, which understandably makes this hard to follow. For DP, the PR to add this concept to SOF was just submitted for review thesofproject/sof#7089
e035b0a
to
3209a52
Compare
updated comments for domain type |
esensing, | ||
emax, | ||
einvalid = emax | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kv2019i module_type enum was defined for the Host SW driver purpose. The idea was to have option to identify components of specific functionality like for e.g. wov, mux or any other listed above. That capability allow for more topology flexibility at Host SW level. For example, instead of hardcoding in topology that you need Module_1 with specific GUID you can point that you need Module_1 with specific functionality type. That allow to swap components of the same functionality without need to change the topology itself / modifying GUIDs.
The bottom line is that new modules module_type should be matched with one of the available on list or if necessary the new custom type should be added. I would also recommend to change the enum name to something like module_fuctionality_type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack @mwasko . I think the "bottom line" part should be added directly in the docs to help module developers choose correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mwasko good for you ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good start but lots of questions raised @RanderWang
*********************** | ||
| **name**: name of the module | ||
| **uuid**: uuid of the module | ||
| **affinity_mask**: usable dsp core mask, bit N is for core N, 0x3 means core 0 and 1 can be used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does 'usable' mean? is this restricting on which core a module can run, with the actual determination done on a per-instance basis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
enum type { | ||
pcm = 0, | ||
mp3, | ||
aac, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no. this should not be added, @mmaka1 mentioned this is not used by firmware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@plbossart extended module config are used by driver, not by firmware. type is included in conf and I need to comments it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not going to question @mmaka1 's answer " The driver never used this one. And it was always hardcoded to ePcm. "
don't document things that are not useful or even used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack - lets remove
3209a52
to
27076d8
Compare
@plbossart updates good for you ? |
| **uuid**: uuid of the module | ||
| **affinity_mask**: usable dsp core mask, bit N is for core N, 0x3 means core 0 and 1 can be used | ||
| **instance_count**: max module instance count can be active in fw | ||
| **domain_types**: two schedule domains: domain ll (0), and dp (1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should give a bit more guidance here about which to choose for developers who may just building a standalone module are not SOF developers. LL and DP mean nothing to outsiders. To be honest I only know edf and ll, I have no clue what dp is.
.. code-block:: bash | ||
|
||
pin = [dir, type, sample rates, sample size, sample container size, channel config] | ||
For example, gain module pin = [0, 0, 0xfeef, 0xf, 0xf, 0x45ff], it supports input pcm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there no better way to document/configure this? This seems like a heavy load on the user to (de)compile and humans are great sources of error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it needs to develop a new tool to make it easy, something like a ui tool to chose feature by clicking mouse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, just simply using enums, and discrete fields would be better than manual bitpacking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cujomalainey sure. Let's add this feature to rimage tool.
27076d8
to
7bafdad
Compare
updated, thanks! |
7bafdad
to
485dbdc
Compare
@cujomalainey updated to use string instead of hex number for pin setting. If it is confirmed, I will start to add support in rimage tools |
485dbdc
to
b0d2b5f
Compare
updated https://github.com/thesofproject/converged-sof-modules/blob/main/README.md to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking much better, thank you, almost there
Module config | ||
------------- | ||
**Usage:** | ||
``mod_cfg PAR_0 PAR_1 PAR_2 PAR_3 IS_BYTES CPS IBS OBS MOD_FLAGS CPC OBLS`` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a bit long, 11 args is a bit hard to read
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's your suggestion ? It defines array of config data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The indicies are named no? Can they not be broken out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I don't get your idea. Can you give an example ? Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the description even though it is a byte array, the bytes themselves are all mapped directly to a value. Just curious why we cannot treat this as a packed struct and give everything a name and/or possible sub structs to make access and identification easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, we can define struct in C language code, but this is a config file and these data blob are generated by FW tools, so like topology setting, we just include byte array.
b0d2b5f
to
9790ecc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@RanderWang this is a starting point which can be built upon. Just one issue to close.
enum type { | ||
pcm = 0, | ||
mp3, | ||
aac, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack - lets remove
9790ecc
to
888fbaf
Compare
removed AAC and change init_config to init_config_has_extenstion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets use this as the starting point.
@cujomalainey @plbossart can we unblock this as the starting point as today we have zero documentation and this is better than zero. This then allows others to add more context like @btian1 (who has CPC formula's) and @mwasko (who has other manifest data). Thanks ! |
Ack but can we get issues tracking the cleanup requests? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Numerous edits are included to ensure grammatical and style consistency throughout this doc and the rest of SOF documentation.
This is a introduction of ipc4 extended module config and how to add this information in the xxx.toml for template. Signed-off-by: Rander Wang <[email protected]>
888fbaf
to
63e3905
Compare
refined style according to comments, thanks! |
This is a introduction of ipc4 extended module config and how to add these information in config file xxx.toml for ipc4.