From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: <vinod.koul@intel.com>
Cc: <dmaengine@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-omap@vger.kernel.org>, <linux@arm.linux.org.uk>,
<misael.lopez@ti.com>
Subject: [PATCH] dmaengine: omap-dma: Enable packed accesses for cyclic transfers
Date: Mon, 14 Sep 2015 15:31:05 +0300 [thread overview]
Message-ID: <1442233865-10412-1-git-send-email-peter.ujfalusi@ti.com> (raw)
From: Misael Lopez Cruz <misael.lopez@ti.com>
The L3 throughput can be higher than expected when packed access
is not enabled. The ratio depends on the number of bytes in a
transaction and the EMIF interface width.
The throughput was measured for the following settings/cases:
* Case 1: Burst size of 64 bytes, packed access disabled
* Case 2: Burst size of 64 bytes, packed access enabled
* Case 3: Burst disabled, packed access disabled
Throughput measurements were done during McASP-based audio
playback on the Jacinto6 EVM using the omapconf tool [1]:
$ omapconf trace bw -m sdma_rd
---------------------------------------------------------
Throughput (MB/s)
Audio parameters Case 1 Case 2 Case 3
---------------------------------------------------------
44.1kHz, 16-bits, stereo 1.41 0.18 1.41
44.1kHz, 32-bits, stereo 1.41 0.35 1.41
44.1kHz, 16-bits, 4-chan 2.82 0.35 2.82
44.1kHz, 16-bits, 6-chan 4.23 0.53 4.23
44.1kHz, 16-bits, 8-chan 5.64 0.71 5.64
---------------------------------------------------------
>From above measurements, case 2 is the only one that delivers
the expected throughput for the given audio parameters. For
that reason, the packed accesses are now enabled.
It's worth to mention that packed accesses cannot be enabled
for all addressing modes. In cyclic transfers, it can be
enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM,
as they use post-increment mode which supports packed accesses.
Peter Ujfalusi:
>From the TRM regarding to this:
"NOTE: Except in the constant addressing mode, the source or
destination must be specified as packed for burst transactions
to occur."
So w/o the packed setting the burst on the MEM side was not
enabled, this explains the numbers.
[1] https://github.com/omapconf/omapconf
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/omap-dma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 249445c8a4c6..1dfc71c90123 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -935,8 +935,12 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
else
d->ccr |= CCR_SYNC_ELEMENT;
- if (dir == DMA_DEV_TO_MEM)
+ if (dir == DMA_DEV_TO_MEM) {
d->ccr |= CCR_TRIGGER_SRC;
+ d->csdp |= CSDP_DST_PACKED;
+ } else {
+ d->csdp |= CSDP_SRC_PACKED;
+ }
d->cicr |= CICR_MISALIGNED_ERR_IE | CICR_TRANS_ERR_IE;
--
2.5.2
WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: vinod.koul@intel.com
Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, linux@arm.linux.org.uk,
misael.lopez@ti.com
Subject: [PATCH] dmaengine: omap-dma: Enable packed accesses for cyclic transfers
Date: Mon, 14 Sep 2015 15:31:05 +0300 [thread overview]
Message-ID: <1442233865-10412-1-git-send-email-peter.ujfalusi@ti.com> (raw)
From: Misael Lopez Cruz <misael.lopez@ti.com>
The L3 throughput can be higher than expected when packed access
is not enabled. The ratio depends on the number of bytes in a
transaction and the EMIF interface width.
The throughput was measured for the following settings/cases:
* Case 1: Burst size of 64 bytes, packed access disabled
* Case 2: Burst size of 64 bytes, packed access enabled
* Case 3: Burst disabled, packed access disabled
Throughput measurements were done during McASP-based audio
playback on the Jacinto6 EVM using the omapconf tool [1]:
$ omapconf trace bw -m sdma_rd
---------------------------------------------------------
Throughput (MB/s)
Audio parameters Case 1 Case 2 Case 3
---------------------------------------------------------
44.1kHz, 16-bits, stereo 1.41 0.18 1.41
44.1kHz, 32-bits, stereo 1.41 0.35 1.41
44.1kHz, 16-bits, 4-chan 2.82 0.35 2.82
44.1kHz, 16-bits, 6-chan 4.23 0.53 4.23
44.1kHz, 16-bits, 8-chan 5.64 0.71 5.64
---------------------------------------------------------
>From above measurements, case 2 is the only one that delivers
the expected throughput for the given audio parameters. For
that reason, the packed accesses are now enabled.
It's worth to mention that packed accesses cannot be enabled
for all addressing modes. In cyclic transfers, it can be
enabled in the source for MEM_TO_DEV and in dest for DEV_TO_MEM,
as they use post-increment mode which supports packed accesses.
Peter Ujfalusi:
>From the TRM regarding to this:
"NOTE: Except in the constant addressing mode, the source or
destination must be specified as packed for burst transactions
to occur."
So w/o the packed setting the burst on the MEM side was not
enabled, this explains the numbers.
[1] https://github.com/omapconf/omapconf
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/omap-dma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 249445c8a4c6..1dfc71c90123 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -935,8 +935,12 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
else
d->ccr |= CCR_SYNC_ELEMENT;
- if (dir == DMA_DEV_TO_MEM)
+ if (dir == DMA_DEV_TO_MEM) {
d->ccr |= CCR_TRIGGER_SRC;
+ d->csdp |= CSDP_DST_PACKED;
+ } else {
+ d->csdp |= CSDP_SRC_PACKED;
+ }
d->cicr |= CICR_MISALIGNED_ERR_IE | CICR_TRANS_ERR_IE;
--
2.5.2
next reply other threads:[~2015-09-14 12:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 12:31 Peter Ujfalusi [this message]
2015-09-14 12:31 ` [PATCH] dmaengine: omap-dma: Enable packed accesses for cyclic transfers Peter Ujfalusi
2015-09-25 7:00 ` Peter Ujfalusi
2015-09-25 7:00 ` Peter Ujfalusi
2015-10-05 15:32 ` Vinod Koul
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=1442233865-10412-1-git-send-email-peter.ujfalusi@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=misael.lopez@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 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.