target/linux/brcm2708/patches-4.4/0407-dmaengine-bcm2835-Avoid-splitting-periods-into-very-.patch

   1 From 6bcfb541bbf5398f91d426c9e6c0e3817d18bb8e Mon Sep 17 00:00:00 2001
   2 From: Matthias Reichl <hias@horus.com>
   3 Date: Wed, 8 Jun 2016 13:09:56 +0200
   4 Subject: [PATCH 407/423] dmaengine: bcm2835: Avoid splitting periods into very
   5  small chunks
   6
   7 The current cyclic DMA period splitting implementation can generate
   8 very small chunks at the end of each period. For example a 65536 byte
   9 period will be split into a 65532 byte chunk and a 4 byte chunk on
  10 the "lite" DMA channels.
  11
  12 This increases pressure on the RAM controller as the DMA controller
  13 needs to fetch two control blocks from RAM in quick succession and
  14 could potentially cause latency issues if the RAM is tied up by other
  15 devices.
  16
  17 We can easily avoid these situations by distributing the remaining
  18 length evenly between the last-but-one and the last chunk, making
  19 sure that split chunks will be at least half the maximum length the
  20 DMA controller can handle.
  21
  22 This patch checks if the last chunk would be less than half of
  23 the maximum DMA length and if yes distributes the max len+4...max_len*1.5
  24 bytes evenly between the last 2 chunks. This results in chunk sizes
  25 between max_len/2 and max_len*0.75 bytes.
  26
  27 Signed-off-by: Matthias Reichl <hias@horus.com>
  28 Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
  29 Tested-by: Clive Messer <clive.messer@digitaldreamtime.co.uk>
  30 ---
  31  drivers/dma/bcm2835-dma.c | 14 ++++++++++++++
  32  1 file changed, 14 insertions(+)
  33
  34 --- a/drivers/dma/bcm2835-dma.c
  35 +++ b/drivers/dma/bcm2835-dma.c
  36 @@ -253,6 +253,20 @@ static void bcm2835_dma_create_cb_set_le
  37
  38         /* have we filled in period_length yet? */
  39         if (*total_len + control_block->length < period_len) {
  40 +               /*
  41 +                * If the next control block is the last in the period
  42 +                * and it's length would be less than half of max_len
  43 +                * change it so that both control blocks are (almost)
  44 +                * equally long. This avoids generating very short
  45 +                * control blocks (worst case would be 4 bytes) which
  46 +                * might be problematic. We also have to make sure the
  47 +                * new length is a multiple of 4 bytes.
  48 +                */
  49 +               if (*total_len + control_block->length + max_len / 2 >
  50 +                   period_len) {
  51 +                       control_block->length =
  52 +                               DIV_ROUND_UP(period_len - *total_len, 8) * 4;
  53 +               }
  54                 /* update number of bytes in this period so far */
  55                 *total_len += control_block->length;
  56                 return;