[Sound-open-firmware] Questions about the DAI DMA/pipeline flow
Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored).
What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms).
Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes?
I see couple of problems here: 1. Preload finishes too quickly - what does it exactly mean? As far as I remember you have direct access to the host, so probably your memcpy is done very fast and there is nothing else to wait for. 2. On preload finish DAI and DMA are just started, so there should be at least 1 ms difference between finishing preload task and next pipeline copy schedule. It indicates some kind of problem with DMA interrupts on your side.
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, September 5, 2019 9:03 AM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DAI DMA/pipeline flow
Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored).
What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms).
Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes? _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware --------------------------------------------------------------------
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
1. I'm not talking about the host DMA but the DAI one. I don't think I'm seeing any issues with the host DMA, though I won't submit it until I see that everything works. Preload finishes quickly in the sense that before exiting from the dma_start() function on the DAI DMA I'm already getting an IRQ and running its callback. 2. So I should investigate why the DAI DMA sends an interrupt rather quickly after setting the "start" bit in the corresponding register? Given that it's 384 bytes and the DAI itself (ESAI) holds a buffer with the samples that it will later send to the codec.
(I'm also not getting any interrupts from the DAI at all, at least not the expected ones; guess I should look into that too)
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Thursday, September 5, 2019 10:27 AM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
I see couple of problems here: 1. Preload finishes too quickly - what does it exactly mean? As far as I remember you have direct access to the host, so probably your memcpy is done very fast and there is nothing else to wait for. 2. On preload finish DAI and DMA are just started, so there should be at least 1 ms difference between finishing preload task and next pipeline copy schedule. It indicates some kind of problem with DMA interrupts on your side.
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, September 5, 2019 9:03 AM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DAI DMA/pipeline flow
Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored).
What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms).
Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes? _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al... --------------------------------------------------------------------
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
It definitely looks like the problem with interrupts. I don't know any specifics about your DMA, but it seems that you are either registered on the wrong irq or your transfer settings are wrong and it triggers immediately.
Tomek
-----Original Message----- From: Paul Olaru [mailto:paul.olaru@nxp.com] Sent: Thursday, September 5, 2019 9:32 AM To: Lauda, Tomasz tomasz.lauda@intel.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
1. I'm not talking about the host DMA but the DAI one. I don't think I'm seeing any issues with the host DMA, though I won't submit it until I see that everything works. Preload finishes quickly in the sense that before exiting from the dma_start() function on the DAI DMA I'm already getting an IRQ and running its callback. 2. So I should investigate why the DAI DMA sends an interrupt rather quickly after setting the "start" bit in the corresponding register? Given that it's 384 bytes and the DAI itself (ESAI) holds a buffer with the samples that it will later send to the codec.
(I'm also not getting any interrupts from the DAI at all, at least not the expected ones; guess I should look into that too)
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Thursday, September 5, 2019 10:27 AM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
I see couple of problems here: 1. Preload finishes too quickly - what does it exactly mean? As far as I remember you have direct access to the host, so probably your memcpy is done very fast and there is nothing else to wait for. 2. On preload finish DAI and DMA are just started, so there should be at least 1 ms difference between finishing preload task and next pipeline copy schedule. It indicates some kind of problem with DMA interrupts on your side.
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, September 5, 2019 9:03 AM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DAI DMA/pipeline flow
Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored).
What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms).
Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes? _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al... --------------------------------------------------------------------
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
From what I understood, shouldn't start() actually trigger an immediate transfer, but only allow the DAI to trigger it via the hardware request mechanism? My current implementation triggers an immediate transfer and I'm getting the interrupt after the transfer was done.
I may need to look into the ESAI driver more to see why I'm not getting the regular interrupt, nor a hardware request. All I'm getting is the ESAI DMA channel interrupt once the 384 bytes are transferred to the ESAI internal buffer.
Could the problem be from the ESAI itself, not requesting the interrupt? I still don't trust my implementation of the driver for the moment.
Unrelated to most of the above discussion, should I submit draft pull requests with the current state of the i.MX drivers I'm currently working on (Dummy DMA for the host, EDMA for the DAI and ESAI which is the DAI itself)? Maybe there is something obvious that isn't hardware specific that I'm doing wrong.
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Thursday, September 5, 2019 11:14 AM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
It definitely looks like the problem with interrupts. I don't know any specifics about your DMA, but it seems that you are either registered on the wrong irq or your transfer settings are wrong and it triggers immediately.
Tomek
-----Original Message----- From: Paul Olaru [mailto:paul.olaru@nxp.com] Sent: Thursday, September 5, 2019 9:32 AM To: Lauda, Tomasz tomasz.lauda@intel.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
1. I'm not talking about the host DMA but the DAI one. I don't think I'm seeing any issues with the host DMA, though I won't submit it until I see that everything works. Preload finishes quickly in the sense that before exiting from the dma_start() function on the DAI DMA I'm already getting an IRQ and running its callback. 2. So I should investigate why the DAI DMA sends an interrupt rather quickly after setting the "start" bit in the corresponding register? Given that it's 384 bytes and the DAI itself (ESAI) holds a buffer with the samples that it will later send to the codec.
(I'm also not getting any interrupts from the DAI at all, at least not the expected ones; guess I should look into that too)
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Thursday, September 5, 2019 10:27 AM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
I see couple of problems here: 1. Preload finishes too quickly - what does it exactly mean? As far as I remember you have direct access to the host, so probably your memcpy is done very fast and there is nothing else to wait for. 2. On preload finish DAI and DMA are just started, so there should be at least 1 ms difference between finishing preload task and next pipeline copy schedule. It indicates some kind of problem with DMA interrupts on your side.
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, September 5, 2019 9:03 AM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DAI DMA/pipeline flow
Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored).
What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms).
Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes? _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al... --------------------------------------------------------------------
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
--------------------------------------------------------------------
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
@all, for the next email threads let's try to use use plain-text mode for email clients and also bottom/inline posting (do not to post).
@Paul Olaru, it might be an EDMA configuration issue but we really need to understand how EDMA drivers integrates with SOF insfrastructure.
Please send PRs for DMAs and DAIs you have. We can start the discussion from there.
thanks, Daniel.
On Thu, Sep 5, 2019 at 12:04 PM Paul Olaru paul.olaru@nxp.com wrote:
From what I understood, shouldn't start() actually trigger an immediate transfer, but only allow the DAI to trigger it via the hardware request mechanism? My current implementation triggers an immediate transfer and I'm getting the interrupt after the transfer was done.
I may need to look into the ESAI driver more to see why I'm not getting the regular interrupt, nor a hardware request. All I'm getting is the ESAI DMA channel interrupt once the 384 bytes are transferred to the ESAI internal buffer.
Could the problem be from the ESAI itself, not requesting the interrupt? I still don't trust my implementation of the driver for the moment.
Unrelated to most of the above discussion, should I submit draft pull requests with the current state of the i.MX drivers I'm currently working on (Dummy DMA for the host, EDMA for the DAI and ESAI which is the DAI itself)? Maybe there is something obvious that isn't hardware specific that I'm doing wrong.
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Thursday, September 5, 2019 11:14 AM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
It definitely looks like the problem with interrupts. I don't know any specifics about your DMA, but it seems that you are either registered on the wrong irq or your transfer settings are wrong and it triggers immediately.
Tomek
-----Original Message----- From: Paul Olaru [mailto:paul.olaru@nxp.com] Sent: Thursday, September 5, 2019 9:32 AM To: Lauda, Tomasz tomasz.lauda@intel.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
- I'm not talking about the host DMA but the DAI one. I don't think I'm seeing any issues with the host DMA, though I won't submit it until I see that everything works. Preload finishes quickly in the sense that before exiting from the dma_start() function on the DAI DMA I'm already getting an IRQ and running its callback.
- So I should investigate why the DAI DMA sends an interrupt rather quickly after setting the "start" bit in the corresponding register? Given that it's 384 bytes and the DAI itself (ESAI) holds a buffer with the samples that it will later send to the codec.
(I'm also not getting any interrupts from the DAI at all, at least not the expected ones; guess I should look into that too)
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Thursday, September 5, 2019 10:27 AM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DAI DMA/pipeline flow
I see couple of problems here:
- Preload finishes too quickly - what does it exactly mean? As far as I remember you have direct access to the host, so probably your memcpy is done very fast and there is nothing else to wait for.
- On preload finish DAI and DMA are just started, so there should be at least 1 ms difference between finishing preload task and next pipeline copy schedule. It indicates some kind of problem with DMA interrupts on your side.
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, September 5, 2019 9:03 AM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DAI DMA/pipeline flow
Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored).
What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms).
Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes? _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
participants (3)
-
Daniel Baluta -
Lauda, Tomasz -
Paul Olaru