dmaengine: convert dw_dmac/spear13xx to generic binding

With the new OF DMA binding, it is possible to completely avoid the need for platform_data for configuring a DMA channel. In cases where the platform has already been converted, calling dma_request_slave_channel should get all the necessary information from the device tree.

Like the patch that converts the dw_dma controller, this is completely untested and is looking for someone to try it out.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Grant Likely <grant.likely-s3s/[email protected]>

Cc Mark Brown <broonie-yzvPICuk2AATkU/[email protected]>

Cc spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Cc Viresh Kumar <[email protected]>

Cc Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]>

Cc Vinod Koul <vinod.koul-VuQAYsv1563Yd54FQh9/[email protected]>

Cc devicetree-discuss-uLR06cmDAlY/[email protected]

Cc [email protected]

---
 drivers/spi/spi-pl022.c | 43 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 41 insertions(+), 2 deletions(-)

drivers/spi/spi-pl022.c +41 -2

index b0fe393..371cc66f 100644
@@ -1139,6 +1139,35 @@ err_no_rxchan:
 	return -ENODEV;
 }
 
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+	struct device *dev = &pl022->adev->dev;
+
+	/* automatically configure DMA channels from platform, normally using DT */
+	pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+	if (!pl022->dma_rx_channel)
+		goto err_no_rxchan;
+
+	pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
+	if (!pl022->dma_tx_channel)
+		goto err_no_txchan;
+
+	pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
+	if (!pl022->dummypage)
+		goto err_no_dummypage;
+
+	return 0;
+
+err_no_dummypage:
+	dma_release_channel(pl022->dma_tx_channel);
+	pl022->dma_tx_channel = NULL;
+err_no_txchan:
+	dma_release_channel(pl022->dma_rx_channel);
+	pl022->dma_rx_channel = NULL;
+err_no_rxchan:
+	return -ENODEV;
+}
+		
 static void terminate_dma(struct pl022 *pl022)
 {
 	struct dma_chan *rxchan = pl022->dma_rx_channel;

@@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
 	return -ENODEV;
 }
 
+static inline int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+	return 0;
+}
+
 static inline int pl022_dma_probe(struct pl022 *pl022)
 {
 	return 0;

@@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const struct amba_id *id)
 		goto err_no_irq;
 	}
 
-	/* Get DMA channels */
-	if (platform_info->enable_dma) {
+	/* Get DMA channels, try autoconfiguration first */
+	status = pl022_dma_autoprobe(pl022);
+
+	/* If that failed, use channels from platform_info */
+	if (status == 0)
+		platform_info->enable_dma = 1;
+	else if (platform_info->enable_dma) {
 		status = pl022_dma_probe(pl022);
 		if (status != 0)
 			platform_info->enable_dma = 0;

Signature · 1 line

1.8.0

With the new OF DMA binding, it is possible to completely avoid the need for platform_data for configuring a DMA channel. In cases where the platform has already been converted, calling dma_request_slave_channel should get all the necessary information from the device tree.

Like the patch that converts the dw_dma controller, this is completely untested and is looking for someone to try it out.

Signed-off-by Arnd Bergmann <[email protected]>

With the new OF DMA binding, it is possible to completely avoid the need for platform_data for configuring a DMA channel. In cases where the platform has already been converted, calling dma_request_slave_channel should get all the necessary information from the device tree.

Like the patch that converts the dw_dma controller, this is completely untested and is looking for someone to try it out.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Grant Likely <grant.likely-s3s/[email protected]>

Cc Jiri Slaby <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Linus Walleij <[email protected]>

Cc spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org

Cc Viresh Kumar <[email protected]>

Cc Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]>

Cc Vinod Koul <vinod.koul-VuQAYsv1563Yd54FQh9/[email protected]>

Cc devicetree-discuss-uLR06cmDAlY/[email protected]

Cc [email protected]

---
 drivers/tty/serial/amba-pl011.c | 62 ++++++++++++++++++++++++-----------------
 1 file changed, 37 insertions(+), 25 deletions(-)

drivers/tty/serial/amba-pl011.c +37 -25

index 3ea5408..c25b00e 100644
@@ -245,7 +245,7 @@ static void pl011_sgbuf_free(struct dma_chan *chan, struct pl011_sgbuf *sg,
 	}
 }
 
-static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
+static void pl011_dma_probe_initcall(struct device *dev, struct uart_amba_port *uap)
 {
 	/* DMA is the sole user of the platform data right now */
 	struct amba_pl011_data *plat = uap->port.dev->platform_data;

@@ -259,20 +259,25 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 	struct dma_chan *chan;
 	dma_cap_mask_t mask;
 
-	/* We need platform data */
-	if (!plat || !plat->dma_filter) {
-		dev_info(uap->port.dev, "no DMA platform data\n");
-		return;
-	}
+	chan = dma_request_slave_channel(dev, "tx");
 
-	/* Try to acquire a generic DMA engine slave TX channel */
-	dma_cap_zero(mask);
-	dma_cap_set(DMA_SLAVE, mask);
-
-	chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
 	if (!chan) {
-		dev_err(uap->port.dev, "no TX DMA channel!\n");
-		return;
+		/* We need platform data */
+		if (!plat || !plat->dma_filter) {
+			dev_info(uap->port.dev, "no DMA platform data\n");
+			return;
+		}
+
+		/* Try to acquire a generic DMA engine slave TX channel */
+		dma_cap_zero(mask);
+		dma_cap_set(DMA_SLAVE, mask);
+
+		chan = dma_request_channel(mask, plat->dma_filter,
+						plat->dma_tx_param);
+		if (!chan) {
+			dev_err(uap->port.dev, "no TX DMA channel!\n");
+			return;
+		}
 	}
 
 	dmaengine_slave_config(chan, &tx_conf);

@@ -282,7 +287,18 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 		 dma_chan_name(uap->dmatx.chan));
 
 	/* Optionally make use of an RX channel as well */
-	if (plat->dma_rx_param) {
+	chan = dma_request_slave_channel(dev, "rx");
+	
+	if (!chan && plat->dma_rx_param) {
+		chan = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
+
+		if (!chan) {
+			dev_err(uap->port.dev, "no RX DMA channel!\n");
+			return;
+		}
+	}
+
+	if (chan) {
 		struct dma_slave_config rx_conf = {
 			.src_addr = uap->port.mapbase + UART01x_DR,
 			.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,

@@ -291,12 +307,6 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 			.device_fc = false,
 		};
 
-		chan = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
-		if (!chan) {
-			dev_err(uap->port.dev, "no RX DMA channel!\n");
-			return;
-		}
-
 		dmaengine_slave_config(chan, &rx_conf);
 		uap->dmarx.chan = chan;
 

@@ -315,6 +325,7 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
 struct dma_uap {
 	struct list_head node;
 	struct uart_amba_port *uap;
+	struct device *dev;
 };
 
 static LIST_HEAD(pl011_dma_uarts);

@@ -325,7 +336,7 @@ static int __init pl011_dma_initcall(void)
 
 	list_for_each_safe(node, tmp, &pl011_dma_uarts) {
 		struct dma_uap *dmau = list_entry(node, struct dma_uap, node);
-		pl011_dma_probe_initcall(dmau->uap);
+		pl011_dma_probe_initcall(dmau->dev, dmau->uap);
 		list_del(node);
 		kfree(dmau);
 	}

@@ -334,18 +345,19 @@ static int __init pl011_dma_initcall(void)
 
 device_initcall(pl011_dma_initcall);
 
-static void pl011_dma_probe(struct uart_amba_port *uap)
+static void pl011_dma_probe(struct device *dev, struct uart_amba_port *uap)
 {
 	struct dma_uap *dmau = kzalloc(sizeof(struct dma_uap), GFP_KERNEL);
 	if (dmau) {
 		dmau->uap = uap;
+		dmau->dev = dev;
 		list_add_tail(&dmau->node, &pl011_dma_uarts);
 	}
 }
 #else
-static void pl011_dma_probe(struct uart_amba_port *uap)
+static void pl011_dma_probe(struct device *dev, struct uart_amba_port *uap)
 {
-	pl011_dma_probe_initcall(uap);
+	pl011_dma_probe_initcall(dev, uap);
 }
 #endif
 

@@ -2020,7 +2032,7 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
 	uap->port.ops = &amba_pl011_pops;
 	uap->port.flags = UPF_BOOT_AUTOCONF;
 	uap->port.line = i;
-	pl011_dma_probe(uap);
+	pl011_dma_probe(&dev->dev, uap);
 
 	/* Ensure interrupts from this UART are masked and cleared */
 	writew(0, uap->port.membase + UART011_IMSC);

Signature · 1 line

1.8.0

Hi everyone,

This is my attempt to convert the spear platform and the dw_dmac to the generic device tree binding for DMA, so that we don't get a release with the broken version. I'm pretty sure that this has bugs, but it's as good as I could do without access to hardware or specs.

The original device tree binding for this driver, from Viresh Kumar unfortunately conflicted with the generic DMA binding, and did not allow to completely seperate slave device configuration from the controller.

This is an attempt to replace it with an implementation of the generic binding, but it is currently completely untested, because I do not have any hardware with this particular controller.

The patch applies on top of linux-next, which contains both the base support for the generic DMA binding, as well as the earlier attempt from Viresh. Both of these are currently not merged upstream however.

Documentation/devicetree/bindings/dma/snps-dma.txt +0 -0

index 5bb3dfb..212d387 100644
@@ -3,59 +3,62 @@
 Required properties:
 - compatible: "snps,dma-spear1340"
 - reg: Address range of the DMAC registers

Documentation/devicetree/bindings/dma/snps-dma.txt +9 -0

+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a five-cell specifier for each channel.
+The five cells in order are:
+
+1. A phandle pointing to the DMA controller
+2. The value for the cfg_hi register.
+3. The value for the cfg_lo register.
+4. Source master for transfers on allocated channel.
+5. Destination master for transfers on allocated channel.
 

drivers/dma/dw_dmac.c +1 -0

index 8cfaaf8..88504c2 100644
@@ -18,6 +18,7 @@
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/of.h>
+#include <linux/of_dma.h>
 #include <linux/mm.h>
 #include <linux/module.h>
 #include <linux/platform_device.h>

drivers/dma/dw_dmac.c +5 -7

+};
+
+static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
 {
        struct dw_dma *dw = to_dw_dma(chan->device);
-       static struct dw_dma *last_dw;
-       static char *last_bus_id;
-       int i = -1;
+       struct dw_dma_filter_args *fargs = param;
+       struct dw_dma_slave *sd;
 
-       /*
-        * dmaengine framework calls this routine for all channels of all dma
-        * controller, until true is returned. If 'param' bus_id is not
-        * registered with a dma controller (dw), then there is no need of

drivers/dma/dw_dmac.c +1 -6

+       if (dw != fargs->dw)
                return false;
-       /*
-        * Return true:
-        * - If dw_dma's platform data is not filled with slave info, then all
-        *   dma controllers are fine for transfer.
-        * - Or if param is NULL
-        */

drivers/dma/dw_dmac.c +12 -6

+       if (!sd)
+               return false;
 
-                       return true;
-               }
-       }
+       sd->dma_dev     = dw->dma.dev;
+       sd->cfg_hi      = fargs->cfg_hi;
+       sd->cfg_lo      = fargs->cfg_lo;
+       sd->src_master  = fargs->src;
+       sd->dst_master  = fargs->dst;
+
+       chan->private = sd;
 
-       last_dw = dw;
-       last_bus_id = param;
-       return false;
+       return true;
+}
+

Quoted 13 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +0 -4

index 5bb3dfb..212d387 100644
@@ -3,59 +3,62 @@
 Required properties:
 - compatible: "snps,dma-spear1340"
 - reg: Address range of the DMAC registers
-- interrupt-parent: Should be the phandle for the interrupt controller
-  that services interrupts for this device
 - interrupt: Should contain the DMAC interrupt number
-- nr_channels: Number of channels supported by hardware
-- is_private: The device channels should be marked as private and not for by the

Documentation/devicetree/bindings/dma/snps-dma.txt line 10

Quoted 5 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +4 -1

-  general purpose DMA channel allocator. False if not passed.
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be <3>

Shouldn't this be 4? Would be better to mention what fields are these, right here. I have seen them below though.

Documentation/devicetree/bindings/dma/snps-dma.txt line 12

Quoted 3 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +2 -1

-bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
+/* forward declaration used in filter */
+static struct platform_driver dw_driver;

extern? This is not a declaration but definition.

Quoted 4 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +0 -4

-       /*
-        * dmaengine framework calls this routine for all channels of all dma
-        * controller, until true is returned. If 'param' bus_id is not
-        * registered with a dma controller (dw), then there is no need of

Documentation/devicetree/bindings/dma/snps-dma.txt line 15

Quoted 10 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +3 -7

-        * running below function for all channels of dw.
-        *
-        * This block of code does this by saving the parameters of last
-        * failure. If dw and param are same, i.e. trying on same dw with
-        * different channel, return false.
-        */
-       if ((last_dw == dw) && (last_bus_id == param))
+       /* both the driver and the device must match */
+        if (chan->device->dev->driver != &dw_driver.driver)
+                return false;

Can this ever happen? Isn't it the case that this routine would be called only for dw_dmac?

Documentation/devicetree/bindings/dma/snps-dma.txt line 17

Quoted 7 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +2 -5

-       while (++i < dw->sd_count) {
-               if (!strcmp(dw->sd[i].bus_id, param)) {
-                       chan->private = &dw->sd[i];
-                       last_dw = NULL;
-                       last_bus_id = NULL;
+       /* FIXME: memory leak! could we put this into dw_dma_chan? */
+       sd = devm_kzalloc(dw->dma.dev, sizeof (*sd), GFP_KERNEL);

Yes.

Quoted 4 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +4 -0

+static struct dma_chan *dw_dma_xlate(struct of_phandle_args *dma_spec,
+                                        struct of_dma *ofdma)
+{
+       struct dw_dma *dw = ofdma->of_dma_data;

Documentation/devicetree/bindings/dma/snps-dma.txt line 27

Quoted 6 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +6 -0

+       struct dw_dma_filter_args fargs = {
+               .dw = dw,
+       };
+       dma_cap_mask_t cap;
+
+       if (dma_spec->args_count != 4)

args_count contains count of all params leaving the phandle?

Documentation/devicetree/bindings/dma/snps-dma.txt line 29

Quoted 2 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +2 -0

+       /* FIXME: This binding is rather clumsy. Can't we use the
+          request line numbers here instead? */

yes.

Documentation/devicetree/bindings/dma/snps-dma.txt line 38

Quoted 9 lines

Documentation/devicetree/bindings/dma/snps-dma.txt +9 -0

+       fargs.cfg_lo = be32_to_cpup(dma_spec->args+0);
+       fargs.cfg_hi = be32_to_cpup(dma_spec->args+1);
+       fargs.src = be32_to_cpup(dma_spec->args+2);
+       fargs.dst = be32_to_cpup(dma_spec->args+3);
+
+       dma_cap_zero(cap);
+       dma_cap_set(DMA_SLAVE, cap);
+       /* FIXME: there should be a simpler way to do this */
+       return dma_request_channel(cap, dw_dma_generic_filter, &dma_spec->args[0]);

don't you need to send &fargs as the last argument?

Quoted 2 lines · Viresh Kumar

Shouldn't this be 4? Would be better to mention what fields are these, right here. I have seen them below though.

Correct. I changed these a couple of times while trying to understand what the fields are, and I missed this instance. I'm still not sure whether we actually need all four fields, or what the simplest format for them would be. This just mirrors what you had in your binding.

Quoted 4 lines

drivers/dma/dw_dmac.c static void dwc_free_chan_resources(struct dma_chan *chan) · line 1207

Quoted 2 lines

drivers/dma/dw_dmac.c +2 -0

+       /* FIXME: memory leak! could we put this into dw_dma_chan? */
+       sd = devm_kzalloc(dw->dma.dev, sizeof (*sd), GFP_KERNEL);

Yes.

Yes it can be in dw_dma_chan or yes it is a memory leak?

Quoted 3 lines

Quoted 1 line

+ if (dma_spec->args_count != 4)

args_count contains count of all params leaving the phandle?

That was my interpretation from reading the code, but I have not tried it.

Quoted 4 lines

drivers/dma/dw_dmac.c static void dwc_free_chan_resources(struct dma_chan *chan) · line 1235

Quoted 2 lines

drivers/dma/dw_dmac.c +2 -0

+       /* FIXME: This binding is rather clumsy. Can't we use the
+          request line numbers here instead? */

yes.

Ok, Very good. What is the encoding of the registers then?

Thanks a lot for the input. When I fix the above, are actually able to test the changes, or have you lost access to the hardware when leaving ST?

Quoted 8 lines · Arnd Bergmann

Quoted 4 lines · Viresh Kumar

drivers/dma/dw_dmac.c static void dwc_free_chan_resources(struct dma_chan *chan) · line 1235

Quoted 2 lines

drivers/dma/dw_dmac.c +2 -0

+       /* FIXME: This binding is rather clumsy. Can't we use the
+          request line numbers here instead? */

yes.

Ok, Very good. What is the encoding of the registers then?

You can still keep fargs as is and just fill them as:

       fargs.cfg_lo = 0;

if (DMA_TO_DEV)

       // dest is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
else if (DEV_TO_DMA)
       // src is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;

Quoted 6 lines · Viresh Kumar

if (DMA_TO_DEV)

       // dest is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
else if (DEV_TO_DMA)
       // src is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;

We have macros for such shifts.

drivers/dma/dw_dmac.c:187: cfghi = DWC_CFGH_DST_PER(...
drivers/dma/dw_dmac.c:189: cfghi = DWC_CFGH_SRC_PER(...

Quoted 8 lines · Andy Shevchenko

Quoted 6 lines · Viresh Kumar

if (DMA_TO_DEV)

       // dest is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
else if (DEV_TO_DMA)
       // src is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;

Quoted 4 lines

We have macros for such shifts.

drivers/dma/dw_dmac.c:187: cfghi = DWC_CFGH_DST_PER(...
drivers/dma/dw_dmac.c:189: cfghi = DWC_CFGH_SRC_PER(...

I am getting older now, bad memory :)
I grepped into drivers/dma/dw_dmac_regs.h and left include/linux/dw_dmac.h :(

You can still keep fargs as is and just fill them as:

       fargs.cfg_lo = 0;

if (DMA_TO_DEV)

       // dest is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
else if (DEV_TO_DMA)
       // src is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;

The field size is 4 bits.

Quoted 3 lines

Thanks a lot for the input. When I fix the above, are actually able to test the changes, or have you lost access to the hardware when leaving ST?

I don't have any sort of access for testing these :( But, Vipul might try these at his end.

Quoted 11 lines · Viresh Kumar

You can still keep fargs as is and just fill them as:

       fargs.cfg_lo = 0;

if (DMA_TO_DEV)

       // dest is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
else if (DEV_TO_DMA)
       // src is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;

Quoted 1 line

The field size is 4 bits.

Ah, good. So I guess the "dma-requests" property should actually be "16" then.

Does this mean that an implicit zero request line means memory?

Could we have device-to-device DMAs with this controller, and if we can, should we have both 'src' and 'dst' fields?

Are the
two number ranges sharing the same address space, i.e. is request '7' as the destination guaranteed to be the same device as request '7' in the source?

Quoted 14 lines · Arnd Bergmann

Quoted 12 lines · Viresh Kumar

You can still keep fargs as is and just fill them as:

       fargs.cfg_lo = 0;

if (DMA_TO_DEV)

       // dest is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
else if (DEV_TO_DMA)
       // src is periph
       fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;

The field size is 4 bits.

Quoted 4 lines

Ah, good. So I guess the "dma-requests" property should actually be "16" then.

Does this mean that an implicit zero request line means memory?

No, it doesn't.
When dma is doing mem2mem transfers the request line field is ignored by the hw.

Quoted 5 lines · Arnd Bergmann

On Tuesday 29 January 2013, Viresh Kumar wrote:
Ah, good. So I guess the "dma-requests" property should actually be "16" then.

Does this mean that an implicit zero request line means memory?

No, it doesn't.
When dma is doing mem2mem transfers the request line field is ignored by the hw.

Quoted 2 lines

Could we have device-to-device DMAs with this controller, and if we can, should we have both 'src' and 'dst' fields?

As far as I know there is no driver under dmaengine that supports per2per transfers.

Quoted 4 lines

Are the
two number ranges sharing the same address space, i.e. is request '7' as the destination guaranteed to be the same device as request '7' in the source?

Request line should be unique. It means a real wire from slave hw to the dmac.

Ah, good. So I guess the "dma-requests" property should actually be "16" then.

Does this mean that an implicit zero request line means memory?

Could we have device-to-device DMAs with this controller, and if we can, should we have both 'src' and 'dst' fields? Are the two number ranges sharing the same address space, i.e. is request '7' as the destination guaranteed to be the same device as request '7' in the source?

If we need two lines, we could interleave them with the bus master numbers:

In theory, we could use bit-stuffing to put them all into a single 32 bit word I guess, but generally people don't seem to like that for new bindings.

Quoted 2 lines · Arnd Bergmann

Ah, good. So I guess the "dma-requests" property should actually be "16" then.

yes, even i was checking on that separately :)

Quoted 5 lines

Could we have device-to-device DMAs with this controller, and if we can, should we have both 'src' and 'dst' fields? Are the two number ranges sharing the same address space, i.e. is request '7' as the destination guaranteed to be the same device as request '7' in the source?

Request lines are per master... So, for a master single request line is independent of direction. Many DMA controllers have capability of doing dev-to-dev transfers but DMAENGINE doesn't have any support for it, even we don't have a usecase too :)

Quoted 2 lines

If we need two lines, we could interleave them with the bus master numbers:

not required.

Quoted 5 lines · Viresh Kumar

Quoted 2 lines · Arnd Bergmann

Ah, good. So I guess the "dma-requests" property should actually be "16" then.

yes, even i was checking on that separately :)

Actually, I just discovered something odd in the arch/arm/mach-spear/spear13xx-dma.h file that gets removed in the last patch: there, we define request numbers up to 32, e.g.

(quoted diff) +0 -4

-       SPEAR1310_DMA_REQ_UART2_RX = 14,
-       SPEAR1310_DMA_REQ_UART2_TX = 15,
-       SPEAR1310_DMA_REQ_UART5_RX = 16,
-       SPEAR1310_DMA_REQ_UART5_TX = 17,

What is the meaning of this, if the maximum request number is 15?

Ok. Would it be enough to have only one master and one request field in the DT dma descriptor then, and have the code figure whether to use it as source or destination, based on the configuration? Which one should come first? Since you have multiple masters per controller, and multiple requests per master, it sounds like the cleanest descriptor form would be

        <controller master request>;

Or possibly

        <controller master request direction>;

if the direction needs to be known at the time the channel is requested.

Quoted 17 lines · Arnd Bergmann

Quoted 5 lines · Viresh Kumar

Quoted 2 lines · Arnd Bergmann

Ah, good. So I guess the "dma-requests" property should actually be "16" then.

yes, even i was checking on that separately :)

Actually, I just discovered something odd in the arch/arm/mach-spear/spear13xx-dma.h file that gets removed in the last patch: there, we define request numbers up to 32, e.g.

(quoted diff) +0 -4

-       SPEAR1310_DMA_REQ_UART2_RX = 14,
-       SPEAR1310_DMA_REQ_UART2_TX = 15,
-       SPEAR1310_DMA_REQ_UART5_RX = 16,
-       SPEAR1310_DMA_REQ_UART5_TX = 17,

Quoted 1 line

What is the meaning of this, if the maximum request number is 15?

I knew you will come to this :)
So, the hardware is like: there are 16 request line slots per master, a platform can choose to connect same or separate devices to these.

So, these are really 16 per master.

Quoted 12 lines

Ok. Would it be enough to have only one master and one request field in the DT dma descriptor then, and have the code figure whether to use it as source or destination, based on the configuration? Which one should come first? Since you have multiple masters per controller, and multiple requests per master, it sounds like the cleanest descriptor form would be

        <controller master request>;

Or possibly

Quoted 4 lines

        <controller master request direction>;

if the direction needs to be known at the time the channel is requested.

Its better to keep masters as is. So, that we can use appropriate masters for peripheral and memory to make the transfer fast.

Quoted 5 lines · Viresh Kumar

I knew you will come to this :)
So, the hardware is like: there are 16 request line slots per master, a platform can choose to connect same or separate devices to these.

So, these are really 16 per master.

Ok, I see. Do you know how these are numbered in the data sheet?

If the convention is to have subsequent numbers for these in the hardware description, we should probably just have that single request number in the binding, too, and calculate the master number from that. If it lists pairs of request/master number, we should use pairs in the binding as well, in the same order.

Quoted 17 lines

Quoted 16 lines

Ok. Would it be enough to have only one master and one request field in the DT dma descriptor then, and have the code figure whether to use it as source or destination, based on the configuration? Which one should come first? Since you have multiple masters per controller, and multiple requests per master, it sounds like the cleanest descriptor form would be

        <controller master request>;

Or possibly

        <controller master request direction>;

if the direction needs to be known at the time the channel is requested.

Quoted 2 lines

Its better to keep masters as is. So, that we can use appropriate masters for peripheral and memory to make the transfer fast.

So you mean keep the format as

        <controller request src-master dst-master>;

?

Quoted 7 lines · Arnd Bergmann

Quoted 5 lines · Viresh Kumar

I knew you will come to this :)
So, the hardware is like: there are 16 request line slots per master, a platform can choose to connect same or separate devices to these.

So, these are really 16 per master.

Quoted 7 lines

Ok, I see. Do you know how these are numbered in the data sheet?

If the convention is to have subsequent numbers for these in the hardware description, we should probably just have that single request number in the binding, too, and calculate the master number from that. If it lists pairs of request/master number, we should use pairs in the binding as well, in the same order.

Actually what would be better to have is:
- have this range from 0-15 only
- together with the master we want to use for peripheral

this should be enough.

Datasheet of dw_dmac doesn't tell much about it.. just four bits for programming it and so values are from 0-15 :)

I meant the spear13xx data sheet, which has to list the request lines for its integrated components. There may be other SoCs using the same dw_dmac, but this is the main one that is upstream now, and it's probably as good as any other one. I just wouldn't want to establish a binding that doesn't match any of the known implementations in the way it expresses request lines.

drivers/dma/dw_dmac.c static void dwc_free_chan_resources(struct dma_chan *chan) · line 1201

Quoted 3 lines · Arnd Bergmann

drivers/dma/dw_dmac.c +2 -1

-	if ((last_dw == dw) && (last_bus_id == param))
+	/* both the driver and the device must match */
+        if (chan->device->dev->driver != &dw_driver.driver)

Could we somehow pass the &.driver to the generic filter function (via *_dma_controller_register() ? ) and do this to each DMA driver?

drivers/dma/dw_dmac.c static void dwc_free_chan_resources(struct dma_chan *chan) · line 1215

Quoted 5 lines

drivers/dma/dw_dmac.c +5 -0

+	sd->dma_dev	= dw->dma.dev;
+	sd->cfg_hi	= fargs->cfg_hi;
+	sd->cfg_lo	= fargs->cfg_lo;
+	sd->src_master	= fargs->src;
+	sd->dst_master	= fargs->dst;

Could we use fargs structure directly?

(putting back the Cc list, I assumed you dropped them accidentally)

Quoted 7 lines · Arnd Bergmann

drivers/dma/dw_dmac.c static void dwc_free_chan_resources(struct dma_chan *chan) · line 1201

Quoted 3 lines

drivers/dma/dw_dmac.c +2 -1

-	if ((last_dw == dw) && (last_bus_id == param))
+	/* both the driver and the device must match */
+        if (chan->device->dev->driver != &dw_driver.driver)

Could we somehow pass the &.driver to the generic filter function (via *_dma_controller_register() ? ) and do this to each DMA driver?

My hope is still that we can avoid using filter functions entirely when we use xlate() logic, and instead just go through the channels of the dma engine we know we are looking at.

Quoted 8 lines · Andy Shevchenko

Quoted 7 lines · Arnd Bergmann

Quoted 3 lines

- if ((last_dw == dw) && (last_bus_id == param))
+ /* both the driver and the device must match */
+ if (chan->device->dev->driver != &dw_driver.driver)

Could we somehow pass the &.driver to the generic filter function (via *_dma_controller_register() ? ) and do this to each DMA driver?

How, and what driver gets passed?

Quoted 3 lines

My hope is still that we can avoid using filter functions entirely when we use xlate() logic, and instead just go through the channels of the dma engine we know we are looking at.

Has anyone yet determined whether any of these new DMA engine slave APIs are usable for implementations which have a separate MUX between the DMA engine and the DMA peripheral?

Can you give an example for this? We were careful to make sure it works with platforms that connect a slave to multiple dma engines, out of which any could be used for a given transfer. In the device tree binding, you specify all possible controllers and give the alternatives the same name, for example:

	serial at 10000000 {
		compatible = "arm,pl011", "arm,primecell";
		dmas = <dwdma0 7 0>, <dwdma0 8 1>, <&pl330 17>, <&pl330 15>;
		dma-names = "rx", "tx", "rx", "tx;
		...
	};

No, that's not what I mean. I mean the situation we find on Versatile platforms:

8 3 >3
PL080 DMA --/--+--/------> FPGA Mux --/--> {bunch of off-CPU peripherals}

               |  5
               `--/------> {On-CPU peripherals}

This is something that I've been raising _every time_ I've been involved with DMA engine discussions when it comes to the matching stuff, so this is nothing new, and it's not unknown about.

From the DT binding perspective, doing this should be no problem. I guess

Quoted 11 lines · Russell King - ARM Linux

No, that's not what I mean. I mean the situation we find on Versatile platforms:

8 3 >3
PL080 DMA --/--+--/------> FPGA Mux --/--> {bunch of off-CPU peripherals}

               |  5
               `--/------> {On-CPU peripherals}

This is something that I've been raising _every time_ I've been involved with DMA engine discussions when it comes to the matching stuff, so this is nothing new, and it's not unknown about.

Ok, I see. I have not actually been involved with the DMA engine API much, so for me it's the first time /I/ see this being explained.

From the DT binding perspective, doing this should be no problem. I guess you would model the MUX as a trivial dma engine device that forwards to another one, just like we do for nested interrupt controllers:

	pl080: dma-engine at 10000000 {
		compatible ="arm,pl080", "arm,primecell";
		reg = <0x10000000 0x1000>;
		dma-requests = <8>;
		dma-channels = <4>;
		#dma-cells = <2>;
	};

	fpga {
		mux: dma-mux at f0008000 {
			reg = <0xf0008000 100>;
			compatible = "arm,versatile-fpga-dmamux";
			dma-requests = <7>;
			dma-channels = <3>;
			#dma-cells = <1>;
			dmas = <&pl080 5 0>, <&pl080 6 0> <&pl080 7 0>;
			dma-names = "mux5", "mux6", "mux7";
		};
		...

		some-device at f000a000 {
			compatible = "foo,using-muxed-dma";
			dmas = <&mux 3>, <&mux 4>;
			dma-names = "rx", "tx";
		};
	};

The driver for foo,using-muxed-dma just requests a slave channel for its lines, which ends up calling the xlate function of the driver for the mux. That driver still needs to get written, of course, but it should be able to recursively call dma_request_slave_channel on the pl080 device. The arm,versatile-fpga-dmamux driver would not be registered to the dmaengine layer, but it would register as an of_dma_controller.

That's a good way to represent it but it fails in a very big way:
You're stuffing N peripherals down to 3 request lines to the DMA engine, and you may want more than 3 of those peripherals to be making use of the DMA engine at any one time.

Before anyone says "you shouldn't be doing this" consider this:
your typical DMA slave engine already has this structure:

N DMA channels <---> M DMA requests <---> M peripherals

where N < M. In other words, there is already a MUX between the peripherals and the DMA engine channels themselves (what do you think the "request index" which you have to program into DMA channel control registers is doing...

We support this external mux today in the PL080 driver - and we do that by having the PL080 driver do the scheduling of virtual DMA channels on the actual hardware itself. The PL080 driver has knowledge that there may be some sort of additional muxing layer between it and the peripheral.

As the APIs stand today, you just can't do this without having the DMA engine driver itself intimately involved because a layer above doesn't really have much clue as to what's going on, and the DMA engine stuff itself doesn't layer particularly well.

If the pl080 driver already has code for the mux in it, then it should handle both of_dma_controller instances in my example. It would not change anything regarding the binding, which just describes the way that the hardware is connected. I have not looked at the implementation of the pl080 driver, but I'd assume we could get away with just having two separate xlate() functions.

Well, how it all works in the PL08x driver at present is:

the patches were certainly on the mailing list
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017818.html

Do you (or Linus) know what happened to the patch series?

Based on your description, it sounds all doable, but the split between platform specific code and device driver code would be
different: While the muxing that you describe all takes place in the get_signal/put_signal functions in platform code, doing a proper DT binding for the mux would imply moving that into the pl080 driver itself, at least as a compile-time option for the driver. Do you think that would be acceptable?

While I guess we could still keep the get_signal/put_signal callbacks in mach-versatile but drop them for platforms without a mux, I'm not sure if that would make the overall driver better or worse.

The original device tree binding for this driver, from Viresh Kumar unfortunately conflicted with the generic DMA binding, and did not allow to completely seperate slave device configuration from the controller.

This is an attempt to replace it with an implementation of the generic binding, but it is currently completely untested, because I do not have any hardware with this particular controller.

The patch applies on top of linux-next, which contains both the base support for the generic DMA binding, as well as the earlier attempt from Viresh. Both of these are currently not merged upstream however.

There are a couple of TODO items that are left remaining and are open for ideas from other people.

Have one question and one comment.

So, what is the status of this work? Do you manage to provide something for v3.9? (Oh, two questions :-) )

Quoted 7 lines

drivers/dma/dw_dmac.c +0 -0

@@ -1765,7 +1753,11 @@ static int dw_probe(struct platform_device *pdev)
 
      dma_async_device_register(&dw->dma);
 

drivers/dma/dw_dmac.c static int dw_probe(struct platform_device *pdev) · line 1758

Quoted 4 lines

drivers/dma/dw_dmac.c +3 -1

-     return 0;
+     err = of_dma_controller_register(pdev->dev.of_node, dw_dma_xlate, dw);
+     if (err)
+             dma_async_device_unregister(&dw->dma);

I don't think this is a good idea. The impossibility to register in the of-dma helper is not critical. Just printing debug message is enough.

With the new OF DMA binding, it is possible to completely avoid the need for platform_data for configuring a DMA channel. In cases where the platform has already been converted, calling dma_request_slave_channel should get all the necessary information from the device tree.

Like the patch that converts the dw_dma controller, this is completely untested and is looking for someone to try it out.

With the new OF DMA binding, it is possible to completely avoid the need for platform_data for configuring a DMA channel. In cases where the platform has already been converted, calling dma_request_slave_channel should get all the necessary information from the device tree.

Like the patch that converts the dw_dma controller, this is completely untested and is looking for someone to try it out.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Grant Likely <[email protected]>

Cc Mark Brown <[email protected]>

Cc spi-devel-general at lists.sourceforge.net

Cc Viresh Kumar <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc Vinod Koul <[email protected]>

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-arm-kernel at lists.infradead.org

---
 .../devicetree/bindings/spi/spi_pl022.txt          | 36 ++++++++++++++++++
 drivers/spi/spi-pl022.c                            | 43 +++++++++++++++++++++-
 2 files changed, 77 insertions(+), 2 deletions(-)

drivers/spi/spi-pl022.c +4 -0

@@ -1139,6 +1139,35 @@ err_no_rxchan:
 	return -ENODEV;
 }
 
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+	struct device *dev = &pl022->adev->dev;
+

drivers/spi/spi-pl022.c +27 -2

+	if (!pl022->dummypage)
+		goto err_no_dummypage;
+
+	return 0;
+
+err_no_dummypage:
+	dma_release_channel(pl022->dma_tx_channel);
+	pl022->dma_tx_channel = NULL;
+err_no_txchan:
+	dma_release_channel(pl022->dma_rx_channel);
+	pl022->dma_rx_channel = NULL;
+err_no_rxchan:
+	return -ENODEV;
+}
+		
 static void terminate_dma(struct pl022 *pl022)
 {
 	struct dma_chan *rxchan = pl022->dma_rx_channel;

@@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
 	return -ENODEV;
 }
 
+static inline int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+	return 0;
+}
+
 static inline int pl022_dma_probe(struct pl022 *pl022)
 {
 	return 0;

@@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const struct amba_id *id)
 		goto err_no_irq;
 	}
 
-	/* Get DMA channels */
-	if (platform_info->enable_dma) {
+	/* Get DMA channels, try autoconfiguration first */
+	status = pl022_dma_autoprobe(pl022);
+
+	/* If that failed, use channels from platform_info */
+	if (status == 0)
+		platform_info->enable_dma = 1;
+	else if (platform_info->enable_dma) {
 		status = pl022_dma_probe(pl022);
 		if (status != 0)
 			platform_info->enable_dma = 0;

Quoted 10 lines

drivers/spi/spi-pl022.c +10 -0

+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+	struct device *dev = &pl022->adev->dev;
+
+	/* automatically configure DMA channels from platform, normally using DT */
+	pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+	if (!pl022->dma_rx_channel)
+		goto err_no_rxchan;
+
+	pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");

drivers/spi/spi-pl022.c err_no_rxchan: · line 1155

Quoted 4 lines

drivers/spi/spi-pl022.c +4 -0

+	if (!pl022->dma_tx_channel)
+		goto err_no_txchan;
+
+	pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);

Where this memory will be freed?
In dependence of the answer could you consider to use devm_kmalloc or __get_free_page?

Quoted 5 lines · Andy Shevchenko

Quoted 1 line

+ pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);

Where this memory will be freed?
In dependence of the answer could you consider to use devm_kmalloc or __get_free_page?

There is another function like this called pl022_dma_probe() that has the same allocation, and it gets freed in the same place.

It's probably worth changing this into something different, but I felt that it didn't belong into this patch. I was also not sure if the best option would be dmam_alloc_coherent, dev_kzalloc, or __get_free_page.

Quoted 8 lines · Arnd Bergmann

Quoted 5 lines · Andy Shevchenko

Quoted 1 line

+ pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);

Where this memory will be freed?
In dependence of the answer could you consider to use devm_kmalloc or __get_free_page?

Quoted 7 lines

There is another function like this called pl022_dma_probe() that has the same allocation, and it gets freed in the same place.

It's probably worth changing this into something different, but I felt that it didn't belong into this patch. I was also not sure if the best option would be dmam_alloc_coherent, dev_kzalloc, or __get_free_page.

Actually I once read about a feature where the kernel provides a static page full of zeroes or something like this, that would be ideal to use in cases like this, then all of this dummy page allocation and freeing can be deleted.

Quoted 4 lines · Linus Walleij

Actually I once read about a feature where the kernel provides a static page full of zeroes or something like this, that would be ideal to use in cases like this, then all of this dummy page allocation and freeing can be deleted.

You mean empty_zero_page? That only works if this page is read-only from the perspective of the DMA controller, but then it would be a good fit, yes.

Quoted 10 lines · Arnd Bergmann

Quoted 4 lines · Linus Walleij

Actually I once read about a feature where the kernel provides a static page full of zeroes or something like this, that would be ideal to use in cases like this, then all of this dummy page allocation and freeing can be deleted.

You mean empty_zero_page? That only works if this page is read-only from the perspective of the DMA controller, but then it would be a good fit, yes.

That's actually how it's used.

SPI is symmetric, and in the DMA case we're not poking data into the buffers from the CPU so the controller need something - anything - to stream to the block.

If we can use that page we'll even save a few remaps.

Quoted 12 lines · On Thursday 07 February 2013 21:19:04 Linus Walleij wrote:

Quoted 10 lines · Arnd Bergmann

Quoted 4 lines · Linus Walleij

Actually I once read about a feature where the kernel provides a static page full of zeroes or something like this, that would be ideal to use in cases like this, then all of this dummy page allocation and freeing can be deleted.

You mean empty_zero_page? That only works if this page is read-only from the perspective of the DMA controller, but then it would be a good fit, yes.

Quoted 7 lines

That's actually how it's used.

SPI is symmetric, and in the DMA case we're not poking data into the buffers from the CPU so the controller need something - anything - to stream to the block.

If we can use that page we'll even save a few remaps.

I'm slightly worried about the caching effects though. The idea of the empty-zero page is that all user processes get it when they read a page before they write to it, so the data in it can essentially always be cache-hot.

If we do DMA from that page to a device what would be the overhead of flushing the (clean) cache lines?

If it's DMA _to_ a device, then we will only ever clean the lines prior to a transfer, never invalidate them. So that's not really a concern. (There better not be any dirty cache lines associated with the empty zero page either.)

Quoted 4 lines · On Friday 08 February 2013 16:22:48 Russell King - ARM Linux wrote:

If it's DMA _to_ a device, then we will only ever clean the lines prior to a transfer, never invalidate them. So that's not really a concern. (There better not be any dirty cache lines associated with the empty zero page either.)

Right, makes sense. I thought I had read about a CPU that could not flush a cache line without also invalidating it, but that must have been something other than ARM, or maybe I'm misremembering it.

Actually I once read about a feature where the kernel provides a static page full of zeroes or something like this, that would be ideal to use in cases like this, then all of this dummy page allocation and freeing can be deleted.

With the new OF DMA binding, it is possible to completely avoid the need for platform_data for configuring a DMA channel. In cases where the platform has already been converted, calling dma_request_slave_channel should get all the necessary information from the device tree.

This also adds a binding document specific to the pl011 controller, and extends the generic primecell binding to mention "dmas" and other common properties.

Like the patch that converts the dw_dma controller, this is completely untested and is looking for someone to try it out.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Grant Likely <[email protected]>

Cc Jiri Slaby <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Linus Walleij <[email protected]>

Cc spi-devel-general at lists.sourceforge.net

Cc Viresh Kumar <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc Vinod Koul <[email protected]>

Cc devicetree-discuss at lists.ozlabs.org

Cc linux-arm-kernel at lists.infradead.org

This adds a complete DT binding for the arasan device driver. There is currently only one user, which is the spear13xx platform, so we don't actually have to parse all the properties until another user comes in, but this does use the generic DMA binding to find the DMA channel.

The patch is untested so far and is part of a series to convert the spear platform over to use the generic DMA binding, so it should stay with the rest of the series.

This replaces an earlier patch from Viresh Kumar to move the spear platform over to the generic DMA binding. This version is now based on the merged multiplatform capable spear platform, rather than the separate spear13xx/3xx/6xx directories.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Viresh Kumar <[email protected]>

Cc Vinod Koul <[email protected]>

Cc Andy Shevchenko <[email protected]>

Cc devicetree-discuss at lists.ozlabs.org

---
 arch/arm/boot/dts/spear1340.dtsi         |   3 +
 arch/arm/boot/dts/spear13xx.dtsi         |  25 +++++-
 arch/arm/mach-spear/generic.h            |   6 --
 arch/arm/mach-spear/include/mach/spear.h |   2 -
 arch/arm/mach-spear/spear1310.c          |  30 +-------
 arch/arm/mach-spear/spear1340.c          |  32 +-------
 arch/arm/mach-spear/spear13xx-dma.h      | 128 -------------------------------
 arch/arm/mach-spear/spear13xx.c          |  58 --------------
 8 files changed, 29 insertions(+), 255 deletions(-)
 delete mode 100644 arch/arm/mach-spear/spear13xx-dma.h

arch/arm/boot/dts/spear1340.dtsi +3 -0

index 34da11a..e1786a0 100644
@@ -113,6 +113,9 @@
                                reg = <0xb4100000 0x1000>;
                                interrupts = <0 105 0x4>;
                                status = "disabled";
+                               dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */
+                                       <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */
+                               dma-names = "tx", "rx";
                        };
 
                        thermal at e07008c4 {

arch/arm/boot/dts/spear13xx.dtsi +2 -0

index b4ca60f..45597fd 100644
@@ -98,13 +98,24 @@
                        reg = <0xb2800000 0x1000>;
                        interrupts = <0 29 0x4>;
                        status = "disabled";
+                       dmas = <&dwdma0 0 0 0 0>;
+                       dma-names = "data";
                };

You forgot spear-devel for this series.

Review

Quoted 2 lines

(quoted diff) +2 -0

+                       dma-channels = <8>;
+                       #dma-cells = <3>;