aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch
diff options
context:
space:
mode:
Diffstat (limited to 'target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch')
-rw-r--r--target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch56
1 files changed, 56 insertions, 0 deletions
diff --git a/target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch b/target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch
new file mode 100644
index 0000000000..265ee10f45
--- /dev/null
+++ b/target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch
@@ -0,0 +1,56 @@
+From 47b93cc5b706cb592f924199f00d5adbb66bd3ca Mon Sep 17 00:00:00 2001
+From: Matthias Reichl <hias@horus.com>
+Date: Wed, 8 Jun 2016 13:09:56 +0200
+Subject: [PATCH] dmaengine: bcm2835: Avoid splitting periods into very small
+ chunks
+
+The current cyclic DMA period splitting implementation can generate
+very small chunks at the end of each period. For example a 65536 byte
+period will be split into a 65532 byte chunk and a 4 byte chunk on
+the "lite" DMA channels.
+
+This increases pressure on the RAM controller as the DMA controller
+needs to fetch two control blocks from RAM in quick succession and
+could potentially cause latency issues if the RAM is tied up by other
+devices.
+
+We can easily avoid these situations by distributing the remaining
+length evenly between the last-but-one and the last chunk, making
+sure that split chunks will be at least half the maximum length the
+DMA controller can handle.
+
+This patch checks if the last chunk would be less than half of
+the maximum DMA length and if yes distributes the max len+4...max_len*1.5
+bytes evenly between the last 2 chunks. This results in chunk sizes
+between max_len/2 and max_len*0.75 bytes.
+
+Signed-off-by: Matthias Reichl <hias@horus.com>
+Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
+Tested-by: Clive Messer <clive.messer@digitaldreamtime.co.uk>
+---
+ drivers/dma/bcm2835-dma.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/drivers/dma/bcm2835-dma.c
++++ b/drivers/dma/bcm2835-dma.c
+@@ -253,6 +253,20 @@ static void bcm2835_dma_create_cb_set_le
+
+ /* have we filled in period_length yet? */
+ if (*total_len + control_block->length < period_len) {
++ /*
++ * If the next control block is the last in the period
++ * and it's length would be less than half of max_len
++ * change it so that both control blocks are (almost)
++ * equally long. This avoids generating very short
++ * control blocks (worst case would be 4 bytes) which
++ * might be problematic. We also have to make sure the
++ * new length is a multiple of 4 bytes.
++ */
++ if (*total_len + control_block->length + max_len / 2 >
++ period_len) {
++ control_block->length =
++ DIV_ROUND_UP(period_len - *total_len, 8) * 4;
++ }
+ /* update number of bytes in this period so far */
+ *total_len += control_block->length;
+ return;