All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mark A. Greer" <mgreer@animalcreek.com>
To: "Péter Ujfalusi" <peter.ujfalusi@ti.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
Date: Fri, 16 Nov 2012 15:39:30 -0700	[thread overview]
Message-ID: <20121116223930.GA25182@animalcreek.com> (raw)
In-Reply-To: <50814B83.7090203@ti.com>

On Fri, Oct 19, 2012 at 02:45:55PM +0200, Péter Ujfalusi wrote:
> Hi,
> 
> On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote:
> > I would suggest getting some feedback from the ASoC people first, before
> > trying to invent new APIs to work around this stuff.  If they can live
> > with having prefetch enabled on OMAP then there isn't an issue here.  If
> > not, we need a solution to this.
> > 
> > I do not believe that precisely stopping and starting playback across a
> > suspend/resume event is really necessary (it's desirable but the world
> > doesn't collapse if you miss a few samples.)  It could be more of an
> > issue for pause/resume though, but as I say, that's for ASoC people to
> > comment on.
> 
> There is another issue with the prefetch in audio:
> we tend to like to know the position of the DMA and also to know how much data
> we have stored in buffers, FIFOs. This information is used by userspace to do
> echo cancellation and also used by PA for example to do runtime mixing
> directly in the audio buffer. We have means to extract this information from
> McBSP for example (and from tlv320dac33 codec) but AFAIK this information can
> not be retrieved from sDMA.
> We could assume that the sDMA FIFO is kept full and report that as a 'delay'
> or do not account this information.
> 
> For now I think the cyclic mode should not set the prefetch. If I recall right
> the cyclic mode is only used by audio at the moment.
> 
> > I'm merely pointing out here that we need their feedback here before
> > deciding if there's anything further that needs to happen.
> 
> Thanks Russell, I'll take a look at the implication of the prefetch for audio.

So how about enabling prefetch for just non-cyclic?


---
From 04b4d7b2d940822af501ea8a6bf265098d2c1810 Mon Sep 17 00:00:00 2001
From: "Mark A. Greer" <mgreer@animalcreek.com>
Date: Wed, 17 Oct 2012 18:12:21 -0700
Subject: [PATCH] dmaengine: omap-dma: Allow DMA controller to prefetch data
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Enable DMA prefetching for non-cyclic DMAs by setting the
'OMAP_DMA_DST_SYNC_PREFETCH' flag when there is a destination
synchronized DMA transfer.  Prefetching is not allowed on
source synchronized DMA transfers.  It is not allowed on
cyclic DMAs either since that can cause issues with some
users (e.g., suspending/resuming audio).

CC: rmk+kernel@arm.linux.org.uk
CC: Péter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
 drivers/dma/omap-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..e660f94 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
 		dev_addr = c->cfg.dst_addr;
 		dev_width = c->cfg.dst_addr_width;
 		burst = c->cfg.dst_maxburst;
-		sync_type = OMAP_DMA_DST_SYNC;
+		sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
 	} else {
 		dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
 		return NULL;
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: mgreer@animalcreek.com (Mark A. Greer)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data
Date: Fri, 16 Nov 2012 15:39:30 -0700	[thread overview]
Message-ID: <20121116223930.GA25182@animalcreek.com> (raw)
In-Reply-To: <50814B83.7090203@ti.com>

On Fri, Oct 19, 2012 at 02:45:55PM +0200, P?ter Ujfalusi wrote:
> Hi,
> 
> On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote:
> > I would suggest getting some feedback from the ASoC people first, before
> > trying to invent new APIs to work around this stuff.  If they can live
> > with having prefetch enabled on OMAP then there isn't an issue here.  If
> > not, we need a solution to this.
> > 
> > I do not believe that precisely stopping and starting playback across a
> > suspend/resume event is really necessary (it's desirable but the world
> > doesn't collapse if you miss a few samples.)  It could be more of an
> > issue for pause/resume though, but as I say, that's for ASoC people to
> > comment on.
> 
> There is another issue with the prefetch in audio:
> we tend to like to know the position of the DMA and also to know how much data
> we have stored in buffers, FIFOs. This information is used by userspace to do
> echo cancellation and also used by PA for example to do runtime mixing
> directly in the audio buffer. We have means to extract this information from
> McBSP for example (and from tlv320dac33 codec) but AFAIK this information can
> not be retrieved from sDMA.
> We could assume that the sDMA FIFO is kept full and report that as a 'delay'
> or do not account this information.
> 
> For now I think the cyclic mode should not set the prefetch. If I recall right
> the cyclic mode is only used by audio at the moment.
> 
> > I'm merely pointing out here that we need their feedback here before
> > deciding if there's anything further that needs to happen.
> 
> Thanks Russell, I'll take a look at the implication of the prefetch for audio.

So how about enabling prefetch for just non-cyclic?


---
>From 04b4d7b2d940822af501ea8a6bf265098d2c1810 Mon Sep 17 00:00:00 2001
From: "Mark A. Greer" <mgreer@animalcreek.com>
Date: Wed, 17 Oct 2012 18:12:21 -0700
Subject: [PATCH] dmaengine: omap-dma: Allow DMA controller to prefetch data
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Enable DMA prefetching for non-cyclic DMAs by setting the
'OMAP_DMA_DST_SYNC_PREFETCH' flag when there is a destination
synchronized DMA transfer.  Prefetching is not allowed on
source synchronized DMA transfers.  It is not allowed on
cyclic DMAs either since that can cause issues with some
users (e.g., suspending/resuming audio).

CC: rmk+kernel at arm.linux.org.uk
CC: P?ter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---
 drivers/dma/omap-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..e660f94 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
 		dev_addr = c->cfg.dst_addr;
 		dev_width = c->cfg.dst_addr_width;
 		burst = c->cfg.dst_maxburst;
-		sync_type = OMAP_DMA_DST_SYNC;
+		sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
 	} else {
 		dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
 		return NULL;
-- 
1.7.12

  parent reply	other threads:[~2012-11-16 22:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-18 22:20 [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data Mark A. Greer
2012-10-18 22:20 ` Mark A. Greer
2012-10-18 22:46 ` Mark A. Greer
2012-10-18 22:46   ` Mark A. Greer
2012-10-18 22:55 ` Russell King - ARM Linux
2012-10-18 22:55   ` Russell King - ARM Linux
2012-10-18 23:24   ` Mark A. Greer
2012-10-18 23:24     ` Mark A. Greer
2012-10-18 23:33     ` Russell King - ARM Linux
2012-10-18 23:33       ` Russell King - ARM Linux
2012-10-18 23:50       ` Mark A. Greer
2012-10-18 23:50         ` Mark A. Greer
2012-10-19 12:45       ` Péter Ujfalusi
2012-10-19 12:45         ` Péter Ujfalusi
2012-11-05 22:06         ` Mark A. Greer
2012-11-05 22:06           ` Mark A. Greer
2012-11-16 22:39         ` Mark A. Greer [this message]
2012-11-16 22:39           ` Mark A. Greer
2012-11-17 11:31         ` Russell King - ARM Linux
2012-11-17 11:31           ` Russell King - ARM Linux
2012-11-19 10:00           ` Peter Ujfalusi
2012-11-19 10:00             ` Peter Ujfalusi
2012-11-19 12:16             ` Russell King - ARM Linux
2012-11-19 12:16               ` Russell King - ARM Linux
2012-11-19 10:01 ` Peter Ujfalusi
2012-11-19 10:01   ` Peter Ujfalusi
2012-11-19 16:19   ` Mark A. Greer
2012-11-19 16:19     ` Mark A. Greer
2012-11-19 16:49     ` Mark A. Greer
2012-11-19 16:49       ` Mark A. Greer

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=20121116223930.GA25182@animalcreek.com \
    --to=mgreer@animalcreek.com \
    --cc=jarkko.nikula@bitmer.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=peter.ujfalusi@ti.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.