[FEATURE] Extend zephyr_ll to get its LL system tick from the DMA IRQ

[iuliana-prodan]

Is your feature request related to a problem? Please describe.
Now the zephyr_ll gets its LL system tick from the timer. This runs in IRQ context and is non preemptable.
Therefore is limited to timer_domain - see here

Describe the solution you'd like
Extend zephy_ll to get its LL system tick from the DMA IRQ

Additional context
See more comments here

[marc-hb]

From #4503

in i.MX case, we don't want to use zephyr_ll since this is limited to TIMER_DOMAIN (see here) and we are using DMA_DOMAIN. We want, for now, to keep using ll_schedule.

so DMA domain is becoming problematic as it does not scale well to multiple low latency streams (it's simple and great when there is a smaller number of streams though) or when the codec is driving the clocks.
I think we need to improve the DMA driven domain as follows.

Today we have

Zephyr LL gets its LL system tick from the timer. This runs in IRQ context and is non preemtable.
LL system tick wakes up high priority LL thread.
LL thread executes pipeline work.
We need to make one change to support DMA domain here and make it synchronous. Step 1 should also be able to be

Zephyr LL gets its LL system tick from the DMA IRQ. This runs in IRQ context and is non preemtable.
This means we keep the DMA based time domain and we can also scale all LL streams to this time domain.

Fwiw, this is how things worked on OMAP4, the topology would tell FW which DMA channel was to be used as time domain. If the DMA channel stopped then FW had to then use the DMA channel from the next running stream. PR #4471 is allowing the trigger(start|stops) to be synchronised and this would mean that DMA IRQs could also be synchronised.

[marc-hb]

@lyakh is this still relevant?

[dbaluta]

This feature is implemented under CONFIG_DMA_DOMAIN.