public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Liam Girdwood <lrg@ti.com>, Vinod Koul <vinod.koul@intel.com>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ASoC: dmaengine-pcm: Add support for querying stream position from DMA device
Date: Mon, 11 Jun 2012 16:02:42 +0200	[thread overview]
Message-ID: <4FD5FA82.7090107@metafoo.de> (raw)
In-Reply-To: <20120611132409.GG11168@n2100.arm.linux.org.uk>

On 06/11/2012 03:24 PM, Russell King - ARM Linux wrote:
> On Mon, Jun 11, 2012 at 02:04:13PM +0200, Lars-Peter Clausen wrote:
>> @@ -202,7 +203,27 @@ EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_trigger);
>>  snd_pcm_uframes_t snd_dmaengine_pcm_pointer(struct snd_pcm_substream *substream)
>>  {
>>  	struct dmaengine_pcm_runtime_data *prtd = substream_to_prtd(substream);
>> -	return bytes_to_frames(substream->runtime, prtd->pos);
>> +	struct dma_tx_state state;
>> +	enum dma_status status;
>> +	unsigned int pos;
>> +
>> +	status = dmaengine_tx_status(prtd->dma_chan, prtd->cookie, &state);
>> +	if (status != DMA_IN_PROGRESS && status != DMA_PAUSED) {
>> +		pos = 0;
>> +	} else if (state.residue == 0) {
>> +		/* This should never happen with cyclic transfers, so assume
>> +		 * that the dmaengine driver does not support reporting residue
>> +		 * and fall back to counting periods. */
>> +		pos = prtd->pos;
> 
> That is an incorrect assumption.
> 
> The current DMA position is defined by the DMA pointer.  When the DMA
> engine has transferred the last few bytes of the DMA, the DMA pointer
> will be pointing to the byte _after_ the last byte transferred in the
> buffer.
> 
> Therefore, when you calculate the residue as (buf_start + buf_len -
> current_pointer) you end up with zero.

My assumption is that for cyclic DMA it will be pointing to the first byte
again after the last byte has been transferred. Something like this:

offset = (offset + 1) % buf_len
and current_pointer = buf_start + offset

If this is not true for a particular DMA controller I think we should still
make sure in the driver for this controller that residue will never be zero
for cyclic transfers, but instead will return the buffer size. This is the
only thing that really makes sense. The buffer only has buf_len bytes, if
residue can be a value in the interval of [0,buf_len] this means that it has
buf_len+1 possible values. Which again means there must be two values which
map to the same state. In this case it would be 0 and buf_len.

> 
> What we need to do is to get rid of this idea that reporting the residue
> is optional for DMA engine drivers.  Let's make it absolutely required
> in order to support cyclic transfers.

While I agree, I don't think we can just rip out the old mechanism until the
platforms which are currently using this have fixed their dmaengine drivers
to provide residue.

- Lars

  reply	other threads:[~2012-06-11 13:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11 12:04 [PATCH 1/2] dmaengine: Add wrapper for device_tx_status callback Lars-Peter Clausen
2012-06-11 12:04 ` [PATCH 2/2] ASoC: dmaengine-pcm: Add support for querying stream position from DMA device Lars-Peter Clausen
2012-06-11 13:24   ` Russell King - ARM Linux
2012-06-11 14:02     ` Lars-Peter Clausen [this message]
2012-06-11 14:09       ` Russell King - ARM Linux
2012-06-11 14:30         ` Lars-Peter Clausen
2012-06-11 14:57     ` Mark Brown
2012-06-11 15:20       ` [alsa-devel] " Lars-Peter Clausen
2012-06-11 15:35         ` Mark Brown

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=4FD5FA82.7090107@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lrg@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox