IPC4: fix for pipaline cleanup

[tmleman]

Regularly used flow when removing pipeline:

1. Set ppl state PAUSED,
2. Unbinding modules,
3. Set ppl state RESET,
4. Deleting Pipeline

Changes made:

• allowing to unbind modules under the same pipeline. It should be ignored under ipc4, but not cause an error.
• changing modules state during pipe reset, without this FW reports error at pipeline deletion.

[lgirdwood]

@marcinszkudlinski

[ranj063]

@tmleman can I ask you a question regarding the unbinding of modules, lets say you have a topology like this:

And pipeline 12 is stopped while pipeline 1 is still active. Should we unbind mixin12.1 and mixout.2.1 before pipeline 12 is deleted? Would it cause any issues because mixout.2.1 is in active state still?

[tmleman]

I made some research and its was my mistake to assume that unbind of modules under the same pipeline should be normally processed.
Documentation informs that this operation should be ignored, so error reporting via IPC is also incorrect.
@RanderWang will returning 0 and adding a warning in the log will be enough?

[ranj063]

@tmleman I didnt get what you mean by returning 0? in which case would be return 0? when 2 modules belong to different pipelines?

[tmleman]

return 0 instead of the error code as it has been done so far. Change is for case when modules belong to the same pipeline.

[RanderWang]

Tested on windows. Is pipaline a typo ?

[lgirdwood]

CI showing known and unrelated issues.

[RanderWang]

@tmleman for commit ipc4: fix pipeline reset I found a regression issue on windows. The problem is propagate_state_to_ppl_comp set component to reset and pipeline_reset will also set component to reset then a error will returned that the component is already set to reset. I want to know in which case pipeline_reset() can't set component to reset state ? It should set them to reset state and don't need to explicitly set it to reset

		ret = propagate_state_to_ppl_comp(ipc, id, COMP_TRIGGER_RESET);
		if (ret != 0)
			return ret;

		/* resource is not released by triggering reset which is used by current FW */
		ret = pipeline_reset(host->cd->pipeline, host->cd);

[tmleman]

@RanderWang function propagate_state_to_ppl_comp was added because pipeline_reset did not set reset state to pipeline components. If that has changed this function is no longer necessary.

[RanderWang]

@tmleman do you have any test case for me to validate it ? thanks. If none, I will remove this function

[tmleman]

@RanderWang can you point to a change that changes the behavior of pipeline_reset? I can't find in history in which cases problem described on commit message was visible.
I think it is best to let this change pass through our CI on some dev build.

[RanderWang]

@tmleman please check pipeline_reset function. I don't make any change but it should call comp_reset to set component state to reset. So I want to check your case to find why it doesn't work.

pipeline_reset
----  pipeline_comp_reset
-------- comp_reset

[tmleman]

@RanderWang earlier pipeline components was not set to RESET state and that caused error during pipeline delete. I don't see this behavior right now. My fault I didn't see pipeline_comp_reset. I think you can delete propagate_state_to_ppl_comp function.

[RanderWang]

@tmleman thanks for your explanation. I will do it.