[tlauda]

Changes pipeline behavior to trigger pipelines with
the same scheduling component. This change allows
for properly triggering topologies with mixer.

Signed-off-by: Tomasz Lauda tomasz.lauda@linux.intel.com

[tlauda]

@ranj063 @singalsu In order for this change to work we need to update mixer topologies - pcm media pipelines should have the same scheduling id as low latency pipeline (similar to detect pipeline). Could someone introduce such change in m4 scripts?

[lgirdwood]

Not sure we want to change M4 scheduling config as the media PCM is intended to show mixing of two pipelines with different scheduling configuration e.g. low latency and media decode. We may have to make the media PCM mixer source buffer larger if mixer is starving though....

[tlauda]

@lgirdwood PCM media pipeline is connected to the low latency pipeline with mixer, but it doesn't have any scheduling component. It should have the same as ll pipeline, so the FW would know it should copy its source. It's the mixer copy thing we have discussed some time ago. It has nothing to do with the buffer size. Both pipelines will still work on the same DMA interrupt.

[dbaluta]

@tlauda I have some generic questions about pipelines and scheduling components. Feel free
to answer if time allows you that:

1. What is a scheduling component? Is the first component in the pipeline?
2. Is the host component always the first component in the pipeline?
3. What is a low latency pipeline? Are there any more "types" of pipelines.

[dbaluta]

Why don't you put pipeline_is_same_sched_comp on the same line with int is_same_sched? It does fit inside 80 char limit.

[tlauda]

@dbaluta But then ppl_data->start->pipeline can't be aligned with opening bracket, because it will exceed 80 chars.

[dbaluta]

oh, ok. I see your point.

[lgirdwood]

@lgirdwood PCM media pipeline is connected to the low latency pipeline with mixer, but it doesn't have any scheduling component. It should have the same as ll pipeline, so the FW would know it should copy its source. It's the mixer copy thing we have discussed some time ago. It has nothing to do with the buffer size. Both pipelines will still work on the same DMA interrupt.

My question was more about two pipelines that were scheduled differently (whether using different periods or clock domains or both) and joined via the mixer, this is something we should support.

[tlauda]

@tlauda I have some generic questions about pipelines and scheduling components. Feel free
to answer if time allows you that:

1. What is a scheduling component? Is the first component in the pipeline?
2. Is the host component always the first component in the pipeline?
3. What is a low latency pipeline? Are there any more "types" of pipelines.

1. In our case it's always DAI, but in theory it can be any component that will drive pipeline schedule.
2. Not really, it can be any component basically.
3. I've called it low latency, because it was the name given in the m4 script. I'm not really sure what does it mean exactly in this case and why it was called like that. As for types of pipelines, I don't think we have any generic names. Usually we call them capture and playback and maybe specify the interface e.g. SSP, DMIC, HDA.

@lgirdwood PCM media pipeline is connected to the low latency pipeline with mixer, but it doesn't have any scheduling component. It should have the same as ll pipeline, so the FW would know it should copy its source. It's the mixer copy thing we have discussed some time ago. It has nothing to do with the buffer size. Both pipelines will still work on the same DMA interrupt.

My question was more about two pipelines that were scheduled differently (whether using different periods or clock domains or both) and joined via the mixer, this is something we should support.

Yes, definitely, but it's a bigger feature than this simple fix. This patch simply fixes the currently used pipeline topologies with mixer.

[tlauda]

@lgirdwood Any thoughts? If you agree with this approach, we could proceed with the topology changes. Of course this is not the final resolution and scheduling of connected pipelines needs to be revisited.

[lgirdwood]

@tlauda fine by me, as long as we will add the pipeline scheduling updates for different periods in a subsequent PR (for 1.4 ?)