ASoC: sof: ipc4-topology: Add support to sched_domain attribute #5382
Conversation
jsarha
force-pushed
the
topology2_sched_domain_support
branch
from
e7f2745 to
6bbbbb5
Compare
jsarha
force-pushed
the
topology2_sched_domain_support
branch
from
6bbbbb5 to
22e80a0
Compare
jsarha
requested review from
bardliao,
dbaluta,
kv2019i,
lgirdwood,
lyakh,
plbossart and
ujfalusi
as code owners
|
@ujfalusi could you approve this to get this merged? |
|
@lyakh , @ujfalusi , I still think no warning should be needed if we somehow encounter unrecognized topology value. Something like that should not really happen as long as the current topology attribute definition is not tampered: https://github.com/thesofproject/sof/blob/d6786df73a3e6185d06b90c2c02a3c54c63e7907/tools/topology/topology2/include/components/widget-common.conf#L124 But would it get this PR moving if I device a mechanism to provide a warning in such a case by introducing one more enum value for invalid string to be stored in swidget->comp_domain and report a warning in sof_ipc4_widget_setup_msg() about that value? That solution is far from ideal, as the warning would come only if that widget is set up, and always when its set up, but it could not tell what the wrong string was. Of course the ultimate solution would be changing the prototype for struct sof_topology_token -> get_token() and add sof_dev there, but that is a big change touching all over the place, and I really don't thing it is in the scope of this PR. |
jsarha
force-pushed
the
topology2_sched_domain_support
branch
2 times, most recently
from
6759ebb to
e52a93a
Compare
jsarha
force-pushed
the
topology2_sched_domain_support
branch
from
e52a93a to
b077804
Compare
Add SOF_TKN_COMP_SCHED_DOMAIN and connect it to struct snd_sof_widget comp_domain member, with new get_token_comp_domain() function. The logic is such that if the topology attribute is not present in the widget node the corresponding IPC4 extension value is taken from the module's manifest like before. But if the attribute is found and recognized its value overrides what is there in the manifest. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>
jsarha
force-pushed
the
topology2_sched_domain_support
branch
from
b077804 to
33b3efb
Compare
jsarha
left a comment
jsarha
left a comment
There was a problem hiding this comment.
@ujfalusi & @lgirdwood , New version pushded. Hope its finally good.
|
SOFCI TEST |
|
@ranj063 good to merge ? |
5 participants
Add SOF_TKN_COMP_SCHED_DOMAIN and connect it to struct snd_sof_widget comp_domain member, with new get_token_comp_domain() function.
The logic is such that if the topology attribute is not present in the widget node the corresponding IPC4 extension value is taken from the module's manifest like before. But if the attribute is found its value overrides what is there in the manifest.
I do not yet know how to test this feature end to end, so that is why this is only Draft now. However, with a corresponding topology change the attribute is correctly passed to domain extension bit in widget setup message