sof
sof copied to clipboard
thesofproject
ipc4: add basic ipc4 support in selector
Although this patch doesn't support large_config_set|get and corresponding per-channel process, it can support simple usage of selector and support capture applications like voice recoder, zoom on windows platform. It will be used for WOV development in recently.
Signed-off-by: Rander Wang [email protected]
@RanderWang can we schedule some ipc3 and ipc4 validation for this PR before merge ? (this is due the IIR PR having a regression, but not sure if its framwork or module)
I validated on windows since IPC4 selector is not supported by Linux now. And I don't know how to validate in IPC3 path. It is lucky that CI has such test for selector.
The reason is the same as your expectation in framework. For original path, we will call hw_params then prepare for each components. Some components will change pcm params setting in hw_params and it will affect the following components in the pipeline. But with module adapter change, the hw_params ops disappears in module interface, so the pcm params can't be changed in time.
Take selector as a example, it will change channel number in hw_params and the following dai will match the setting in pcm params. Now no hw_params in selector but dai still has it, so the setting can't be matched.
Current module interface:
init, prepare, process, set_config, get_config, set_processing_mode, get_processing_mode, reset and free.
In my PR we still need to build hw_params and it is done in prepare function. To fix it we either need to adopt dai to module interface or add hw_params.
I will have a vocation next week, so I can't update it.
@RanderWang can we schedule some ipc3 and ipc4 validation for this PR before merge ? (this is due the IIR PR having a regression, but not sure if its framwork or module)
I validated on windows since IPC4 selector is not supported by Linux now. And I don't know how to validate in IPC3 path. It is lucky that CI has such test for selector.
The reason is the same as your expectation in framework. For original path, we will call hw_params then prepare for each components. Some components will change pcm params setting in hw_params and it will affect the following components in the pipeline. But with module adapter change, the hw_params ops disappears in module interface, so the pcm params can't be changed in time.
Take selector as a example, it will change channel number in hw_params and the following dai will match the setting in pcm params. Now no hw_params in selector but dai still has it, so the setting can't be matched.
Current module interface:
init, prepare, process, set_config, get_config, set_processing_mode, get_processing_mode, reset and free.In my PR we still need to build hw_params and it is done in prepare function. To fix it we either need to adopt dai to module interface or add hw_params.
I will have a vocation next week, so I can't update it.
@lgirdwood we need to convert dai component first . Do you plan to enable module adapter with dai component ?
@lgirdwood we need to convert dai component first . Do you plan to enable module adapter with dai component ?
I dont think the DAI component is needed as it's wrapped by the copier ? Although pls check, I maybe wrong.
@lgirdwood we need to convert dai component first . Do you plan to enable module adapter with dai component ?
I dont think the DAI component is needed as it's wrapped by the copier ? Although pls check, I maybe wrong.
@lgirdwood yes. But this PR enable module adapter for both ipc3 & ipc4 and now ipc3 is failed since dai can't work with selector with module adapter enabled. Do you plan to only enable module adapter in ipc4 path ?
Do you plan to only enable module adapter in ipc4 path ?
No, it must work with IPC3 & IPC4, so are you saying this PR will break IPC3 for selector ?
Do you plan to only enable module adapter in ipc4 path ?
No, it must work with IPC3 & IPC4, so are you saying this PR will break IPC3 for selector ?
yes, it breaks selector CI tests for above reason
Do you plan to only enable module adapter in ipc4 path ?
No, it must work with IPC3 & IPC4, so are you saying this PR will break IPC3 for selector ?
@lgirdwood what's your advice ?
Do you plan to only enable module adapter in ipc4 path ?
No, it must work with IPC3 & IPC4, so are you saying this PR will break IPC3 for selector ?
@lgirdwood what's your advice ?
This PR must preserve both IPC3 and IPC4 functions via the IPC version Kconfig (like the volume).
@lyakh can you check for SPARSE usage. Thanks
@lgirdwood sorry, maybe @RanderWang has uploaded a wrong version, all the same comments apply, none of them have been addressed, although some comments are answered with done and many are marked as "resolved." Bad git push?
@lyakh can you check for SPARSE usage. Thanks
@lgirdwood sorry, maybe @RanderWang has uploaded a wrong version, all the same comments apply, none of them have been addressed, although some comments are answered with
doneand many are marked as "resolved." Badgit push?
@lyakh sorry, there are two commits and I fixed in the second commit. Do I need to fix it in the first commit ?
@lyakh sorry, there are two commits and I fixed in the second commit. Do I need to fix it in the first commit ?
Yes please, otherwise we break bisect.
@lyakh sorry, there are two commits and I fixed in the second commit. Do I need to fix it in the first commit ?
Yes please, otherwise we break bisect.
@RanderWang indeed, and not only that, in general it's better to avoid committing wrong code in the first place than committing it with an immediately following fix
@lyakh sorry, there are two commits and I fixed in the second commit. Do I need to fix it in the first commit ?
Yes please, otherwise we break bisect.
@RanderWang indeed, and not only that, in general it's better to avoid committing wrong code in the first place than committing it with an immediately following fix
Thanks. I first didn't realized that the issue is introduced by first commit since the second commit also change these code
@fredoh9 please see - the SSD test appears to be failing on all ADL SDW RVP now. Can you check the dmesg. https://sof-ci.01.org/sofpr/PR5973/build1255/devicetest/?model=ADLP_RVP_SDW_ZEPHYR&testcase=verify-pcm-list