All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Liam Girdwood <lrg@ti.com>, Tony Lindgren <tony@atomide.com>,
	Vinod Koul <vinod.koul@intel.com>, 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 11/11] ASoC: omap-pcm: Convert to use dmaengine
Date: Wed, 12 Sep 2012 15:53:47 +0300	[thread overview]
Message-ID: <505085DB.5000407@ti.com> (raw)
In-Reply-To: <20120912120028.GC28448@n2100.arm.linux.org.uk>

On 09/12/2012 03:00 PM, Russell King - ARM Linux wrote:
> On Wed, Sep 12, 2012 at 02:47:07PM +0300, Peter Ujfalusi wrote:
>> 2. Pause/Resume
>>    OMAP DMA engine backend does not support pausing and resuming
>>    an in-progress transfer.  It is unclear from the specs what
>>    effect clearing the enable bit has on the DMA position of a
>>    destination synchronized transfer, and whether the transfer
>>    can be restarted from the exact point that it was paused (or
>>    whether the data in the FIFO read from memory is simply
>>    discarded.)
> 
> It's worth noting that this comment (which was in my original patch)
> is there to spark _comment_ and _discussion_ and should not make its
> way into the final version of these patches.
> 
> Given that suspend/resume is important on OMAP platforms, it's something
> that needs to be resolved - in a way that complies with what ALSA expects.
> I do not believe that the way the existing drivers do this is compliant
> as the manuals imply that stopping memory->peripheral transfers results
> in data being discarded from the DMA's FIFOs.  As I understand it, ALSA
> requires no data to be discarded.
> 
> As we have no way to know how much data may be discarded from the DMA
> FIFO...

I need to look at this, but at first look we do wait for the drain in
omap_stop_dma(). We used to use omap_stop_dma/omap_start_dma for pause/resume
operations.
But sDMA also have a bit: CDPi: PAUSE_LINK_LIST which should do what we are
looking for.
Need to read the relevant parts of the TRM, but AFAIK we are using normal mode
with linked list (self linking).
I already have the patch for this, I just need to test it on HW.

-- 
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 11/11] ASoC: omap-pcm: Convert to use dmaengine
Date: Wed, 12 Sep 2012 15:53:47 +0300	[thread overview]
Message-ID: <505085DB.5000407@ti.com> (raw)
In-Reply-To: <20120912120028.GC28448@n2100.arm.linux.org.uk>

On 09/12/2012 03:00 PM, Russell King - ARM Linux wrote:
> On Wed, Sep 12, 2012 at 02:47:07PM +0300, Peter Ujfalusi wrote:
>> 2. Pause/Resume
>>    OMAP DMA engine backend does not support pausing and resuming
>>    an in-progress transfer.  It is unclear from the specs what
>>    effect clearing the enable bit has on the DMA position of a
>>    destination synchronized transfer, and whether the transfer
>>    can be restarted from the exact point that it was paused (or
>>    whether the data in the FIFO read from memory is simply
>>    discarded.)
> 
> It's worth noting that this comment (which was in my original patch)
> is there to spark _comment_ and _discussion_ and should not make its
> way into the final version of these patches.
> 
> Given that suspend/resume is important on OMAP platforms, it's something
> that needs to be resolved - in a way that complies with what ALSA expects.
> I do not believe that the way the existing drivers do this is compliant
> as the manuals imply that stopping memory->peripheral transfers results
> in data being discarded from the DMA's FIFOs.  As I understand it, ALSA
> requires no data to be discarded.
> 
> As we have no way to know how much data may be discarded from the DMA
> FIFO...

I need to look at this, but at first look we do wait for the drain in
omap_stop_dma(). We used to use omap_stop_dma/omap_start_dma for pause/resume
operations.
But sDMA also have a bit: CDPi: PAUSE_LINK_LIST which should do what we are
looking for.
Need to read the relevant parts of the TRM, but AFAIK we are using normal mode
with linked list (self linking).
I already have the patch for this, I just need to test it on HW.

-- 
P?ter

  reply	other threads:[~2012-09-12 12:53 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12 11:46 [PATCH 00/11] ASoC: OMAP: Convert to use dmaengine Peter Ujfalusi
2012-09-12 11:46 ` Peter Ujfalusi
2012-09-12 11:46 ` [PATCH 01/11] dmaengine: omap: Support for element mode in cyclic DMA Peter Ujfalusi
2012-09-12 11:46   ` Peter Ujfalusi
2012-09-12 11:46   ` Peter Ujfalusi
2012-09-12 11:46 ` [PATCH 02/11] ASoC: omap-mcbsp: Use sDMA packet mode instead of frame mode Peter Ujfalusi
2012-09-12 11:46   ` Peter Ujfalusi
2012-09-12 11:46 ` [PATCH 03/11] ASoC: omap-pcm: Select sDMA synchronization based on packet_size Peter Ujfalusi
2012-09-12 11:46   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 04/11] ASoC: OMAP: Remove sync_mode from omap_pcm_dma_data struct Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 05/11] ASoC: omap-pcm: Prepare to configure the DMA data_type based on stream properties Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 06/11] ARM: OMAP4: hwmod_data: Add resource names to McPDM memory ranges Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 07/11] ASoC: omap-mcpdm: Use platform_get_resource_* to get resources Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 08/11] ASoC: OMAP: mcbsp, mcpdm, dmic: Let omap-pcm to pick the dma_type Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 09/11] ASoC: omap-pcm, omap-hdmi: Change the use of omap_pcm_dma_data->data_type Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 10/11] ASoC: OMAP: mcbsp, mcpdm, dmic, hdmi: Set dma_data at startup time Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 11:47 ` [PATCH 11/11] ASoC: omap-pcm: Convert to use dmaengine Peter Ujfalusi
2012-09-12 11:47   ` Peter Ujfalusi
2012-09-12 12:00   ` Russell King - ARM Linux
2012-09-12 12:00     ` Russell King - ARM Linux
2012-09-12 12:53     ` Peter Ujfalusi [this message]
2012-09-12 12:53       ` Peter Ujfalusi
2012-09-12 14:35       ` Peter Ujfalusi
2012-09-12 14:35         ` Peter Ujfalusi
2012-09-12 14:35         ` Peter Ujfalusi
2012-09-12 14:05     ` Takashi Iwai
2012-09-12 14:05       ` [alsa-devel] " Takashi Iwai
2012-09-12 14:05       ` Takashi Iwai
2012-09-13  8:11 ` [PATCH 00/11] ASoC: OMAP: " Mark Brown
2012-09-13  8:11   ` Mark Brown
2012-09-13  8:11   ` Mark Brown
2012-09-13  9:20   ` Peter Ujfalusi
2012-09-13  9:20     ` Peter Ujfalusi
2012-09-13  9:20     ` 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=505085DB.5000407@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=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lrg@ti.com \
    --cc=ricardo.neri@ti.com \
    --cc=tony@atomide.com \
    --cc=vinod.koul@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.