[RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
flag whenever there is a destination synchronized DMA transfer.
Prefetching is not allowed on source synchronized DMA transfers.

Enabling prefetch significantly improves DMA performance.
For example, running 'modprobe tcrypt sec=2 mode=403' which
exercises the omap-sham driver on an am37x EVM yeilds the
following results:

a) With prefetch disabled

testing speed of async sha1
test  0 (   16 byte blocks,   16 bytes per update,   1 updates):  24049 opers/sec,    384784 bytes/sec
test  1 (   64 byte blocks,   16 bytes per update,   4 updates):  22030 opers/sec,   1409920 bytes/sec
test  2 (   64 byte blocks,   64 bytes per update,   1 updates):  24055 opers/sec,   1539520 bytes/sec
test  3 (  256 byte blocks,   16 bytes per update,  16 updates):   7648 opers/sec,   1958016 bytes/sec
test  4 (  256 byte blocks,   64 bytes per update,   4 updates):   7918 opers/sec,   2027008 bytes/sec
test  5 (  256 byte blocks,  256 bytes per update,   1 updates):   8000 opers/sec,   2048000 bytes/sec
test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates):   3295 opers/sec,   3374080 bytes/sec
test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates):   3602 opers/sec,   3688960 bytes/sec
test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates):   3753 opers/sec,   3843072 bytes/sec
test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates):   3239 opers/sec,   6633472 bytes/sec
test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates):   3557 opers/sec,   7284736 bytes/sec
test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates):   3591 opers/sec,   7354368 bytes/sec
test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates):   3598 opers/sec,   7369728 bytes/sec
test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates):   1751 opers/sec,   7174144 bytes/sec
test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates):   2302 opers/sec,   9431040 bytes/sec
test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates):   2087 opers/sec,   8548352 bytes/sec
test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates):   2050 opers/sec,   8398848 bytes/sec
test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates):    864 opers/sec,   7077888 bytes/sec
test 18 ( 8192 byte blocks,  256 bytes per update,  32 updates):    993 opers/sec,   8138752 bytes/sec
test 19 ( 8192 byte blocks, 1024 bytes per update,   8 updates):    936 opers/sec,   7671808 bytes/sec
test 20 ( 8192 byte blocks, 4096 bytes per update,   2 updates):   1048 opers/sec,   8589312 bytes/sec
test 21 ( 8192 byte blocks, 8192 bytes per update,   1 updates):   1274 opers/sec,  10436608 bytes/sec

b) With prefetch enabled

testing speed of async sha1
test  0 (   16 byte blocks,   16 bytes per update,   1 updates):  23868 opers/sec,    381888 bytes/sec
test  1 (   64 byte blocks,   16 bytes per update,   4 updates):  21928 opers/sec,   1403424 bytes/sec
test  2 (   64 byte blocks,   64 bytes per update,   1 updates):  23910 opers/sec,   1530272 bytes/sec
test  3 (  256 byte blocks,   16 bytes per update,  16 updates):   7664 opers/sec,   1962112 bytes/sec
test  4 (  256 byte blocks,   64 bytes per update,   4 updates):   7924 opers/sec,   2028672 bytes/sec
test  5 (  256 byte blocks,  256 bytes per update,   1 updates):   8006 opers/sec,   2049536 bytes/sec
test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates):   3276 opers/sec,   3355136 bytes/sec
test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates):   3856 opers/sec,   3949056 bytes/sec
test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates):   3634 opers/sec,   3721728 bytes/sec
test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates):   3257 opers/sec,   6670336 bytes/sec
test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates):   3604 opers/sec,   7380992 bytes/sec
test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates):   3604 opers/sec,   7380992 bytes/sec
test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates):   3624 opers/sec,   7422976 bytes/sec
test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates):   2698 opers/sec,  11051008 bytes/sec
test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates):   3500 opers/sec,  14336000 bytes/sec
test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates):   3596 opers/sec,  14729216 bytes/sec
test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates):   3588 opers/sec,  14698496 bytes/sec
test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates):   1319 opers/sec,  10809344 bytes/sec
test 18 ( 8192 byte blocks,  256 bytes per update,  32 updates):   1550 opers/sec,  12701696 bytes/sec
test 19 ( 8192 byte blocks, 1024 bytes per update,   8 updates):   1164 opers/sec,   9539584 bytes/sec
test 20 ( 8192 byte blocks, 4096 bytes per update,   2 updates):   1802 opers/sec,  14766080 bytes/sec
test 21 ( 8192 byte blocks, 8192 bytes per update,   1 updates):   1720 opers/sec,  14094336 bytes/sec

CC: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
---

This patch seems fairly stable but I've only tested omap-sham (crypto)
and omap_hsmmc (mmc) on an am37x EVM.  I also enabled burst mode but
that made the system unstable when exercising either omap-sham or
omap_hsmmc.  I'm unaware of any errata that would make this an unwanted
modification but I haven't checked all of the SoCs.  Are there other
reasons that this should be applied??

The different types of hardware that I have is somewhat limited so if
you have some different platforms/SoCs, please give this patch a try.
It should apply cleanly against recent k.o. kernels.

Note that the current omap-sham driver doesn't use the dmaengine API
but I have a set of patches to convert it which is what I used when
testing.  I will submit those patches once they're ready (next day or so).
Also note that an am37xx GP actually does have sham hardware and yours
might too if you look closely.  If so, you'll have hack omap_sham_mod_init()
to use it.

Thanks,

Mark

 drivers/dma/omap-dma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..aadddb2 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;
@@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
 		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

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:

> This patch seems fairly stable but I've only tested omap-sham (crypto)
> and omap_hsmmc (mmc) on an am37x EVM.  I also enabled burst mode but
> that made the system unstable when exercising either omap-sham or
> omap_hsmmc.  I'm unaware of any errata that would make this an unwanted
> modification but I haven't checked all of the SoCs.  Are there other
> reasons that this should be applied??
                          ^not

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Russell King - ARM Linux]

On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> This patch seems fairly stable but I've only tested omap-sham (crypto)
> and omap_hsmmc (mmc) on an am37x EVM.  I also enabled burst mode but
> that made the system unstable when exercising either omap-sham or
> omap_hsmmc.  I'm unaware of any errata that would make this an unwanted
> modification but I haven't checked all of the SoCs.  Are there other
> reasons that this should be applied??

It definitely needs checking with audio, because it will affect the
pointer position in relation to audio output, and it will have an
effect on how much audio data is lost over a pause/resume event.

Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
it can only do a "stop" which involves dumping its FIFOs on the floor
in the case of anything but a DEV->MEM transfer.  So the more data
held in the DMA hardware, the more is lost on pause.

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > and omap_hsmmc (mmc) on an am37x EVM.  I also enabled burst mode but
> > that made the system unstable when exercising either omap-sham or
> > omap_hsmmc.  I'm unaware of any errata that would make this an unwanted
> > modification but I haven't checked all of the SoCs.  Are there other
> > reasons that this should be applied??
> 
> It definitely needs checking with audio, because it will affect the
> pointer position in relation to audio output, and it will have an
> effect on how much audio data is lost over a pause/resume event.
> 
> Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
> it can only do a "stop" which involves dumping its FIFOs on the floor
> in the case of anything but a DEV->MEM transfer.  So the more data
> held in the DMA hardware, the more is lost on pause.

Hmm, interesting.

Is there a way to tweak DMA params like this on a per logical channel
basis using the dmaengine API?  I don't see any but I could have missed it.

If not, are you open to adding such a thing (e.g., extend 'enum dma_ctrl_flags'
with DMA_ENABL_PREFETCH)?

Mark
--

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Russell King - ARM Linux]

On Thu, Oct 18, 2012 at 04:24:05PM -0700, Mark A. Greer wrote:
> On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > > and omap_hsmmc (mmc) on an am37x EVM.  I also enabled burst mode but
> > > that made the system unstable when exercising either omap-sham or
> > > omap_hsmmc.  I'm unaware of any errata that would make this an unwanted
> > > modification but I haven't checked all of the SoCs.  Are there other
> > > reasons that this should be applied??
> > 
> > It definitely needs checking with audio, because it will affect the
> > pointer position in relation to audio output, and it will have an
> > effect on how much audio data is lost over a pause/resume event.
> > 
> > Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
> > it can only do a "stop" which involves dumping its FIFOs on the floor
> > in the case of anything but a DEV->MEM transfer.  So the more data
> > held in the DMA hardware, the more is lost on pause.
> 
> Hmm, interesting.
> 
> Is there a way to tweak DMA params like this on a per logical channel
> basis using the dmaengine API?  I don't see any but I could have missed it.
> 
> If not, are you open to adding such a thing (e.g., extend 'enum dma_ctrl_flags'
> with DMA_ENABL_PREFETCH)?

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.

I'm merely pointing out here that we need their feedback here before
deciding if there's anything further that needs to happen.

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

On Fri, Oct 19, 2012 at 12:33:35AM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 18, 2012 at 04:24:05PM -0700, Mark A. Greer wrote:
> > On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote:
> > > > This patch seems fairly stable but I've only tested omap-sham (crypto)
> > > > and omap_hsmmc (mmc) on an am37x EVM.  I also enabled burst mode but
> > > > that made the system unstable when exercising either omap-sham or
> > > > omap_hsmmc.  I'm unaware of any errata that would make this an unwanted
> > > > modification but I haven't checked all of the SoCs.  Are there other
> > > > reasons that this should be applied??
> > > 
> > > It definitely needs checking with audio, because it will affect the
> > > pointer position in relation to audio output, and it will have an
> > > effect on how much audio data is lost over a pause/resume event.
> > > 
> > > Unfortunately, the OMAP DMA hardware has no way to do a proper "pause",
> > > it can only do a "stop" which involves dumping its FIFOs on the floor
> > > in the case of anything but a DEV->MEM transfer.  So the more data
> > > held in the DMA hardware, the more is lost on pause.
> > 
> > Hmm, interesting.
> > 
> > Is there a way to tweak DMA params like this on a per logical channel
> > basis using the dmaengine API?  I don't see any but I could have missed it.
> > 
> > If not, are you open to adding such a thing (e.g., extend 'enum dma_ctrl_flags'
> > with DMA_ENABL_PREFETCH)?
> 
> 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.
> 
> I'm merely pointing out here that we need their feedback here before
> deciding if there's anything further that needs to happen.

Thanks, I will do that.

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Péter Ujfalusi]

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.

-- 
Péter
--
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

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

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.

Ping?
--
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

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

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

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Russell King - ARM Linux]

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'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.

Péter, any news?
--
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

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Peter Ujfalusi]

On 11/17/2012 12:31 PM, Russell King - ARM Linux wrote:
> 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'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.
> 
> Péter, any news?

Sorry, I was carried away with other things...
I did some testing with and without the dma prefetch for audio (on BeagleBoard
with mplayer: -ao alsa/pulse).
When we have prefetch enabled we tend to resume after pause from a slightly
off place than when the prefetch is disabled.
I also remember that in n9 we have had some issue with the DMA prefetch.

So I would for sure enable the prefetch for non cyclic DMA.
For the cyclic I would not enable it for now. I need to dig a bit deeper in
DMA/McBSP to have better view on the issue.

I have one comment to the patch itself as well.

-- 
Péter
--
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

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Peter Ujfalusi]

Hi,

On 10/19/2012 12:20 AM, Mark A. Greer wrote:
> Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
> flag whenever there is a destination synchronized DMA transfer.
> Prefetching is not allowed on source synchronized DMA transfers.
> 
> Enabling prefetch significantly improves DMA performance.
> For example, running 'modprobe tcrypt sec=2 mode=403' which
> exercises the omap-sham driver on an am37x EVM yeilds the
> following results:

>  drivers/dma/omap-dma.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index bb2d8e7..aadddb2 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;

This should be:
 -		sync_type = OMAP_DMA_DST_SYNC;
 +		sync_type = OMAP_DMA_DST_SYNC_PREFETCH;


>  	} else {
>  		dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
>  		return NULL;
> @@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
>  		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;

We should not enable the prefetch for cyclic right now. We will investigate it
more.

>  	} else {
>  		dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
>  		return NULL;
> 

-- 
Péter

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Russell King - ARM Linux]

On Mon, Nov 19, 2012 at 11:00:15AM +0100, Peter Ujfalusi wrote:
> When we have prefetch enabled we tend to resume after pause from a slightly
> off place than when the prefetch is disabled.

That is exactly what I was expecting would happen having read how the
DMA works.

With memory->device transfers, if you stop them (there is no pause), the
DMA hardware discards its buffers.  So if you allow it to prefetch data,
you're going to throw more data away when you stop it.

For device->memory transfers, at least it will write the contents back to
memory before stopping.

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

On Mon, Nov 19, 2012 at 11:01:44AM +0100, Peter Ujfalusi wrote:
> Hi,
> 
> On 10/19/2012 12:20 AM, Mark A. Greer wrote:
> > Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
> > flag whenever there is a destination synchronized DMA transfer.
> > Prefetching is not allowed on source synchronized DMA transfers.
> > 
> > Enabling prefetch significantly improves DMA performance.
> > For example, running 'modprobe tcrypt sec=2 mode=403' which
> > exercises the omap-sham driver on an am37x EVM yeilds the
> > following results:
> 
> >  drivers/dma/omap-dma.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> > index bb2d8e7..aadddb2 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;
> 
> This should be:
>  -		sync_type = OMAP_DMA_DST_SYNC;
>  +		sync_type = OMAP_DMA_DST_SYNC_PREFETCH;

Ah, right.  I will fix.

> >  	} else {
> >  		dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
> >  		return NULL;
> > @@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> >  		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;
> 
> We should not enable the prefetch for cyclic right now. We will investigate it
> more.

OK.  I'll send a patch in a few minutes.

Mark
--

Re: [RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

On Mon, Nov 19, 2012 at 09:19:15AM -0700, Mark A. Greer wrote:
> On Mon, Nov 19, 2012 at 11:01:44AM +0100, Peter Ujfalusi wrote:
> > Hi,
> > 
> > On 10/19/2012 12:20 AM, Mark A. Greer wrote:
> > > Enable DMA prefetching by setting the 'OMAP_DMA_DST_SYNC_PREFETCH'
> > > flag whenever there is a destination synchronized DMA transfer.
> > > Prefetching is not allowed on source synchronized DMA transfers.
> > > 
> > > Enabling prefetch significantly improves DMA performance.
> > > For example, running 'modprobe tcrypt sec=2 mode=403' which
> > > exercises the omap-sham driver on an am37x EVM yeilds the
> > > following results:
> > 
> > >  drivers/dma/omap-dma.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> > > index bb2d8e7..aadddb2 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;
> > 
> > This should be:
> >  -		sync_type = OMAP_DMA_DST_SYNC;
> >  +		sync_type = OMAP_DMA_DST_SYNC_PREFETCH;
> 
> Ah, right.  I will fix.
> 
> > >  	} else {
> > >  		dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
> > >  		return NULL;
> > > @@ -387,7 +387,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> > >  		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;
> > 
> > We should not enable the prefetch for cyclic right now. We will investigate it
> > more.
> 
> OK.  I'll send a patch in a few minutes.

https://patchwork.kernel.org/patch/1765941/