[Sound-open-firmware] Questions about the DMA driver flow in SOF
I need to understand the general flow on how a DMA driver should Work in SOF. In particular what each callback should do.
I get channel_get, channel_put, start, stop, pause, release (although I don't quite get the nuance between stop and pause, or between start and release; thankfully I hope it's not important if I treat them the same). I get most of the others too, at least for the most part.
What I don't get at all is how the copy callback should work. In the DW DMA driver it seems to just run the callback and do something based on what the callback set in next, in HDA it seems to wait for the host buffer to be full or empty (I think this one may be the more intuitive one?) and the link HDA DMA seems to again just run the callback.
What should the copy callback really do? Is it different between a host DMA and a DAI DMA?
Hi Paul,
DAI DMA is the one, which interrupts usually drive the scheduling of the pipeline (the other possibility is timer). IRQ callback should be called in the interrupt handler of the DMA and in our case DAI schedules pipeline copy in such cb. Next is used to transfer information from DAI callback function back to the DMA and based on this information DMA executes some additional action e.g. after getting an interrupt we need to load the next linked list item in order for the DMA to continue the data transfer. COPY callback should be called in dma_copy and it's used to tell DAI how much data has been copied, so it can increment read/write pointers of the buffer. I must admit, that this solution is very hard to follow and I'm working on little simplification, but it's tough to write common handling code for different types of DMAs. Does your DMA also use interrupts to schedule the pipe?
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, August 29, 2019 4:27 PM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DMA driver flow in SOF
I need to understand the general flow on how a DMA driver should Work in SOF. In particular what each callback should do.
I get channel_get, channel_put, start, stop, pause, release (although I don't quite get the nuance between stop and pause, or between start and release; thankfully I hope it's not important if I treat them the same). I get most of the others too, at least for the most part.
What I don't get at all is how the copy callback should work. In the DW DMA driver it seems to just run the callback and do something based on what the callback set in next, in HDA it seems to wait for the host buffer to be full or empty (I think this one may be the more intuitive one?) and the link HDA DMA seems to again just run the callback.
What should the copy callback really do? Is it different between a host DMA and a DAI DMA? _______________________________________________ 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.
In the old framework, the DMA interrupts were indeed those that scheduled the pipe. I'm not sure if the iMX platform even has a driver for timers in SOF at the moment.
So copy() just reports on how much has been copied already? I do get that the IRQ callback is to be called inside the IRQ handler (currently I'm having issues with the driver implementation and I'm not sure if it's due to the implementation itself or due to me not understanding this properly in implementing the host DMA).
For how to interpret the information in next(), would the DW driver be good inspiration? The HDA one?
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Friday, August 30, 2019 12:43 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DMA driver flow in SOF
Hi Paul,
DAI DMA is the one, which interrupts usually drive the scheduling of the pipeline (the other possibility is timer). IRQ callback should be called in the interrupt handler of the DMA and in our case DAI schedules pipeline copy in such cb. Next is used to transfer information from DAI callback function back to the DMA and based on this information DMA executes some additional action e.g. after getting an interrupt we need to load the next linked list item in order for the DMA to continue the data transfer. COPY callback should be called in dma_copy and it's used to tell DAI how much data has been copied, so it can increment read/write pointers of the buffer. I must admit, that this solution is very hard to follow and I'm working on little simplification, but it's tough to write common handling code for different types of DMAs. Does your DMA also use interrupts to schedule the pipe?
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, August 29, 2019 4:27 PM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DMA driver flow in SOF
I need to understand the general flow on how a DMA driver should Work in SOF. In particular what each callback should do.
I get channel_get, channel_put, start, stop, pause, release (although I don't quite get the nuance between stop and pause, or between start and release; thankfully I hope it's not important if I treat them the same). I get most of the others too, at least for the most part.
What I don't get at all is how the copy callback should work. In the DW DMA driver it seems to just run the callback and do something based on what the callback set in next, in HDA it seems to wait for the host buffer to be full or empty (I think this one may be the more intuitive one?) and the link HDA DMA seems to again just run the callback.
What should the copy callback really do? Is it different between a host DMA and a DAI DMA? _______________________________________________ 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 depends whether you need to interpret it at all. HDA DMA always do the same thing, so it doesn't need it. The only drivers using it is DW-DMA.
Tomek
-----Original Message----- From: Paul Olaru [mailto:paul.olaru@nxp.com] Sent: Friday, August 30, 2019 11:56 AM To: Lauda, Tomasz tomasz.lauda@intel.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DMA driver flow in SOF
In the old framework, the DMA interrupts were indeed those that scheduled the pipe. I'm not sure if the iMX platform even has a driver for timers in SOF at the moment.
So copy() just reports on how much has been copied already? I do get that the IRQ callback is to be called inside the IRQ handler (currently I'm having issues with the driver implementation and I'm not sure if it's due to the implementation itself or due to me not understanding this properly in implementing the host DMA).
For how to interpret the information in next(), would the DW driver be good inspiration? The HDA one?
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Friday, August 30, 2019 12:43 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DMA driver flow in SOF
Hi Paul,
DAI DMA is the one, which interrupts usually drive the scheduling of the pipeline (the other possibility is timer). IRQ callback should be called in the interrupt handler of the DMA and in our case DAI schedules pipeline copy in such cb. Next is used to transfer information from DAI callback function back to the DMA and based on this information DMA executes some additional action e.g. after getting an interrupt we need to load the next linked list item in order for the DMA to continue the data transfer. COPY callback should be called in dma_copy and it's used to tell DAI how much data has been copied, so it can increment read/write pointers of the buffer. I must admit, that this solution is very hard to follow and I'm working on little simplification, but it's tough to write common handling code for different types of DMAs. Does your DMA also use interrupts to schedule the pipe?
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, August 29, 2019 4:27 PM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DMA driver flow in SOF
I need to understand the general flow on how a DMA driver should Work in SOF. In particular what each callback should do.
I get channel_get, channel_put, start, stop, pause, release (although I don't quite get the nuance between stop and pause, or between start and release; thankfully I hope it's not important if I treat them the same). I get most of the others too, at least for the most part.
What I don't get at all is how the copy callback should work. In the DW DMA driver it seems to just run the callback and do something based on what the callback set in next, in HDA it seems to wait for the host buffer to be full or empty (I think this one may be the more intuitive one?) and the link HDA DMA seems to again just run the callback.
What should the copy callback really do? Is it different between a host DMA and a DAI DMA? _______________________________________________ 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.
If I have hardware support for scatter-gather (and btw, I enable scatter-gather unconditionally for the moment since I don't get what I'm getting in set_config, two dma_sg_elems with scatter-gather disabled?), hardware activation (the DAI can trigger the DMA automatically in hardware), do I need to consider what the callback writes in next?
Or would the approach of setting next.elem.size to bytes for the COPY callback and using an uninitialized structor for the IRQ callback work just fine?
I suspect the driver should also record how many bytes are transferred overall so that copy() could work properly if called non-blocking?
I also still wonder what I should do with the host DMA (which isn't even a hardware DMA, given that the DSP has full, direct access to the host memory). I suspect a few things are broken due to this one too. ________________________________ From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Friday, August 30, 2019 1:05 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org sound-open-firmware@alsa-project.org Subject: RE: Questions about the DMA driver flow in SOF
It depends whether you need to interpret it at all. HDA DMA always do the same thing, so it doesn't need it. The only drivers using it is DW-DMA.
Tomek
-----Original Message----- From: Paul Olaru [mailto:paul.olaru@nxp.com] Sent: Friday, August 30, 2019 11:56 AM To: Lauda, Tomasz tomasz.lauda@intel.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DMA driver flow in SOF
In the old framework, the DMA interrupts were indeed those that scheduled the pipe. I'm not sure if the iMX platform even has a driver for timers in SOF at the moment.
So copy() just reports on how much has been copied already? I do get that the IRQ callback is to be called inside the IRQ handler (currently I'm having issues with the driver implementation and I'm not sure if it's due to the implementation itself or due to me not understanding this properly in implementing the host DMA).
For how to interpret the information in next(), would the DW driver be good inspiration? The HDA one?
-----Original Message----- From: Lauda, Tomasz tomasz.lauda@intel.com Sent: Friday, August 30, 2019 12:43 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: RE: Questions about the DMA driver flow in SOF
Hi Paul,
DAI DMA is the one, which interrupts usually drive the scheduling of the pipeline (the other possibility is timer). IRQ callback should be called in the interrupt handler of the DMA and in our case DAI schedules pipeline copy in such cb. Next is used to transfer information from DAI callback function back to the DMA and based on this information DMA executes some additional action e.g. after getting an interrupt we need to load the next linked list item in order for the DMA to continue the data transfer. COPY callback should be called in dma_copy and it's used to tell DAI how much data has been copied, so it can increment read/write pointers of the buffer. I must admit, that this solution is very hard to follow and I'm working on little simplification, but it's tough to write common handling code for different types of DMAs. Does your DMA also use interrupts to schedule the pipe?
Tomek
-----Original Message----- From: Sound-open-firmware [mailto:sound-open-firmware-bounces@alsa-project.org] On Behalf Of Paul Olaru Sent: Thursday, August 29, 2019 4:27 PM To: sound-open-firmware@alsa-project.org Subject: [Sound-open-firmware] Questions about the DMA driver flow in SOF
I need to understand the general flow on how a DMA driver should Work in SOF. In particular what each callback should do.
I get channel_get, channel_put, start, stop, pause, release (although I don't quite get the nuance between stop and pause, or between start and release; thankfully I hope it's not important if I treat them the same). I get most of the others too, at least for the most part.
What I don't get at all is how the copy callback should work. In the DW DMA driver it seems to just run the callback and do something based on what the callback set in next, in HDA it seems to wait for the host buffer to be full or empty (I think this one may be the more intuitive one?) and the link HDA DMA seems to again just run the callback.
What should the copy callback really do? Is it different between a host DMA and a DAI DMA? _______________________________________________ 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.
participants (2)
-
Lauda, Tomasz
-
Paul Olaru