[Sound-open-firmware] First caller of pipeline_copy
Hi, I want to understand how copying data works on a playback pipeline, specifically how the first bytes are copied. It looks like SOF_SCHEDULE_LL_DMA scheduler takes care about scheduling pipeline_task. In a simple pipeline with Host <-> (buf0) <-> Volume <->(buf1) DAI the data needs to be propagated from upstream up to DAI. DMA is responsible to copy the data from buf1 to DAI. But at the time the DMA interrupt arrives the data are not yet propagated to buf1. We would need a way to preload first bytes. But I couldn't find anywhere in the code where this happens.
On Mon, Apr 13, 2020 at 2:16 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
Hi,
I want to understand how copying data works on a playback pipeline, specifically how the first bytes are copied.
It looks like SOF_SCHEDULE_LL_DMA scheduler takes care about scheduling pipeline_task.
In a simple pipeline with Host <-> (buf0) <-> Volume <->(buf1) DAI the data needs to be propagated from upstream up to DAI.
DMA is responsible to copy the data from buf1 to DAI. But at the time the DMA interrupt arrives the data are not yet propagated to buf1.
We would need a way to preload first bytes. But I couldn't find anywhere in the code where this happens.
More to add to this: So, basically in our design the DMA controller will send an interrupt after successfully copied data. So, in order for this to work the first chunk needs to be preloaded into buf1. Any suggestion where to look into the code are welcomed!
Hi Daniel, Data is not preloaded anymore. Some time ago I've introduced additional DMA buffers in both host and dai components, so buf1 is not directly connected to DMA. Transfer is started right away and zeroes are sent out before first chunk of data is copied. Tomek -----Original Message----- From: Sound-open-firmware <sound-open-firmware-bounces@alsa-project.org> On Behalf Of Daniel Baluta Sent: Monday, April 13, 2020 1:55 PM To: tomasz.lauda@linux.intel.com Cc: Paul Olaru <paul.olaru@nxp.com>; sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] First caller of pipeline_copy On Mon, Apr 13, 2020 at 2:16 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
Hi,
I want to understand how copying data works on a playback pipeline, specifically how the first bytes are copied.
It looks like SOF_SCHEDULE_LL_DMA scheduler takes care about scheduling pipeline_task.
In a simple pipeline with Host <-> (buf0) <-> Volume <->(buf1) DAI the data needs to be propagated from upstream up to DAI.
DMA is responsible to copy the data from buf1 to DAI. But at the time the DMA interrupt arrives the data are not yet propagated to buf1.
We would need a way to preload first bytes. But I couldn't find anywhere in the code where this happens.
More to add to this: So, basically in our design the DMA controller will send an interrupt after successfully copied data. So, in order for this to work the first chunk needs to be preloaded into buf1. Any suggestion where to look into the code are welcomed! _______________________________________________ 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.
Alright but there is something I don't get about the flow of the calls to the DMA driver. In order to get an interrupt from the DMAC I need to mark at least one buffer as containing data. Do we know that on playback the buffers already contain data at the time set_config() is called, or between this call and the subsequent start() call, so that I can mark them as ready in the hardware descriptors when I create them in set_config()? ________________________________________ From: Sound-open-firmware <sound-open-firmware-bounces@alsa-project.org> on behalf of Lauda, Tomasz <tomasz.lauda@intel.com> Sent: Tuesday, April 14, 2020 7:50 AM To: Daniel Baluta Cc: Paul Olaru; sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] First caller of pipeline_copy Hi Daniel, Data is not preloaded anymore. Some time ago I've introduced additional DMA buffers in both host and dai components, so buf1 is not directly connected to DMA. Transfer is started right away and zeroes are sent out before first chunk of data is copied. Tomek -----Original Message----- From: Sound-open-firmware <sound-open-firmware-bounces@alsa-project.org> On Behalf Of Daniel Baluta Sent: Monday, April 13, 2020 1:55 PM To: tomasz.lauda@linux.intel.com Cc: Paul Olaru <paul.olaru@nxp.com>; sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] First caller of pipeline_copy On Mon, Apr 13, 2020 at 2:16 PM Daniel Baluta <daniel.baluta@gmail.com> wrote:
Hi,
I want to understand how copying data works on a playback pipeline, specifically how the first bytes are copied.
It looks like SOF_SCHEDULE_LL_DMA scheduler takes care about scheduling pipeline_task.
In a simple pipeline with Host <-> (buf0) <-> Volume <->(buf1) DAI the data needs to be propagated from upstream up to DAI.
DMA is responsible to copy the data from buf1 to DAI. But at the time the DMA interrupt arrives the data are not yet propagated to buf1.
We would need a way to preload first bytes. But I couldn't find anywhere in the code where this happens.
More to add to this: So, basically in our design the DMA controller will send an interrupt after successfully copied data. So, in order for this to work the first chunk needs to be preloaded into buf1. Any suggestion where to look into the code are welcomed! _______________________________________________ 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. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
On Tue, Apr 14, 2020 at 10:50 AM Lauda, Tomasz <tomasz.lauda@intel.com> wrote:
Hi Daniel,
Data is not preloaded anymore. Some time ago I've introduced additional DMA buffers in both host and dai components, so buf1 is not directly connected to DMA. Transfer is started right away and zeroes are sent out before first chunk of data is copied.
Thanks Tomek, I've seen your patches. The biggest problem with this design now are not the buffers but the time when the DMA interrupt is registered. pipeline_trigger( => dai_comp_trigger() START => dai_trigger() [1] => dma_start() [2] => pipeline_schedule_trigger => pipeline_schedule_copy => dma interrupt register [3] We send a DMA request after [1], then at [2] we start the DMA which does some copying and sends an interrupt. But by the time we actually get to register the handler the interrupt is missed. We could enable the interrupt at [3] but then we will miss the DMA request at [1].
participants (3)
-
Daniel Baluta -
Lauda, Tomasz -
Paul Olaru (OSS)