From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Vinod Koul" <vinod.koul@intel.com>,
"Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>,
dmaengine@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Hiroyuki Yokoyama" <hiroyuki.yokoyama.vx@renesas.com>
Subject: Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue
Date: Thu, 19 Oct 2017 14:56:10 +0300 [thread overview]
Message-ID: <1829561.1ekuWUXXN0@avalon> (raw)
In-Reply-To: <87bml4c5e0.wl%kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
Thank you for the patch.
On Thursday, 19 October 2017 04:15:13 EEST Kuninori Morimoto wrote:
> From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>
> 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> 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
next prev parent reply other threads:[~2017-10-19 11:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 1:15 [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue Kuninori Morimoto
2017-10-19 7:41 ` Geert Uytterhoeven
2017-10-19 11:56 ` Laurent Pinchart [this message]
2017-10-20 6:15 ` Vinod Koul
2017-10-31 10:45 ` Geert Uytterhoeven
2017-10-31 10:46 ` Geert Uytterhoeven
2017-10-31 11:41 ` Vinod Koul
2017-11-01 3:07 ` Kuninori Morimoto
2017-11-06 1:24 ` Kuninori Morimoto
2017-11-06 13:27 ` Geert Uytterhoeven
2017-11-08 5:35 ` Vinod Koul
2017-11-08 6:33 ` Kuninori Morimoto
2017-11-08 8:37 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1829561.1ekuWUXXN0@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=hiroyuki.yokoyama.vx@renesas.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.