[RFC]ll_schedule: refine to schedule period task no later than half period

[keyonjie]

For period task like DMIC/SSP pipeline, starting the first copying too
late may lead to xrun after the DAI is started.

Change to ask for earlier first-time scheduling (not later than half
period) to avoid this kind of issue as more as possible.

Signed-off-by: Keyon Jie yang.jie@linux.intel.com

[lgirdwood]

I think we have a race between enabling the DAI/DMA (which is the result of an async IPC) and copy the data (which is periodic).
It's probably a lot better if we do

1. On IPC trigger start keep pipeline in inactive state but add it to scheduler list.
2. When scheduler next runs we enable the endpoints on any pipeline that is in the inactive state before we do copy.

@iuliana-prodan @dbaluta fyi - I think you had a similar issue recently.

[iuliana-prodan]

@iuliana-prodan @dbaluta fyi - I think you had a similar issue recently.

The issue we had was #3809 and was fixed by #3867 pull request.

I see that this pull request is linked to #3939 bug, on sof-tgl-nocodec-ci.tplg which seems to use SCHEDULE_TIME_DOMAIN_TIMER.

On i.MX we are using SCHEDULE_TIME_DOMAIN_DMA. The problem we had was that on multiple start/stop runs for playback or record or combined, we got an underrun/overflow. That was because the DAI made a DMA request, before the DMA channel was enabled.

[paulstelian97]

Please resubmit with "main" as PR base branch.

[keyonjie]

I think we have a race between enabling the DAI/DMA (which is the result of an async IPC) and copy the data (which is periodic).
It's probably a lot better if we do

1. On IPC trigger start keep pipeline in inactive state but add it to scheduler list.
2. When scheduler next runs we enable the endpoints on any pipeline that is in the inactive state before we do copy.

@lgirdwood I thought about this, but sometimes we do need start the endpoints first to prepare and avoid underrun for capture case. At the same time that solution will requires more changes (e.g. add generic synchronization/notification b/w scheduler and client like pipeline, change the pipeline prepare and state machine, ...)

Here what I change is legit to me, for all pipeline copy tasks with 'start' = 0, we should schedule it ASAP, the align to period policy I added previous is aimed to simplify the scheduling policy and avoid doing it fragment, that helped for scheduler performance, but we do need a compromise b/w the scheduling real-time and the alignment among tasks here.