From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Bondarenko Subject: Re: [PATCH v3 1/7] spi: imx: Fix DMA transfer Date: Sat, 14 Nov 2015 11:02:58 +0100 Message-ID: <564706D2.5050607@gmail.com> References: <1446388901-6073-1-git-send-email-anton.bondarenko.sama@gmail.com> <1446388901-6073-2-git-send-email-anton.bondarenko.sama@gmail.com> <20151105083422.GH8526@pengutronix.de> <563B88FD.8050702@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, b38343-KZfg59tc24xl57MIdRCFDg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org, jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org To: Sascha Hauer Return-path: In-Reply-To: <563B88FD.8050702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-spi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On 05.11.2015 17:51, Anton Bondarenko wrote: > On 05.11.2015 09:34, Sascha Hauer wrote: >> On Sun, Nov 01, 2015 at 03:41:35PM +0100, Anton Bondarenko wrote: >>> From: Anton Bondarenko >>> >>> RX DMA tail data handling doesn't work correctly in many cases with >>> current implementation. It happens because SPI core was setup >>> to generates both RX watermark level and RX DATA TAIL events >>> incorrectly. SPI transfer triggering for DMA also done in wrong way. >>> >>> SPI client wants to transfer 70 words for example. The old DMA >>> implementation setup RX DATA TAIL equal 6 words. In this case >>> RX DMA event will be generated after 6 words read from RX FIFO. >>> The garbage can be read out from RX FIFO because SPI HW does >>> not receive all required words to trigger RX watermark event. >>> >>> New implementation change handling of RX data tail. DMA is used to >>> process >>> all TX data and only full chunks of RX data with size aligned to FIFO/2. >>> Driver is waiting until both TX and RX DMA transaction done and all >>> TX data are pushed out. At that moment there is only RX data tail in >>> the RX FIFO. This data read out using PIO. >> >> Have you looked at the RX_DMA_LENGTH and RXTDEN fields of the DMA >> register? These seem to be for handling the remaining bytes of a DMA >> transfer which do not reach the watermark level. From reading the >> documentation I haven't really understood how it works though. >> >> Sascha >> > > A lot of times. Current implementation is trying to use it, but works > incorrectly if length % WML != 0 (which means RX_DMA_LENGTH == 0). > > Regards, Anton Does anyone has other comments regarding this commit? Regards, Anton -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: anton.bondarenko.sama@gmail.com (Anton Bondarenko) Date: Sat, 14 Nov 2015 11:02:58 +0100 Subject: [PATCH v3 1/7] spi: imx: Fix DMA transfer In-Reply-To: <563B88FD.8050702@gmail.com> References: <1446388901-6073-1-git-send-email-anton.bondarenko.sama@gmail.com> <1446388901-6073-2-git-send-email-anton.bondarenko.sama@gmail.com> <20151105083422.GH8526@pengutronix.de> <563B88FD.8050702@gmail.com> Message-ID: <564706D2.5050607@gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05.11.2015 17:51, Anton Bondarenko wrote: > On 05.11.2015 09:34, Sascha Hauer wrote: >> On Sun, Nov 01, 2015 at 03:41:35PM +0100, Anton Bondarenko wrote: >>> From: Anton Bondarenko >>> >>> RX DMA tail data handling doesn't work correctly in many cases with >>> current implementation. It happens because SPI core was setup >>> to generates both RX watermark level and RX DATA TAIL events >>> incorrectly. SPI transfer triggering for DMA also done in wrong way. >>> >>> SPI client wants to transfer 70 words for example. The old DMA >>> implementation setup RX DATA TAIL equal 6 words. In this case >>> RX DMA event will be generated after 6 words read from RX FIFO. >>> The garbage can be read out from RX FIFO because SPI HW does >>> not receive all required words to trigger RX watermark event. >>> >>> New implementation change handling of RX data tail. DMA is used to >>> process >>> all TX data and only full chunks of RX data with size aligned to FIFO/2. >>> Driver is waiting until both TX and RX DMA transaction done and all >>> TX data are pushed out. At that moment there is only RX data tail in >>> the RX FIFO. This data read out using PIO. >> >> Have you looked at the RX_DMA_LENGTH and RXTDEN fields of the DMA >> register? These seem to be for handling the remaining bytes of a DMA >> transfer which do not reach the watermark level. From reading the >> documentation I haven't really understood how it works though. >> >> Sascha >> > > A lot of times. Current implementation is trying to use it, but works > incorrectly if length % WML != 0 (which means RX_DMA_LENGTH == 0). > > Regards, Anton Does anyone has other comments regarding this commit? Regards, Anton From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751394AbbKNKDF (ORCPT ); Sat, 14 Nov 2015 05:03:05 -0500 Received: from mail-lf0-f49.google.com ([209.85.215.49]:36414 "EHLO mail-lf0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751068AbbKNKDB (ORCPT ); Sat, 14 Nov 2015 05:03:01 -0500 Subject: Re: [PATCH v3 1/7] spi: imx: Fix DMA transfer To: Sascha Hauer References: <1446388901-6073-1-git-send-email-anton.bondarenko.sama@gmail.com> <1446388901-6073-2-git-send-email-anton.bondarenko.sama@gmail.com> <20151105083422.GH8526@pengutronix.de> <563B88FD.8050702@gmail.com> Cc: broonie@kernel.org, b38343@freescale.com, linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, vladimir_zapolskiy@mentor.com, jiada_wang@mentor.com From: Anton Bondarenko Message-ID: <564706D2.5050607@gmail.com> Date: Sat, 14 Nov 2015 11:02:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B88FD.8050702@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05.11.2015 17:51, Anton Bondarenko wrote: > On 05.11.2015 09:34, Sascha Hauer wrote: >> On Sun, Nov 01, 2015 at 03:41:35PM +0100, Anton Bondarenko wrote: >>> From: Anton Bondarenko >>> >>> RX DMA tail data handling doesn't work correctly in many cases with >>> current implementation. It happens because SPI core was setup >>> to generates both RX watermark level and RX DATA TAIL events >>> incorrectly. SPI transfer triggering for DMA also done in wrong way. >>> >>> SPI client wants to transfer 70 words for example. The old DMA >>> implementation setup RX DATA TAIL equal 6 words. In this case >>> RX DMA event will be generated after 6 words read from RX FIFO. >>> The garbage can be read out from RX FIFO because SPI HW does >>> not receive all required words to trigger RX watermark event. >>> >>> New implementation change handling of RX data tail. DMA is used to >>> process >>> all TX data and only full chunks of RX data with size aligned to FIFO/2. >>> Driver is waiting until both TX and RX DMA transaction done and all >>> TX data are pushed out. At that moment there is only RX data tail in >>> the RX FIFO. This data read out using PIO. >> >> Have you looked at the RX_DMA_LENGTH and RXTDEN fields of the DMA >> register? These seem to be for handling the remaining bytes of a DMA >> transfer which do not reach the watermark level. From reading the >> documentation I haven't really understood how it works though. >> >> Sascha >> > > A lot of times. Current implementation is trying to use it, but works > incorrectly if length % WML != 0 (which means RX_DMA_LENGTH == 0). > > Regards, Anton Does anyone has other comments regarding this commit? Regards, Anton