This is a note to let you know that I've just added the patch titled

dmaengine: rcar-dmac: use TCRB instead of TCR for residue

to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...

The filename of the patch is: dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.

From foo@baz Mon Dec 18 13:28:59 CET 2017

From: Hiroyuki Yokoyama hiroyuki.yokoyama.vx@renesas.com Date: Thu, 19 Oct 2017 01:15:13 +0000 Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue

From: Hiroyuki Yokoyama hiroyuki.yokoyama.vx@renesas.com

[ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ]

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 hiroyuki.yokoyama.vx@renesas.com [Kuninori: added detail information in log] Signed-off-by: Kuninori Morimoto kuninori.morimoto.gx@renesas.com Reviewed-by: Geert Uytterhoeven geert+renesas@glider.be Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Signed-off-by: Vinod Koul vinod.koul@intel.com

Signed-off-by: Sasha Levin alexander.levin@verizon.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/dma/sh/rcar-dmac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

--- 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_r }

/* 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; }

Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx@renesas.com are

queue-4.14/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch