Skip to content

Commit e4ccefa

Browse files
Revert "ipc4: handler: maintain IPC set_pipeline_state order"
This reverts commit 05bffd7. The LL scheduler already guarantees that pipelines run in the order they were triggered by the host (while respecting priorities). The original workaround (#8504), which is now being reverted, has few problems: adds 1 ms startup latency per pipeline, ignores pipeline priorities and, hopefully, is unnecessary. The original workaround was added as a result of investigating issue #8481. I believe there were two different problems that both caused the same issue. The first is a problem in the topology. The driver sent a multi-pipeline start for pipelines 0 and 1, meaning the driver expects pipeline 1 to start after pipeline 0. However, pipeline 0 was created with priority 1 and pipeline 1 with priority 0, so the firmware started pipeline 1 first. However, fixing the priority in the topology did not change the pipeline start order. This was probably caused by a bug in the firmware: complex IPC3 pipeline triggering logic was used instead of straightforward IPC4 logic. This appears to have been fixed by #8506. I'm not exactly sure why the original workaround with wait_for_compound_msg() was added. Perhaps having two problems causing the same issue simultaneously led to some confusion during verification. Let's try removing it, and if we encounter any problems with pipeline triggering order (hopefully not), we'll fix them elsewhere.
1 parent c291489 commit e4ccefa

1 file changed

Lines changed: 0 additions & 11 deletions

File tree

src/ipc/ipc4/handler-user.c

Lines changed: 0 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -543,17 +543,6 @@ static int ipc4_set_pipeline_state(struct ipc4_message_request *ipc4)
543543
ipc_compound_pre_start(state.primary.r.type);
544544
ret = ipc4_pipeline_trigger(ppl_icd, cmd, &delayed);
545545
ipc_compound_post_start(state.primary.r.type, ret, delayed);
546-
if (delayed) {
547-
/* To maintain pipeline order for triggers, we must
548-
* do a blocking wait until trigger is processed.
549-
* This will add a max delay of 'ppl_count' LL ticks
550-
* to process the full trigger list.
551-
*/
552-
if (ipc_wait_for_compound_msg() != 0) {
553-
ipc_cmd_err(&ipc_tr, "ipc4: fail with delayed trigger");
554-
return IPC4_FAILURE;
555-
}
556-
}
557546
}
558547

559548
if (ret != 0)

0 commit comments

Comments
 (0)