audio: pipeline: do not propagate pipeline triggers for IPC4

kv2019i · kv2019i · commit fbce9c32db8c · 2023-11-21T13:11:18.000+02:00
One major difference in IPC4 versus IPC3 is that each pipeline will get a separate SET_PIPELINE_STATE command. This is in stark contrast to IPC3 where host sends STREAM_TRIG_START and firmware is expected to propagate the state change to all connected pipelines in the graph. Change the code such that when pipeline component trigger is executed in IPC4 build, propagation is stopped whenever we reach another pipeline. This prevents bugs stemming from IPC3 related logic to propagate pipeline triggers, interfering with IPC4 usages like in bug 8481. Link: #8481 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
diff --git a/src/audio/pipeline/pipeline-stream.c b/src/audio/pipeline/pipeline-stream.c
@@ -352,6 +352,20 @@ static int pipeline_comp_trigger(struct comp_dev *current,
 		 "pipeline_comp_trigger(), current->comp.id = %u, dir = %u",
 		 dev_comp_id(current), dir);
 
+#if CONFIG_IPC_MAJOR_4
+	/*
+	 * IPC4 has a SET_PIPELINE_STATE for each pipeline, so FW
+	 * should not propagate triggers on its own.
+	 * IPC3 has commands only for graph edges, so propagation is required.
+	 */
+	if (!is_single_ppl) {
+		pipe_dbg(current->pipeline,
+			 "pipeline_comp_trigger(), stop trigger propagation at comp.id = %u",
+			 dev_comp_id(current));
+		return 0;
+	}
+#endif
+
 	switch (ppl_data->cmd) {
 	case COMP_TRIGGER_PRE_RELEASE:
 	case COMP_TRIGGER_PRE_START:
