From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751439AbdJTGLB (ORCPT ); Fri, 20 Oct 2017 02:11:01 -0400 Received: from mga01.intel.com ([192.55.52.88]:13634 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750968AbdJTGK7 (ORCPT ); Fri, 20 Oct 2017 02:10:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,405,1503385200"; d="scan'208";a="140307690" Date: Fri, 20 Oct 2017 11:45:16 +0530 From: Vinod Koul To: Kuninori Morimoto Cc: Geert Uytterhoeven , Laurent Pinchart , Dan Williams , Niklas =?iso-8859-1?Q?S=F6derlund?= , dmaengine@vger.kernel.org, "linux-kernel@vger.kernel.org" , Hiroyuki Yokoyama Subject: Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue Message-ID: <20171020061516.GM30097@localhost> References: <87bml4c5e0.wl%kuninori.morimoto.gx@renesas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bml4c5e0.wl%kuninori.morimoto.gx@renesas.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 19, 2017 at 01:15:13AM +0000, Kuninori Morimoto wrote: > From: Hiroyuki Yokoyama > > SYS/RT/Audio DMAC includes independent data buffers for reading > and writing. Therefore, the read transfer counter and write transfer > counter have different values. > TCR indicates read counter, and TCRB indicates write counter. > The relationship is like below. > > TCR TCRB > [SOURCE] -> [DMAC] -> [SINK] > > In the MEM_TO_DEV direction, what really matters is how much data has > been written to the device. If the DMA is interrupted between read and > write, then, the data doesn't end up in the destination, so shouldn't > be counted. TCRB is thus the register we should use in this cases. > > In the DEV_TO_MEM direction, the situation is more complex. Both the > read and write side are important. What matters from a data consumer > point of view is how much data has been written to memory. > On the other hand, if the transfer is interrupted between read and > write, we'll end up losing data. It can also be important to report. > > In the MEM_TO_MEM direction, what matters is of course how much data > has been written to memory from data consumer point of view. > Here, because read and write have independent data buffers, it will > take a while for TCR and TCRB to become equal. Thus we should check > TCRB in this case, too. > > Thus, all cases we should check TCRB instead of TCR. > > Without this patch, Sound Capture has noise after PluseAudio support > (= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because > the recorder will use wrong residue counter which indicates transferred > from sound device, but in reality the data was not yet put to memory > and recorder will record it. Applied, thanks. -- ~Vinod