From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752958AbdJSLzu (ORCPT ); Thu, 19 Oct 2017 07:55:50 -0400 Received: from galahad.ideasonboard.com ([185.26.127.97]:49795 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751680AbdJSLzs (ORCPT ); Thu, 19 Oct 2017 07:55:48 -0400 From: Laurent Pinchart To: Kuninori Morimoto Cc: Geert Uytterhoeven , Dan Williams , Vinod Koul , 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 Date: Thu, 19 Oct 2017 14:56:10 +0300 Message-ID: <1829561.1ekuWUXXN0@avalon> In-Reply-To: <87bml4c5e0.wl%kuninori.morimoto.gx@renesas.com> References: <87bml4c5e0.wl%kuninori.morimoto.gx@renesas.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Morimoto-san, Thank you for the patch. On Thursday, 19 October 2017 04:15:13 EEST 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. > > Signed-off-by: Hiroyuki Yokoyama > [Kuninori: added detail information in log] > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > v2 -> v3 > > - Code is back to same as v1 > - log has more detail explanation > - From: is back to Yokoyama-san again > > drivers/dma/sh/rcar-dmac.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > index 2b2c7db..50c4950 100644 > --- a/drivers/dma/sh/rcar-dmac.c > +++ b/drivers/dma/sh/rcar-dmac.c > @@ -1310,7 +1310,7 @@ static unsigned int rcar_dmac_chan_get_residue(struct > rcar_dmac_chan *chan, } > > /* Add the residue for the current chunk. */ > - residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift; > + residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift; > > return residue; > } -- Regards, Laurent Pinchart