Re: [PATCH resend] dmaengine: rcar-dmac: Document R8A774A1 bindings
On 15-11-18, 11:58, Fabrizio Castro wrote: > Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible > with this driver, therefore document RZ/G2M specific bindings. Applied, thanks -- ~Vinod
Re: [PATCH resend] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
On 15-11-18, 11:59, Fabrizio Castro wrote: > From: Biju Das > > This patch adds binding for r8a774a1 (RZ/G2M). > > Signed-off-by: Biju Das Applied, thanks -- ~Vinod
Re: [PATCH 1/2] dt-bindings: dmaengine: usb-dmac: Add binding for r8a77470
On 25-10-18, 15:53, Biju Das wrote: > This patch adds usb high-speed dmac binding for r8a77470 (RZ/G1C) SoC. Applied, thanks -- ~Vinod
Re: [PATCH 1/2] dt-bindings: dmaengine: usb-dmac: Add binding for r8a77470
On 25-10-18, 15:53, Biju Das wrote: > This patch adds usb high-speed dmac binding for r8a77470 (RZ/G1C) SoC. Where is the patch 2/2 ...? > Signed-off-by: Biju Das > --- > This patch tested against linux-next. > --- > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > index 1743017..a1e7b814 100644 > --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > @@ -6,6 +6,7 @@ Required Properties: > - "renesas,r8a7743-usb-dmac" (RZ/G1M) > - "renesas,r8a7744-usb-dmac" (RZ/G1N) > - "renesas,r8a7745-usb-dmac" (RZ/G1E) > + - "renesas,r8a77470-usb-dmac" (RZ/G1C) > - "renesas,r8a7790-usb-dmac" (R-Car H2) > - "renesas,r8a7791-usb-dmac" (R-Car M2-W) > - "renesas,r8a7793-usb-dmac" (R-Car M2-N) > -- > 2.7.4 -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: set scatter/gather max segment size
On 14-09-18, 17:43, Wolfram Sang wrote: > Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a > device_dma_parameters structure and filling in the max segment size. Applied, thanks -- ~Vinod
Re: [PATCH] dt-bindings: dmaengine: usb-dmac: Add binding for r8a7744
On 27-09-18, 13:46, Biju Das wrote: > This patch adds binding for r8a7744 (RZ/G1N). Applied, thanks -- ~Vinod
Re: [PATCH] dt-bindings: rcar-dmac: Document r8a7744 support
On 17-09-18, 16:18, Biju Das wrote: > Renesas RZ/G SoC also have the R-Car gen2/3 compatible DMA controllers. > Document RZ/G1N (also known as R8A7744) SoC bindings. Applied, thanks -- ~Vinod
Re: [PATCH] dma: sh: convert to SPDX identifiers
On 12-09-18, 14:05, Geert Uytterhoeven wrote: > Hi Vinod, > > On Wed, Sep 12, 2018 at 11:43 AM Vinod wrote: > > Btw I have sent the series for dma_slave_config direction removal, sh/ > > drivers turned to be bit more, can you guys take care of it please? > > I'm sorry, I can't seem to find that. I though I had Cced renesas folks including you, but looks like I missed you, apologies > Can you please provide a link to the patch series? https://www.spinics.net/lists/dmaengine/msg16551.html Thanks -- ~Vinod
Re: [PATCH] dma: sh: convert to SPDX identifiers
On 11-09-18, 10:17, Geert Uytterhoeven wrote: > Hi Vinod, > > On Tue, Sep 11, 2018 at 9:48 AM Vinod wrote: > > On 07-09-18, 01:58, Kuninori Morimoto wrote: > > > From: Kuninori Morimoto > > > > > > This patch updates license to use SPDX-License-Identifier > > > instead of verbose license text. > > > > Thanks but the style is not consistent in files :( > > > > Can we use one only? > > Please read > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst#n69 > > 2. Style: > >The SPDX license identifier is added in form of a comment. The comment >style depends on the file type:: > > C source: // SPDX-License-Identifier: > C header: /* SPDX-License-Identifier: */ Right and I missed patch is doing for both c & h files, my bad Applying this now. Btw I have sent the series for dma_slave_config direction removal, sh/ drivers turned to be bit more, can you guys take care of it please? -- ~Vinod
Re: [PATCH] dma: sh: convert to SPDX identifiers
On 07-09-18, 01:58, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. Thanks but the style is not consistent in files :( Can we use one only? > diff --git a/drivers/dma/sh/shdma-arm.h b/drivers/dma/sh/shdma-arm.h > index a1b0ef4..30bcfe3 100644 > --- a/drivers/dma/sh/shdma-arm.h > +++ b/drivers/dma/sh/shdma-arm.h > @@ -1,11 +1,8 @@ > -/* > +/* SPDX-License-Identifier: GPL-2.0 this is one > #ifndef SHDMA_ARM_H > diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c > index 6b5626e..c51de49 100644 > --- a/drivers/dma/sh/shdma-base.c > +++ b/drivers/dma/sh/shdma-base.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0 different > diff --git a/drivers/dma/sh/shdma.h b/drivers/dma/sh/shdma.h > index 2c0a969..73aec72 100644 > --- a/drivers/dma/sh/shdma.h > +++ b/drivers/dma/sh/shdma.h > @@ -1,14 +1,9 @@ > -/* > +/* SPDX-License-Identifier: GPL-2.0+ this and so on.. -- ~Vinod
Re: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
On 24-08-18, 08:56, Fabrizio Castro wrote: > From: Biju Das > > This patch adds binding for r8a774a1 (RZ/G2M). Acked-by: Vinod Koul -- ~Vinod
Re: [PATCH] dmaengine: sh: rcar-dmac: Should not stop the DMAC by rcar_dmac_sync_tcr()
On 25-07-18, 17:27, Yoshihiro Shimoda wrote:
> rcar_dmac_chan_get_residue() should not stop the DMAC, because
> the commit 538603c6026c ("dmaengine: sh: rcar-dmac: avoid to write
> CHCR.TE to 1 if TCR is set to 0") had fixed unexpected re-transferring
> issue. But it had caused the next issue which might stop the cyclic
> mode transferring. Thus, for example R-Car sound might be stopped
> suddenly.
>
> According to the commit 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB
> instead of TCR for residue"), the purpose of clearing CHCR.DE bit is
> flushing buffered data to calculate the exact residue.
>
> Such the "exact" residue had been required by sh-sci driver. sh-sci
> driver is calling dmaengine_pause() to stop transferring, and get
> "exact" residue. Otherwise, it might receive extra data during
> getting residue without pausing.
>
> In rx_timer_fn() of sh-sci driver:
> dmaengine_tx_status(); /* For checking roughly */
> dmaengine_pause();
> dmaengine_tx_status(); /* For getting residue */
> dmaengine_terminate_all();
>
> But, unfortunately the rcar-dmac driver didn't support dmaengine_pause()
> at that time. So, the sh-sci driver cannot get the "exact" residue
> without stopping the transferring, because rcar-dmac is buffering data
> inside.
>
> Because of these backgrounds, rcar-dmac had been cleared/set CHCR.DE
> bit in rcar_dmac_chan_get_residue() to synchronizing data and getting
> "exact" residue.
>
> However, rcar-dmac driver has rcar_dmac_chan_pause() now, and clearing
> CHCR.DE bit in rcar_dmac_chan_get_residue() doesn't need anymore.
> So, this patch removes the rcar_dmac_sync_tcr().
Applied, thanks
--
~Vinod
Re: [PATCH v2 0/2] dmaengine: sh: rcar-dmac: Add dma_pause operation
Hey Geert, On 20-07-18, 15:06, Geert Uytterhoeven wrote: > On Wed, Jul 11, 2018 at 7:18 AM Vinod wrote: > > On 11-07-18, 11:10, Yoshihiro Shimoda wrote: > > > This patch set is based on the lasest slave-dma / next branch. > > > > > > This issue can be reproduced by the following commands on r8a7795 > > > Salvator-XS with the fixed patch [1] and Windows Teraterm :) : > > > # stty 921600 > > > (Change Teraterm baud rate) > > > # cat > rx.txt > > > (Send 5MiB file by Teraterm.) > > > # cmp rx.txt > > > output "differ: byte N, line MMM" > > > > Applied, thanks > > I can't seem to find this patch in today's next, nor in your next or > topic/renesas branches. > > Am I looking at the wrong places? Yes you are looking at the right place. I seem to have applied but missed to merge to next and push. Done now -- ~Vinod
Re: [PATCH v2 0/2] dmaengine: sh: rcar-dmac: Add dma_pause operation
On 11-07-18, 11:10, Yoshihiro Shimoda wrote: > This patch set is based on the lasest slave-dma / next branch. > > This issue can be reproduced by the following commands on r8a7795 > Salvator-XS with the fixed patch [1] and Windows Teraterm :) : > # stty 921600 > (Change Teraterm baud rate) > # cat > rx.txt > (Send 5MiB file by Teraterm.) > # cmp rx.txt > output "differ: byte NNNNN, line MMM" Applied, thanks -- ~Vinod
Re: [PATCH 0/2] dma: sh: rcar-dmac: Add dma_pause operation
On 02-07-18, 18:21, Yoshihiro Shimoda wrote: > This patch set is based on the lasest slave-dma / next branch. > > This issue can be reproduced by the following commands on r8a7795 > Salvator-XS with the fixed patch [1] and Windows Teraterm :) : > # stty 921600 > (Change Teraterm baud rate) > # cat > rx.txt > (Send 5MiB file by Teraterm.) > # cmp rx.txt > output "differ: byte N, line MMM" This fails to apply for me. Please rebase. Also please fix the subsystem name -- ~Vinod
Re: [PATCH] dma: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0
On 02-07-18, 18:18, Yoshihiro Shimoda wrote:
> This patch fixes an issue that unexpected retransfering happens
> if TCR is set to 0 before rcar_dmac_sync_tcr() writes DE bit to
> the CHCR register. For example, sh-sci driver can reproduce this
> issue like below:
>
> In rx_timer_fn():/* CHCR DE bit may be set to 1 */
> dmaengine_tx_status()
>rcar_dmac_tx_status()
> rcar_dmac_chan_get_residue()
> rcar_dmac_sync_tcr() /* TCR is possible to be set to 0 */
>
> According to the description of commit 73a47bd0da66 ("dmaengine:
> rcar-dmac: use TCRB instead of TCR for residue"), "this buffered data
> will be transferred if CHCR::DE bit was cleared". So, this patch
> doesn't need to check TCRB register.
>
> Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
> residue")
> Signed-off-by: Yoshihiro Shimoda
> ---
> This patch is based on the latest slave-dma / fixes branch.
>
> This issue can be reproduced by the following commands on r8a7795
> Salvator-XS and Windows Teraterm :) :
> # stty 921600
> (Change Teraterm baud rate)
> # cat > rx.txt
> (Send 5MiB file by Teraterm. After a few minutes later, we cannot
> input any commands by the serial console.)
Applied after fixing subsystem name
--
~Vinod
Re: [PATCH 0/2] dma: sh: rcar-dmac: Add dma_pause operation
On 02-07-18, 18:21, Yoshihiro Shimoda wrote: > This patch set is based on the lasest slave-dma / next branch. > > This issue can be reproduced by the following commands on r8a7795 > Salvator-XS with the fixed patch [1] and Windows Teraterm :) : > # stty 921600 > (Change Teraterm baud rate) > # cat > rx.txt > (Send 5MiB file by Teraterm.) > # cmp rx.txt > output "differ: byte N, line MMM" Looks okay to me, Acks/tested-by..? > > [1] https://patchwork.kernel.org/patch/10500775/ > > Yoshihiro Shimoda (2): > dma: sh: rcar-dmac: add a new function to clear CHCR.DE with barrier > dma: sh: rcar-dmac: Add dma_pause operation > > drivers/dma/sh/rcar-dmac.c | 27 +++ > 1 file changed, 23 insertions(+), 4 deletions(-) > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe dmaengine" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- ~Vinod
Re: [PATCH] dma: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0
On 02-07-18, 18:18, Yoshihiro Shimoda wrote:
> This patch fixes an issue that unexpected retransfering happens
> if TCR is set to 0 before rcar_dmac_sync_tcr() writes DE bit to
> the CHCR register. For example, sh-sci driver can reproduce this
> issue like below:
>
> In rx_timer_fn():/* CHCR DE bit may be set to 1 */
> dmaengine_tx_status()
>rcar_dmac_tx_status()
> rcar_dmac_chan_get_residue()
> rcar_dmac_sync_tcr() /* TCR is possible to be set to 0 */
>
> According to the description of commit 73a47bd0da66 ("dmaengine:
> rcar-dmac: use TCRB instead of TCR for residue"), "this buffered data
> will be transferred if CHCR::DE bit was cleared". So, this patch
> doesn't need to check TCRB register.
>
> Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for
> residue")
> Signed-off-by: Yoshihiro Shimoda
> ---
> This patch is based on the latest slave-dma / fixes branch.
>
> This issue can be reproduced by the following commands on r8a7795
> Salvator-XS and Windows Teraterm :) :
> # stty 921600
> (Change Teraterm baud rate)
> # cat > rx.txt
> (Send 5MiB file by Teraterm. After a few minutes later, we cannot
> input any commands by the serial console.)
Ack/tested-by ..?
>
> drivers/dma/sh/rcar-dmac.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 2a2ccd9..8305a1c 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -774,8 +774,9 @@ static void rcar_dmac_sync_tcr(struct rcar_dmac_chan
> *chan)
> /* make sure all remaining data was flushed */
> rcar_dmac_chcr_de_barrier(chan);
>
> - /* back DE */
> - rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
> + /* back DE if remain data exists */
> + if (rcar_dmac_chan_read(chan, RCAR_DMATCR))
> + rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
> }
>
> static void rcar_dmac_chan_halt(struct rcar_dmac_chan *chan)
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~Vinod
Re: [PATCH v3] dmaengine: rcar-dmac: clear channel register when error
On 03-07-18, 00:29, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > We need to clear channel register in error case as recovery. > The channel is already stopped in such case, thus we don't need to call > rcar_dmac_chan_halt() before clearing. > > rcar_dmac_chan_halt() will clear and confirm DE bit. > But it will be failed because channel is already stopped in error case. > In other words, we shouldn't call it then. Applied, thanks -- ~Vinod
Re: [PATCH v2] dmaengine: rcar-dmac: convert to SPDX identifiers
On 04-07-18, 00:34, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch is using C++ comment style for SPDX line only, > because driver author want it. Applied, thanks -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: convert to SPDX identifiers
Hi Laurent, On 03-07-18, 09:25, Laurent Pinchart wrote: > On Tuesday, 3 July 2018 09:20:08 EEST Vinod wrote: > > On 03-07-18, 08:49, Laurent Pinchart wrote: > > > Hi Morimoto-san, > > > > > > Thank you for the patch. > > > > > > On Tuesday, 3 July 2018 03:29:59 EEST Kuninori Morimoto wrote: > > > > From: Kuninori Morimoto > > > > > > A commit message would be nice :-) > > > > > > > Signed-off-by: Kuninori Morimoto > > > > --- > > > > > > > > drivers/dma/sh/rcar-dmac.c | 18 +++--- > > > > 1 file changed, 7 insertions(+), 11 deletions(-) > > > > > > > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > > > > index 79d14af..322e57b 100644 > > > > --- a/drivers/dma/sh/rcar-dmac.c > > > > +++ b/drivers/dma/sh/rcar-dmac.c > > > > @@ -1,14 +1,10 @@ > > > > -/* > > > > - * Renesas R-Car Gen2 DMA Controller Driver > > > > - * > > > > - * Copyright (C) 2014 Renesas Electronics Inc. > > > > - * > > > > - * Author: Laurent Pinchart > > > > - * > > > > - * This is free software; you can redistribute it and/or modify > > > > - * it under the terms of version 2 of the GNU General Public License as > > > > - * published by the Free Software Foundation. > > > > - */ > > > > +// SPDX-License-Identifier: GPL-2.0 > > > > +// > > > > +// Renesas R-Car Gen2 DMA Controller Driver > > > > +// > > > > +// Copyright (C) 2014 Renesas Electronics Inc. > > > > +// > > > > +// Author: Laurent Pinchart > > > > > > I think the preferred comment style, accordingly to what other drivers do, > > > is > > > > > > // SPDX-License-Identifier: GPL-2.0 > > > /* > > > > > > * Renesas R-Car Gen2 DMA Controller Driver > > > * > > > * Copyright (C) 2014 Renesas Electronics Inc. > > > * > > > * Author: Laurent Pinchart > > > */ > > > > And Linus said this https://lkml.org/lkml/2017/11/25/133 > > > > So lets keep C99 style as Morimoto-San proposed. > > > > And high time, this should be documented :) > > As mentioned before, while I certainly prefer the traditional C-style > comments, I ultimately let driver authors decide. What matters most in my > opinion is consistency, mixing styles in the same driver just makes the code > harder to read. > > What matters in the end is how easy reading the code will be, and until the > majority of kernel developers get used to the C++ comment style, no matter > what Linus' personal preference is, // will be an annoyance. Agreed, honestly this (style changes) has been unnecessary noise with no value add. Sticking to one style would help and better to focus on real issues would be my take :) Thanks -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: convert to SPDX identifiers
On 03-07-18, 08:49, Laurent Pinchart wrote: > Hi Morimoto-san, > > Thank you for the patch. > > On Tuesday, 3 July 2018 03:29:59 EEST Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > A commit message would be nice :-) > > > Signed-off-by: Kuninori Morimoto > > --- > > drivers/dma/sh/rcar-dmac.c | 18 +++--- > > 1 file changed, 7 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > > index 79d14af..322e57b 100644 > > --- a/drivers/dma/sh/rcar-dmac.c > > +++ b/drivers/dma/sh/rcar-dmac.c > > @@ -1,14 +1,10 @@ > > -/* > > - * Renesas R-Car Gen2 DMA Controller Driver > > - * > > - * Copyright (C) 2014 Renesas Electronics Inc. > > - * > > - * Author: Laurent Pinchart > > - * > > - * This is free software; you can redistribute it and/or modify > > - * it under the terms of version 2 of the GNU General Public License as > > - * published by the Free Software Foundation. > > - */ > > +// SPDX-License-Identifier: GPL-2.0 > > +// > > +// Renesas R-Car Gen2 DMA Controller Driver > > +// > > +// Copyright (C) 2014 Renesas Electronics Inc. > > +// > > +// Author: Laurent Pinchart > > I think the preferred comment style, accordingly to what other drivers do, is > > // SPDX-License-Identifier: GPL-2.0 > /* > * Renesas R-Car Gen2 DMA Controller Driver > * > * Copyright (C) 2014 Renesas Electronics Inc. > * > * Author: Laurent Pinchart > */ And Linus said this https://lkml.org/lkml/2017/11/25/133 So lets keep C99 style as Morimoto-San proposed. And high time, this should be documented :) -- ~Vinod
Re: [PATCH resend] dmaengine: rcar-dmac: Document R8A77990 bindings
On 20-06-18, 14:01, Ulrich Hecht wrote: > From: Hiroyuki Yokoyama > > Renesas R-Car E3 (R8A77990) SoC also has the R-Car gen2/3 compatible DMA > controllers, so document the SoC specific binding. > > Signed-off-by: Hiroyuki Yokoyama > Signed-off-by: Ulrich Hecht > Reviewed-by: Simon Horman > Acked-by: Rob Herring > Reviewed-by: Geert Uytterhoeven > --- > This didn't apply for Vinod before, but now it seems to. If it still does > not, please tell me what tree to base this on. It applied for me this time so applied thanks. Typically it should apply cleanly on dmaengine-next -- ~Vinod
Re: [PATCH 2/2] dmaengine: rcar-dmac: Document R8A77990 bindings
On 16-05-18, 15:06, Ulrich Hecht wrote: > From: Hiroyuki Yokoyama <hiroyuki.yokoyama...@renesas.com> > > Renesas R-Car E3 (R8A77990) SoC also has the R-Car gen2/3 compatible DMA > controllers, so document the SoC specific binding. This fails to apply for me, please rebase and send -- ~Vinod
Re: [PATCH 1/2] dmaengine: usb-dmac: Document R8A7799{0,5} bindings
On 16-05-18, 15:06, Ulrich Hecht wrote: > From: Hiroyuki Yokoyama <hiroyuki.yokoyama...@renesas.com> > > Renesas R-Car D3 (R8A77995) and E3 (R8A77990) SoCs also have the R-Car > gen2/3 compatible DMA controllers, so document the SoC specific binding. Applied, thanks -- ~Vinod
Re: [PATCH v4] dmaengine: rcar-dmac: Document R-Car D3 bindings
On Tue, Apr 24, 2018 at 10:51:06AM +0200, Simon Horman wrote: > From: Ulrich Hecht <ulrich.hecht+rene...@gmail.com> > > R8A77995's SYS-DMAC is R-Car Gen3-compatible. Applied, thanks -- ~Vinod
Re: [PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS
On Fri, Apr 20, 2018 at 03:28:28PM +0200, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check, just like before support for Renesas ARM SoCs was added.
>
> Instead of blindly changing all the #ifdefs, switch the main code block
> in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
> remaining #ifdefs.
>
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Applied, thanks
--
~Vinod
Re: [PATCH 09/61] dmaengine: qcom: simplify getting .drvdata
On Thu, Apr 19, 2018 at 04:05:39PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. Applied, thanks -- ~Vinod
Re: [PATCH 08/61] dmaengine: dw: simplify getting .drvdata
On Thu, Apr 19, 2018 at 04:05:38PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. Applied, thanks -- ~Vinod
Re: [PATCH 07/61] dma: simplify getting .drvdata
On Thu, Apr 19, 2018 at 04:05:37PM +0200, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. Do you mind splitting this per driver please, that makes it easy to manage for me :) -- ~Vinod
Re: [PATCH] dt-bindings: rcar-dmac: Document r8a77470 support
On Thu, Mar 29, 2018 at 11:11:06AM +0100, Biju Das wrote: > Renesas RZ/G SoC also have the R-Car gen2/3 compatible DMA controllers. > Document RZ/G1C (also known as R8A77470) SoC bindings. Applied, thanks -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: Fix too early/late system suspend/resume callbacks
On Thu, Mar 29, 2018 at 06:53:32PM +0200, Geert Uytterhoeven wrote:
> If serial console wake-up is enabled ("echo enabled >
> /sys/.../ttySC0/power/wakeup"), and any serial input is received while
> the system is suspended, serial port input no longer works after system
> resume.
>
> Note that:
> 1) The system can still be woken up using the serial console,
> 2) Serial port input keeps working if the system is woken up in some
> other way (e.g. Wake-on-LAN or gpio-keys), and no serial input was
> received while suspended.
>
> To fix this, replace SET_LATE_SYSTEM_SLEEP_PM_OPS() by
> SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(), as the callbacks installed by the
> former happen too early resp. late in the suspend resp. resume process.
Applied, thanks
--
~Vinod
Re: [PATCH] dmaengine: rcar-dmac: Check the done lists in rcar_dmac_chan_get_residue()
On Fri, Feb 02, 2018 at 07:05:15PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that a race condition happens between a client
> driver and the rcar-dmac driver:
>
> - The rcar_dmac_isr_transfer_end() is called.
> - The done list appears, and desc.running is the next active list.
> - rcar_dmac_chan_get_residue() is called by a client driver before
> rcar_dmac_isr_channel_thread() is called.
> - The rcar_dmac_chan_get_residue() will not find any descriptors.
> - And, the following WARNING happens:
> WARN(1, "No descriptor for cookie!");
>
> The sh-sci driver with HSCIF (921,600bps) on R-Car H3 can cause this
> situation.
> So, this patch checks the done lists in rcar_dmac_chan_get_residue()
> and returns zero if the done lists has the argument cookie.
Applied, thanks
>
> Tested-by: Nguyen Viet Dung <dung.nguyen...@renesas.com>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> ---
> drivers/dma/sh/rcar-dmac.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 2b2c7db..f748be6 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1264,8 +1264,17 @@ static unsigned int rcar_dmac_chan_get_residue(struct
> rcar_dmac_chan *chan,
>* If the cookie doesn't correspond to the currently running transfer
>* then the descriptor hasn't been processed yet, and the residue is
>* equal to the full descriptor size.
> + * Also, a client driver is possible to call this function before
> + * rcar_dmac_isr_channel_thread() runs. In this case, the "desc.running"
> + * will be the next descriptor, and the done list will appear. So, if
> + * the argument cookie matches the done list's cookie, we can assume
> + * the residue is zero.
>*/
> if (cookie != desc->async_tx.cookie) {
> + list_for_each_entry(desc, >desc.done, node) {
> + if (cookie == desc->async_tx.cookie)
> + return 0;
> + }
> list_for_each_entry(desc, >desc.pending, node) {
> if (cookie == desc->async_tx.cookie)
> return desc->size;
> --
> 1.9.1
>
--
~Vinod
Re: [PATCH] dmaengine: usb-dmac: add binding for r8a77965
On Tue, Feb 27, 2018 at 02:54:56PM +0900, Yoshihiro Shimoda wrote: > This patch adds binding for r8a77965 (R-Car M3-N). Applied, thanks > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> > --- > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > index f3d1f15..9dc935e 100644 > --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt > @@ -11,6 +11,7 @@ Required Properties: > - "renesas,r8a7794-usb-dmac" (R-Car E2) > - "renesas,r8a7795-usb-dmac" (R-Car H3) > - "renesas,r8a7796-usb-dmac" (R-Car M3-W) > + - "renesas,r8a77965-usb-dmac" (R-Car M3-N) > - reg: base address and length of the registers block for the DMAC > - interrupts: interrupt specifiers for the DMAC, one for each entry in >interrupt-names. > -- > 1.9.1 > -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: fix max_chunk_size for R-Car Gen3
On Wed, Feb 14, 2018 at 06:40:12PM +0900, Yoshihiro Shimoda wrote: > According to R-Car Gen3 Rev.0.80 manual, the DMATCR can be set to > 16,777,215 as maximum. So, this patch fixes the max_chunk_size for > safety on all of SoCs. Otherwise, a system may hang if the DMATCR > is set to 0 on R-Car Gen3. Applied, thanks -- ~Vinod
Re: [PATCH] DT: dma: renesas,rcar-dmac: document R8A77980 support
On Thu, Feb 01, 2018 at 10:09:25PM +0300, Sergei Shtylyov wrote: > Renesas R-Car V3H SoC has the R-Car gen3 compatible DMA controllers. > Document R-Car V3H (also known as R8A77980) SoC bindings. Applied, thanks -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: Make DMAC reinit during system resume explicit
On Wed, Jan 17, 2018 at 10:38:28AM +0100, Geert Uytterhoeven wrote:
> The current (empty) system sleep callbacks rely on the PM core to force
> a runtime resume to reinitialize the DMAC registers during system
> resume. Without a reinitialization, e.g. SCIF DMA will hang silently
> after a system resume on R-Car Gen3.
>
> Make this explicit by using pm_runtime_force_{suspend,resume}() as the
> system sleep callbacks instead. Use SET_LATE_SYSTEM_SLEEP_PM_OPS() as
> DMA engines must be initialized before all DMA slave devices.
>
> Suggested-by: Ulf Hansson <ulf.hans...@linaro.org>
> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
> This is a dependency for "[PATCH 1/2] PM / genpd: Stop/start devices
> without pm_runtime_force_suspend/resume()"
> (https://www.spinics.net/lists/kernel/msg2696802.html), so perhaps it
> makes most sense if Rafael takes it through the PM tree?
Sounds okay to me.
Acked-By: Vinod Koul <vinod.k...@intel.com>
--
~Vinod
Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue
On Wed, Nov 08, 2017 at 06:33:33AM +, Kuninori Morimoto wrote:
>
> Hi Vinod
>
> > > > > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB
> > > > > instead of TCR for residue") in slave-dma/next, and breaks serial
> > > > > console
> > > > > input on koelsch (shmobile_defconfig) and salvator-x
> > > > > (renesas_defconfig).
> > > > > Reverting that commit fixes the issue for me.
> > >
> > > Okay since we are close to merge window I can drop this patch for now,
> > > unless we identify the fix very quickly
> >
> > I have not seen a resolution to this, so reverted it.
>
> We are sorry, but we still don't have solution about this.
thats okay, reverted seemed best in this situation. Once we have a solution
we can apply and mark to stable.
--
~Vinod
Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue
On Tue, Oct 31, 2017 at 05:11:13PM +0530, Vinod Koul wrote:
> On Tue, Oct 31, 2017 at 11:46:36AM +0100, Geert Uytterhoeven wrote:
> > >
> > > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB
> > > instead of TCR for residue") in slave-dma/next, and breaks serial console
> > > input on koelsch (shmobile_defconfig) and salvator-x (renesas_defconfig).
> > > Reverting that commit fixes the issue for me.
>
> Okay since we are close to merge window I can drop this patch for now,
> unless we identify the fix very quickly
I have not seen a resolution to this, so reverted it.
--
~Vinod
Re: [PATCH v3] dmaengine: rcar-dmac: use TCRB instead of TCR for residue
On Tue, Oct 31, 2017 at 11:46:36AM +0100, Geert Uytterhoeven wrote:
> CC linux-renesas-soc
>
> On Tue, Oct 31, 2017 at 11:45 AM, Geert Uytterhoeven
> <ge...@linux-m68k.org> wrote:
> > Hi Vinod, Morimoto-san, Yokoyama-san,
> >
> > On Fri, Oct 20, 2017 at 8:15 AM, Vinod Koul <vinod.k...@intel.com> wrote:
> >> On Thu, Oct 19, 2017 at 01:15:13AM +, Kuninori Morimoto wrote:
> >>> From: Hiroyuki Yokoyama <hiroyuki.yokoyama...@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.
> >>
> >> Applied, thanks.
> >
> > This is now commit 847449f23dcbff68 ("dmaengine: rcar-dmac: use TCRB
> > instead of TCR for residue") in slave-dma/next, and breaks serial console
> > input on koelsch (shmobile_defconfig) and salvator-x (renesas_defconfig).
> > Reverting that commit fixes the issue for me.
Okay since we are close to merge window I can drop this patch for now,
unless we identify the fix very quickly
--
~Vinod
Re: [PATCH] dmaengine: nbpfaxi: Use of_device_get_match_data() helper
On Wed, Oct 04, 2017 at 02:15:23PM +0200, Geert Uytterhoeven wrote: > Use the of_device_get_match_data() helper instead of open coding. > Note that when used with DT, there's always a valid match. Applied, thanks -- ~Vinod
Re: [PATCH v2] dmaengine: usb-dmac: Add compatible string for r8a7743/5
On Fri, Oct 06, 2017 at 06:15:17PM +0100, Biju Das wrote: > This patch adds support for r8a7743/5 SoCs. The Renesas RZ/G1[ME] > (R8A7743/5) usbdmac engine is identical to the R-Car Gen2 family. > > No driver change is needed due to the fallback compatible value > "renesas,r8a7743-usb-dmac". > Adding the SoC-specific compatible values here has two purposes: > 1. Document which SoCs have this hardware module, > 2. Allow checkpatch to validate compatible values. Applied, thanks -- ~Vinod
Re: [PATCH v2] dmaengine: rcar-dmac: document R8A77970 bindings
On Thu, Aug 31, 2017 at 11:59:24PM +0300, Sergei Shtylyov wrote: > Renesas R-Car V3M (R8A77970) SoC also has the R-Car gen2/3 compatible DMA > controllers, so document the SoC specific binding. Applied, thanks -- ~Vinod
Re: [PATCH v2] rcar-dmac: initialize all data before registering IRQ handler
On Mon, Aug 21, 2017 at 06:31:57AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto <kuninori.morimoto...@renesas.com> > > Anton Volkov noticed that engine->dev is NULL before > of_dma_controller_register() in probe. > Thus there might be a NULL pointer dereference in > rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which > is equal to (>engine)->dev. > On same reason, same and similar things will happen if we didn't > initialize all necessary data before calling register irq function. > To be more safety code, this patch initialize all necessary data > before calling register irq function. Applied after adding subsytem name, thanks -- ~Vinod
Re: [PATCH] dmaengine: usb-dmac: Add soctype for R-Car M3-W
On Fri, Aug 25, 2017 at 05:47:22AM +, Yoshihiro Shimoda wrote: > Hi Rob, > > > From: Rob Herring > > Sent: Friday, August 11, 2017 1:26 AM > > > > On Wed, Aug 02, 2017 at 08:33:34PM +0900, Yoshihiro Shimoda wrote: > > > This patch adds R-Car M3-W device tree bindings for usb-dmac driver. > > > > > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com> > > > --- > > > Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > Acked-by: Rob Herring <r...@kernel.org> > > Thank you for your Acked-by! > > Hi, Vinod, > > I checked your next branch today, but it doesn't have this patch. > So, would you apply this patch into your repo? Can you check again, i can see it and also on Web UI http://git.infradead.org/users/vkoul/slave-dma.git/commit/2d166e66aca3e832cb0851da7d0183090dd699d4 -- ~Vinod
Re: [PATCH 1/7] dmaengine: use proper name for the R-Car SoC
On Sun, May 28, 2017 at 11:30:44AM +0200, Wolfram Sang wrote: > It is 'R-Car', not 'r-car'. No code or binding changes, only descriptive text. Applied, thanks -- ~Vinod
Re: [PATCH] dt-bindings: rcar-dmac: Document missing error interrupt
On Fri, May 19, 2017 at 09:27:47AM +0200, Geert Uytterhoeven wrote: > The documentation for the "interrupt-names" property only mentions the > per-channel interrupts, while the error interrupt has always been > mandatory, too. Applied, thanks -- ~Vinod
Re: [PATCH v2 0/3] dmaengine: rcar-dmac: fix resource freeing synchronization
On Tue, May 16, 2017 at 01:09:14AM +0200, Niklas Söderlund wrote: > Hi, > > This series fix resource freeing synchronization by: > > 1. Patch 1/3 >Store the IRQ number in the global struct so it can be used later >together with synchronize_irq(). > > 2. Patch 2/3 >Adding support for the device_synchronize() callback in patch 2/3. > > 3. Patch 3/3 >Waiting for any ISR that might still be running after the channel is >halted prior to freeing its resources. This was patch previously part >of a patch sent out by Yoshihiro Shimoda and authored by Hiroyuki >Yokoyama, see [1]. > >In that thread it was suggested by Lars-Peter Clausen to instead >implement the device_synchronize() callback. Unfortunately this is not >enough to solve the issue. In rcar_dmac_free_chan_resources() the >channel is halted by a call to rcar_dmac_chan_halt() and then directly >moves on to freeing resources, here it is still needed to add a wait >for any ISR to finish before freeing the resources, despite that a >device_synchronize() have been added. This is because call chain: > >dma_release_channel() > dma_chan_put() >dmaengine_synchronize() >rcar_dmac_free_chan_resources() > rcar_dmac_chan_halt() > >Here dmaengine_synchronize() is called prior to rcar_dmac_chan_halt() >so an extra synchronisation to wait for any running ISR is still >needed. > > By both adding a device_synchronize() which can be used in conjunction > with device_terminate_all() and fiends and by adding an explicit > synchronize_irq() when freeing channel resources I feel the > synchronisation for freeing channel resources are in a much better > shape. It also solves the issue in the original mail thread. Applied now, thanks -- ~Vinod
Re: [PATCH v2 1/3] dmaengine: rcar-dmac: store channel IRQ in struct rcar_dmac_chan
On Fri, May 19, 2017 at 08:59:03AM +0200, Geert Uytterhoeven wrote:
> Hi Vinod,
>
> On Fri, May 19, 2017 at 5:51 AM, Vinod Koul <vinod.k...@intel.com> wrote:
> > On Tue, May 16, 2017 at 01:09:15AM +0200, Niklas Söderlund wrote:
> >> The IRQ number is needed after probe to be able to add synchronisation
> >> points in other places in the driver when freeing resources and to
> >> implement a device_synchronize() callback. Store the IRQ number in the
> >> struct rcar_dmac_chan so that it can be used later.
> >>
> >> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> >> ---
> >> drivers/dma/sh/rcar-dmac.c | 13 -
> >> 1 file changed, 8 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> >> index db41795fe42ae6ed..c68c3336bdad44df 100644
> >> --- a/drivers/dma/sh/rcar-dmac.c
> >> +++ b/drivers/dma/sh/rcar-dmac.c
> >> @@ -144,6 +144,7 @@ struct rcar_dmac_chan_map {
> >> * @chan: base DMA channel object
> >> * @iomem: channel I/O memory base
> >> * @index: index of this channel in the controller
> >> + * @irq: channel IRQ
> >> * @src: slave memory address and size on the source side
> >> * @dst: slave memory address and size on the destination side
> >> * @mid_rid: hardware MID/RID for the DMA client using this channel
> >> @@ -161,6 +162,7 @@ struct rcar_dmac_chan {
> >> struct dma_chan chan;
> >> void __iomem *iomem;
> >> unsigned int index;
> >> + int irq;
> >
> > Thats a bit odd choice to store per ch, I would have stored in rcar_dmac.
> > Any specific reason, do we have per ch irq here?
>
> Yes, each channel has its own interrupt.
Then this one is just fine :)
--
~Vinod
Re: [PATCH v2 1/3] dmaengine: rcar-dmac: store channel IRQ in struct rcar_dmac_chan
On Tue, May 16, 2017 at 01:09:15AM +0200, Niklas Söderlund wrote:
> The IRQ number is needed after probe to be able to add synchronisation
> points in other places in the driver when freeing resources and to
> implement a device_synchronize() callback. Store the IRQ number in the
> struct rcar_dmac_chan so that it can be used later.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> ---
> drivers/dma/sh/rcar-dmac.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index db41795fe42ae6ed..c68c3336bdad44df 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -144,6 +144,7 @@ struct rcar_dmac_chan_map {
> * @chan: base DMA channel object
> * @iomem: channel I/O memory base
> * @index: index of this channel in the controller
> + * @irq: channel IRQ
> * @src: slave memory address and size on the source side
> * @dst: slave memory address and size on the destination side
> * @mid_rid: hardware MID/RID for the DMA client using this channel
> @@ -161,6 +162,7 @@ struct rcar_dmac_chan {
> struct dma_chan chan;
> void __iomem *iomem;
> unsigned int index;
> + int irq;
Thats a bit odd choice to store per ch, I would have stored in rcar_dmac.
Any specific reason, do we have per ch irq here?
>
> struct rcar_dmac_chan_slave src;
> struct rcar_dmac_chan_slave dst;
> @@ -1647,7 +1649,6 @@ static int rcar_dmac_chan_probe(struct rcar_dmac *dmac,
> struct dma_chan *chan = >chan;
> char pdev_irqname[5];
> char *irqname;
> - int irq;
> int ret;
>
> rchan->index = index;
> @@ -1664,8 +1665,8 @@ static int rcar_dmac_chan_probe(struct rcar_dmac *dmac,
>
> /* Request the channel interrupt. */
> sprintf(pdev_irqname, "ch%u", index);
> - irq = platform_get_irq_byname(pdev, pdev_irqname);
> - if (irq < 0) {
> + rchan->irq = platform_get_irq_byname(pdev, pdev_irqname);
> + if (rchan->irq < 0) {
> dev_err(dmac->dev, "no IRQ specified for channel %u\n", index);
> return -ENODEV;
> }
> @@ -1675,11 +1676,13 @@ static int rcar_dmac_chan_probe(struct rcar_dmac
> *dmac,
> if (!irqname)
> return -ENOMEM;
>
> - ret = devm_request_threaded_irq(dmac->dev, irq, rcar_dmac_isr_channel,
> + ret = devm_request_threaded_irq(dmac->dev, rchan->irq,
> + rcar_dmac_isr_channel,
> rcar_dmac_isr_channel_thread, 0,
> irqname, rchan);
> if (ret) {
> - dev_err(dmac->dev, "failed to request IRQ %u (%d)\n", irq, ret);
> + dev_err(dmac->dev, "failed to request IRQ %u (%d)\n",
> + rchan->irq, ret);
orthogonal, while at it care to fix explicit free of irq in remove, it seems
this driver doesn't do so..
--
~Vinod
Re: [PATCH] dmaengine: usb-dmac: Fix DMAOR AE bit definition
On Mon, May 15, 2017 at 05:49:52PM +0900, Yoshihiro Shimoda wrote: > From: Hiroyuki Yokoyama <hiroyuki.yokoyama...@renesas.com> > > This patch fixes the register definition of AE (Address Error flag) bit. Applied, thanks -- ~Vinod
Re: [PATCH 3/3] dmaengine: rcar-dmac: wait for ISR to finish before freeing resources
On Fri, May 12, 2017 at 02:49:38PM +0200, Niklas Söderlund wrote: > On 2017-04-07 14:33:47 +0300, Laurent Pinchart wrote: > > Hi Geert, > > > > On Wednesday 05 Apr 2017 12:40:11 Geert Uytterhoeven wrote: > > > On Wed, Apr 5, 2017 at 11:14 AM, Niklas Söderlund wrote: > > > > On 2017-04-05 08:55:31 +0530, Vinod Koul wrote: > > > >> On Thu, Mar 30, 2017 at 09:38:39AM +0200, Niklas Söderlund wrote: > > > >>> On 2017-03-29 15:30:42 +0200, Niklas Söderlund wrote: > > > >>>> On 2017-03-29 14:31:33 +0200, Geert Uytterhoeven wrote: > > > >>>>> On Wed, Mar 29, 2017 at 12:40 AM, Niklas Söderlund wrote: > > > >>>>>> This fixes a race condition where the channel resources could be > > > >>>>>> freed before the ISR had finished running resulting in a NULL > > > >>>>>> pointer reference from the ISR. > > > >>>>>> > > > >>>>>> [ 167.148934] Unable to handle kernel NULL pointer dereference > > > >>>>>> at virtual address > > > >>>>>> [ 167.157051] pgd = 80003c641000 > > > >>>>>> [ 167.160449] [] *pgd=7c507003, > > > >>>>>> *pud=7c4ff003, *pmd= > > > >>>>>> [ 167.168719] Internal error: Oops: 9646 [#1] PREEMPT SMP > > > >>>>>> [ 167.174289] Modules linked in: > > > >>>>>> [ 167.177348] CPU: 3 PID: 10547 Comm: dma_ioctl Not tainted > > > >>>>>> 4.11.0-rc1-1-g8d92afddc2f6633a #73 > > > >>>>>> [ 167.186131] Hardware name: Renesas Salvator-X board based on > > > >>>>>> r8a7795 (DT) > > > >>>>>> [ 167.192917] task: 80003a411a00 task.stack: 80003bcd4000 > > > >>>>>> [ 167.198850] PC is at rcar_dmac_chan_prep_sg+0xe0/0x400 > > > >>>>>> [ 167.203985] LR is at rcar_dmac_chan_prep_sg+0x48/0x400 > > > >>>>> > > > >>>>> Do you have a test case to trigger this? > > > >>>> > > > >>>> Yes I have a testcase, it's rather complex and involves both a kernel > > > >>>> module and a userspaces application to stress the rcar-dmac. I'm > > > >>>> checking if I can share this publicly or not, please hold :-) > > > >>> > > > >>> I have now received feedback that I'm unfortunately not allowed to > > > >>> share the test case :-( > > > >>> > > > >>> The big picture in how to trigger this problem is that you start a DMA > > > >>> transfer like this: > > > >>> > > > >>> struct dma_async_tx_descriptor *tx = ...; > > > >>> > > > >>> ... > > > >>> > > > >>> tx->tx_submit(tx); > > > >>> > > > >>> And then you directly call dma_release_channel() on this channel > > > >>> without making sure the completion callback ran or anything. Now if > > > >>> you > > > >>> are unlucky the ISR have not finished running for the DMA when > > > >>> dma_release_channel() starts to clean up resources. The > > > >>> synchronisation > > > >>> point in the dma_release_channel() call path fixes this. > > > >> > > > >> Well the API expectation would be you abort the txn before calling > > > >> release. So the expected order should be: > > > >> > > > >> dmaengine_terminate_all(); > > > >> dma_release_channel(); > > > > > > > > Agree this is the correct way and in this case patch 3/3 in this series > > > > could be dropped. Then device_synchronize() would added to rcar-dmac, > > > > dmaengine_terminate_all() would turn of the IRQ and > > > > dma_release_channel() would ensure that device_synchronize() is called > > > > prior to calling rcar-dmac device_free_chan_resources(). > > > > > > > >> Terminate should then stop the channel, ie abort the pending > > > >> descriptors.. > > > > > > > > However for reasons unknown to me the rcar-dmac > > > > device_free_chan_resources() implementation implements logic to turn of > > > > IRQs before it frees the resources.
Re: [PATCH 3/3] dmaengine: rcar-dmac: wait for ISR to finish before freeing resources
On Thu, Mar 30, 2017 at 09:38:39AM +0200, Niklas Söderlund wrote: > Hi Geert, > > On 2017-03-29 15:30:42 +0200, Niklas Söderlund wrote: > > Hi Geert, > > > > On 2017-03-29 14:31:33 +0200, Geert Uytterhoeven wrote: > > > Hi Niklas, > > > > > > On Wed, Mar 29, 2017 at 12:40 AM, Niklas Söderlund > > > <niklas.soderlund+rene...@ragnatech.se> wrote: > > > > This fixes a race condition where the channel resources could be freed > > > > before the ISR had finished running resulting in a NULL pointer > > > > reference from the ISR. > > > > > > > > [ 167.148934] Unable to handle kernel NULL pointer dereference at > > > > virtual address > > > > [ 167.157051] pgd = 80003c641000 > > > > [ 167.160449] [] *pgd=7c507003, *pud=7c4ff003, > > > > *pmd= > > > > [ 167.168719] Internal error: Oops: 9646 [#1] PREEMPT SMP > > > > [ 167.174289] Modules linked in: > > > > [ 167.177348] CPU: 3 PID: 10547 Comm: dma_ioctl Not tainted > > > > 4.11.0-rc1-1-g8d92afddc2f6633a #73 > > > > [ 167.186131] Hardware name: Renesas Salvator-X board based on r8a7795 > > > > (DT) > > > > [ 167.192917] task: 80003a411a00 task.stack: 80003bcd4000 > > > > [ 167.198850] PC is at rcar_dmac_chan_prep_sg+0xe0/0x400 > > > > [ 167.203985] LR is at rcar_dmac_chan_prep_sg+0x48/0x400 > > > > > > Do you have a test case to trigger this? > > > > Yes I have a testcase, it's rather complex and involves both a kernel > > module and a userspaces application to stress the rcar-dmac. I'm > > checking if I can share this publicly or not, please hold :-) > > I have now received feedback that I'm unfortunately not allowed to share > the test case :-( > > The big picture in how to trigger this problem is that you start a DMA > transfer like this: > > struct dma_async_tx_descriptor *tx = ...; > > ... > > tx->tx_submit(tx); > > And then you directly call dma_release_channel() on this channel without > making sure the completion callback ran or anything. Now if you are > unlucky the ISR have not finished running for the DMA when > dma_release_channel() starts to clean up resources. The synchronisation > point in the dma_release_channel() call path fixes this. Well the API expectation would be you abort the txn before calling release. So the expected order should be: dmaengine_terminate_all(); dma_release_channel(); Terminate should then stop the channel, ie abort the pending descriptors.. -- ~Vinod
Re: [PATCH v3] dmaengine: rcar-dmac: enable descriptor mode on 40bit
On Wed, Mar 22, 2017 at 04:22:36AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto <kuninori.morimoto...@renesas.com> > > SYS-DMAC can use 40bit address transfer, and it supports Descriptor > Mode too. Current SYS-DMAC driver disables Descriptor Mode if it was > 40bit address today. But it can use Descriptor Mode with 40bit if > transfer Source/Destination address are located in same 4GiB region > in the 40 bit address space. > This patch enables it if all condition was clear Applied, thanks -- ~Vinod
Re: [PATCH v2] dmaengine: rcar-dmac: Widen DMA mask to 40 bits
On Mon, Feb 13, 2017 at 12:00:26PM +0100, Geert Uytterhoeven wrote: > By default, the DMA mask covers only the low 32-bit address space, which > causes SWIOTLB on arm64 to fall back to a bounce buffer for DMA > transfers involving memory outside the 32-bit address space. > > The R-Car DMA controller hardware supports a 40-bit address space, hence > widen the DMA mask to 40 bits to actually make use of this feature. Applied, thanks -- ~Vinod
Re: [PATCH] dmaengine: rcar-dmac: unmap slave resource when channel is freed
On Wed, Jan 11, 2017 at 03:39:31PM +0100, Niklas Söderlund wrote: > The slave mapping should be removed together with other channel > resources when the channel is freed. If it's not unmapped it will hang > around forever after the channel is freed. Applied, thanks -- ~Vinod
Re: [PATCH dmaengine/next] dmaengine: rcar-dmac: Document R-Car M3-W bindings
On Thu, Nov 24, 2016 at 03:23:06PM +0100, Simon Horman wrote: > From: Ulrich Hecht <ulrich.hecht+rene...@gmail.com> Applied, thanks -- ~Vinod
Re: [PATCH] DT: dma: rcar-dmac: document R8A7743/5 support
On Thu, Sep 29, 2016 at 01:25:48AM +0300, Sergei Shtylyov wrote: > Renesas RZ/G SoC also have the R-Car gen2/3 compatible DMA controllers. > Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings. Applied, thanks -- ~Vinod
Re: [PATCH] dma-debug: fix ia64 build, use PHYS_PFN
On Thu, Sep 29, 2016 at 09:59:15PM +0200, Niklas Söderlund wrote: > kbuild test robot reports: > >lib/dma-debug.c: In function 'debug_dma_map_resource': > >> lib/dma-debug.c:1541:16: error: implicit declaration of function > >> '__phys_to_pfn' [-Werror=implicit-function-declaration] > entry->pfn = __phys_to_pfn(addr); >^ > > ia64 does not provide __phys_to_pfn(), use the PHYS_PFN() alias. Applied, thanks -- ~Vinod
Re: [PATCH 0/2] dma-mapping: fix ia64 and m32r build error and warnings
On Thu, Sep 29, 2016 at 12:02:38PM +0200, Niklas Söderlund wrote: > From: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> > > Hi Vindo, :( > > This small series fixes the build error and warnings for ia64 and m32r > which kbuild test robot found and where introduced in the series > '[PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave > transfers'. Applied both Thanks -- ~Vinod
Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote: > Hi, > > This series tries to solve the problem with DMA with device registers > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A > recent patch '9575632 (dmaengine: make slave address physical)' > clarifies that DMA slave address provided by clients is the physical > address. This puts the task of mapping the DMA slave address from a > phys_addr_t to a dma_addr_t on the DMA engine. > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are > the same and no special care is needed. However if you have a IOMMU you > need to map the DMA slave phys_addr_t to a dma_addr_t using something > like this. > > This series is based on top of v4.8-rc1. And I'm hoping to be able to collect > a > Ack from Russell King on patch 4/6 that adds the ARM specific part and then be > able to take the whole series through the dmaengine tree. If this is not the > best route I'm more then happy to do it another way. > > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with > /dev/mmcblk1, i2c and the serial console which are devices behind the > iommu. > > Furthermore I have audited to the best of my ability all call paths > involved to make sure that the dma_addr_t obtained from > dma_map_resource() to is not used in a way where it would be expected > for the mapping to be RAM (have a struct page). Many thanks to Christoph > Hellwig and Laurent Pinchart for there input in this effort. Applied, thanks -- ~Vinod
Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote: > On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote: > > Hi, > > > > This series tries to solve the problem with DMA with device registers > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A > > recent patch '9575632 (dmaengine: make slave address physical)' > > clarifies that DMA slave address provided by clients is the physical > > address. This puts the task of mapping the DMA slave address from a > > phys_addr_t to a dma_addr_t on the DMA engine. > > > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are > > the same and no special care is needed. However if you have a IOMMU you > > need to map the DMA slave phys_addr_t to a dma_addr_t using something > > like this. > > > > This series is based on top of v4.8-rc1. And I'm hoping to be able to > > collect a > > Ack from Russell King on patch 4/6 that adds the ARM specific part and then > > be > > able to take the whole series through the dmaengine tree. If this is not the > > best route I'm more then happy to do it another way. > > > > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the > > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with > > /dev/mmcblk1, i2c and the serial console which are devices behind the > > iommu. > > As I said in last one, the dmaengine parts look fine to me. But to go thru > dmaengine tree I would need ACK on non dmaengine patches. I havent heard back from this one and I am inclined to merge this one now. If anyone has any objects, please speak up now... Also ACKs welcome... -- ~Vinod
Re: [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas Söderlund wrote: > Hi, > > This series tries to solve the problem with DMA with device registers > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A > recent patch '9575632 (dmaengine: make slave address physical)' > clarifies that DMA slave address provided by clients is the physical > address. This puts the task of mapping the DMA slave address from a > phys_addr_t to a dma_addr_t on the DMA engine. > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are > the same and no special care is needed. However if you have a IOMMU you > need to map the DMA slave phys_addr_t to a dma_addr_t using something > like this. > > This series is based on top of v4.8-rc1. And I'm hoping to be able to collect > a > Ack from Russell King on patch 4/6 that adds the ARM specific part and then be > able to take the whole series through the dmaengine tree. If this is not the > best route I'm more then happy to do it another way. > > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with > /dev/mmcblk1, i2c and the serial console which are devices behind the > iommu. As I said in last one, the dmaengine parts look fine to me. But to go thru dmaengine tree I would need ACK on non dmaengine patches. -- ~Vinod
Re: [PATCH] dmaengine: usb-dmac: check CHCR.DE bit in usb_dmac_isr_channel()
On Thu, Aug 04, 2016 at 07:59:41PM +0900, Yoshihiro Shimoda wrote: > The USB-DMAC's interruption happens even if the CHCR.DE is not set to 1 > because CHCR.NULLE is set to 1. So, this driver should call > usb_dmac_isr_transfer_end() if the DE bit is set to 1 only. Otherwise, > the desc is possible to be NULL in the usb_dmac_isr_transfer_end(). Applied, thanks -- ~Vinod
Re: Question about struct snd_soc_dai() :: cpu_dai->codec
On Fri, Jul 29, 2016 at 11:07:49AM +0200, Lars-Peter Clausen wrote: > On 07/29/2016 02:30 AM, Takashi Sakamoto wrote: > > Lars, > > > > On Jul 29 2016 05:33, Lars-Peter Clausen wrote: > >> Hotplug is something that always pops up sooner or later. E.g. if someone > >> puts a ASoC supported CODEC on a hot-pluggable device (maybe USB) we > >> don't want to duplicate the code, but be able to reuse. > > > > (A bit to sidetrack) > > > > To me, it's unclear for devices on USB. When ALSA SoC part supports these > > devices, what is the scenario you assumed? In short, assuming we put codes > > to ALSA SoC part, what is the shape of the corresponding devices and links > > of pairs of endpoints? Additionally, in this case, what codes are able to be > > reused? > > Lets say you have USB stick with a small micro controller or FPGA which has > a USB interface on one side and a I2S and I2C interface on the other side. > The I2S and I2C are connected to a CODEC. I2S for data, I2C for control. If > the interface is implemented in a way so that it is just a simple USB to I2C > bridge, this means the raw I2C commands are send over the USB interface you > can implement a I2C adapter driver for this bridge. If you have that you can > instantiate the existing ASoC CODEC driver, which is a I2C device driver, on > the bus registered by the adapter. That still seems a bit fancy hardware :) If we can reasonably support this, I am for it. But not making stuff overtly complex... -- ~Vinod
Re: [alsa-devel] Question about struct snd_soc_dai() :: cpu_dai->codec
On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote:
> On Wed, 27 Jul 2016 20:22:33 +0200,
> Mark Brown wrote:
> >
> > On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote:
> >
> > > I'm wondering whether it's a better option to block the unbind
> > > behavior, either in driver base (allowing to return an error) or in
> > > the sound side (waiting in remove() until the sane point).
> >
> > That's certainly going to be a lot easier and part of the reason it's
> > never been looked at much is that (unlike USB) there's very little
> > reason why an ASoC sound card would ever be hotplugged - even in
> > development these days the normal development flow involves rebooting.
I agree, it makese no sense for devices to be hotplugged. And for
developement flows people can do rmmond and insmod. That works fine!
> Actually there is already the suppress_bind_attr flag in struct
> device_driver. For a simple platform driver like snd-soc-rcar, it's
> easy like:
I like this idea, should we do this per driver or in core? I think we should
let drivers decide..
> diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
> index 3351a701c60e..d019824927de 100644
> --- a/sound/soc/sh/rcar/core.c
> +++ b/sound/soc/sh/rcar/core.c
> @@ -1251,6 +1251,7 @@ static struct platform_driver rsnd_driver = {
> .driver = {
> .name = "rcar_sound",
> .of_match_table = rsnd_of_match,
> + .suppress_bind_attrs = true,
> },
> .probe = rsnd_probe,
> .remove = rsnd_remove,
>
> Then there will be no sysfs bind/unbind for this driver.
> (Note: totally untested: let me know if it really works.)
>
> The same technique is likely available for i2c and spi codec drivers.
> But it's another open question whether we should suppress the sysfs
> bind/unbind of these devices at all. My gut feeling is that sysfs
> bind/unbind are mostly useless for drivers like ASoC codecs. At
> least, it would be much safer to disable for now.
--
~Vinod
Re: [alsa-devel] Question about struct snd_soc_dai() :: cpu_dai->codec
On Tue, Jul 26, 2016 at 05:41:56AM +, Kuninori Morimoto wrote: > > Hi ALSA SoC > > My current headache is ALSA SoC's each modules (= Card/Codec/CPU/Platform) > doesn't care about "unbind/rmmod". > For example, if someone unbinded/rmmoded "Codec", Card or other modules > doesn't know about it. Thus, user can continue to use this sound card, > and kernel will be Oops. Are you sure about this? Have you tried removing a module? During card probe, asoc will hold a reference to the component. See the calls to try_module_get(). This will prevent from unloading under normal cases. -- ~Vinod
Re: [PATCH 0/4] Residue patches for rcar-dmac from renesas-drivers
On Wed, Jun 15, 2016 at 01:13:04PM +0200, Niklas Söderlund wrote: > Hi all, > > Laurent Pinchart (1): > dmaengine: rcar-dmac: Fix residue reporting for pending descriptors > > Muhammad Hamza Farooq (2): > dma: rcar-dma: use result of updated get_residue in tx_status > dma: rcar-dma: Fixed active descriptor initializing > > Niklas Söderlund (1): > dmaengine: rcar-dmac: warn if transfer cannot start as TE = 1 At least maintain consistency in patch title, 2 are dma and two dmaengine. Correct one is latter.. > > drivers/dma/sh/rcar-dmac.c | 40 +--- > 1 file changed, 37 insertions(+), 3 deletions(-) > > -- > 2.8.3 > -- ~Vinod
Re: [PATCHv7 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
On Thu, Jun 02, 2016 at 02:58:07PM +0200, Niklas Söderlund wrote: > Hi Vinod, > > On 2016-06-01 23:36:11 +0530, Vinod Koul wrote: > > On Wed, Jun 01, 2016 at 05:22:23PM +0200, Niklas Söderlund wrote: > > > Hi, > > > > > > [In this v7 series I have tried to address the questions raised by > > > Christoph > > > Hellwig and I hope it can awnser your concernes regarding dma-debug.] > > > > > > This series tries to solve the problem with DMA with device registers > > > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A > > > recent patch '9575632 (dmaengine: make slave address physical)' > > > clarifies that DMA slave address provided by clients is the physical > > > address. This puts the task of mapping the DMA slave address from a > > > phys_addr_t to a dma_addr_t on the DMA engine. > > > > > > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are > > > the same and no special care is needed. However if you have a IOMMU you > > > need to map the DMA slave phys_addr_t to a dma_addr_t using something > > > like this. > > > > > > This series is based on top of v4.7-rc1. > > > > The dmanegine bits looks okay to me. Btw how is the merge planned for this? > > Do you wnat this to be merged thru dmaengine tree or something else? > > Yes, since the arm specific patch are depending on other parts of the > series I was hoping to be able to get Russells Ack on it and then try to > get it all in through the dmaengine tree. Sounds good to me.. > If you see a better way I'm happy to do it that way, let me know what > you think. I hold off v8 that adresses the issues Russell brought up a > few days untill I know what you think is best. -- ~Vinod
Re: [PATCH] dmaengine: of_dma: approximate an average distribution
On Wed, May 11, 2016 at 03:15:11PM +0200, Niklas Söderlund wrote:
> Currently the following DT description would result in dmac0 always
> being tried first and dmac1 second if dmac0 was unavailable. This
> results in heavier use of dmac0 then of dmac1. This patch adds an
> approximate average distribution over the two nodes lessening the load
> of anyone of them.
>
>i2c6: i2c@e60b {
>...
>dmas = < 0x77>, < 0x78>,
> < 0x77>, < 0x78>;
>dma-names = "tx", "rx", "tx", "rx";
>...
>};
Applied, thanks
--
~Vinod
Re: [PATCH v4 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers
On Tue, Feb 16, 2016 at 09:39:42PM +0100, Niklas Söderlund wrote:
> Enable slave transfers to devices behind IPMMU:s by mapping the slave
IPMMU:s ?
> addresses using the dma-mapping API.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> ---
> drivers/dma/sh/rcar-dmac.c | 52
> +-
> 1 file changed, 47 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 743873c..6a24847 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1106,21 +1106,63 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan,
> dma_addr_t buf_addr,
> return desc;
> }
>
> +static int rcar_dmac_set_slave_addr(struct dma_chan *chan,
> + struct rcar_dmac_chan_slave *slave,
> + phys_addr_t addr, size_t size)
> +{
> + enum dma_data_direction dir;
> +
> + /*
> + * We can't know the direction at this time, see documentation for
> + * 'direction' in struct dma_slave_config.
> + */
Okay so we are mapping on the device config, which doesn't seem intutive.
Why is this not done during prepare calls?
> + dir = DMA_BIDIRECTIONAL;
> +
> + if (slave->xfer_size) {
> + dma_unmap_resource(chan->device->dev, slave->slave_addr,
> +slave->xfer_size, dir, NULL);
> + slave->slave_addr = 0;
> + slave->xfer_size = 0;
> + }
> +
> + if (size) {
> + slave->slave_addr = dma_map_resource(chan->device->dev, addr,
> + size, dir, NULL);
> +
> + if (dma_mapping_error(chan->device->dev, slave->slave_addr)) {
> + struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> +
> + dev_err(chan->device->dev,
> + "chan%u: failed to map %zx@%pap", rchan->index,
> + size, );
> + return -EIO;
> + }
> +
> + slave->xfer_size = size;
> + }
> +
> + return 0;
> +}
> +
> static int rcar_dmac_device_config(struct dma_chan *chan,
> struct dma_slave_config *cfg)
> {
> struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> + int ret;
>
> /*
>* We could lock this, but you shouldn't be configuring the
>* channel, while using it...
>*/
> - rchan->src.slave_addr = cfg->src_addr;
> - rchan->dst.slave_addr = cfg->dst_addr;
> - rchan->src.xfer_size = cfg->src_addr_width;
> - rchan->dst.xfer_size = cfg->dst_addr_width;
>
> - return 0;
> + ret = rcar_dmac_set_slave_addr(chan, >src, cfg->src_addr,
> + cfg->src_addr_width);
> + if (ret)
> + return ret;
> +
> + ret = rcar_dmac_set_slave_addr(chan, >dst, cfg->dst_addr,
> +cfg->dst_addr_width);
> + return ret;
> }
>
> static int rcar_dmac_chan_terminate_all(struct dma_chan *chan)
> --
> 2.7.1
>
--
~Vinod
Re: [PATCH] dmaengine: sh: shdmac: don't open code of_device_get_match_data()
On Tue, Mar 01, 2016 at 05:37:07PM +0100, Wolfram Sang wrote: > From: Wolfram Sang <wsa+rene...@sang-engineering.com> > > This change will also make Coverity happy by avoiding a theoretical NULL > pointer dereference; yet another reason is to use the above helper function > to tighten the code and make it more readable. Applied, thanks -- ~Vinod
Re: [PATCH][CFT]: dmaengine: make slave address physical
On Mon, Feb 22, 2016 at 10:49:08AM +0100, Niklas Söderlund wrote:
> Hi Vinod,
>
> On 2016-02-21 20:50:46 +0530, Vinod Koul wrote:
> > The slave dmaengine semantics required the client to map dma
> > addresses and pass DMA address to dmaengine drivers. While this
> > was a convenient notion coming from generic dma offload cases
> > where dmaengines are interchangeable and client is not aware of
> > which engine to map to.
> >
> > But in case of slave, we know the dmaengine and always use a
> > specific one. Further the IOMMU cases can lead to failure of this
> > notion, so make this as physical address and now dmaengine driver
> > will do the required mapping.
>
> Thanks! I have tested this patch with my IOMMU series and it works
> nicely.
>
> >
> > Original-patch-by: Linus Walleij <linus.wall...@linaro.org>
> > Signed-off-by: Vinod Koul <vinod.k...@intel.com>
>
> Tested-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se>
Thanks :)
>
> > ---
> > include/linux/dmaengine.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index 16a1cad30c33..d85ecd20af50 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -357,8 +357,8 @@ enum dma_slave_buswidth {
> > */
> > struct dma_slave_config {
> > enum dma_transfer_direction direction;
> > - dma_addr_t src_addr;
> > - dma_addr_t dst_addr;
> > + phys_addr_t src_addr;
> > + phys_addr_t dst_addr;
> > enum dma_slave_buswidth src_addr_width;
> > enum dma_slave_buswidth dst_addr_width;
> > u32 src_maxburst;
>
> --
> Regards,
> Niklas Söderlund
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~Vinod
[PATCH][CFT]: dmaengine: make slave address physical
The slave dmaengine semantics required the client to map dma
addresses and pass DMA address to dmaengine drivers. While this
was a convenient notion coming from generic dma offload cases
where dmaengines are interchangeable and client is not aware of
which engine to map to.
But in case of slave, we know the dmaengine and always use a
specific one. Further the IOMMU cases can lead to failure of this
notion, so make this as physical address and now dmaengine driver
will do the required mapping.
Original-patch-by: Linus Walleij <linus.wall...@linaro.org>
Signed-off-by: Vinod Koul <vinod.k...@intel.com>
---
include/linux/dmaengine.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 16a1cad30c33..d85ecd20af50 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -357,8 +357,8 @@ enum dma_slave_buswidth {
*/
struct dma_slave_config {
enum dma_transfer_direction direction;
- dma_addr_t src_addr;
- dma_addr_t dst_addr;
+ phys_addr_t src_addr;
+ phys_addr_t dst_addr;
enum dma_slave_buswidth src_addr_width;
enum dma_slave_buswidth dst_addr_width;
u32 src_maxburst;
--
1.9.1
Re: [PATCH] dmaengine: use phys_addr_t for slave configuration
On Tue, Feb 09, 2016 at 11:57:24PM +0100, Wolfram Sang wrote: > > > This is a dependency for adding iommu support to the rcar-dmac driver, cfr. > > "[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave > > transfers". > > http://www.spinics.net/lists/linux-renesas-soc/msg00066.html > > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg00108.html > > > > Thank you for applying! > > Yup, we really need it. Anything we can do to help? I have done this change and discussing wider changes I will send CFT hopefully before EOW, pls test :) -- ~Vinod signature.asc Description: Digital signature
