From 2b1c6b21b5e6c82ebb55d7fb7df90e60e88cbb14 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=81lvaro=20Fern=C3=A1ndez=20Rojas?= Date: Sat, 10 Sep 2016 14:54:26 +0200 Subject: brcm2708: update linux 4.4 patches to latest version MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As usual these patches were extracted and rebased from the raspberry pi repo: https://github.com/raspberrypi/linux/tree/rpi-4.4.y Also adds support for Raspberry Pi Compute Module 3 (untested). Signed-off-by: Álvaro Fernández Rojas --- ...cm2835-Avoid-splitting-periods-into-very-.patch | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) create mode 100644 target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch (limited to 'target/linux/brcm2708/patches-4.4/0406-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch') 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 +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 +Signed-off-by: Martin Sperl +Tested-by: Clive Messer +--- + 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; -- cgit v1.2.3