From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Vinod Koul <vinod.koul@linux.intel.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Liam Girdwood <lrg@ti.com>, Tony Lindgren <tony@atomide.com>,
Russell King <rmk+kernel@arm.linux.org.uk>,
Dan Williams <djbw@fb.com>,
Jarkko Nikula <jarkko.nikula@bitmer.com>,
alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>,
Ricardo Neri <ricardo.neri@ti.com>
Subject: Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
Date: Fri, 14 Sep 2012 12:28:28 +0300 [thread overview]
Message-ID: <5052F8BC.4020102@ti.com> (raw)
In-Reply-To: <1347612630.1943.29.camel@vkoul-udesk3>
Hi,
On 09/14/2012 11:50 AM, Vinod Koul wrote:
>> Well, the idea was that the driver would disable interrupts if there is no
>> callback to call, since there would be nothing to do in the interrupt
>> handler anyway. But I guess the flags approach should work fine as well.
> Yes we _could_ do that, but this relies on dmaengine driver to have this
> implicit understanding. Anyone using dmaengine library in ASoC may or
> may not be aware of this, so i would consider it hackish.
>
> Using this flag explicitly makes everyone aware what the intended
> behaviour is.
I'm not sure about which flags should ASoC set for the two case we are going
to have. I think it should be something like this:
unsigned long flags = DMA_CTRL_ACK;
if (!substream->runtime->no_period_wakeup)
flags |= DMA_PREP_INTERRUPT;
I'm not 100% sure of the role of DMA_CTRL_ACK in this case. Or should we only
handle the DMA_PREP_INTERRUPT flag, like this:
unsigned long flags = 0;
if (!substream->runtime->no_period_wakeup)
flags |= DMA_PREP_INTERRUPT;
What do you think?
--
Péter
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Vinod Koul <vinod.koul@linux.intel.com>
Cc: alsa-devel@alsa-project.org, Lars-Peter Clausen <lars@metafoo.de>,
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>,
Tony Lindgren <tony@atomide.com>,
Ricardo Neri <ricardo.neri@ti.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Dan Williams <djbw@fb.com>,
Russell King <rmk+kernel@arm.linux.org.uk>,
linux-omap@vger.kernel.org, Liam Girdwood <lrg@ti.com>,
Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
Date: Fri, 14 Sep 2012 12:28:28 +0300 [thread overview]
Message-ID: <5052F8BC.4020102@ti.com> (raw)
In-Reply-To: <1347612630.1943.29.camel@vkoul-udesk3>
Hi,
On 09/14/2012 11:50 AM, Vinod Koul wrote:
>> Well, the idea was that the driver would disable interrupts if there is no
>> callback to call, since there would be nothing to do in the interrupt
>> handler anyway. But I guess the flags approach should work fine as well.
> Yes we _could_ do that, but this relies on dmaengine driver to have this
> implicit understanding. Anyone using dmaengine library in ASoC may or
> may not be aware of this, so i would consider it hackish.
>
> Using this flag explicitly makes everyone aware what the intended
> behaviour is.
I'm not sure about which flags should ASoC set for the two case we are going
to have. I think it should be something like this:
unsigned long flags = DMA_CTRL_ACK;
if (!substream->runtime->no_period_wakeup)
flags |= DMA_PREP_INTERRUPT;
I'm not 100% sure of the role of DMA_CTRL_ACK in this case. Or should we only
handle the DMA_PREP_INTERRUPT flag, like this:
unsigned long flags = 0;
if (!substream->runtime->no_period_wakeup)
flags |= DMA_PREP_INTERRUPT;
What do you think?
--
Péter
WARNING: multiple messages have this Message-ID (diff)
From: peter.ujfalusi@ti.com (Peter Ujfalusi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
Date: Fri, 14 Sep 2012 12:28:28 +0300 [thread overview]
Message-ID: <5052F8BC.4020102@ti.com> (raw)
In-Reply-To: <1347612630.1943.29.camel@vkoul-udesk3>
Hi,
On 09/14/2012 11:50 AM, Vinod Koul wrote:
>> Well, the idea was that the driver would disable interrupts if there is no
>> callback to call, since there would be nothing to do in the interrupt
>> handler anyway. But I guess the flags approach should work fine as well.
> Yes we _could_ do that, but this relies on dmaengine driver to have this
> implicit understanding. Anyone using dmaengine library in ASoC may or
> may not be aware of this, so i would consider it hackish.
>
> Using this flag explicitly makes everyone aware what the intended
> behaviour is.
I'm not sure about which flags should ASoC set for the two case we are going
to have. I think it should be something like this:
unsigned long flags = DMA_CTRL_ACK;
if (!substream->runtime->no_period_wakeup)
flags |= DMA_PREP_INTERRUPT;
I'm not 100% sure of the role of DMA_CTRL_ACK in this case. Or should we only
handle the DMA_PREP_INTERRUPT flag, like this:
unsigned long flags = 0;
if (!substream->runtime->no_period_wakeup)
flags |= DMA_PREP_INTERRUPT;
What do you think?
--
P?ter
next prev parent reply other threads:[~2012-09-14 9:27 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 13:37 [PATCH v2 00/15] ASoC: OMAP: Convert to use dmaengine Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 01/15] dmaengine: omap: Support for element mode in cyclic DMA Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 02/15] dmaengine: omap: Add support for pause/resume in cyclic dma mode Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic() Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 15:27 ` Lars-Peter Clausen
2012-09-13 15:27 ` Lars-Peter Clausen
2012-09-13 15:27 ` Lars-Peter Clausen
2012-09-13 15:38 ` Russell King - ARM Linux
2012-09-13 15:38 ` Russell King - ARM Linux
2012-09-14 3:27 ` Vinod Koul
2012-09-14 3:27 ` Vinod Koul
2012-09-14 3:27 ` Vinod Koul
2012-09-14 7:15 ` Peter Ujfalusi
2012-09-14 7:15 ` Peter Ujfalusi
2012-09-14 7:15 ` Peter Ujfalusi
2012-09-14 3:26 ` Vinod Koul
2012-09-14 3:26 ` Vinod Koul
2012-09-14 3:26 ` Vinod Koul
2012-09-14 7:18 ` [alsa-devel] " Peter Ujfalusi
2012-09-14 7:18 ` Peter Ujfalusi
2012-09-14 7:18 ` Peter Ujfalusi
2012-09-14 8:13 ` Lars-Peter Clausen
2012-09-14 8:13 ` Lars-Peter Clausen
2012-09-14 8:13 ` Lars-Peter Clausen
2012-09-14 8:50 ` Vinod Koul
2012-09-14 8:50 ` Vinod Koul
2012-09-14 8:50 ` Vinod Koul
2012-09-14 9:28 ` Peter Ujfalusi [this message]
2012-09-14 9:28 ` Peter Ujfalusi
2012-09-14 9:28 ` Peter Ujfalusi
2012-09-14 9:38 ` Vinod Koul
2012-09-14 9:38 ` Vinod Koul
2012-09-14 9:38 ` Vinod Koul
2012-09-14 10:01 ` Russell King - ARM Linux
2012-09-14 10:01 ` Russell King - ARM Linux
2012-09-14 7:12 ` Peter Ujfalusi
2012-09-14 7:12 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-14 3:24 ` Vinod Koul
2012-09-14 3:24 ` Vinod Koul
2012-09-14 3:24 ` Vinod Koul
2012-09-14 7:07 ` Peter Ujfalusi
2012-09-14 7:07 ` Peter Ujfalusi
2012-09-14 7:07 ` Peter Ujfalusi
2012-09-17 6:34 ` Shawn Guo
2012-09-17 6:34 ` Shawn Guo
2012-09-17 6:34 ` Shawn Guo
2012-09-17 7:16 ` Peter Ujfalusi
2012-09-17 7:16 ` Peter Ujfalusi
2012-09-17 7:16 ` Peter Ujfalusi
2012-09-17 7:23 ` Shawn Guo
2012-09-17 7:23 ` Shawn Guo
2012-09-17 9:01 ` Linus Walleij
2012-09-17 9:01 ` Linus Walleij
2012-09-17 9:01 ` Linus Walleij
2012-09-18 8:31 ` Russell King - ARM Linux
2012-09-18 8:31 ` Russell King - ARM Linux
2012-09-18 8:31 ` Russell King - ARM Linux
2012-09-18 9:00 ` Vinod Koul
2012-09-18 9:00 ` Vinod Koul
2012-09-18 9:00 ` Vinod Koul
2012-09-18 12:22 ` Linus Walleij
2012-09-18 12:22 ` Linus Walleij
2012-09-18 12:22 ` Linus Walleij
2012-09-13 13:37 ` [PATCH v2 05/15] dmaengine: omap-dma: Add support for no_wakeup in cyclic mode Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 06/15] ASoC: omap-mcbsp: Use sDMA packet mode instead of frame mode Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 07/15] ASoC: omap-pcm: Select sDMA synchronization based on packet_size Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 08/15] ASoC: OMAP: Remove sync_mode from omap_pcm_dma_data struct Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:37 ` [PATCH v2 09/15] ASoC: omap-pcm: Prepare to configure the DMA data_type based on stream properties Peter Ujfalusi
2012-09-13 13:37 ` Peter Ujfalusi
2012-09-13 13:38 ` [PATCH v2 10/15] ARM: OMAP4: hwmod_data: Add resource names to McPDM memory ranges Peter Ujfalusi
2012-09-13 13:38 ` Peter Ujfalusi
2012-09-13 13:38 ` [PATCH v2 11/15] ASoC: omap-mcpdm: Use platform_get_resource_* to get resources Peter Ujfalusi
2012-09-13 13:38 ` Peter Ujfalusi
2012-09-13 13:38 ` Peter Ujfalusi
2012-09-13 13:38 ` [PATCH v2 12/15] ASoC: OMAP: mcbsp, mcpdm, dmic: Let omap-pcm to pick the dma_type Peter Ujfalusi
2012-09-13 13:38 ` Peter Ujfalusi
2012-09-13 13:38 ` [PATCH v2 13/15] ASoC: omap-pcm, omap-dmic: Change the use of omap_pcm_dma_data->data_type Peter Ujfalusi
2012-09-13 13:38 ` Peter Ujfalusi
2012-09-13 13:38 ` [PATCH v2 14/15] ASoC: OMAP: mcbsp, mcpdm, dmic, hdmi: Set dma_data at startup time Peter Ujfalusi
2012-09-13 13:38 ` Peter Ujfalusi
2012-09-13 13:38 ` [PATCH v2 15/15] ASoC: omap-pcm: Convert to use dmaengine Peter Ujfalusi
2012-09-13 13:38 ` Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5052F8BC.4020102@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=djbw@fb.com \
--cc=jarkko.nikula@bitmer.com \
--cc=jkrzyszt@tis.icnet.pl \
--cc=lars@metafoo.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lrg@ti.com \
--cc=ricardo.neri@ti.com \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=tony@atomide.com \
--cc=vinod.koul@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.