[FEATURE] update system agent to deal with DMA scheduling

[plbossart]

Is your feature request related to a problem? Please describe.
Follow-up to #2671, let's make sure the system agent does work with DMA-based scheduling (either disabled or more intelligent)

No solution in mind, just making sure we don't forget about this thread.

[tlauda]

@lgirdwood @mmaka1 Any ideas on how to make it work with DMA based scheduling, other than disabling the agent? The whole purpose of the agent is to track drifts in system ticks. Accepting any other async source of the interrupts kills this purpose. We could think about scheduling such pipes as EDF tasks, but it won't work for platforms, where DMA expects real-time data reload.

[paulstelian97]

@lgirdwood @mmaka1 Any ideas on how to make it work with DMA based scheduling, other than disabling the agent? The whole purpose of the agent is to track drifts in system ticks. Accepting any other async source of the interrupts kills this purpose. We could think about scheduling such pipes as EDF tasks, but it won't work for platforms, where DMA expects real-time data reload.

Is it possible to have a hybrid approach, where platforms that don't require immediate reload can still schedule the DMA pipelines in EDF and benefit from the agent? The flow being something like: DMA driver is notified that an interrupt has arrived (possibly a new callback) if it needs to do something immediately, e.g. prepare new hardware transfer descriptors if the hardware itself cannot fetch them on its own, then pipeline is scheduled and when returning from the interrupt the pipeline will run as an EDF task.

[lgirdwood]

Agent needs to be aware of different time domains where drift will be expected and is non fatal up to a point. e.g. if DMA being clocked by external clock drifts > 10% per period then we can alert the user (no need to panic). We could pass in a flag here to agent from client to help.
We should only panic if we dont enter the idle loop every so often.