Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753395AbbGJIEL (ORCPT ); Fri, 10 Jul 2015 04:04:11 -0400 Received: from mga03.intel.com ([134.134.136.65]:53779 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753045AbbGJID6 (ORCPT ); Fri, 10 Jul 2015 04:03:58 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,445,1432623600"; d="scan'208";a="744292105" Date: Fri, 10 Jul 2015 13:35:42 +0530 From: Vinod Koul To: Cyrille Pitchen Cc: nicolas.ferre@atmel.com, ludovic.desroches@atmel.com, dan.j.williams@intel.com, dmaengine@vger.kernel.org, torfl6749@gmail.com, jiri.prchal@aksignal.cz, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH linux-next v2 1/1] dmaengine: at_hdmac: fix residue computation Message-ID: <20150710080542.GD836@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2139 Lines: 43 On Thu, Jun 18, 2015 at 01:25:41PM +0200, Cyrille Pitchen wrote: > As claimed by the programmer datasheet and confirmed by the IP designer, > the Block Transfer Size (BTSIZE) bitfield of the Channel x Control A > Register (CTRLAx) always refers to a number of Source Width (SRC_WIDTH) > transfers. > > Both the SRC_WIDTH and BTSIZE bitfields can be extacted from the CTRLAx > register to compute the DMA residue. So the 'tx_width' field is useless > and can be removed from the struct at_desc. > > Before this patch, atc_prep_slave_sg() was not consistent: BTSIZE was > correctly initialized according to the SRC_WIDTH but 'tx_width' was always > set to reg_width, which was incorrect for MEM_TO_DEV transfers. It led to > bad DMA residue when 'tx_width' != SRC_WIDTH. > > Also the 'tx_width' field was mostly set only in the first and last > descriptors. Depending on the kind of DMA transfer, this field remained > uninitialized for intermediate descriptors. The accurate DMA residue was > computed only when the currently processed descriptor was the first or the > last of the chain. This algorithm was a little bit odd. An accurate DMA > residue can always be computed using the SRC_WIDTH and BTSIZE bitfields > in the CTRLAx register. > > Finally, the test to check whether the currently processed descriptor is > the last of the chain was wrong: for cyclic transfer, last_desc->lli.dscr > is NOT equal to zero, since set_desc_eol() is never called, but logically > equal to first_desc->txd.phys. This bug has a side effect on the > drivers/tty/serial/atmel_serial.c driver, which uses cyclic DMA transfer > to receive data. Since the DMA residue was wrong each time the DMA > transfer reaches the second (and last) period of the transfer, no more > data were received by the USART driver till the cyclic DMA transfer loops > back to the first period. > Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/