Repository navigation
schedule: implement dma_single_chan_domain - #1893
Conversation
9bb4d12 to
6ee7912
Compare
|
SOFCI TEST |
6ee7912 to
23e1861
Compare
|
SOFCI TEST |
11d51c6 to
e153e73
Compare
Adds new NOTIFIER_ID_DMA_DOMAIN_CHANGE. This id will be used by DMA single channel scheduling domain. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Adds DMA channel period value to dma_chan_data. We can now easily retrieve the period value of DMA channel transfers. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Some ll scheduling domains require to have interrupt cleared right at the beginning of handler. Clear domain earlier to fulfill that requirement. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Adds implementation of DMA single channel scheduling domain. This domain allows to schedule all the tasks on all the cores on single DMA channel interrupt. This way we have only one interrupt source and we don't need to worry about handling many interrupts. We always select the channel with the lowest period. This domain cannot be used with the DMAs, which require to manually reload the next data to be transferred e.g. DW-DMA on BYT or HSW. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Fixes pipe-dai-capture and pipe-dai-playback pipelines to use passed DAI_PERIODS value instead of hardcoded. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Uses DAI_PERIODS in calculation of DAI buffer size. In case the DAI_PERIODS value is undefined, we use DAI_DEFAULT_PERIOD value of 2. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Changes number of SSP and DMIC DAI periods from 2 to 3. This way we can support both timer and new single DMA channel scheduling. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Changes number of SSP, DMIC and ALH DAI periods from 2 to 3. This way we can support both timer and new single DMA channel scheduling. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Changes number of SSP, DMIC and ALH DAI periods from 2 to 3. This way we can support both timer and new single DMA channel scheduling. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Changes number of SSP and DMIC DAI periods from 2 to 3. This way we can support both timer and new single DMA channel scheduling. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Changes number of DMIC DAI periods from 2 to 3. This way we can support both timer and new single DMA channel scheduling. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Switches from DMA multi channel domain to single channel as the scheduling source for one of the low latency schedulers for cAVS platforms. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
Doesn't copy sink component, if it's not active. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
With new schedulers implementations we don't need to trigger pipeline in atomic context anymore. Signed-off-by: Tomasz Lauda <tomasz.lauda@linux.intel.com>
e153e73 to
5edb438
Compare
|
SOFCI TEST |
|
@tlauda I'm having trouble trying to rebase on top of this patchset. My current version of topic/imx_wip (which contains the incomplete ESAI driver as well as some testing code which shall not be submitted) works fine for the most part (minor issues). After rebasing on top of this PR I'm getting some interesting freezes on Stop (Xrun and the DSP becomes unresponsive to future IPCs). Is there something I need to do with my DMA drivers to fix that? |
|
@paulstelian97 It's weird. This patch just adds new domain (which I assume you don't even use) and mostly makes some topology changes. Other than that, just some cosmetics. Could you verify if reverting "pipeline: trigger pipeline in non-atomic context" helps? |
|
I will try that after regenerating the topology files (may that be a possibility as well?) |
|
Doesn't seem to help for some reason. And from what I have seen (I tried) I don't think I can rebase on top of individual commits without getting even worse breakage (to be able to identify the culprit). Any pointers on how I can check? |
|
The only thing that can potentially break anything is the last commit from this PR. It's small change, so just remove it manually. I don't see any other potential causes. |
|
Well reverting this one doesn't seem to help. So guess I'll have to directly compare the branches so I see what changes have been introduced and what could be the cause. Rebasing on top of 938652a also seems to cause issues, so I partially reverted that one locally too. |
|
b283637 seems to also cause big trouble and I cannot rebase on top of it. Which is pretty funny. With this one added in (but none of the newer ones, and the other one with the timers reverted) I'm unable to make it work. Also tried to add an extra uint32_t field just to allow that to align and it still breaks. |
|
Removing the reads from dev->pipeline->ipc_pipe in params (for host and dai, not sure if I can just remove one of them, will test now) also makes it fine. So it's not an alignment issue. |
|
I need to know what already uses said period so I can investigate. Because while I can see it being valid in the print I get serious issues with actually using it. |
|
It's only used by DMA single channel domain, so it seems you have some kind of memory leaks, rather than functionality problems. |
|
I will try to rebase and revert each commit which causes trouble at least in part and let you know which changes actually cause me trouble. |
|
Alright, apparently something has suddenly become a lot more time-sensitive and our local hacks for traces (a serial console driver which operates in polling mode) causes IPCs to be dropped in such a way that everything breaks. Sorry for bothering. Even without reverting the commit you mentioned I still don't have issues, although I now have other issues (cannot figure out at all how to reliably get traces from the test board now that serial is no longer an option -- dtrace drops WAY too many logs ("589 logs dropped" and similar), etrace is finnicky and I don't fully trust my Dummy DMA driver to properly transfer the traces for dtrace) |
Adds implementation of DMA single channel scheduling domain.
This domain allows to schedule all the tasks on all the cores
on single DMA channel interrupt. This way we have only one
interrupt source and we don't need to worry about handling
many interrupts. We always select the channel with the lowest
period. This domain cannot be used with the DMAs, which require
to manually reload the next data to be transferred e.g. DW-DMA
on BYT or HSW.
Signed-off-by: Tomasz Lauda tomasz.lauda@linux.intel.com