* dmaengine: rcar-dmac: Document R8A774A1 bindings
From: Simon Horman @ 2018-11-08 12:23 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Mark Rutland, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Geert Uytterhoeven, Chris Paterson, Biju Das,
linux-renesas-soc@vger.kernel.org
Hi Fabrizio,
I believe this one is for Vinod.
On Thu, Nov 08, 2018 at 11:03:53AM +0000, Fabrizio Castro wrote:
> Dear All,
>
> Who is the best person to take this patch?
>
> Thanks,
> Fab
>
> > From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Sent: 14 August 2018 13:32
> > Subject: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings
> >
> > Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible
> > with this driver, therefore document RZ/G2M specific bindings.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > index 946229c..2de2eed 100644
> > --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > @@ -1,6 +1,6 @@
> > * Renesas R-Car (RZ/G) DMA Controller Device Tree bindings
> >
> > -Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA
> > +Renesas R-Car (Gen 2/3) and RZ/G SoCs have multiple multi-channel DMA
> > controller instances named DMAC capable of serving multiple clients. Channels
> > can be dedicated to specific clients or shared between a large number of
> > clients.
> > @@ -19,6 +19,7 @@ Required Properties:
> > - "renesas,dmac-r8a7743" (RZ/G1M)
> > - "renesas,dmac-r8a7745" (RZ/G1E)
> > - "renesas,dmac-r8a77470" (RZ/G1C)
> > +- "renesas,dmac-r8a774a1" (RZ/G2M)
> > - "renesas,dmac-r8a7790" (R-Car H2)
> > - "renesas,dmac-r8a7791" (R-Car M2-W)
> > - "renesas,dmac-r8a7792" (R-Car V2H)
> > --
> > 2.7.4
>
>
>
>
> Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
>
^ permalink raw reply
* [4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Fabrizio Castro @ 2018-11-08 12:48 UTC (permalink / raw)
To: Fabrizio Castro, Vinod Koul, Rob Herring, Mark Rutland
Cc: Biju Das, Greg Kroah-Hartman, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, Simon Horman, Geert Uytterhoeven,
Chris Paterson, linux-renesas-soc@vger.kernel.org,
linux-kernel@vger.kernel.org
Dear All,
Who is the best person to take this patch?
Thanks,
Fab
> From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Sent: 24 August 2018 08:56
> Subject: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
>
> From: Biju Das <biju.das@bp.renesas.com>
>
> This patch adds binding for r8a774a1 (RZ/G2M).
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.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 482e543..417ca90 100644
> --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
> +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
> @@ -5,6 +5,7 @@ Required Properties:
> Examples with soctypes are:
> - "renesas,r8a7743-usb-dmac" (RZ/G1M)
> - "renesas,r8a7745-usb-dmac" (RZ/G1E)
> + - "renesas,r8a774a1-usb-dmac" (RZ/G2M)
> - "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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Simon Horman @ 2018-11-08 13:21 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Mark Rutland, Biju Das,
Greg Kroah-Hartman, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Chris Paterson,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
On Thu, Nov 08, 2018 at 12:48:46PM +0000, Fabrizio Castro wrote:
> Dear All,
>
> Who is the best person to take this patch?
I believe this one is for Vinod.
^ permalink raw reply
* [4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Simon Horman @ 2018-11-08 13:26 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Mark Rutland, Biju Das,
Greg Kroah-Hartman, dmaengine, devicetree, Geert Uytterhoeven,
Chris Paterson, linux-renesas-soc, linux-kernel
On Fri, Aug 24, 2018 at 08:56:13AM +0100, Fabrizio Castro wrote:
> From: Biju Das <biju.das@bp.renesas.com>
>
> This patch adds binding for r8a774a1 (RZ/G2M).
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* dmaengine: rcar-dmac: Document R8A774A1 bindings
From: Fabrizio Castro @ 2018-11-08 13:59 UTC (permalink / raw)
To: Simon Horman, Vinod Koul
Cc: Rob Herring, Mark Rutland, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Geert Uytterhoeven, Chris Paterson, Biju Das,
linux-renesas-soc@vger.kernel.org
Thank you Simon for getting back to me.
Vinod, does this patch look ok to you?
Thanks,
Fab
> Subject: Re: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings
>
> Hi Fabrizio,
>
> I believe this one is for Vinod.
>
> On Thu, Nov 08, 2018 at 11:03:53AM +0000, Fabrizio Castro wrote:
> > Dear All,
> >
> > Who is the best person to take this patch?
> >
> > Thanks,
> > Fab
> >
> > > From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Sent: 14 August 2018 13:32
> > > Subject: [PATCH] dmaengine: rcar-dmac: Document R8A774A1 bindings
> > >
> > > Renesas' RZ/G2M (R8A774A1) SoC has DMA controllers compatible
> > > with this driver, therefore document RZ/G2M specific bindings.
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> > > ---
> > > Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > > b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > > index 946229c..2de2eed 100644
> > > --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > > +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> > > @@ -1,6 +1,6 @@
> > > * Renesas R-Car (RZ/G) DMA Controller Device Tree bindings
> > >
> > > -Renesas R-Car Generation 2 SoCs have multiple multi-channel DMA
> > > +Renesas R-Car (Gen 2/3) and RZ/G SoCs have multiple multi-channel DMA
> > > controller instances named DMAC capable of serving multiple clients. Channels
> > > can be dedicated to specific clients or shared between a large number of
> > > clients.
> > > @@ -19,6 +19,7 @@ Required Properties:
> > > - "renesas,dmac-r8a7743" (RZ/G1M)
> > > - "renesas,dmac-r8a7745" (RZ/G1E)
> > > - "renesas,dmac-r8a77470" (RZ/G1C)
> > > +- "renesas,dmac-r8a774a1" (RZ/G2M)
> > > - "renesas,dmac-r8a7790" (R-Car H2)
> > > - "renesas,dmac-r8a7791" (R-Car M2-W)
> > > - "renesas,dmac-r8a7792" (R-Car V2H)
> > > --
> > > 2.7.4
> >
> >
> >
> >
> > Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England
> & Wales under Registered No. 04586709.
> >
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Fabrizio Castro @ 2018-11-08 14:12 UTC (permalink / raw)
To: Fabrizio Castro, Vinod Koul, Rob Herring, Mark Rutland
Cc: Biju Das, Greg Kroah-Hartman, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, Simon Horman, Geert Uytterhoeven,
Chris Paterson, linux-renesas-soc@vger.kernel.org,
linux-kernel@vger.kernel.org
Hello Vinod,
Do you think you can take this patch?
Thanks,
Fab
> From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Sent: 24 August 2018 08:56
> Subject: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
>
> From: Biju Das <biju.das@bp.renesas.com>
>
> This patch adds binding for r8a774a1 (RZ/G2M).
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.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 482e543..417ca90 100644
> --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
> +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
> @@ -5,6 +5,7 @@ Required Properties:
> Examples with soctypes are:
> - "renesas,r8a7743-usb-dmac" (RZ/G1M)
> - "renesas,r8a7745-usb-dmac" (RZ/G1E)
> + - "renesas,r8a774a1-usb-dmac" (RZ/G2M)
> - "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
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Fabrizio Castro @ 2018-11-08 14:13 UTC (permalink / raw)
To: Simon Horman
Cc: Vinod Koul, Rob Herring, Mark Rutland, Biju Das,
Greg Kroah-Hartman, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Chris Paterson,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Thank you Simon for getting back to me.
> From: Simon Horman <horms@verge.net.au>
> Sent: 08 November 2018 13:21
> Subject: Re: [PATCH 4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
>
> On Thu, Nov 08, 2018 at 12:48:46PM +0000, Fabrizio Castro wrote:
> > Dear All,
> >
> > Who is the best person to take this patch?
>
> I believe this one is for Vinod.
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [06/17] dma: bcm2835: Switch to SPDX identifier
From: Stefan Wahren @ 2018-11-10 15:34 UTC (permalink / raw)
To: Eric Anholt, Vinod Koul
Cc: linux-rpi-kernel, dmaengine, linux-kernel, Stefan Wahren,
Florian Kauer
Adopt the SPDX license identifier headers to ease license compliance
management.
Cc: Florian Kauer <florian.kauer@koalo.de>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/dma/bcm2835-dma.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index ed871eb..1a44c80 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
/*
* BCM2835 DMA engine support
*
@@ -18,16 +19,6 @@
*
* MARVELL MMP Peripheral DMA Driver
* Copyright 2012 Marvell International Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
*/
#include <linux/dmaengine.h>
#include <linux/dma-mapping.h>
^ permalink raw reply related
* [v2,1/2] dt-bindings: dmaengine: dw-dmac: add protection control property
From: Christian Lamparter @ 2018-11-10 16:28 UTC (permalink / raw)
To: dmaengine, devicetree
Cc: Dan Williams, Vinod Koul, Andy Shevchenko, Viresh Kumar,
Rob Herring, Mark Rutland
This patch for the DesignWare AHB Central
Direct Memory Access Controller adds the dma
protection control property:
"snps,dma-protection-control"
as well as the properties specific values defines into
a new include file: include/dt-bindings/dma/dw-dmac.h
Note: The protection control signals are one-to-one
mapped to the AHB HPROT[1:3] signals for this controller.
The HPROT0 (Data Access) is always hardwired to 1.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
I've included the "Reviewed-by" from the v1 in this patch for now.
But if a new issue comes up regarding the updates, please let me know.
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 4 ++++
MAINTAINERS | 4 +++-
include/dt-bindings/dma/dw-dmac.h | 14 ++++++++++++++
3 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/dma/dw-dmac.h
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 39e2b26be344..db757df7057d 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -27,6 +27,10 @@ Optional properties:
general purpose DMA channel allocator. False if not passed.
- multi-block: Multi block transfers supported by hardware. Array property with
one cell per channel. 0: not supported, 1 (default): supported.
+- snps,dma-protection-control: AHB HPROT[3:1] protection setting.
+ The default value is 0 (for non-cacheable, non-buffered,
+ unprivileged data access).
+ Refer to include/dt-bindings/dma/dw-dmac.h for possible values.
Example:
diff --git a/MAINTAINERS b/MAINTAINERS
index dacba23b80b4..c35998e20e9d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14107,9 +14107,11 @@ SYNOPSYS DESIGNWARE DMAC DRIVER
M: Viresh Kumar <vireshk@kernel.org>
R: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
S: Maintained
+F: Documentation/devicetree/bindings/dma/snps-dma.txt
+F: drivers/dma/dw/
+F: include/dt-bindings/dma/dw-dmac.h
F: include/linux/dma/dw.h
F: include/linux/platform_data/dma-dw.h
-F: drivers/dma/dw/
SYNOPSYS DESIGNWARE ENTERPRISE ETHERNET DRIVER
M: Jose Abreu <Jose.Abreu@synopsys.com>
diff --git a/include/dt-bindings/dma/dw-dmac.h b/include/dt-bindings/dma/dw-dmac.h
new file mode 100644
index 000000000000..d1ca705c95b3
--- /dev/null
+++ b/include/dt-bindings/dma/dw-dmac.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+
+#ifndef __DT_BINDINGS_DMA_DW_DMAC_H__
+#define __DT_BINDINGS_DMA_DW_DMAC_H__
+
+/*
+ * Protection Control bits provide protection against illegal transactions.
+ * The protection bits[0:2] are one-to-one mapped to AHB HPROT[3:1] signals.
+ */
+#define DW_DMAC_HPROT1_PRIVILEGED_MODE (1 << 0) /* Privileged Mode */
+#define DW_DMAC_HPROT2_BUFFERABLE (1 << 1) /* DMA is bufferable */
+#define DW_DMAC_HPROT3_CACHEABLE (1 << 2) /* DMA is cacheable */
+
+#endif /* __DT_BINDINGS_DMA_DW_DMAC_H__ */
^ permalink raw reply related
* [v2,2/2] dmaengine: dw-dmac: implement dma protection control setting
From: Christian Lamparter @ 2018-11-10 16:28 UTC (permalink / raw)
To: dmaengine, devicetree
Cc: Dan Williams, Vinod Koul, Andy Shevchenko, Viresh Kumar,
Rob Herring, Mark Rutland
This patch adds a new device-tree property that allows to
specify the dma protection control bits for the all of the
DMA controller's channel uniformly.
Setting the "correct" bits can have a huge impact on the
PPC460EX and APM82181 that use this DMA engine in combination
with a DesignWare' SATA-II core (sata_dwc_460ex driver).
In the OpenWrt Forum, the user takimata reported that:
|It seems your patch unleashed the full power of the SATA port.
|Where I was previously hitting a really hard limit at around
|82 MB/s for reading and 27 MB/s for writing, I am now getting this:
|
|root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024
|1024+0 records in
|1024+0 records out
|real 0m 13.65s
|user 0m 0.01s
|sys 0m 11.89s
|
|root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024
|1024+0 records in
|1024+0 records out
|real 0m 8.41s
|user 0m 0.01s
|sys 0m 4.70s
|
|This means: 121 MB/s reading and 75 MB/s writing!
|
|The drive is a WD Green WD10EARX taken from an older MBL Single.
|I repeated the test a few times with even larger files to rule out
|any caching, I'm still seeing the same great performance. OpenWrt is
|now completely on par with the original MBL firmware's performance.
Another user And.short reported:
|I can report that your fix worked! Boots up fine with two
|drives even with more partitions, and no more reboot on
|concurrent disk access!
A closer look into the sata_dwc_460ex code revealed that
the driver did initally set the correct protection control
bits. However, this feature was lost when the sata_dwc_460ex
driver was converted to the generic DMA driver framework.
BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55
BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50
Fixes: 8b3444852a2b ("sata_dwc_460ex: move to generic DMA driver")
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/dma/dw/core.c | 2 ++
drivers/dma/dw/platform.c | 6 ++++++
drivers/dma/dw/regs.h | 4 ++++
include/linux/platform_data/dma-dw.h | 6 ++++++
4 files changed, 18 insertions(+)
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index f43e6dafe446..0772d2d6cc68 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -160,12 +160,14 @@ static void dwc_initialize_chan_idma32(struct dw_dma_chan *dwc)
static void dwc_initialize_chan_dw(struct dw_dma_chan *dwc)
{
+ struct dw_dma *dw = to_dw_dma(dwc->chan.device);
u32 cfghi = DWC_CFGH_FIFO_MODE;
u32 cfglo = DWC_CFGL_CH_PRIOR(dwc->priority);
bool hs_polarity = dwc->dws.hs_polarity;
cfghi |= DWC_CFGH_DST_PER(dwc->dws.dst_id);
cfghi |= DWC_CFGH_SRC_PER(dwc->dws.src_id);
+ cfghi |= DWC_CFGH_PROTCTL(dw->pdata->protctl);
/* Set polarity of handshake interface */
cfglo |= hs_polarity ? DWC_CFGL_HS_DST_POL | DWC_CFGL_HS_SRC_POL : 0;
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index f62dd0944908..c299ff181bb6 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -162,6 +162,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->multi_block[tmp] = 1;
}
+ if (!of_property_read_u32(np, "snps,dma-protection-control", &tmp)) {
+ if (tmp > CHAN_PROTCTL_MASK)
+ return NULL;
+ pdata->protctl = tmp;
+ }
+
return pdata;
}
#else
diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
index 09e7dfdbb790..646c9c960c07 100644
--- a/drivers/dma/dw/regs.h
+++ b/drivers/dma/dw/regs.h
@@ -200,6 +200,10 @@ enum dw_dma_msize {
#define DWC_CFGH_FCMODE (1 << 0)
#define DWC_CFGH_FIFO_MODE (1 << 1)
#define DWC_CFGH_PROTCTL(x) ((x) << 2)
+#define DWC_CFGH_PROTCTL_DATA (0 << 2) /* data access - always set */
+#define DWC_CFGH_PROTCTL_PRIV (1 << 2) /* privileged -> AHB HPROT[1] */
+#define DWC_CFGH_PROTCTL_BUFFER (2 << 2) /* bufferable -> AHB HPROT[2] */
+#define DWC_CFGH_PROTCTL_CACHE (4 << 2) /* cacheable -> AHB HPROT[3] */
#define DWC_CFGH_DS_UPD_EN (1 << 5)
#define DWC_CFGH_SS_UPD_EN (1 << 6)
#define DWC_CFGH_SRC_PER(x) ((x) << 7)
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 896cb71a382c..b7b9d4a56bb0 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -49,6 +49,7 @@ struct dw_dma_slave {
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
* @multi_block: Multi block transfers supported by hardware per channel.
+ * @protctl: Protection control signals setting per channel.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
@@ -65,6 +66,11 @@ struct dw_dma_platform_data {
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
+#define CHAN_PROTCTL_PRIVILEGED BIT(0)
+#define CHAN_PROTCTL_BUFFERABLE BIT(1)
+#define CHAN_PROTCTL_CACHEABLE BIT(2)
+#define CHAN_PROTCTL_MASK GENMASK(2, 0)
+ unsigned char protctl;
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
^ permalink raw reply related
* [06/17] dma: bcm2835: Switch to SPDX identifier
From: Eric Anholt @ 2018-11-10 16:54 UTC (permalink / raw)
To: Stefan Wahren, Vinod Koul
Cc: linux-rpi-kernel, dmaengine, linux-kernel, Florian Kauer
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Adopt the SPDX license identifier headers to ease license compliance
> management.
Reviewed-by: Eric Anholt <eric@anholt.net>
^ permalink raw reply
* [v2,2/2] dmaengine: dw-dmac: implement dma protection control setting
From: Andy Shevchenko @ 2018-11-10 18:45 UTC (permalink / raw)
To: Christian Lamparter
Cc: dmaengine, devicetree, Dan Williams, Vinod Koul, Viresh Kumar,
Rob Herring, Mark Rutland
On Sat, Nov 10, 2018 at 05:28:31PM +0100, Christian Lamparter wrote:
> This patch adds a new device-tree property that allows to
> specify the dma protection control bits for the all of the
> DMA controller's channel uniformly.
>
> Setting the "correct" bits can have a huge impact on the
> PPC460EX and APM82181 that use this DMA engine in combination
> with a DesignWare' SATA-II core (sata_dwc_460ex driver).
>
> In the OpenWrt Forum, the user takimata reported that:
> |It seems your patch unleashed the full power of the SATA port.
> |Where I was previously hitting a really hard limit at around
> |82 MB/s for reading and 27 MB/s for writing, I am now getting this:
> |
> |root@OpenWrt:/mnt# time dd if=/dev/zero of=tempfile bs=1M count=1024
> |1024+0 records in
> |1024+0 records out
> |real 0m 13.65s
> |user 0m 0.01s
> |sys 0m 11.89s
> |
> |root@OpenWrt:/mnt# time dd if=tempfile of=/dev/null bs=1M count=1024
> |1024+0 records in
> |1024+0 records out
> |real 0m 8.41s
> |user 0m 0.01s
> |sys 0m 4.70s
> |
> |This means: 121 MB/s reading and 75 MB/s writing!
> |
> |The drive is a WD Green WD10EARX taken from an older MBL Single.
> |I repeated the test a few times with even larger files to rule out
> |any caching, I'm still seeing the same great performance. OpenWrt is
> |now completely on par with the original MBL firmware's performance.
>
> Another user And.short reported:
> |I can report that your fix worked! Boots up fine with two
> |drives even with more partitions, and no more reboot on
> |concurrent disk access!
>
> A closer look into the sata_dwc_460ex code revealed that
> the driver did initally set the correct protection control
> bits. However, this feature was lost when the sata_dwc_460ex
> driver was converted to the generic DMA driver framework.
LGTM, though minor style comment below.
>
> BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/55
> BugLink: https://forum.openwrt.org/t/wd-mybook-live-duo-two-disks/16195/50
> Fixes: 8b3444852a2b ("sata_dwc_460ex: move to generic DMA driver")
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> drivers/dma/dw/core.c | 2 ++
> drivers/dma/dw/platform.c | 6 ++++++
> drivers/dma/dw/regs.h | 4 ++++
> include/linux/platform_data/dma-dw.h | 6 ++++++
> 4 files changed, 18 insertions(+)
>
> diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
> index f43e6dafe446..0772d2d6cc68 100644
> --- a/drivers/dma/dw/core.c
> +++ b/drivers/dma/dw/core.c
> @@ -160,12 +160,14 @@ static void dwc_initialize_chan_idma32(struct dw_dma_chan *dwc)
>
> static void dwc_initialize_chan_dw(struct dw_dma_chan *dwc)
> {
> + struct dw_dma *dw = to_dw_dma(dwc->chan.device);
> u32 cfghi = DWC_CFGH_FIFO_MODE;
> u32 cfglo = DWC_CFGL_CH_PRIOR(dwc->priority);
> bool hs_polarity = dwc->dws.hs_polarity;
>
> cfghi |= DWC_CFGH_DST_PER(dwc->dws.dst_id);
> cfghi |= DWC_CFGH_SRC_PER(dwc->dws.src_id);
> + cfghi |= DWC_CFGH_PROTCTL(dw->pdata->protctl);
>
> /* Set polarity of handshake interface */
> cfglo |= hs_polarity ? DWC_CFGL_HS_DST_POL | DWC_CFGL_HS_SRC_POL : 0;
> diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
> index f62dd0944908..c299ff181bb6 100644
> --- a/drivers/dma/dw/platform.c
> +++ b/drivers/dma/dw/platform.c
> @@ -162,6 +162,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
> pdata->multi_block[tmp] = 1;
> }
>
> + if (!of_property_read_u32(np, "snps,dma-protection-control", &tmp)) {
> + if (tmp > CHAN_PROTCTL_MASK)
> + return NULL;
> + pdata->protctl = tmp;
> + }
> +
> return pdata;
> }
> #else
> diff --git a/drivers/dma/dw/regs.h b/drivers/dma/dw/regs.h
> index 09e7dfdbb790..646c9c960c07 100644
> --- a/drivers/dma/dw/regs.h
> +++ b/drivers/dma/dw/regs.h
> @@ -200,6 +200,10 @@ enum dw_dma_msize {
> #define DWC_CFGH_FCMODE (1 << 0)
> #define DWC_CFGH_FIFO_MODE (1 << 1)
> #define DWC_CFGH_PROTCTL(x) ((x) << 2)
> +#define DWC_CFGH_PROTCTL_DATA (0 << 2) /* data access - always set */
> +#define DWC_CFGH_PROTCTL_PRIV (1 << 2) /* privileged -> AHB HPROT[1] */
> +#define DWC_CFGH_PROTCTL_BUFFER (2 << 2) /* bufferable -> AHB HPROT[2] */
> +#define DWC_CFGH_PROTCTL_CACHE (4 << 2) /* cacheable -> AHB HPROT[3] */
> #define DWC_CFGH_DS_UPD_EN (1 << 5)
> #define DWC_CFGH_SS_UPD_EN (1 << 6)
> #define DWC_CFGH_SRC_PER(x) ((x) << 7)
> diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
> index 896cb71a382c..b7b9d4a56bb0 100644
> --- a/include/linux/platform_data/dma-dw.h
> +++ b/include/linux/platform_data/dma-dw.h
> @@ -49,6 +49,7 @@ struct dw_dma_slave {
> * @data_width: Maximum data width supported by hardware per AHB master
> * (in bytes, power of 2)
> * @multi_block: Multi block transfers supported by hardware per channel.
> + * @protctl: Protection control signals setting per channel.
> */
> struct dw_dma_platform_data {
> unsigned int nr_channels;
> @@ -65,6 +66,11 @@ struct dw_dma_platform_data {
> unsigned char nr_masters;
> unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
> unsigned char multi_block[DW_DMA_MAX_NR_CHANNELS];
> +#define CHAN_PROTCTL_PRIVILEGED BIT(0)
> +#define CHAN_PROTCTL_BUFFERABLE BIT(1)
> +#define CHAN_PROTCTL_CACHEABLE BIT(2)
> +#define CHAN_PROTCTL_MASK GENMASK(2, 0)
TAB vs. SPACE.
> + unsigned char protctl;
> };
>
> #endif /* _PLATFORM_DATA_DMA_DW_H */
> --
> 2.19.1
>
^ permalink raw reply
* [for-stable] dmaengine: stm32-dma: fix incomplete configuration in cyclic mode
From: Greg Kroah-Hartman @ 2018-11-11 1:11 UTC (permalink / raw)
To: Joel Fernandes (Google)
Cc: stable, Pierre Yves MORDRET, Hugues Fruchet, Vinod Koul,
Alexandre Torgue, Dan Williams, dmaengine,
moderated list:ARM/STM32 ARCHITECTURE, linux-kernel,
Maxime Coquelin
On Tue, Oct 16, 2018 at 05:00:03PM -0700, Joel Fernandes (Google) wrote:
> From: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
>
> commit e57cb3b3f10d005410f09d4598cc6d62b833f2b0 upstream.
>
> When in cyclic mode, the configuration is updated after having started the
> DMA hardware (STM32_DMA_SCR_EN) leading to incomplete configuration of
> SMxAR registers.
>
> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
> ---
> drivers/dma/stm32-dma.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
I'm just guessing you want this for 4.14.y? I've added it there. If
not, please give me a hint :)
^ permalink raw reply
* [2/3] dma: bcm2835: make license text and module license match
From: Vinod Koul @ 2018-11-11 9:09 UTC (permalink / raw)
To: Stefan Wahren
Cc: Florian Meier, Chris Boot, Martin Sperl, Eric Anholt,
Michael Turquette, Stephen Boyd, Mark Brown, linux-clk, dmaengine,
linux-spi, linux-arm-kernel
On 23-10-18, 13:06, Stefan Wahren wrote:
> The license text is specifying GPL v2 or later but the MODULE_LICENSE
> is set to GPL v2 which means GNU Public License v2 only. So choose the
> license text as the correct one.
Applied after fixing subsystem name, thanks
^ permalink raw reply
* [06/17] dma: bcm2835: Switch to SPDX identifier
From: Vinod Koul @ 2018-11-11 9:13 UTC (permalink / raw)
To: Stefan Wahren
Cc: Eric Anholt, linux-rpi-kernel, dmaengine, linux-kernel,
Florian Kauer
On 10-11-18, 16:34, Stefan Wahren wrote:
> Adopt the SPDX license identifier headers to ease license compliance
> management.
Applied after fixing subsystem tags, thanks
^ permalink raw reply
* [resend] dma: sh: convert to SPDX identifiers
From: Vinod Koul @ 2018-11-11 9:15 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: dmaengine
On 08-11-18, 06:32, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
Please pay attention the use of subsystem tag, its dmaengine.
Applied with that fix, thanks
^ permalink raw reply
* dmaengine: rcar-dmac: Document R8A774A1 bindings
From: Vinod Koul @ 2018-11-11 9:17 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Simon Horman, Rob Herring, Mark Rutland,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Geert Uytterhoeven, Chris Paterson,
Biju Das, linux-renesas-soc@vger.kernel.org
On 08-11-18, 13:59, Fabrizio Castro wrote:
> Thank you Simon for getting back to me.
>
> Vinod, does this patch look ok to you?
This does not appear in my queue, please resend and collect the acks
received if any as well
Thanks
^ permalink raw reply
* [4/6] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Vinod Koul @ 2018-11-11 9:19 UTC (permalink / raw)
To: Simon Horman
Cc: Fabrizio Castro, Rob Herring, Mark Rutland, Biju Das,
Greg Kroah-Hartman, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven, Chris Paterson,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
On 08-11-18, 14:21, Simon Horman wrote:
> On Thu, Nov 08, 2018 at 12:48:46PM +0000, Fabrizio Castro wrote:
> > Dear All,
> >
> > Who is the best person to take this patch?
>
> I believe this one is for Vinod.
Please resend it, it is not in my queue
^ permalink raw reply
* dmaengine: sa11x0: unexport sa11x0_dma_filter_fn and clean up
From: Vinod Koul @ 2018-11-11 9:24 UTC (permalink / raw)
To: Russell King; +Cc: linux-arm-kernel, Dan Williams, dmaengine
On 06-11-18, 13:45, Russell King wrote:
> As we now have no users of sa11x0_dma_filter_fn() in the tree, we can
> unexport this function, and remove the now unused header file.
Applied, thanks
^ permalink raw reply
* dmaengine: fix some typo
From: Vinod Koul @ 2018-11-11 9:28 UTC (permalink / raw)
To: Yangtao Li; +Cc: dan.j.williams, dmaengine, linux-kernel
On 01-11-18, 11:35, Yangtao Li wrote:
> Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
While sending patches it is a good idea to see the convention of the
tags used. git log <file> will help you with that
Applied after adding file tag to this
^ permalink raw reply
* [1/2] dt-bindings: dmaengine: usb-dmac: Add binding for r8a77470
From: Vinod Koul @ 2018-11-11 9:31 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, dmaengine, devicetree, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Fabrizio Castro,
linux-renesas-soc
On 25-10-18, 15:53, Biju Das wrote:
> This patch adds usb high-speed dmac binding for r8a77470 (RZ/G1C) SoC.
Applied, thanks
^ permalink raw reply
* [2/2] dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC
From: Vinod Koul @ 2018-11-11 10:19 UTC (permalink / raw)
To: shun-chih.yu
Cc: Sean Wang, Rob Herring, Matthias Brugger, Dan Williams, dmaengine,
linux-arm-kernel, linux-mediatek, devicetree, linux-kernel,
srv_wsdupstream
On 18-10-18, 15:49, shun-chih.yu@mediatek.com wrote:
> From: Shun-Chih Yu <shun-chih.yu@mediatek.com>
>
> MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated
> to memory-to-memory transfer through queue based descriptor management.
>
> There are only 3 physical channels inside CQDMA, while the driver is
> extended to support 32 virtual channels for multiple dma users to issue
> dma requests onto the CQDMA simultaneously.
I see some warns in the driver when I compile with C=1 please do fix
those in next rev
> +struct mtk_cqdma_vdesc {
> + struct virt_dma_desc vd;
> + size_t len;
> + size_t residue;
why should you store residue in descriptor, it will get stale very soon!
> + dma_addr_t dest;
> + dma_addr_t src;
> + struct dma_chan *ch;
> +
> + struct list_head node;
why do you need your own list, vd has a list for descriptors!
> +struct mtk_cqdma_pchan {
> + struct list_head queue;
> + void __iomem *base;
> + u32 irq;
> +
> + refcount_t refcnt;
Can you submit more than one descriptor at any point of time?
> +struct mtk_cqdma_vchan {
> + struct virt_dma_chan vc;
> + struct mtk_cqdma_pchan *pc;
> + struct completion issue_completion;
> + bool issue_synchronize;
what lock protects this?
> +static void mtk_cqdma_start(struct mtk_cqdma_pchan *pc,
> + struct mtk_cqdma_vdesc *cvd)
> +{
> + /* wait for the previous transaction done */
> + if (mtk_cqdma_poll_engine_done(pc, true) < 0)
> + dev_err(cqdma2dev(to_cqdma_dev(cvd->ch)), "cqdma wait transaction timeout\n");
Please split this to 2 lines to adhere to 80 chars limit
Also no bailout of error?
> +static struct mtk_cqdma_vdesc
> +*mtk_cqdma_consume_work_queue(struct mtk_cqdma_pchan *pc)
> +{
> + struct mtk_cqdma_vchan *cvc;
> + struct mtk_cqdma_vdesc *cvd, *ret = NULL;
ret initialization seems superfluous
> +static void mtk_cqdma_tasklet_cb(unsigned long data)
> +{
> + struct mtk_cqdma_pchan *pc = (struct mtk_cqdma_pchan *)data;
> + struct mtk_cqdma_vdesc *cvd = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&pc->lock, flags);
> + /* consume the queue */
> + cvd = mtk_cqdma_consume_work_queue(pc);
why not do this from ISR, DMA should be submitted as fast as possible!
> +static int mtk_cqdma_alloc_chan_resources(struct dma_chan *c)
> +{
> + struct mtk_cqdma_device *cqdma = to_cqdma_dev(c);
> + struct mtk_cqdma_vchan *vc = to_cqdma_vchan(c);
> + struct mtk_cqdma_pchan *pc = NULL;
> + u32 i, min_refcnt = U32_MAX, refcnt;
> + unsigned long flags;
> +
> + /* allocate PC with the minimun refcount */
^^^^^^^
typo
> +static int mtk_cqdma_probe(struct platform_device *pdev)
> +{
> + struct mtk_cqdma_device *cqdma;
> + struct mtk_cqdma_vchan *vc;
> + struct dma_device *dd;
> + struct resource *res;
> + int err;
> + u32 i;
> +
> + cqdma = devm_kzalloc(&pdev->dev, sizeof(*cqdma), GFP_KERNEL);
> + if (!cqdma)
> + return -ENOMEM;
> +
> + dd = &cqdma->ddev;
> +
> + cqdma->clk = devm_clk_get(&pdev->dev, "cqdma");
> + if (IS_ERR(cqdma->clk)) {
> + dev_err(&pdev->dev, "No clock for %s\n",
> + dev_name(&pdev->dev));
> + return PTR_ERR(cqdma->clk);
> + }
> +
> + dma_cap_set(DMA_MEMCPY, dd->cap_mask);
> +
> + dd->copy_align = MTK_CQDMA_ALIGN_SIZE;
> + dd->device_alloc_chan_resources = mtk_cqdma_alloc_chan_resources;
> + dd->device_free_chan_resources = mtk_cqdma_free_chan_resources;
> + dd->device_tx_status = mtk_cqdma_tx_status;
> + dd->device_issue_pending = mtk_cqdma_issue_pending;
> + dd->device_prep_dma_memcpy = mtk_cqdma_prep_dma_memcpy;
> + dd->device_terminate_all = mtk_cqdma_terminate_all;
> + dd->src_addr_widths = MTK_CQDMA_DMA_BUSWIDTHS;
> + dd->dst_addr_widths = MTK_CQDMA_DMA_BUSWIDTHS;
> + dd->directions = BIT(DMA_MEM_TO_MEM);
> + dd->residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
> + dd->dev = &pdev->dev;
> + INIT_LIST_HEAD(&dd->channels);
> +
> + if (pdev->dev.of_node && of_property_read_u32(pdev->dev.of_node,
> + "dma-requests",
> + &cqdma->dma_requests)) {
> + dev_info(&pdev->dev,
> + "Using %u as missing dma-requests property\n",
> + MTK_CQDMA_NR_VCHANS);
> +
> + cqdma->dma_requests = MTK_CQDMA_NR_VCHANS;
> + }
> +
> + if (pdev->dev.of_node && of_property_read_u32(pdev->dev.of_node,
> + "dma-channels",
> + &cqdma->dma_channels)) {
> + dev_info(&pdev->dev,
> + "Using %u as missing dma-channels property\n",
> + MTK_CQDMA_NR_PCHANS);
> +
> + cqdma->dma_channels = MTK_CQDMA_NR_PCHANS;
> + }
> +
> + cqdma->pc = devm_kcalloc(&pdev->dev, cqdma->dma_channels,
> + sizeof(*cqdma->pc), GFP_KERNEL);
> + if (!cqdma->pc)
> + return -ENOMEM;
> +
> + /* initialization for PCs */
> + for (i = 0; i < cqdma->dma_channels; ++i) {
> + cqdma->pc[i] = devm_kcalloc(&pdev->dev, 1,
> + sizeof(**cqdma->pc), GFP_KERNEL);
> + if (!cqdma->pc[i])
> + return -ENOMEM;
> +
> + INIT_LIST_HEAD(&cqdma->pc[i]->queue);
> + spin_lock_init(&cqdma->pc[i]->lock);
> + refcount_set(&cqdma->pc[i]->refcnt, 0);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, i);
> + if (!res) {
> + dev_err(&pdev->dev, "No mem resource for %s\n",
> + dev_name(&pdev->dev));
> + return -EINVAL;
> + }
> +
> + cqdma->pc[i]->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(cqdma->pc[i]->base))
> + return PTR_ERR(cqdma->pc[i]->base);
> +
> + /* allocate IRQ resource */
> + res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> + if (!res) {
> + dev_err(&pdev->dev, "No irq resource for %s\n",
> + dev_name(&pdev->dev));
> + return -EINVAL;
> + }
> + cqdma->pc[i]->irq = res->start;
> +
> + err = devm_request_irq(&pdev->dev, cqdma->pc[i]->irq,
> + mtk_cqdma_irq, 0, dev_name(&pdev->dev),
> + cqdma);
> + if (err) {
> + dev_err(&pdev->dev,
> + "request_irq failed with err %d\n", err);
> + return -EINVAL;
> + }
> + }
> +
> + /* allocate resource for VCs */
> + cqdma->vc = devm_kcalloc(&pdev->dev, cqdma->dma_requests,
> + sizeof(*cqdma->vc), GFP_KERNEL);
> + if (!cqdma->vc)
> + return -ENOMEM;
> +
> + for (i = 0; i < cqdma->dma_requests; i++) {
> + vc = &cqdma->vc[i];
> + vc->vc.desc_free = mtk_cqdma_vdesc_free;
> + vchan_init(&vc->vc, dd);
> + init_completion(&vc->issue_completion);
> + }
> +
> + err = dma_async_device_register(dd);
> + if (err)
> + return err;
> +
> + err = of_dma_controller_register(pdev->dev.of_node,
> + of_dma_xlate_by_chan_id, cqdma);
> + if (err) {
> + dev_err(&pdev->dev,
> + "MediaTek CQDMA OF registration failed %d\n", err);
> + goto err_unregister;
> + }
> +
> + err = mtk_cqdma_hw_init(cqdma);
> + if (err) {
> + dev_err(&pdev->dev,
> + "MediaTek CQDMA HW initialization failed %d\n", err);
> + goto err_unregister;
> + }
> +
> + platform_set_drvdata(pdev, cqdma);
> +
> + /* initialize tasklet for each PC */
> + for (i = 0; i < cqdma->dma_channels; ++i)
> + tasklet_init(&cqdma->pc[i]->tasklet, mtk_cqdma_tasklet_cb,
> + (unsigned long)cqdma->pc[i]);
> +
> + dev_info(&pdev->dev, "MediaTek CQDMA driver registered\n");
debug log please
> +static int mtk_cqdma_remove(struct platform_device *pdev)
> +{
> + struct mtk_cqdma_device *cqdma = platform_get_drvdata(pdev);
> + struct mtk_cqdma_vchan *vc;
> + unsigned long flags;
> + int i;
> +
> + /* kill VC task */
> + for (i = 0; i < cqdma->dma_requests; i++) {
> + vc = &cqdma->vc[i];
> +
> + list_del(&vc->vc.chan.device_node);
> + tasklet_kill(&vc->vc.task);
> + }
> +
> + /* disable interrupt */
> + for (i = 0; i < cqdma->dma_channels; i++) {
> + spin_lock_irqsave(&cqdma->pc[i]->lock, flags);
> + mtk_dma_clr(cqdma->pc[i], MTK_CQDMA_INT_EN,
> + MTK_CQDMA_INT_EN_BIT);
> + spin_unlock_irqrestore(&cqdma->pc[i]->lock, flags);
> +
> + /* Waits for any pending IRQ handlers to complete */
> + synchronize_irq(cqdma->pc[i]->irq);
> +
> + tasklet_kill(&cqdma->pc[i]->tasklet);
> + }
please kill VC tasks after this, they can still be fired while you are
disabling interrupt, so interrupt first and then tasklets
^ permalink raw reply
* [v2,2/4] dmaengine: xilinx_dma: Refactor axidma channel validation
From: Vinod Koul @ 2018-11-11 10:29 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: dan.j.williams, michal.simek, appana.durga.rao, dmaengine,
linux-arm-kernel, linux-kernel
On 29-09-18, 11:17, Radhey Shyam Pandey wrote:
> In axidma start_transfer, prefer checking channel states before
> other params i.e pending_list. No functional change.
There needs to be proper reason rather than a preference, can you
explain why
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
> ---
> Changes for v2:
> Modified the commit message to mark it as non-functional change.
> ---
> drivers/dma/xilinx/xilinx_dma.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 06d1632..a37871e 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1271,10 +1271,10 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> if (chan->err)
> return;
>
> - if (list_empty(&chan->pending_list))
> + if (!chan->idle)
> return;
>
> - if (!chan->idle)
> + if (list_empty(&chan->pending_list))
> return;
>
> head_desc = list_first_entry(&chan->pending_list,
> --
> 1.7.1
^ permalink raw reply
* [1/5] dmaengine: mmp_pdma: remove dma_slave_config direction usage
From: Vinod Koul @ 2018-11-11 15:47 UTC (permalink / raw)
To: dmaengine; +Cc: Vinod Koul
dma_slave_config direction was marked as deprecated quite some
time back, remove the usage from this driver so that the field
can be removed
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/mmp_pdma.c | 28 +++++++++++++++++++++++-----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index eb3a1f42ab06..334bab92d26d 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -96,6 +96,7 @@ struct mmp_pdma_chan {
struct dma_async_tx_descriptor desc;
struct mmp_pdma_phy *phy;
enum dma_transfer_direction dir;
+ struct dma_slave_config slave_config;
struct mmp_pdma_desc_sw *cyclic_first; /* first desc_sw if channel
* is in cyclic mode */
@@ -140,6 +141,10 @@ struct mmp_pdma_device {
#define to_mmp_pdma_dev(dmadev) \
container_of(dmadev, struct mmp_pdma_device, device)
+static int mmp_pdma_config_write(struct dma_chan *dchan,
+ struct dma_slave_config *cfg,
+ enum dma_transfer_direction direction);
+
static void set_desc(struct mmp_pdma_phy *phy, dma_addr_t addr)
{
u32 reg = (phy->idx << 4) + DDADR;
@@ -537,6 +542,8 @@ mmp_pdma_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
chan->byte_align = false;
+ mmp_pdma_config_write(dchan, &chan->slave_config, dir);
+
for_each_sg(sgl, sg, sg_len, i) {
addr = sg_dma_address(sg);
avail = sg_dma_len(sgl);
@@ -619,6 +626,7 @@ mmp_pdma_prep_dma_cyclic(struct dma_chan *dchan,
return NULL;
chan = to_mmp_pdma_chan(dchan);
+ mmp_pdma_config_write(dchan, &chan->slave_config, direction);
switch (direction) {
case DMA_MEM_TO_DEV:
@@ -684,8 +692,9 @@ mmp_pdma_prep_dma_cyclic(struct dma_chan *dchan,
return NULL;
}
-static int mmp_pdma_config(struct dma_chan *dchan,
- struct dma_slave_config *cfg)
+static int mmp_pdma_config_write(struct dma_chan *dchan,
+ struct dma_slave_config *cfg,
+ enum dma_transfer_direction direction)
{
struct mmp_pdma_chan *chan = to_mmp_pdma_chan(dchan);
u32 maxburst = 0, addr = 0;
@@ -694,12 +703,12 @@ static int mmp_pdma_config(struct dma_chan *dchan,
if (!dchan)
return -EINVAL;
- if (cfg->direction == DMA_DEV_TO_MEM) {
+ if (direction == DMA_DEV_TO_MEM) {
chan->dcmd = DCMD_INCTRGADDR | DCMD_FLOWSRC;
maxburst = cfg->src_maxburst;
width = cfg->src_addr_width;
addr = cfg->src_addr;
- } else if (cfg->direction == DMA_MEM_TO_DEV) {
+ } else if (direction == DMA_MEM_TO_DEV) {
chan->dcmd = DCMD_INCSRCADDR | DCMD_FLOWTRG;
maxburst = cfg->dst_maxburst;
width = cfg->dst_addr_width;
@@ -720,7 +729,7 @@ static int mmp_pdma_config(struct dma_chan *dchan,
else if (maxburst == 32)
chan->dcmd |= DCMD_BURST32;
- chan->dir = cfg->direction;
+ chan->dir = direction;
chan->dev_addr = addr;
/* FIXME: drivers should be ported over to use the filter
* function. Once that's done, the following two lines can
@@ -732,6 +741,15 @@ static int mmp_pdma_config(struct dma_chan *dchan,
return 0;
}
+static int mmp_pdma_config(struct dma_chan *dchan,
+ struct dma_slave_config *cfg)
+{
+ struct mmp_pdma_chan *chan = to_mmp_pdma_chan(dchan);
+
+ memcpy(&chan->slave_config, cfg, sizeof(*cfg));
+ return 0;
+}
+
static int mmp_pdma_terminate_all(struct dma_chan *dchan)
{
struct mmp_pdma_chan *chan = to_mmp_pdma_chan(dchan);
^ permalink raw reply related
* [2/5] dmaengine: sprd: remove dma_slave_config direction usage
From: Vinod Koul @ 2018-11-11 15:47 UTC (permalink / raw)
To: dmaengine; +Cc: Vinod Koul, Baolin Wang
dma_slave_config direction was marked as deprecated quite some
time back, remove the usage from this driver so that the field
can be removed
Signed-off-by: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/sprd-dma.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 38d4e4f07c66..c226dc93e401 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -847,9 +847,6 @@ static int sprd_dma_slave_config(struct dma_chan *chan,
struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
struct dma_slave_config *slave_cfg = &schan->slave_cfg;
- if (!is_slave_direction(config->direction))
- return -EINVAL;
-
memcpy(slave_cfg, config, sizeof(*config));
return 0;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox