ipc4: handler: maintain IPC set_pipeline_state order

[kv2019i]

Fix a side-effect of commit 068f143 ("ipc4: handler: Use separate loops for pipeline state phases") where the order of pipeline triggers was changed when the trigger handling was delayed to the pipeline thread. If host asked for pipelines to be triggered in order 0, 1, 2, the actual trigger order might end up as 2, 1, 0 based on how the pipes were connected.

Fix the issue by adding a blocking wait to the IPC thread between each delayed trigger.

Link: #8481

[kv2019i]

This is a bit heavyweight approach, let's see how this fares in CI.

Alternative approach would be to stop propagating pipeline triggers across pipelines in IPC4 (as in IPC4, host sends a separate IPC action to each pipe while in IPC3, only edge nodes of the graph are triggered and DSP traverses the graph to trigger connected pipes).

[RanderWang]

If pipeline priority is set, can zephyr schedule pipeline by priority ?

[plbossart]

If pipeline priority is set, can zephyr schedule pipeline by priority ?

scheduling for LL is not done at the pipeline level, the priority only defines the order in which LL modules will be handled.

[RanderWang]

If pipeline priority is set, can zephyr schedule pipeline by priority ?

scheduling for LL is not done at the pipeline level, the priority only defines the order in which LL modules will be handled.

For cSOF, pipeline is the basic schedule elements, not LL module (only pipeline calls schedule_task_init_ll, not module) . please check pipeline_task which triggers each module in the pipeline from source to sink.

[plbossart]

If pipeline priority is set, can zephyr schedule pipeline by priority ?

scheduling for LL is not done at the pipeline level, the priority only defines the order in which LL modules will be handled.

For cSOF, pipeline is the basic schedule elements, not LL module (only pipeline calls schedule_task_init_ll, not module) . please check pipeline_task which triggers each module in the pipeline from source to sink.

This will make no sense when LL and DP modules are mixed...

Is there any advantage to define LL & DP in single pipeline ? Suggest to define them in different pipelines in topology.

[RanderWang]

As I know, pipeline2.0 is being prepared, maybe it change the game

[lyakh]

hmm, so that means that in your example the IPC thread might be delayed by up to 3 (or more for more pipelines) ms? I guess it won't break anything, but maybe at least mention this in the comment above?

[kv2019i]

@lyakh Ack. I extended the comment to explain this, see updated patch.

[kv2019i]

@plbossart wrote:

@RanderWang wrote:

If pipeline priority is set, can zephyr schedule pipeline by priority ?

scheduling for LL is not done at the pipeline level, the priority only defines the order in which LL modules will be handled.

Ack on that. For LL tasks, we are using a single Zephyr thread per core, so we need to implement the expected behaviour within SOF LL scheduler logic, i.e. run the tasks in the priority order as requested by host when pipelines are set. And this is what also happens, so no problem here.

[kv2019i]

I pushed an alternative fix to this problem that avoids the delay in executing set_pipeline_states -> #8506

[kv2019i]

V2 and V3:

• extended the inline comment based on Guennadi's input
• clarified the git commit to explain that the order is changed if host asks for trigger order that is different from the order LL will schedule the pipeline tasks (based on their priority)

[kv2019i]

Dropped the title link to bug #8481 . This will help to avoid the dmic -ENODATA error seen in that case, but this change is required anyways for FW to comply to host requested pipeline trigger order.

[lyakh]

a bit scary, but we don't have a better solution so far

[kv2019i]

SOFCI TEST