[RFC] ASoC: SOF: walk through widgets from host to DAI

[bardliao]

Currently, we walk through widgets from source to sink. But it will walk
through all widget that connect to the DAI including irrelevant widgets
in multi stream capture case.
This patch suggests the order from host to DAI. That can ensure only
used widget will be handled.

Signed-off-by: Bard Liao yung-chuan.liao@linux.intel.com

[plbossart]

Does this solve the IO error @bardliao or is this 'just' to avoid setting-up irrelevant widgets?

[bardliao]

Does this solve the IO error @bardliao or is this 'just' to avoid setting-up irrelevant widgets?

It will not solve the IO error, but without this even single capture can't start. I will put some log here later.

[bardliao]

@plbossart It will fail to create the second host copier with the FW reported error: 104 - Other failure of module instance initialization request error

[ 19.595561] snd_sof:sof_ipc4_widget_setup: sof-audio-pci-intel-tgl 0000:00:1f.3: pipeline: 13 memory pages: 2
[ 19.595564] snd_sof:sof_ipc4_widget_setup: sof-audio-pci-intel-tgl 0000:00:1f.3: Create widget pipeline.13 instance 0 - pipe 13 - core 0
[ 19.595568] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx : 0x110d0002|0x0: GLB_CREATE_PIPELINE
[ 19.595893] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx reply: 0x31000000|0x0: GLB_CREATE_PIPELINE
[ 19.595920] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx done : 0x110d0002|0x0: GLB_CREATE_PIPELINE
[ 19.595927] snd_sof:sof_widget_setup: sof-audio-pci-intel-tgl 0000:00:1f.3: widget pipeline.13 setup complete
[ 19.595932] snd_sof:sof_ipc4_widget_setup: sof-audio-pci-intel-tgl 0000:00:1f.3: Create widget copier.host.13.1 instance 2 - pipe 13 - core 0
[ 19.595943] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx : 0x40020004|0xd0015: MOD_INIT_INSTANCE [data size: 84]
[ 19.596275] snd_sof:sof_ipc4_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx reply: 0x60000068|0xd0015: MOD_INIT_INSTANCE
[ 19.596281] sof-audio-pci-intel-tgl 0000:00:1f.3: FW reported error: 104 - Other failure of module instance initialization request
[ 19.596303] sof-audio-pci-intel-tgl 0000:00:1f.3: ipc error for msg 0x40020004|0xd0015
[ 19.596313] Message payload: 00000000: 0000066f 00000300 00000300 00000001
[ 19.596317] Message payload: 00000010: 0000bb80 00000020 ffff3210 00000004
[ 19.596320] Message payload: 00000020: 00000000 00002004 0000bb80 00000020
[ 19.596323] Message payload: 00000030: ffff3210 00000004 00000000 00002004
[ 19.596326] Message payload: 00000040: 00000000 00000100 00000600 00000001
[ 19.596327] Message payload: 00000050: 00000000
[ 19.596329] sof-audio-pci-intel-tgl 0000:00:1f.3: failed to create module copier.host.13.1

dmesg_capture_err.txt
The topology is:

[plbossart]

I am still struggling to understand this PR @bardliao, I managed to capture audio with the demux/IPC3 without changing anything at the kernel level, so wondering if this isn't more of an IPC4 specific state machine or topology requirement that we are missing.

[bardliao]

I am still struggling to understand this PR @bardliao, I managed to capture audio with the demux/IPC3 without changing anything at the kernel level, so wondering if this isn't more of an IPC4 specific state machine or topology requirement that we are missing.

Thanks @plbossart I will check what is the difference between IPC3 and IPC4.

[bardliao]

I am still struggling to understand this PR @bardliao, I managed to capture audio with the demux/IPC3 without changing anything at the kernel level, so wondering if this isn't more of an IPC4 specific state machine or topology requirement that we are missing.

Thanks @plbossart I will check what is the difference between IPC3 and IPC4.

@plbossart After testing with thesofproject/sof#6131, I didn't see different behavior between IPC3 and IPC4 on kernel side. Both pipeline 32 and pipeline 35 are setup. But firmware didn't report error on it.
Then, I tested IPC4 multi stream capture with cSOF, and get the same result. i.e. No "FW reported error:".
I double checked the issue only happen with the IPC4 tester.
However, I am wondering is it correct to setting-up irrelevant widgets?

[plbossart]

Thanks for testing @bardliao

Setting-up 'irrelevant widgets' might not be optimal but I see no reason why it would cause an error.

It's likely that we miss something in the IPC4 sequences.

[bardliao]

Thanks for testing @bardliao

Setting-up 'irrelevant widgets' might not be optimal but I see no reason why it would cause an error.

It's likely that we miss something in the IPC4 sequences.

Agree, close it for now

[bardliao]

@plbossart An issue is that we use stream_tag as host copier's node_id's index id.
https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/ipc4-topology.c#L1150
It works well if we setup a host per pcm. But it will lead to an issue that we have the same node id if we setup two host in one pcm.
@ranj063 FYI

[plbossart]

Indeed the copier node_id cannot be related to stream_tag values. That's a conceptual bug, probably coming from the good old days of the single host-dai pipeline.

@ranj063 any comments?

[ranj063]

Indeed the copier node_id cannot be related to stream_tag values. That's a conceptual bug, probably coming from the good old days of the single host-dai pipeline.

@ranj063 any comments?

@bardliao@plbossart I'm struggling to understand the problem. What is an irrelevant widget? In the topology above, is the second copier irrelevant? If so, why?

[ranj063]

@bardliao Now that I understand the problem better, I think that switching the order of preparing/setting up widgets frrom host->dai is not the right solution. The walk_widgets_in_order() function was introduced for a very specific reason i.e to walk from the source to the sink in all cases and prepare the widgets in that order so that the input/output hw_params are propagated appropriately. Please stay tuned for the right fix.

[ranj063]

@bardliao@plbossart#3858 is the alternate fix

[bardliao]

@bardliao Now that I understand the problem better, I think that switching the order of preparing/setting up widgets frrom host->dai is not the right solution. The walk_widgets_in_order() function was introduced for a very specific reason i.e to walk from the source to the sink in all cases and prepare the widgets in that order so that the input/output hw_params are propagated appropriately. Please stay tuned for the right fix.

Thanks for the explanation. @ranj063