From mboxrd@z Thu Jan 1 00:00:00 1970 From: Priit Laes Subject: Re: [PATCH v2 04/14] ASoC: sun4i-codec: Increase DMA max burst to 8 Date: Thu, 03 Nov 2016 10:42:59 +0200 Message-ID: <1478162579.8841.1.camel@plaes.org> References: <20161103075556.29018-1-wens@csie.org> <20161103075556.29018-5-wens@csie.org> Reply-To: plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20161103075556.29018-5-wens-jdAy2FN1RRM@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: wens-jdAy2FN1RRM@public.gmane.org, Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Maxime Ripard , Rob Herring , Mark Rutland Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Vinod Koul List-Id: alsa-devel@alsa-project.org On Thu, 2016-11-03 at 15:55 +0800, Chen-Yu Tsai wrote: > According to the DMA engine API documentation, maxburst denotes the > largest possible size of a single transfer, so as not to overflow > destination FIFOs as explained in this excerpt from dmaengine.h >=20 > =C2=A0* @src_maxburst: the maximum number of words (note: words, as in > =C2=A0* units of the src_addr_width member, not bytes) that can be sent > =C2=A0* in one burst to the device. Typically something like half the > =C2=A0* FIFO depth on I/O peripherals so you don't overflow it. This > =C2=A0* may or may not be applicable on memory sources. > =C2=A0* @dst_maxburst: same as src_maxburst but for destination target > =C2=A0* mutatis mutandis. ^^ :) >=20 > The TX FIFO is 64 samples deep for stereo, and the RX FIFO is 16 > samples deep. So maxburst could be 32 and 8 for TX and RX > respectively. >=20 > Unfortunately the sunxi DMA controller driver takes maxburst as > the requested burst size, rather than a limit, and returns an error > for unsupported values. The original value was 4, but some later > SoCs do not officially support this burst size. >=20 > This patch increases maxburst on the TX side to 8, which is supported > by all variants of the sunxi DMA controller. >=20 > Cc: Vinod Koul > Signed-off-by: Chen-Yu Tsai > --- > =C2=A0sound/soc/sunxi/sun4i-codec.c | 4 ++-- > =C2=A01 file changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i- > codec.c > index 61ae502a5061..d867b96d367b 100644 > --- a/sound/soc/sunxi/sun4i-codec.c > +++ b/sound/soc/sunxi/sun4i-codec.c > @@ -886,12 +886,12 @@ static int sun4i_codec_probe(struct > platform_device *pdev) > =C2=A0 > =C2=A0 /* DMA configuration for TX FIFO */ > =C2=A0 scodec->playback_dma_data.addr =3D res->start + quirks- > >reg_dac_txdata; > - scodec->playback_dma_data.maxburst =3D 4; > + scodec->playback_dma_data.maxburst =3D 8; > =C2=A0 scodec->playback_dma_data.addr_width =3D > DMA_SLAVE_BUSWIDTH_2_BYTES; > =C2=A0 > =C2=A0 /* DMA configuration for RX FIFO */ > =C2=A0 scodec->capture_dma_data.addr =3D res->start + quirks- > >reg_adc_rxdata; > - scodec->capture_dma_data.maxburst =3D 4; > + scodec->capture_dma_data.maxburst =3D 8; > =C2=A0 scodec->capture_dma_data.addr_width =3D > DMA_SLAVE_BUSWIDTH_2_BYTES; > =C2=A0 > =C2=A0 ret =3D snd_soc_register_codec(&pdev->dev, quirks->codec, > --=C2=A0 > 2.10.2 >=20 --=20 You received this message because you are subscribed to the Google Groups "= linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 From: plaes@plaes.org (Priit Laes) Date: Thu, 03 Nov 2016 10:42:59 +0200 Subject: [linux-sunxi] [PATCH v2 04/14] ASoC: sun4i-codec: Increase DMA max burst to 8 In-Reply-To: <20161103075556.29018-5-wens@csie.org> References: <20161103075556.29018-1-wens@csie.org> <20161103075556.29018-5-wens@csie.org> Message-ID: <1478162579.8841.1.camel@plaes.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 2016-11-03 at 15:55 +0800, Chen-Yu Tsai wrote: > According to the DMA engine API documentation, maxburst denotes the > largest possible size of a single transfer, so as not to overflow > destination FIFOs as explained in this excerpt from dmaengine.h > > ?* @src_maxburst: the maximum number of words (note: words, as in > ?* units of the src_addr_width member, not bytes) that can be sent > ?* in one burst to the device. Typically something like half the > ?* FIFO depth on I/O peripherals so you don't overflow it. This > ?* may or may not be applicable on memory sources. > ?* @dst_maxburst: same as src_maxburst but for destination target > ?* mutatis mutandis. ^^ :) > > The TX FIFO is 64 samples deep for stereo, and the RX FIFO is 16 > samples deep. So maxburst could be 32 and 8 for TX and RX > respectively. > > Unfortunately the sunxi DMA controller driver takes maxburst as > the requested burst size, rather than a limit, and returns an error > for unsupported values. The original value was 4, but some later > SoCs do not officially support this burst size. > > This patch increases maxburst on the TX side to 8, which is supported > by all variants of the sunxi DMA controller. > > Cc: Vinod Koul > Signed-off-by: Chen-Yu Tsai > --- > ?sound/soc/sunxi/sun4i-codec.c | 4 ++-- > ?1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i- > codec.c > index 61ae502a5061..d867b96d367b 100644 > --- a/sound/soc/sunxi/sun4i-codec.c > +++ b/sound/soc/sunxi/sun4i-codec.c > @@ -886,12 +886,12 @@ static int sun4i_codec_probe(struct > platform_device *pdev) > ? > ? /* DMA configuration for TX FIFO */ > ? scodec->playback_dma_data.addr = res->start + quirks- > >reg_dac_txdata; > - scodec->playback_dma_data.maxburst = 4; > + scodec->playback_dma_data.maxburst = 8; > ? scodec->playback_dma_data.addr_width = > DMA_SLAVE_BUSWIDTH_2_BYTES; > ? > ? /* DMA configuration for RX FIFO */ > ? scodec->capture_dma_data.addr = res->start + quirks- > >reg_adc_rxdata; > - scodec->capture_dma_data.maxburst = 4; > + scodec->capture_dma_data.maxburst = 8; > ? scodec->capture_dma_data.addr_width = > DMA_SLAVE_BUSWIDTH_2_BYTES; > ? > ? ret = snd_soc_register_codec(&pdev->dev, quirks->codec, > --? > 2.10.2 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756183AbcKCIvF convert rfc822-to-8bit (ORCPT ); Thu, 3 Nov 2016 04:51:05 -0400 Received: from plaes.org ([188.166.43.21]:51570 "EHLO plaes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755676AbcKCIvD (ORCPT ); Thu, 3 Nov 2016 04:51:03 -0400 X-Greylist: delayed 481 seconds by postgrey-1.27 at vger.kernel.org; Thu, 03 Nov 2016 04:51:03 EDT Message-ID: <1478162579.8841.1.camel@plaes.org> Subject: Re: [linux-sunxi] [PATCH v2 04/14] ASoC: sun4i-codec: Increase DMA max burst to 8 From: Priit Laes To: wens@csie.org, Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , Maxime Ripard , Rob Herring , Mark Rutland Cc: alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-sunxi@googlegroups.com, Vinod Koul Date: Thu, 03 Nov 2016 10:42:59 +0200 In-Reply-To: <20161103075556.29018-5-wens@csie.org> References: <20161103075556.29018-1-wens@csie.org> <20161103075556.29018-5-wens@csie.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.18.5.2-0ubuntu3 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-11-03 at 15:55 +0800, Chen-Yu Tsai wrote: > According to the DMA engine API documentation, maxburst denotes the > largest possible size of a single transfer, so as not to overflow > destination FIFOs as explained in this excerpt from dmaengine.h > >  * @src_maxburst: the maximum number of words (note: words, as in >  * units of the src_addr_width member, not bytes) that can be sent >  * in one burst to the device. Typically something like half the >  * FIFO depth on I/O peripherals so you don't overflow it. This >  * may or may not be applicable on memory sources. >  * @dst_maxburst: same as src_maxburst but for destination target >  * mutatis mutandis. ^^ :) > > The TX FIFO is 64 samples deep for stereo, and the RX FIFO is 16 > samples deep. So maxburst could be 32 and 8 for TX and RX > respectively. > > Unfortunately the sunxi DMA controller driver takes maxburst as > the requested burst size, rather than a limit, and returns an error > for unsupported values. The original value was 4, but some later > SoCs do not officially support this burst size. > > This patch increases maxburst on the TX side to 8, which is supported > by all variants of the sunxi DMA controller. > > Cc: Vinod Koul > Signed-off-by: Chen-Yu Tsai > --- >  sound/soc/sunxi/sun4i-codec.c | 4 ++-- >  1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i- > codec.c > index 61ae502a5061..d867b96d367b 100644 > --- a/sound/soc/sunxi/sun4i-codec.c > +++ b/sound/soc/sunxi/sun4i-codec.c > @@ -886,12 +886,12 @@ static int sun4i_codec_probe(struct > platform_device *pdev) >   >   /* DMA configuration for TX FIFO */ >   scodec->playback_dma_data.addr = res->start + quirks- > >reg_dac_txdata; > - scodec->playback_dma_data.maxburst = 4; > + scodec->playback_dma_data.maxburst = 8; >   scodec->playback_dma_data.addr_width = > DMA_SLAVE_BUSWIDTH_2_BYTES; >   >   /* DMA configuration for RX FIFO */ >   scodec->capture_dma_data.addr = res->start + quirks- > >reg_adc_rxdata; > - scodec->capture_dma_data.maxburst = 4; > + scodec->capture_dma_data.maxburst = 8; >   scodec->capture_dma_data.addr_width = > DMA_SLAVE_BUSWIDTH_2_BYTES; >   >   ret = snd_soc_register_codec(&pdev->dev, quirks->codec, > --  > 2.10.2 >