Commit e4ccefa
committed
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
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
543 | 543 | | |
544 | 544 | | |
545 | 545 | | |
546 | | - | |
547 | | - | |
548 | | - | |
549 | | - | |
550 | | - | |
551 | | - | |
552 | | - | |
553 | | - | |
554 | | - | |
555 | | - | |
556 | | - | |
557 | 546 | | |
558 | 547 | | |
559 | 548 | | |
| |||
0 commit comments