From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423446AbcFNFGz (ORCPT ); Tue, 14 Jun 2016 01:06:55 -0400 Received: from anholt.net ([50.246.234.109]:47210 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbcFNFGy (ORCPT ); Tue, 14 Jun 2016 01:06:54 -0400 From: Eric Anholt To: Matthias Reichl , Vinod Koul , Stephen Warren , Lee Jones Cc: Martin Sperl , Clive Messer , dmaengine@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] dmaengine: bcm2835: Avoid splitting periods into very small chunks In-Reply-To: <1465472504-10191-3-git-send-email-hias@horus.com> References: <1465472504-10191-1-git-send-email-hias@horus.com> <1465472504-10191-3-git-send-email-hias@horus.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Mon, 13 Jun 2016 22:06:49 -0700 Message-ID: <8760tcwe8m.fsf@eliezer.anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Matthias Reichl writes: > 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(+) > > diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c > index 344bcf92..36b998d 100644 > --- a/drivers/dma/bcm2835-dma.c > +++ b/drivers/dma/bcm2835-dma.c > @@ -252,6 +252,20 @@ static void bcm2835_dma_create_cb_set_length( >=20=20 > /* 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 =3D > + DIV_ROUND_UP(period_len - *total_len, 8) * 4; > + } > /* update number of bytes in this period so far */ > *total_len +=3D control_block->length; > return; It seems to me like this would all be a lot simpler if we always split the last 2 control blocks evenly (other than 4-byte rounding): u32 period_remaining =3D period_len - *total_len; /* Early exit if we aren't finishing this period */ if (period_remaining >=3D max_len) { /* * Split the length between the last 2 CBs, to help hide the * latency of fetching the CBs. */ if (period_remaining < max_len * 2) { control_block->length =3D DIV_ROUND_UP(period_remaining, 8) * 4; } /* update number of bytes in this period so far */ *total_len +=3D control_block->length; } I'm about to go semi-AFK for a couple weeks. If there's a good reason to only do this when the last block is very short, I'm fine with: Acked-by: Eric Anholt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJXX5DpAAoJELXWKTbR/J7ozbYQAJWLEclR7M4jb4VJEq2wJLra EPbu22jG9vA9KC7Bk/NTSHBiElCuIFynGXkbErPdJ9AH8NOPVOT/O2hIHQF36S1C jFbooh7WrP56U+d/G7mHo7zcXFNc0bGE0ST1IDqhdIrF1M7aKWIBeaCPKf6Jjd9Z lbeNISjjVSwZ8v4vtZeKkKxbAnalojIlBYB39xQGkn7QKD8+93xI4gtfcfINTw4v O37q3dU5NEwq2rbfo48FRTbosxVIKFWESR2oaRIDDwVn6sgYARRto7c3KdLkNaeC nbHZEukGFic3b/8fGR93GfZlW+JYQgtxX64c4auUa5tjsDyww4Ao7eIIawYKznJS N3HdvquChjWFiDVGXP5T3SkuSwrI8pp0a3wuknfaVpIqfeGhv6AVTqgYr8hEjqug AKRcDrHQFp7Qn4jKERv4g0L0ZV6Q+M2bFMWj/pB4hK6aSZk8BGmsdnweZASbFdNf SKKXNscTUqZWdj8lualXWrKu5pPLy9EF9ixoMUVTxvw5andMyysL5p230TC8bs/A xYZfE71HNyjs7fFrK25tcIn1hGrtjoYk8Neh39zJECtUq5owUZa8OZUKNZXDaHxZ 2BGft1x6oGLWfIAOIi11lsI07BRfKdvLhnQrUeUCQbE8/s/yyRZifbobDBMnoiAf FwLO5VH1mZ6/DBA5YDYW =Y2N9 -----END PGP SIGNATURE----- --=-=-=--