* [v4,2/2] dmaengine: dw-dmac: implement dma protection control setting
From: Christian Lamparter @ 2018-11-17 16:17 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")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
I've included the "LGTM" from Andy from the v2 series and transformed
it into a reviewed-by tag.
---
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 d0c3e50b39fb..2c5ca1961256 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 f01b2c173fa6..31ff8113c3de 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..1a1d58ebffbf 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
* [v4,1/2] dt-bindings: dmaengine: dw-dmac: add protection control property
From: Christian Lamparter @ 2018-11-17 16:17 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>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
---
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 3bd775ba51ce..68327503fa94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14379,9 +14379,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,1/2] dt-bindings: dmaengine: dw-dmac: add protection control property
From: Christian Lamparter @ 2018-11-17 16:14 UTC (permalink / raw)
To: Rob Herring
Cc: dmaengine, devicetree, Dan Williams, Vinod Koul, Andy Shevchenko,
Viresh Kumar, Mark Rutland
On Saturday, November 17, 2018 4:32:47 PM CET Rob Herring wrote:
> On Sat, 10 Nov 2018 17:28:30 +0100, Christian Lamparter wrote:
> > 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
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
Ok, thanks.
I guess I did make the mistake of sending out v3 too soo it seems :).
Anyway, I'll add this tag real quick and sent out v4... As well as
update the v3 series status on patchwork.
Best Regards,
Christian
^ permalink raw reply
* [v2,1/2] dt-bindings: dmaengine: dw-dmac: add protection control property
From: Rob Herring @ 2018-11-17 15:32 UTC (permalink / raw)
To: Christian Lamparter
Cc: dmaengine, devicetree, Dan Williams, Vinod Koul, Andy Shevchenko,
Viresh Kumar, Mark Rutland
On Sat, 10 Nov 2018 17:28:30 +0100, Christian Lamparter wrote:
> 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
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [v3,2/2] dmaengine: dw-dmac: implement dma protection control setting
From: Christian Lamparter @ 2018-11-17 14:10 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")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
I've included the "LGTM" from Andy from the v2 series and transformed
it into a reviewed-by tag.
---
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 d0c3e50b39fb..2c5ca1961256 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 f01b2c173fa6..31ff8113c3de 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..1a1d58ebffbf 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
* [v3,1/2] dt-bindings: dmaengine: dw-dmac: add protection control property
From: Christian Lamparter @ 2018-11-17 14:10 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>
---
---
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 3bd775ba51ce..68327503fa94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14379,9 +14379,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
* dmaengine: fix dmaengine_desc_callback_valid() doesn't check for callback_result
From: Andrea Merello @ 2018-11-16 13:56 UTC (permalink / raw)
To: vkoul, dan.j.williams, dmaengine
Cc: linux-kernel, radhey.shyam.pandey, Andrea Merello
There are two flavors of DMA completion callbacks: callback() and
callback_result(); the latter takes an additional parameter that carries
result information.
Most dmaengine helper functions that work with callbacks take care of both
flavors i.e. dmaengine_desc_get_callback_invoke() first checks for
callback_result() to be not NULL, and eventually it calls this one;
otherwise it goes on checking for callback().
It seems however that dmaengine_desc_callback_valid() does not care about
callback_result(), and it returns false in case callback() is NULL but
callback_result() is not; unless there is a (hidden to me) reason for doing
so then I'd say this is wrong.
I've hit this by using a DMA controller driver (xilinx_dma) that doesn't
trigger any callback invocation unless dmaengine_desc_callback_valid()
returns true, while I had only callback_result() implemented in my client
driver (which AFAICT is always fine since dmaengine documentation says that
callback() will be deprecated).
This patch fixes this by making dmaengine_desc_callback_valid() to return
true in the said scenario.
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
drivers/dma/dmaengine.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
index 501c0b063f85..0ba2c1f3c55d 100644
--- a/drivers/dma/dmaengine.h
+++ b/drivers/dma/dmaengine.h
@@ -168,7 +168,7 @@ dmaengine_desc_get_callback_invoke(struct dma_async_tx_descriptor *tx,
static inline bool
dmaengine_desc_callback_valid(struct dmaengine_desc_callback *cb)
{
- return (cb->callback) ? true : false;
+ return (cb->callback || cb->callback_result);
}
#endif
^ permalink raw reply related
* [v1] dmaengine: stm32-dma: check FIFO error interrupt enable
From: Pierre Yves MORDRET @ 2018-11-16 12:49 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, Maxime Coquelin, Alexandre Torgue,
dmaengine, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Pierre-Yves MORDRET
For avoiding false FIFO detection, check FIFO Error interrupt is
enabled prior raising any errors.
This will prevent having spurious FIFO error where it shouldn't.
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
---
Version history:
v1:
* Initial
---
---
drivers/dma/stm32-dma.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 4903a40..48f7c0f 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -641,12 +641,13 @@ static irqreturn_t stm32_dma_chan_irq(int irq, void *devid)
{
struct stm32_dma_chan *chan = devid;
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
- u32 status, scr;
+ u32 status, scr, sfcr;
spin_lock(&chan->vchan.lock);
status = stm32_dma_irq_status(chan);
scr = stm32_dma_read(dmadev, STM32_DMA_SCR(chan->id));
+ sfcr = stm32_dma_read(dmadev, STM32_DMA_SFCR(chan->id));
if (status & STM32_DMA_TCI) {
stm32_dma_irq_clear(chan, STM32_DMA_TCI);
@@ -661,10 +662,12 @@ static irqreturn_t stm32_dma_chan_irq(int irq, void *devid)
if (status & STM32_DMA_FEI) {
stm32_dma_irq_clear(chan, STM32_DMA_FEI);
status &= ~STM32_DMA_FEI;
- if (!(scr & STM32_DMA_SCR_EN))
- dev_err(chan2dev(chan), "FIFO Error\n");
- else
- dev_dbg(chan2dev(chan), "FIFO over/underrun\n");
+ if (sfcr & STM32_DMA_SFCR_FEIE) {
+ if (!(scr & STM32_DMA_SCR_EN))
+ dev_err(chan2dev(chan), "FIFO Error\n");
+ else
+ dev_dbg(chan2dev(chan), "FIFO over/underrun\n");
+ }
}
if (status) {
stm32_dma_irq_clear(chan, status);
^ permalink raw reply related
* [v1,3/3] dmaengine: stm32-mdma: Add PM Runtime support
From: Pierre Yves MORDRET @ 2018-11-16 12:48 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, Maxime Coquelin, Alexandre Torgue,
dmaengine, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Pierre-Yves MORDRET
Use pm_runtime engine for clock management purpose
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
---
Version history:
v1:
* Initial
---
---
drivers/dma/stm32-mdma.c | 52 ++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/stm32-mdma.c b/drivers/dma/stm32-mdma.c
index 390e4ca..ac0301b 100644
--- a/drivers/dma/stm32-mdma.c
+++ b/drivers/dma/stm32-mdma.c
@@ -37,6 +37,7 @@
#include <linux/of_device.h>
#include <linux/of_dma.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include <linux/slab.h>
@@ -1456,15 +1457,13 @@ static int stm32_mdma_alloc_chan_resources(struct dma_chan *c)
return -ENOMEM;
}
- ret = clk_prepare_enable(dmadev->clk);
- if (ret < 0) {
- dev_err(chan2dev(chan), "clk_prepare_enable failed: %d\n", ret);
+ ret = pm_runtime_get_sync(dmadev->ddev.dev);
+ if (ret < 0)
return ret;
- }
ret = stm32_mdma_disable_chan(chan);
if (ret < 0)
- clk_disable_unprepare(dmadev->clk);
+ pm_runtime_put(dmadev->ddev.dev);
return ret;
}
@@ -1484,7 +1483,7 @@ static void stm32_mdma_free_chan_resources(struct dma_chan *c)
spin_unlock_irqrestore(&chan->vchan.lock, flags);
}
- clk_disable_unprepare(dmadev->clk);
+ pm_runtime_put(dmadev->ddev.dev);
vchan_free_chan_resources(to_virt_chan(c));
dmam_pool_destroy(chan->desc_pool);
chan->desc_pool = NULL;
@@ -1597,6 +1596,12 @@ static int stm32_mdma_probe(struct platform_device *pdev)
return ret;
}
+ ret = clk_prepare_enable(dmadev->clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "clk_prep_enable error: %d\n", ret);
+ return ret;
+ }
+
dmadev->rst = devm_reset_control_get(&pdev->dev, NULL);
if (!IS_ERR(dmadev->rst)) {
reset_control_assert(dmadev->rst);
@@ -1668,6 +1673,10 @@ static int stm32_mdma_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, dmadev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_put(&pdev->dev);
dev_info(&pdev->dev, "STM32 MDMA driver registered\n");
@@ -1677,11 +1686,42 @@ static int stm32_mdma_probe(struct platform_device *pdev)
return ret;
}
+#ifdef CONFIG_PM
+static int stm32_mdma_runtime_suspend(struct device *dev)
+{
+ struct stm32_mdma_device *dmadev = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(dmadev->clk);
+
+ return 0;
+}
+
+static int stm32_mdma_runtime_resume(struct device *dev)
+{
+ struct stm32_mdma_device *dmadev = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(dmadev->clk);
+ if (ret) {
+ dev_err(dev, "failed to prepare_enable clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops stm32_mdma_pm_ops = {
+ SET_RUNTIME_PM_OPS(stm32_mdma_runtime_suspend,
+ stm32_mdma_runtime_resume, NULL)
+};
+
static struct platform_driver stm32_mdma_driver = {
.probe = stm32_mdma_probe,
.driver = {
.name = "stm32-mdma",
.of_match_table = stm32_mdma_of_match,
+ .pm = &stm32_mdma_pm_ops,
},
};
^ permalink raw reply related
* [v1,2/3] dmaengine: stm32-dmamux: Add PM Runtime support
From: Pierre Yves MORDRET @ 2018-11-16 12:48 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, Maxime Coquelin, Alexandre Torgue,
dmaengine, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Pierre-Yves MORDRET
Use pm_runtime engine for clock management purpose.
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
---
Version history:
v1:
* Initial
---
---
drivers/dma/stm32-dmamux.c | 58 +++++++++++++++++++++++++++++++++++++---------
1 file changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c
index b922db9..a671191 100644
--- a/drivers/dma/stm32-dmamux.c
+++ b/drivers/dma/stm32-dmamux.c
@@ -28,6 +28,7 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/of_dma.h>
+#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -79,8 +80,7 @@ static void stm32_dmamux_free(struct device *dev, void *route_data)
stm32_dmamux_write(dmamux->iomem, STM32_DMAMUX_CCR(mux->chan_id), 0);
clear_bit(mux->chan_id, dmamux->dma_inuse);
- if (!IS_ERR(dmamux->clk))
- clk_disable(dmamux->clk);
+ pm_runtime_put_sync(dev);
spin_unlock_irqrestore(&dmamux->lock, flags);
@@ -146,13 +146,10 @@ static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec,
/* Set dma request */
spin_lock_irqsave(&dmamux->lock, flags);
- if (!IS_ERR(dmamux->clk)) {
- ret = clk_enable(dmamux->clk);
- if (ret < 0) {
- spin_unlock_irqrestore(&dmamux->lock, flags);
- dev_err(&pdev->dev, "clk_prep_enable issue: %d\n", ret);
- goto error;
- }
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0) {
+ spin_unlock_irqrestore(&dmamux->lock, flags);
+ goto error;
}
spin_unlock_irqrestore(&dmamux->lock, flags);
@@ -254,6 +251,7 @@ static int stm32_dmamux_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "DMAMUX defaulting on %u requests\n",
stm32_dmamux->dmamux_requests);
}
+ pm_runtime_get_noresume(&pdev->dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
iomem = devm_ioremap_resource(&pdev->dev, res);
@@ -282,6 +280,8 @@ static int stm32_dmamux_probe(struct platform_device *pdev)
stm32_dmamux->dmarouter.route_free = stm32_dmamux_free;
platform_set_drvdata(pdev, stm32_dmamux);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
if (!IS_ERR(stm32_dmamux->clk)) {
ret = clk_prepare_enable(stm32_dmamux->clk);
@@ -291,17 +291,52 @@ static int stm32_dmamux_probe(struct platform_device *pdev)
}
}
+ pm_runtime_get_noresume(&pdev->dev);
+
/* Reset the dmamux */
for (i = 0; i < stm32_dmamux->dma_requests; i++)
stm32_dmamux_write(stm32_dmamux->iomem, STM32_DMAMUX_CCR(i), 0);
- if (!IS_ERR(stm32_dmamux->clk))
- clk_disable(stm32_dmamux->clk);
+ pm_runtime_put(&pdev->dev);
return of_dma_router_register(node, stm32_dmamux_route_allocate,
&stm32_dmamux->dmarouter);
}
+#ifdef CONFIG_PM
+static int stm32_dmamux_runtime_suspend(struct device *dev)
+{
+ struct platform_device *pdev =
+ container_of(dev, struct platform_device, dev);
+ struct stm32_dmamux_data *stm32_dmamux = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(stm32_dmamux->clk);
+
+ return 0;
+}
+
+static int stm32_dmamux_runtime_resume(struct device *dev)
+{
+ struct platform_device *pdev =
+ container_of(dev, struct platform_device, dev);
+ struct stm32_dmamux_data *stm32_dmamux = platform_get_drvdata(pdev);
+ int ret;
+
+ ret = clk_prepare_enable(stm32_dmamux->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to prepare_enable clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops stm32_dmamux_pm_ops = {
+ SET_RUNTIME_PM_OPS(stm32_dmamux_runtime_suspend,
+ stm32_dmamux_runtime_resume, NULL)
+};
+
static const struct of_device_id stm32_dmamux_match[] = {
{ .compatible = "st,stm32h7-dmamux" },
{},
@@ -312,6 +347,7 @@ static struct platform_driver stm32_dmamux_driver = {
.driver = {
.name = "stm32-dmamux",
.of_match_table = stm32_dmamux_match,
+ .pm = &stm32_dmamux_pm_ops,
},
};
^ permalink raw reply related
* [v1,1/3] dmaengine: stm32-dma: Add PM Runtime support
From: Pierre Yves MORDRET @ 2018-11-16 12:48 UTC (permalink / raw)
To: Dan Williams, Vinod Koul, Maxime Coquelin, Alexandre Torgue,
dmaengine, linux-stm32, linux-arm-kernel, linux-kernel
Cc: Pierre-Yves MORDRET
Use pm_runtime engine for clock management purpose.
Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
---
Version history:
v1:
* Initial
---
---
drivers/dma/stm32-dma.c | 58 +++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 51 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 48f7c0f..ba239b5 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -23,6 +23,7 @@
#include <linux/of_device.h>
#include <linux/of_dma.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
#include <linux/reset.h>
#include <linux/sched.h>
#include <linux/slab.h>
@@ -1115,15 +1116,14 @@ static int stm32_dma_alloc_chan_resources(struct dma_chan *c)
int ret;
chan->config_init = false;
- ret = clk_prepare_enable(dmadev->clk);
- if (ret < 0) {
- dev_err(chan2dev(chan), "clk_prepare_enable failed: %d\n", ret);
+
+ ret = pm_runtime_get_sync(dmadev->ddev.dev);
+ if (ret < 0)
return ret;
- }
ret = stm32_dma_disable_chan(chan);
if (ret < 0)
- clk_disable_unprepare(dmadev->clk);
+ pm_runtime_put(dmadev->ddev.dev);
return ret;
}
@@ -1143,7 +1143,7 @@ static void stm32_dma_free_chan_resources(struct dma_chan *c)
spin_unlock_irqrestore(&chan->vchan.lock, flags);
}
- clk_disable_unprepare(dmadev->clk);
+ pm_runtime_put(dmadev->ddev.dev);
vchan_free_chan_resources(to_virt_chan(c));
}
@@ -1243,6 +1243,12 @@ static int stm32_dma_probe(struct platform_device *pdev)
return PTR_ERR(dmadev->clk);
}
+ ret = clk_prepare_enable(dmadev->clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "clk_prep_enable error: %d\n", ret);
+ return ret;
+ }
+
dmadev->mem2mem = of_property_read_bool(pdev->dev.of_node,
"st,mem2mem");
@@ -1292,7 +1298,7 @@ static int stm32_dma_probe(struct platform_device *pdev)
ret = dma_async_device_register(dd);
if (ret)
- return ret;
+ goto clk_free;
for (i = 0; i < STM32_DMA_MAX_CHANNELS; i++) {
chan = &dmadev->chan[i];
@@ -1324,20 +1330,58 @@ static int stm32_dma_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dmadev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_put(&pdev->dev);
+
dev_info(&pdev->dev, "STM32 DMA driver registered\n");
return 0;
err_unregister:
dma_async_device_unregister(dd);
+clk_free:
+ clk_disable_unprepare(dmadev->clk);
return ret;
}
+#ifdef CONFIG_PM
+static int stm32_dma_runtime_suspend(struct device *dev)
+{
+ struct stm32_dma_device *dmadev = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(dmadev->clk);
+
+ return 0;
+}
+
+static int stm32_dma_runtime_resume(struct device *dev)
+{
+ struct stm32_dma_device *dmadev = dev_get_drvdata(dev);
+ int ret;
+
+ ret = clk_prepare_enable(dmadev->clk);
+ if (ret) {
+ dev_err(dev, "failed to prepare_enable clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops stm32_dma_pm_ops = {
+ SET_RUNTIME_PM_OPS(stm32_dma_runtime_suspend,
+ stm32_dma_runtime_resume, NULL)
+};
+
static struct platform_driver stm32_dma_driver = {
.driver = {
.name = "stm32-dma",
.of_match_table = stm32_dma_of_match,
+ .pm = &stm32_dma_pm_ops,
},
};
^ permalink raw reply related
* [5/5] dmaengine: ste_dma40: remove dma_slave_config direction usage
From: Linus Walleij @ 2018-11-15 14:53 UTC (permalink / raw)
To: vkoul; +Cc: dmaengine
On Sun, Nov 11, 2018 at 4:47 PM Vinod Koul <vkoul@kernel.org> wrote:
> 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>
Looks clean and nice:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Sorry for not fixing it up myself :/
Yours,
Linus Walleij
^ permalink raw reply
* [resend] dt-bindings: dmaengine: usb-dmac: Add binding for r8a774a1
From: Fabrizio Castro @ 2018-11-15 11:59 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland
Cc: Biju Das, dmaengine, devicetree, Simon Horman, Geert Uytterhoeven,
Chris Paterson, Fabrizio Castro, linux-renesas-soc
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>
Acked-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Rob Herring <robh@kernel.org>
---
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 a1e7b814..5e2c7e8 100644
--- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
+++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.txt
@@ -7,6 +7,7 @@ Required Properties:
- "renesas,r8a7744-usb-dmac" (RZ/G1N)
- "renesas,r8a7745-usb-dmac" (RZ/G1E)
- "renesas,r8a77470-usb-dmac" (RZ/G1C)
+ - "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)
^ permalink raw reply related
* [resend] dmaengine: rcar-dmac: Document R8A774A1 bindings
From: Fabrizio Castro @ 2018-11-15 11:58 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Mark Rutland
Cc: Fabrizio Castro, dmaengine, devicetree, Simon Horman,
Geert Uytterhoeven, Chris Paterson, Biju Das, linux-renesas-soc
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>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
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 a5a7c3f..cdf32b2 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.
@@ -20,6 +20,7 @@ Required Properties:
- "renesas,dmac-r8a7744" (RZ/G1N)
- "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)
^ permalink raw reply related
* [v2,2/4] dmaengine: xilinx_dma: Refactor axidma channel validation
From: Radhey Shyam Pandey @ 2018-11-15 2:57 UTC (permalink / raw)
To: Vinod Koul
Cc: dan.j.williams@intel.com, Michal Simek,
Appana Durga Kedareswara Rao, dmaengine@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
> -----Original Message-----
> From: Vinod Koul <vkoul@kernel.org>
> Sent: Sunday, November 11, 2018 2:30 AM
> To: Radhey Shyam Pandey <radheys@xilinx.com>
> Cc: dan.j.williams@intel.com; Michal Simek <michals@xilinx.com>; Appana
> Durga Kedareswara Rao <appanad@xilinx.com>; dmaengine@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/4] dmaengine: xilinx_dma: Refactor axidma channel
> validation
>
> 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
Initially, I thought to group channel states check before checking
pending_list. It came up in doing diff with xilinx tree and mainline
tree. But agree it's not of significant importance and can be dropped.
>
> >
> > 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
>
> --
> ~Vinod
^ permalink raw reply
* Applied "spi: bcm2835: make license text and module license match" to the spi tree
From: Mark Brown @ 2018-11-14 22:27 UTC (permalink / raw)
To: Stefan Wahren
Cc: Florian Kauer, Martin Sperl, Mark Brown, Florian Meier,
Chris Boot
The patch
spi: bcm2835: make license text and module license match
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 22bf6cd2ca4df283812a521d3cb534993072cd44 Mon Sep 17 00:00:00 2001
From: Stefan Wahren <stefan.wahren@i2se.com>
Date: Tue, 23 Oct 2018 13:06:08 +0200
Subject: [PATCH] spi: bcm2835: make license text and module license match
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.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Florian Kauer <florian.kauer@koalo.de>
Acked-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-bcm2835.c | 2 +-
drivers/spi/spi-bcm2835aux.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index f35cc10772f6..b0b87ff936c7 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -843,4 +843,4 @@ module_platform_driver(bcm2835_spi_driver);
MODULE_DESCRIPTION("SPI controller driver for Broadcom BCM2835");
MODULE_AUTHOR("Chris Boot <bootc@bootc.net>");
-MODULE_LICENSE("GPL v2");
+MODULE_LICENSE("GPL");
diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index 3094d818cf06..671e374e1b01 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -542,4 +542,4 @@ module_platform_driver(bcm2835aux_spi_driver);
MODULE_DESCRIPTION("SPI controller driver for Broadcom BCM2835 aux");
MODULE_AUTHOR("Martin Sperl <kernel@martin.sperl.org>");
-MODULE_LICENSE("GPL v2");
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* [1/3] dma: tegra: avoid overflow of byte tracking
From: Ben Dooks @ 2018-11-14 14:23 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: dan.j.williams, vkoul, ldewangan, dmaengine, linux-tegra
On 2018-11-14 12:12, Dmitry Osipenko wrote:
> On 14.11.2018 13:13, Ben Dooks wrote:
>> The dma_desc->bytes_transferred counter tracks the number of bytes
>> moved by the DMA channel. This is then used to calculate the
>> information
>> passed back in the in the tegra_dma_tx_status callback, which is
>> usually
>> fine.
>>
>> When the DMA channel is configured as continous, then the
>> bytes_transferred
>> counter will increase over time and eventually overflow to become
>> negative
>> so the residue count will become invalid and the ALSA sound-dma code
>> will
>> report invalid hardware pointer values to the application. This
>> results in
>> some users becoming confused about the playout position and putting
>> audio
>> data in the wrong place.
>>
>> To fix this issue, always ensure the bytes_transferred field is modulo
>> the
>> size of the request. We only do this for the case of the cyclic
>> transfer
>> done ISR as anyone attempting to move 2GiB of DMA data in one transfer
>> is unlikely.
>>
>> Note, we don't fix the issue that we should /never/ transfer a
>> negative
>> number of bytes so we could make those fields unsigned.
>>
>> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> ---
>> drivers/dma/tegra20-apb-dma.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/tegra20-apb-dma.c
>> b/drivers/dma/tegra20-apb-dma.c
>> index 9a558e30c461..8219ab88a507 100644
>> --- a/drivers/dma/tegra20-apb-dma.c
>> +++ b/drivers/dma/tegra20-apb-dma.c
>> @@ -636,7 +636,10 @@ static void
>> handle_cont_sngl_cycle_dma_done(struct tegra_dma_channel *tdc,
>>
>> sgreq = list_first_entry(&tdc->pending_sg_req, typeof(*sgreq),
>> node);
>> dma_desc = sgreq->dma_desc;
>> - dma_desc->bytes_transferred += sgreq->req_len;
>> + /* if we dma for long enough the transfer count will wrap */
>> + dma_desc->bytes_transferred =
>> + (dma_desc->bytes_transferred + sgreq->req_len) %
>> + dma_desc->bytes_requested;
>>
>> /* Callback need to be call */
>> if (!dma_desc->cb_count)
>>
>
> I also actually tested that audio playback breaks after the overflow
> and this patch fixes it.
Thanks, I should have posted a link to a test-patch I had
a while ago.
> Tested-by: Dmitry Osipenko <digetx@gmail.com>
^ permalink raw reply
* dma: coh901318: Fix a double-lock bug
From: Linus Walleij @ 2018-11-14 13:36 UTC (permalink / raw)
To: baijiaju1990
Cc: vkoul, Dan Williams, Linux ARM, dmaengine,
linux-kernel@vger.kernel.org
On Tue, Nov 6, 2018 at 4:33 AM Jia-Ju Bai <baijiaju1990@gmail.com> wrote:
> The function coh901318_alloc_chan_resources() calls spin_lock_irqsave()
> before calling coh901318_config().
> But coh901318_config() calls spin_lock_irqsave() again in its
> definition, which may cause a double-lock bug.
>
> Because coh901318_config() is only called by
> coh901318_alloc_chan_resources(), the bug fix is to remove the
> calls to spin-lock and -unlock functions in coh901318_config().
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [2/3] dma: tegra: make byte counters unsigned int
From: Dmitry Osipenko @ 2018-11-14 12:13 UTC (permalink / raw)
To: Ben Dooks, dan.j.williams, vkoul; +Cc: ldewangan, dmaengine, linux-tegra
On 14.11.2018 13:13, Ben Dooks wrote:
> The buffer byte request length and counter are declared as signed integers
> but the values should never be below zero, so make these unsigned integers
> instead.
>
> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
> drivers/dma/tegra20-apb-dma.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index 8219ab88a507..adfd918baedc 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -155,7 +155,7 @@ struct tegra_dma_channel_regs {
> */
> struct tegra_dma_sg_req {
> struct tegra_dma_channel_regs ch_regs;
> - int req_len;
> + unsigned int req_len;
> bool configured;
> bool last_sg;
> struct list_head node;
> @@ -169,8 +169,8 @@ struct tegra_dma_sg_req {
> */
> struct tegra_dma_desc {
> struct dma_async_tx_descriptor txd;
> - int bytes_requested;
> - int bytes_transferred;
> + unsigned int bytes_requested;
> + unsigned int bytes_transferred;
> enum dma_status dma_status;
> struct list_head node;
> struct list_head tx_list;
>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
^ permalink raw reply
* [1/3] dma: tegra: avoid overflow of byte tracking
From: Dmitry Osipenko @ 2018-11-14 12:12 UTC (permalink / raw)
To: Ben Dooks, dan.j.williams, vkoul; +Cc: ldewangan, dmaengine, linux-tegra
On 14.11.2018 13:13, Ben Dooks wrote:
> The dma_desc->bytes_transferred counter tracks the number of bytes
> moved by the DMA channel. This is then used to calculate the information
> passed back in the in the tegra_dma_tx_status callback, which is usually
> fine.
>
> When the DMA channel is configured as continous, then the bytes_transferred
> counter will increase over time and eventually overflow to become negative
> so the residue count will become invalid and the ALSA sound-dma code will
> report invalid hardware pointer values to the application. This results in
> some users becoming confused about the playout position and putting audio
> data in the wrong place.
>
> To fix this issue, always ensure the bytes_transferred field is modulo the
> size of the request. We only do this for the case of the cyclic transfer
> done ISR as anyone attempting to move 2GiB of DMA data in one transfer
> is unlikely.
>
> Note, we don't fix the issue that we should /never/ transfer a negative
> number of bytes so we could make those fields unsigned.
>
> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> ---
> drivers/dma/tegra20-apb-dma.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index 9a558e30c461..8219ab88a507 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -636,7 +636,10 @@ static void handle_cont_sngl_cycle_dma_done(struct tegra_dma_channel *tdc,
>
> sgreq = list_first_entry(&tdc->pending_sg_req, typeof(*sgreq), node);
> dma_desc = sgreq->dma_desc;
> - dma_desc->bytes_transferred += sgreq->req_len;
> + /* if we dma for long enough the transfer count will wrap */
> + dma_desc->bytes_transferred =
> + (dma_desc->bytes_transferred + sgreq->req_len) %
> + dma_desc->bytes_requested;
>
> /* Callback need to be call */
> if (!dma_desc->cb_count)
>
I also actually tested that audio playback breaks after the overflow and this patch fixes it.
Tested-by: Dmitry Osipenko <digetx@gmail.com>
^ permalink raw reply
* [3/3] dma: tegra: fix incorrect case of DMA
From: Ben Dooks @ 2018-11-14 10:13 UTC (permalink / raw)
To: dan.j.williams, vkoul
Cc: ldewangan, dmaengine, linux-tegra, digetx, Ben Dooks
The use of Dma is annoying, since it is an acronym so should be all
upper case. Fix this throughout the driver.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
Fixes since v1:
- Missing cases fixed as pointed out by Dmitry Osipenko
---
drivers/dma/tegra20-apb-dma.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index adfd918baedc..ec8938a2ecab 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -146,7 +146,7 @@ struct tegra_dma_channel_regs {
};
/*
- * tegra_dma_sg_req: Dma request details to configure hardware. This
+ * tegra_dma_sg_req: DMA request details to configure hardware. This
* contains the details for one transfer to configure DMA hw.
* The client's request for data transfer can be broken into multiple
* sub-transfer as per requester details and hw support.
@@ -574,7 +574,7 @@ static bool handle_continuous_head_request(struct tegra_dma_channel *tdc,
struct tegra_dma_sg_req *hsgreq = NULL;
if (list_empty(&tdc->pending_sg_req)) {
- dev_err(tdc2dev(tdc), "Dma is running without req\n");
+ dev_err(tdc2dev(tdc), "DMA is running without req\n");
tegra_dma_stop(tdc);
return false;
}
@@ -587,7 +587,7 @@ static bool handle_continuous_head_request(struct tegra_dma_channel *tdc,
hsgreq = list_first_entry(&tdc->pending_sg_req, typeof(*hsgreq), node);
if (!hsgreq->configured) {
tegra_dma_stop(tdc);
- dev_err(tdc2dev(tdc), "Error in dma transfer, aborting dma\n");
+ dev_err(tdc2dev(tdc), "Error in DMA transfer, aborting DMA\n");
tegra_dma_abort_all(tdc);
return false;
}
@@ -922,7 +922,7 @@ static int get_transfer_param(struct tegra_dma_channel *tdc,
return 0;
default:
- dev_err(tdc2dev(tdc), "Dma direction is not supported\n");
+ dev_err(tdc2dev(tdc), "DMA direction is not supported\n");
return -EINVAL;
}
return -EINVAL;
@@ -955,7 +955,7 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_slave_sg(
enum dma_slave_buswidth slave_bw;
if (!tdc->config_init) {
- dev_err(tdc2dev(tdc), "dma channel is not configured\n");
+ dev_err(tdc2dev(tdc), "DMA channel is not configured\n");
return NULL;
}
if (sg_len < 1) {
@@ -988,7 +988,7 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_slave_sg(
dma_desc = tegra_dma_desc_get(tdc);
if (!dma_desc) {
- dev_err(tdc2dev(tdc), "Dma descriptors not available\n");
+ dev_err(tdc2dev(tdc), "DMA descriptors not available\n");
return NULL;
}
INIT_LIST_HEAD(&dma_desc->tx_list);
@@ -1008,14 +1008,14 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_slave_sg(
if ((len & 3) || (mem & 3) ||
(len > tdc->tdma->chip_data->max_dma_count)) {
dev_err(tdc2dev(tdc),
- "Dma length/memory address is not supported\n");
+ "DMA length/memory address is not supported\n");
tegra_dma_desc_put(tdc, dma_desc);
return NULL;
}
sg_req = tegra_dma_sg_req_get(tdc);
if (!sg_req) {
- dev_err(tdc2dev(tdc), "Dma sg-req not available\n");
+ dev_err(tdc2dev(tdc), "DMA sg-req not available\n");
tegra_dma_desc_put(tdc, dma_desc);
return NULL;
}
@@ -1090,7 +1090,7 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic(
* terminating the DMA.
*/
if (tdc->busy) {
- dev_err(tdc2dev(tdc), "Request not allowed when dma running\n");
+ dev_err(tdc2dev(tdc), "Request not allowed when DMA running\n");
return NULL;
}
@@ -1147,7 +1147,7 @@ static struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic(
while (remain_len) {
sg_req = tegra_dma_sg_req_get(tdc);
if (!sg_req) {
- dev_err(tdc2dev(tdc), "Dma sg-req not available\n");
+ dev_err(tdc2dev(tdc), "DMA sg-req not available\n");
tegra_dma_desc_put(tdc, dma_desc);
return NULL;
}
^ permalink raw reply related
* [2/3] dma: tegra: make byte counters unsigned int
From: Ben Dooks @ 2018-11-14 10:13 UTC (permalink / raw)
To: dan.j.williams, vkoul
Cc: ldewangan, dmaengine, linux-tegra, digetx, Ben Dooks
The buffer byte request length and counter are declared as signed integers
but the values should never be below zero, so make these unsigned integers
instead.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/dma/tegra20-apb-dma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 8219ab88a507..adfd918baedc 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -155,7 +155,7 @@ struct tegra_dma_channel_regs {
*/
struct tegra_dma_sg_req {
struct tegra_dma_channel_regs ch_regs;
- int req_len;
+ unsigned int req_len;
bool configured;
bool last_sg;
struct list_head node;
@@ -169,8 +169,8 @@ struct tegra_dma_sg_req {
*/
struct tegra_dma_desc {
struct dma_async_tx_descriptor txd;
- int bytes_requested;
- int bytes_transferred;
+ unsigned int bytes_requested;
+ unsigned int bytes_transferred;
enum dma_status dma_status;
struct list_head node;
struct list_head tx_list;
^ permalink raw reply related
* [1/3] dma: tegra: avoid overflow of byte tracking
From: Ben Dooks @ 2018-11-14 10:13 UTC (permalink / raw)
To: dan.j.williams, vkoul
Cc: ldewangan, dmaengine, linux-tegra, digetx, Ben Dooks
The dma_desc->bytes_transferred counter tracks the number of bytes
moved by the DMA channel. This is then used to calculate the information
passed back in the in the tegra_dma_tx_status callback, which is usually
fine.
When the DMA channel is configured as continous, then the bytes_transferred
counter will increase over time and eventually overflow to become negative
so the residue count will become invalid and the ALSA sound-dma code will
report invalid hardware pointer values to the application. This results in
some users becoming confused about the playout position and putting audio
data in the wrong place.
To fix this issue, always ensure the bytes_transferred field is modulo the
size of the request. We only do this for the case of the cyclic transfer
done ISR as anyone attempting to move 2GiB of DMA data in one transfer
is unlikely.
Note, we don't fix the issue that we should /never/ transfer a negative
number of bytes so we could make those fields unsigned.
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
drivers/dma/tegra20-apb-dma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 9a558e30c461..8219ab88a507 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -636,7 +636,10 @@ static void handle_cont_sngl_cycle_dma_done(struct tegra_dma_channel *tdc,
sgreq = list_first_entry(&tdc->pending_sg_req, typeof(*sgreq), node);
dma_desc = sgreq->dma_desc;
- dma_desc->bytes_transferred += sgreq->req_len;
+ /* if we dma for long enough the transfer count will wrap */
+ dma_desc->bytes_transferred =
+ (dma_desc->bytes_transferred + sgreq->req_len) %
+ dma_desc->bytes_requested;
/* Callback need to be call */
if (!dma_desc->cb_count)
^ permalink raw reply related
* [PATCH/RFC] dmaengine: sh: Remove R-Mobile APE6 support
From: Geert Uytterhoeven @ 2018-11-13 22:08 UTC (permalink / raw)
To: Rob Landley
Cc: Geert Uytterhoeven, Vinod, Dan Williams, Guennadi Liakhovetski,
Laurent Pinchart, Wolfram Sang, Simon Horman, Magnus Damm,
dmaengine, Linux-Renesas, Richard Weinberger, Yoshinori Sato,
Linux-sh list
Hi Rob,
On Tue, Nov 13, 2018 at 8:32 PM Rob Landley <rob@landley.net> wrote:
> On 11/12/18 9:30 AM, Geert Uytterhoeven wrote:
> > CC SuperH
> >
> > On Mon, Nov 12, 2018 at 4:22 PM Geert Uytterhoeven
> > <geert+renesas@glider.be> wrote:
> >> Renesas R-Mobile APE6 support is currently unused:
> >> - DMA slaves were never enabled in r8a73a4.dtsi,
> >> - The driver relies on legacy filter matching and describing all
> >> slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
> >> similar hardware like rcar-dmac,
> >> - The driver doesn't seem to work well.
> >>
> >> Remove the driver, it can be resurrected from git history when needed.
> >>
> >> As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
> >> sh-dma-engine driver core is now used on SuperH only.
>
> I'm trying to add dma support to smc91x on an sh7760 board:
>
> https://www.spinics.net/lists/linux-sh/msg53400.html
>
> I missed the ship window for the previous iteration so we had to use PIO, but
> DMA's a huge speedup and it's cycling back around on my todo list...
>
> Unfortunately due to a flash corruption bug we were stuck at 4.14 for that
> release. I'm trying to track that down now, then need to redo this work on top
> of 4.20 or 4.21.
>
> Kernel board support patches are at the lawyers being frowned at expensively
> before release, but it won't include DMA this time because I only got the first
> half of it working. (Board's hooked up and can do memory-to-memory, but the
> ethernet card couldn't use it because the smc91x claims of using dmaengine are
> lies, it's hardwired to a specific arm chip ("mainstone" I think?), and when I
> got QEMU to emulate that ARM board and tried to enable DMA: packet timeouts. I
> dunno if it's broken in the kernel or QEMU doesn't emulate the DMA...)
>
> >> Notes:
> >> 1. As Renesas ARM SoCs no longer use drivers/dma/sh/shdma-base.c, the
> >> task to remove use of the deprecated dma_slave_config.direction
> >> field gets thrown into the SuperH maintainers' basket ;-)
>
> At least in 4.14 there were two DMA apis, once of which is obsolete and unused,
> and the other is modern dmaengine support which at least passes its self-test.
>
> I left off boggling at the "slave API", I think...
Yes, there's SH_DMA_API and the "new" DMA_ENGINE API.
> >> 3. I tried to get SCIFA DMA to work by:
> >> - Applying the DT and driver patches below,
> >> - Reverting 219fb0c1436e4893 ("serial: sh-sci: Remove the
> >> platform data dma slave rx/tx channel IDs").
>
> The board I'm using is platform data, never got converted to device tree. (If I
> can ever convince them to mail a board to Rich Felker I might try to hire him to
> convert it _myself_. Or I could just get him an old board on ebay, current
> cheapest one looks like
> https://www.ebay.com/p/Johnson-Controls-Ms-nae3511-2-Metasys-Controller-NAE-and-2x-Unt1108/567230953?iid=283254042308
> at the moment? Dead battery's fine for a dev/test system...)
>
> But it's not happening this month.
>
> >> After that, serial console output using DMA seems to work, but the
> >> system locks up when receiving any serial console input.
> >> Probably it is easier to add r8a73a4 support to rcar-dmac.
>
> What _is_ the status of dmaengine? I thought it was the generic dma API the
> kernel was moving towards? (The youtube videos suggested such...)
Dmaengine is working on the Renesas R-Car Gen2 and Gen3 SoCs, using
rcar-dmac and usb-dmac. But that's ARM (32/64-bit), not SuperH.
I'm afraid you're on your own on SuperH... Good luck!
Gr{oetje,eeting}s,
Geert
---
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH/RFC] dmaengine: sh: Remove R-Mobile APE6 support
From: Rob Landley @ 2018-11-13 19:32 UTC (permalink / raw)
To: Geert Uytterhoeven, Geert Uytterhoeven
Cc: Vinod, Dan Williams, Guennadi Liakhovetski, Laurent Pinchart,
Wolfram Sang, Simon Horman, Magnus Damm, dmaengine, Linux-Renesas,
Richard Weinberger, Yoshinori Sato, Linux-sh list
On 11/12/18 9:30 AM, Geert Uytterhoeven wrote:
> CC SuperH
>
> On Mon, Nov 12, 2018 at 4:22 PM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Renesas R-Mobile APE6 support is currently unused:
>> - DMA slaves were never enabled in r8a73a4.dtsi,
>> - The driver relies on legacy filter matching and describing all
>> slaves and MID/RIDs in a table, unlike modern DMA engine drivers for
>> similar hardware like rcar-dmac,
>> - The driver doesn't seem to work well.
>>
>> Remove the driver, it can be resurrected from git history when needed.
>>
>> As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the
>> sh-dma-engine driver core is now used on SuperH only.
I'm trying to add dma support to smc91x on an sh7760 board:
https://www.spinics.net/lists/linux-sh/msg53400.html
I missed the ship window for the previous iteration so we had to use PIO, but
DMA's a huge speedup and it's cycling back around on my todo list...
Unfortunately due to a flash corruption bug we were stuck at 4.14 for that
release. I'm trying to track that down now, then need to redo this work on top
of 4.20 or 4.21.
Kernel board support patches are at the lawyers being frowned at expensively
before release, but it won't include DMA this time because I only got the first
half of it working. (Board's hooked up and can do memory-to-memory, but the
ethernet card couldn't use it because the smc91x claims of using dmaengine are
lies, it's hardwired to a specific arm chip ("mainstone" I think?), and when I
got QEMU to emulate that ARM board and tried to enable DMA: packet timeouts. I
dunno if it's broken in the kernel or QEMU doesn't emulate the DMA...)
>> Notes:
>> 1. As Renesas ARM SoCs no longer use drivers/dma/sh/shdma-base.c, the
>> task to remove use of the deprecated dma_slave_config.direction
>> field gets thrown into the SuperH maintainers' basket ;-)
At least in 4.14 there were two DMA apis, once of which is obsolete and unused,
and the other is modern dmaengine support which at least passes its self-test.
I left off boggling at the "slave API", I think...
>> 3. I tried to get SCIFA DMA to work by:
>> - Applying the DT and driver patches below,
>> - Reverting 219fb0c1436e4893 ("serial: sh-sci: Remove the
>> platform data dma slave rx/tx channel IDs").
The board I'm using is platform data, never got converted to device tree. (If I
can ever convince them to mail a board to Rich Felker I might try to hire him to
convert it _myself_. Or I could just get him an old board on ebay, current
cheapest one looks like
https://www.ebay.com/p/Johnson-Controls-Ms-nae3511-2-Metasys-Controller-NAE-and-2x-Unt1108/567230953?iid=283254042308
at the moment? Dead battery's fine for a dev/test system...)
But it's not happening this month.
>> After that, serial console output using DMA seems to work, but the
>> system locks up when receiving any serial console input.
>> Probably it is easier to add r8a73a4 support to rcar-dmac.
What _is_ the status of dmaengine? I thought it was the generic dma API the
kernel was moving towards? (The youtube videos suggested such...)
Rob
^ permalink raw reply
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