Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 2/27/2012 2:09 PM, Nicolas Ferre wrote: On 02/23/2012 04:57 PM, Cousson, Benoit : On 2/23/2012 4:51 PM, Nicolas Ferre wrote: On 02/23/2012 11:03 AM, Cousson, Benoit : Salut Nico, Coucou Benoit ;-) On 2/22/2012 11:59 AM, Nicolas Ferre wrote: On 01/27/2012 06:29 PM, Cousson, Benoit : Add some basic helpers to retrieve a DMA controller device_node and the DMA request line number. For legacy reason another API will export the DMA request number into a Linux resource of type IORESOURCE_DMA. This API is usable only on system with an unique DMA controller. Hi, I followed that discussion and I like very much the biding that Benoit is proposing. It will help me a lot with my current work on Atmel DMA controller. If I understand correctly, some rework is needed before it can be integrated in a stable git tree (I mean before we can base our work on top of it). So, in the meantime, what should I do to help and make things go forward? to be quite frank, I would be interested to have a working DMA enabled device soon ;-) Me too, but unfortunately, I was busy trying to add irq_domain and fixing issues with SPARSE_IRQ on OMAP :-( Been there, loved that ;-) Do you think that 3.4 is out of reach? Maybe not, from the comments, it looks like we should add a .xlate callback to allow any custom parsing of the DMA nodes attributes. I'll be more than happy, if you can finalize that patch :-) I will try to figure out what I can understand from the irq mechanism of .xlate and try to see if I can implement it on top of your patch. In fact that dma code is a big copy/paste of the of/gpio one and gpio was already managing .xlate function. I removed it because I thought it was useless for the DMA :-) You might just have to copy the original code... The thing is that with gpio, we can rely on the gpio_chip structure for having a common storage location of such .xlate callbacks. In our DMA case, I guess that we should not cling to dmaengine infrastructure because not all of us are using it right now. Yep, that's the main issue compared to GPIO or IRQ. So, maybe we should provide some simple xlate helpers like the irqdomain ones. But I fear that a callback directly called from the of_get_dma_request() function is not possible (the gpio code model). I think a well that we cannot much but a simple very abstract callback since we do not have any formal DMA representation? I'm not sure to understand you concern? On the other hand, the cookie based infrastructure seems a little overkill to me. It seems that, in this case, we must establish a relation between the DMA controller code and the device tree DMA helpers. Please correct me if I am wrong. Yes, and in our case the DMA controller cannot be specified with anything else than a Linux device for the moment. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 02/27/2012 03:22 PM, Cousson, Benoit : On 2/27/2012 2:09 PM, Nicolas Ferre wrote: On 02/23/2012 04:57 PM, Cousson, Benoit : On 2/23/2012 4:51 PM, Nicolas Ferre wrote: On 02/23/2012 11:03 AM, Cousson, Benoit : Salut Nico, Coucou Benoit ;-) On 2/22/2012 11:59 AM, Nicolas Ferre wrote: On 01/27/2012 06:29 PM, Cousson, Benoit : Add some basic helpers to retrieve a DMA controller device_node and the DMA request line number. For legacy reason another API will export the DMA request number into a Linux resource of type IORESOURCE_DMA. This API is usable only on system with an unique DMA controller. Hi, I followed that discussion and I like very much the biding that Benoit is proposing. It will help me a lot with my current work on Atmel DMA controller. If I understand correctly, some rework is needed before it can be integrated in a stable git tree (I mean before we can base our work on top of it). So, in the meantime, what should I do to help and make things go forward? to be quite frank, I would be interested to have a working DMA enabled device soon ;-) Me too, but unfortunately, I was busy trying to add irq_domain and fixing issues with SPARSE_IRQ on OMAP :-( Been there, loved that ;-) Do you think that 3.4 is out of reach? Maybe not, from the comments, it looks like we should add a .xlate callback to allow any custom parsing of the DMA nodes attributes. I'll be more than happy, if you can finalize that patch :-) I will try to figure out what I can understand from the irq mechanism of .xlate and try to see if I can implement it on top of your patch. In fact that dma code is a big copy/paste of the of/gpio one and gpio was already managing .xlate function. I removed it because I thought it was useless for the DMA :-) You might just have to copy the original code... The thing is that with gpio, we can rely on the gpio_chip structure for having a common storage location of such .xlate callbacks. In our DMA case, I guess that we should not cling to dmaengine infrastructure because not all of us are using it right now. Yep, that's the main issue compared to GPIO or IRQ. So, maybe we should provide some simple xlate helpers like the irqdomain ones. But I fear that a callback directly called from the of_get_dma_request() function is not possible (the gpio code model). I think a well that we cannot much but a simple very abstract callback since we do not have any formal DMA representation? I'm not sure to understand you concern? Well, in fact I cannot find a place where to store a xlate callback: - it have to be provided by the DMA controller (the one pointed out by the phandle) and not the caller of the of_get_dma_request() funtion - it has to be generic enough to match the dmaengine/non-dmaengine cases (so it cannot be stored in the dmaengine struct dma_device). So I guess that the very basic idea of returning the full DMA specifier (struct of_phandle_args) is the best... My only concern is that the helper becomes very short and empty in this case... Bye, -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 02/23/2012 11:03 AM, Cousson, Benoit :
Salut Nico,
Coucou Benoit ;-)
On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
On 01/27/2012 06:29 PM, Cousson, Benoit :
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Hi,
I followed that discussion and I like very much the biding that Benoit
is proposing. It will help me a lot with my current work on Atmel DMA
controller.
If I understand correctly, some rework is needed before it can be
integrated in a stable git tree (I mean before we can base our work on
top of it). So, in the meantime, what should I do to help and make
things go forward? to be quite frank, I would be interested to have a
working DMA enabled device soon ;-)
Me too, but unfortunately, I was busy trying to add irq_domain and
fixing issues with SPARSE_IRQ on OMAP :-(
Been there, loved that ;-)
Do you think that 3.4 is out of reach?
Maybe not, from the comments, it looks like we should add a .xlate
callback to allow any custom parsing of the DMA nodes attributes.
I'll be more than happy, if you can finalize that patch :-)
I will try to figure out what I can understand from the irq mechanism of
.xlate and try to see if I can implement it on top of your patch.
I will keep you informed...
Bye,
Best regards,
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130
+
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
+- #dma-cells: Number of cell for each DMA line, must be one.
+
+
+Example:
+
+sdma: dma-controller@4800 {
+compatible = ti,sdma-omap4
+reg =0x4800 0x1000;
+interrupts =12;
+dma-controller;
+#dma-cells =1;
+};
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a
phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the
dma-request
+ in the dma-request property.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request =sdma 2sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+def_bool y
+help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO)+= of_mdio.o
obj-$(CONFIG_OF_PCI)+= of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated -
http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/device.h
+#includelinux/err.h
+#includelinux/module.h
+#includelinux/of.h
+#includelinux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and
dma-controller node
+ * @np:device node to get DMA request from
+ *
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 2/23/2012 4:51 PM, Nicolas Ferre wrote: On 02/23/2012 11:03 AM, Cousson, Benoit : Salut Nico, Coucou Benoit ;-) On 2/22/2012 11:59 AM, Nicolas Ferre wrote: On 01/27/2012 06:29 PM, Cousson, Benoit : Add some basic helpers to retrieve a DMA controller device_node and the DMA request line number. For legacy reason another API will export the DMA request number into a Linux resource of type IORESOURCE_DMA. This API is usable only on system with an unique DMA controller. Hi, I followed that discussion and I like very much the biding that Benoit is proposing. It will help me a lot with my current work on Atmel DMA controller. If I understand correctly, some rework is needed before it can be integrated in a stable git tree (I mean before we can base our work on top of it). So, in the meantime, what should I do to help and make things go forward? to be quite frank, I would be interested to have a working DMA enabled device soon ;-) Me too, but unfortunately, I was busy trying to add irq_domain and fixing issues with SPARSE_IRQ on OMAP :-( Been there, loved that ;-) Do you think that 3.4 is out of reach? Maybe not, from the comments, it looks like we should add a .xlate callback to allow any custom parsing of the DMA nodes attributes. I'll be more than happy, if you can finalize that patch :-) I will try to figure out what I can understand from the irq mechanism of .xlate and try to see if I can implement it on top of your patch. In fact that dma code is a big copy/paste of the of/gpio one and gpio was already managing .xlate function. I removed it because I thought it was useless for the DMA :-) You might just have to copy the original code... I will keep you informed... Thanks for the help, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
Salut Nico,
On 2/22/2012 11:59 AM, Nicolas Ferre wrote:
On 01/27/2012 06:29 PM, Cousson, Benoit :
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Hi,
I followed that discussion and I like very much the biding that Benoit
is proposing. It will help me a lot with my current work on Atmel DMA
controller.
If I understand correctly, some rework is needed before it can be
integrated in a stable git tree (I mean before we can base our work on
top of it). So, in the meantime, what should I do to help and make
things go forward? to be quite frank, I would be interested to have a
working DMA enabled device soon ;-)
Me too, but unfortunately, I was busy trying to add irq_domain and
fixing issues with SPARSE_IRQ on OMAP :-(
Do you think that 3.4 is out of reach?
Maybe not, from the comments, it looks like we should add a .xlate
callback to allow any custom parsing of the DMA nodes attributes.
I'll be more than happy, if you can finalize that patch :-)
Thanks,
Benoit
Best regards,
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130 +
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
+- #dma-cells: Number of cell for each DMA line, must be one.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg =0x4800 0x1000;
+ interrupts =12;
+dma-controller;
+ #dma-cells =1;
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request =sdma 2sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/device.h
+#includelinux/err.h
+#includelinux/module.h
+#includelinux/of.h
+#includelinux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * @np:device node to get DMA request from
+ * @propname: property name containing DMA specifier(s)
+ * @index: index of the DMA request
+ * @ctrl_np: a device_node pointer to fill in
+ *
+ * Returns DMA number along to the dma controller node, or one of the errno
+ * value on the error condition. If @ctrl_np is not NULL the function also
+ * fills in the DMA
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 01/27/2012 06:29 PM, Cousson, Benoit :
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Hi,
I followed that discussion and I like very much the biding that Benoit
is proposing. It will help me a lot with my current work on Atmel DMA
controller.
If I understand correctly, some rework is needed before it can be
integrated in a stable git tree (I mean before we can base our work on
top of it). So, in the meantime, what should I do to help and make
things go forward? to be quite frank, I would be interested to have a
working DMA enabled device soon ;-)
Do you think that 3.4 is out of reach?
Best regards,
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130
+
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
+- #dma-cells: Number of cell for each DMA line, must be one.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg = 0x4800 0x1000;
+ interrupts = 12;
+dma-controller;
+ #dma-cells = 1;
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request = sdma 2 sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO)+= of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * @np: device node to get DMA request from
+ * @propname:property name containing DMA specifier(s)
+ * @index: index of the DMA request
+ * @ctrl_np: a device_node pointer to fill in
+ *
+ * Returns DMA number along to the dma controller node, or one of the errno
+ * value on the error condition. If @ctrl_np is not NULL the function also
+ * fills in the DMA controller device_node pointer.
+ */
+int of_get_dma_request(struct device_node *np, int index,
+struct device_node **ctrl_np)
+{
+ int ret = -EINVAL;
+ struct of_phandle_args dma_spec;
+
+ ret = of_parse_phandle_with_args(np, dma-request,
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On Wed, Feb 01, 2012 at 11:50:30AM +0100, Cousson, Benoit wrote: Hi Russell, On 2/1/2012 12:09 AM, Russell King - ARM Linux wrote: On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: This makes the assumption that dma specifiers will only ever be 1 cell. I think to be generally useful, the full dma specifier needs to be either handed to the dma controller to get a cookie or passed back to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. Fully agree, and this is exactly the idea of this DMA binding: First argument is always a DMA controller phandle and then you can add 0, 1 or more cells to define extra specifiers dependent of the DMA controller driver expectation. The one cell Grant was referring was just the extra specifier that is needed for a simple DMA engine like the SDMA we have inside OMAP. But the whole idea is to have a flexible enough mechanism to allow any kind of specifier. No more global linear number space like for IRQ! How does this work when you're stuffing a number into a struct resource as a plain DMA number? That looks very much like a linear number space, as you don't have a way to associate that number with anything else. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 2/2/2012 9:45 AM, Russell King - ARM Linux wrote: On Wed, Feb 01, 2012 at 11:50:30AM +0100, Cousson, Benoit wrote: Hi Russell, On 2/1/2012 12:09 AM, Russell King - ARM Linux wrote: On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: This makes the assumption that dma specifiers will only ever be 1 cell. I think to be generally useful, the full dma specifier needs to be either handed to the dma controller to get a cookie or passed back to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. Fully agree, and this is exactly the idea of this DMA binding: First argument is always a DMA controller phandle and then you can add 0, 1 or more cells to define extra specifiers dependent of the DMA controller driver expectation. The one cell Grant was referring was just the extra specifier that is needed for a simple DMA engine like the SDMA we have inside OMAP. But the whole idea is to have a flexible enough mechanism to allow any kind of specifier. No more global linear number space like for IRQ! How does this work when you're stuffing a number into a struct resource as a plain DMA number? That looks very much like a linear number space, as you don't have a way to associate that number with anything else. As explained in the kernel doc header and in the changelog, that one is for legacy purpose only. +/** + * of_dma_to_resource - Decode a node's DMA and return it as a resource + * @dev: pointer to device tree node + * @index: zero-based index of the DMA request + * @r: pointer to resource structure to return result into. + * + * Using a resource to export a DMA request number to a driver should + * be used only for legacy purpose and on system when only one DMA controller + * is present. + * The proper and only scalable way is to use the native of_get_dma_request API + * in order retrieve both the DMA controller device node and the DMA request + * line for that controller. + */ There is indeed no way to put information about DMA controller and DMA line in the resource structure except if we start hacking the start and end attributes. But I'm not sure anyone will want to do that. The only way to take benefit of the extra information DT can provide is to use the of_get_dma_request API. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
Hi Russell, On 2/1/2012 12:09 AM, Russell King - ARM Linux wrote: On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: This makes the assumption that dma specifiers will only ever be 1 cell. I think to be generally useful, the full dma specifier needs to be either handed to the dma controller to get a cookie or passed back to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. Fully agree, and this is exactly the idea of this DMA binding: First argument is always a DMA controller phandle and then you can add 0, 1 or more cells to define extra specifiers dependent of the DMA controller driver expectation. The one cell Grant was referring was just the extra specifier that is needed for a simple DMA engine like the SDMA we have inside OMAP. But the whole idea is to have a flexible enough mechanism to allow any kind of specifier. No more global linear number space like for IRQ! Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On Tue, Jan 31, 2012 at 10:26:19PM +0100, Cousson, Benoit wrote: Hi Grant, On 1/28/2012 7:06 PM, Grant Likely wrote: On Fri, Jan 27, 2012 at 06:29:22PM +0100, Cousson, Benoit wrote: +EXPORT_SYMBOL_GPL(of_dma_to_resource); How do you see this function being used? I ask because I don't want to add it to the DT device registration code (of_platform_populate()). Yep, that was the plan :-) I actually want to reduce the amount of work being done at device registration time and push resolving irqs out to the device drivers. The reason for this is so that drivers can resolve irqs supplied by other device drivers once I've got deferred probe merged. That make senses, but that will break all the drivers that are expecting IRQ and DMA resources to be already there at probe time. These drivers are still relying on the good old platform_get_resource() API. That will add some extra effort to the drivers migration to DT:-( They will be broken anyway because there isn't any way for the core code to decode DMA properties. There isn't a consistent way that drivers use DMA resources or any complete data about what dma engine those resources refer to. Unlike irqs, there is no global DMA channel number space available to driver, which makes it really hard to generically populate DMA channels into the resource table. It really is much better to resolve it at .probe() time where the driver can get unambiguous information. Plus, as I mentioned, it plays better with deferred probe. This isn't currently possible because a lot of drivers parse the resources table directly. Those users first need to be migrated to use the platform_get_irq*() APIs. But even in that case, the device should still have the resources populated before probe. I'm not sure I fully understand what you mean here. Ah, but once it is in an API, hooks can be implemented in the platform_get_*() APIs to resolve relevant things at call time instead of at device registration time. DMAs have the same issue, so it is important that device drivers resolve the dma specifier at .probe() time so that it can use dma channels supplied by a dma device driver. I suspect having a common of_parse_named_phandle_with_args() will useful when needing to resolve named dma resources from device drivers. So it looks like you really have a plan to deprecate all the platform_get_resource APIs usage from driver? At least for DMA and IRQ? I definitely would like to be rid of (or refactor) the DMA get APIs from drivers because I don't think they provide enough information about how DMA channels are hooked up (as described above). However, I actually prefer the platform_get_ API for irqs over accessing the resource table directly. I can hook into it if/when I change irqs to be resolved at .probe time. g. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
Hi Grant,
On 1/28/2012 7:06 PM, Grant Likely wrote:
On Fri, Jan 27, 2012 at 06:29:22PM +0100, Cousson, Benoit wrote:
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
Hey Benoit.
Good start to this. Comments below.
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130 +
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
I know gpio and interrupt controllers do this, but I'm not convinced
it is necessary. The compatible binding for the device will
implicitly state that the device is a dma controller and adopts the
generic dma binding.
That's fine by me, I was just thinking of a mechanism similar to the IRQ
controller to iterate over the dma controllers at early boot. But I
guess such approach should become useless with the deferred probe mechanism.
+- #dma-cells: Number of cell for each DMA line, must be one.
Must be one? Then why bother with the property?
Must be higher that one was the idea, but it looks like from Stephen's
comment that some simple DMA controller with only one line might even exist.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg =0x4800 0x1000;
+ interrupts =12;
+dma-controller;
+ #dma-cells =1;
Nit: inconsistent indentation (tabs/spaces)... and it looks like
you've got your tabs set to 4 characters. All rightstanding coders know
that the only holy and blessed tab stop is 8 characters, so remind me to
ridicule that 4 character nonsense out of you the next time we're in
the same room.:-}
Outch, I got caught!
I might have argued that this is my Python setting... but in fact the
PEP8 recommend the usage of 4 spaces... so I do not have any valid
excuse :-)
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
As Stephen mentioned, the -names should not be required.
Yep, the code is already doing that, the documentation was wrong.
BTW, should it be dma-request or dma-requests?
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request =sdma 2sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includelinux/device.h
+#includelinux/err.h
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On Sat, Jan 28, 2012 at 11:06:02AM -0700, Grant Likely wrote: This makes the assumption that dma specifiers will only ever be 1 cell. I think to be generally useful, the full dma specifier needs to be either handed to the dma controller to get a cookie or passed back to the caller in its entirety. More to the point, who says that the DMA specifier is even an integer? When people are using DMA engines, it (probably) isn't an integer at all. Several platforms I know of use strings for this. Some platforms can even select between two or more DMA engines for handling the same peripheral - I believe Samsung do this depending on their individual workloads. However, the opaque DMA engine API for requesting a channel doesn't lend itself well to DT, as the match data and match function are entirely left to the individual DMA engine driver and/or platform itself. As far as creating another linear number space for DMA stuff, I'd really suggest against that - you're going to need some additional code in place to manage that numberspace. If you at least use a two- paid cookie, eg 'dma controller phandle + request signal' then that makes all the stuff we're starting to see with the IRQ subsystem, IRQ domains etc become completely unnecessary. I guess what I'm saying is ignore the flat number space, and go straight to some kind of 'dma domains' solution from the start. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On Fri, Jan 27, 2012 at 09:36:05PM +0100, Cousson, Benoit wrote:
On 1/27/2012 7:13 PM, Stephen Warren wrote:
Cousson, Benoit wrote at Friday, January 27, 2012 10:29 AM:
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
+int of_get_dma_request(struct device_node *np, int index,
+ struct device_node **ctrl_np)
+{
+ int ret = -EINVAL;
+ struct of_phandle_args dma_spec;
+
+ ret = of_parse_phandle_with_args(np, dma-request, #dma-cells,
+index,dma_spec);
+ if (ret) {
+ pr_debug(%s: can't parse dma property\n, __func__);
+ goto err0;
+ }
+
+ if (dma_spec.args_count 0)
+ ret = dma_spec.args[0];
Doesn't that force #dma-cells 0? What about a DMA controller that only
supports a single DMA request, in which case you might want #dma-cells==0?
OK, if such DMA controller exist, it will make sense.
Having an of_xlate for the controller would be useful here in general:
Is a single int really enough here?
Some DMA controllers have N channels that can be used for arbitrary
things. You may need to specify the DMA request once when allocating the
channel, or maybe individual for each transfer if it can vary. Other
controllers may need a special channel ID for each type of request. There
are probably more cases I haven't thought of.
In my naive view of the DMA controller the channel is something that
will be handled and allocated by the DMA controller upon driver
request. So this is not something that is necessarily HW related,
and thus should not be described in DT.
But, maybe I'm missing your point.
The binding for each dma controller gets to decide the format and size
of the dma spec (just like for irq and gpio specs). The data in the
spec is opaque to the DMA users, and only has meaning after code with
knowledge of the specific dma controller binding .xlates it into
something useful.
So for OMAP, the binding may trivially map, but other DMA controllers
may require flags or other configuration encoded into the DMA spec.
The generic binding must take that into account.
I suppose a controller may be able to represent that cookie in a single
int, but perhaps not, e.g. if a binding needs #dma-cells=4 for some
reason. Perhaps returning a void* here would be better, coupled with
of_put_dma_request() to allow the controller to free it if required?
That'd allow individual controller bindings to specify e.g. HW FIFO
width, wrap, FIFO levels for HW flow control, ...
(I vaguely recall that dmaengine addresses some of this already, but
unfortunately I'm not very familiar with it yet)
Me neither, but do we have to handle all this parameters in DT? I
guess that most of the configuration will still be under driver
responsibility for the channel. The DMA controller itself can
clearly defined a bunch of parameters to expose its capabilities,
but again so far I do not have any clue about all these fancy DMA
controller variants. Some flexibility will clearly be needed, but
how far should we go?
It goes as far as the binding author deems is appropriate. For your
case it sounds like 1 cell is sufficient, so go with that. Just don't
restrict other binding authors from encoding more (or less) data.
Especially when it is trivial to allow #dma-cells != 1.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On Fri, Jan 27, 2012 at 06:29:22PM +0100, Cousson, Benoit wrote:
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Hey Benoit.
Good start to this. Comments below.
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130
+
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
I know gpio and interrupt controllers do this, but I'm not convinced
it is necessary. The compatible binding for the device will
implicitly state that the device is a dma controller and adopts the
generic dma binding.
+- #dma-cells: Number of cell for each DMA line, must be one.
Must be one? Then why bother with the property?
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg = 0x4800 0x1000;
+ interrupts = 12;
+dma-controller;
+ #dma-cells = 1;
Nit: inconsistent indentation (tabs/spaces)... and it looks like
you've got your tabs set to 4 characters. All rightstanding coders know
that the only holy and blessed tab stop is 8 characters, so remind me to
ridicule that 4 character nonsense out of you the next time we're in
the same room. :-}
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
As Stephen mentioned, the -names should not be required.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request = sdma 2 sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO)+= of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * @np: device node to get DMA request from
+ * @propname:property name containing DMA specifier(s)
+ * @index: index of the DMA request
+ * @ctrl_np: a device_node pointer to fill in
+ *
+ * Returns DMA number along to the dma controller node, or one of the errno
+ * value on the error condition. If @ctrl_np is not NULL the function also
+ * fills in the DMA controller device_node pointer.
+ */
+int of_get_dma_request(struct device_node *np, int index,
+
[RFC PATCH 1/2] of: Add generic device tree DMA helpers
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 44 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 130 +
include/linux/of_dma.h| 49 +
5 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..7f2a301
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,44 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required properties:
+- dma-controller: Mark the device as a DMA controller
+- #dma-cells: Number of cell for each DMA line, must be one.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg = 0x4800 0x1000;
+ interrupts = 12;
+dma-controller;
+ #dma-cells = 1;
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+i2c1: i2c@1 {
+...
+dma-request = sdma 2 sdma 3;
+dma-request-names = tx, rx;
+...
+};
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..d08443b 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..d4927e2
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,130 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_dma.h
+
+/**
+ * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * @np:device node to get DMA request from
+ * @propname: property name containing DMA specifier(s)
+ * @index: index of the DMA request
+ * @ctrl_np: a device_node pointer to fill in
+ *
+ * Returns DMA number along to the dma controller node, or one of the errno
+ * value on the error condition. If @ctrl_np is not NULL the function also
+ * fills in the DMA controller device_node pointer.
+ */
+int of_get_dma_request(struct device_node *np, int index,
+ struct device_node **ctrl_np)
+{
+ int ret = -EINVAL;
+ struct of_phandle_args dma_spec;
+
+ ret = of_parse_phandle_with_args(np, dma-request, #dma-cells,
+index, dma_spec);
+ if (ret) {
+ pr_debug(%s: can't parse dma property\n, __func__);
+ goto err0;
+ }
+
+ if (dma_spec.args_count 0)
+ ret = dma_spec.args[0];
+
+ if (ctrl_np)
+ *ctrl_np = dma_spec.np;
+ else
+ of_node_put(dma_spec.np);
+
+err0:
+ pr_debug(%s exited with status %d\n, __func__, ret);
+ return ret;
+}
+EXPORT_SYMBOL(of_get_dma_request);
+
+/**
+ * of_dma_count - Count DMA requests for a device
+ * @np:device node to count DMAs for
+ *
+ * The function returns the count of DMA
Re: [RFC PATCH 1/2] of: Add generic device tree DMA helpers
On 1/27/2012 7:13 PM, Stephen Warren wrote:
Cousson, Benoit wrote at Friday, January 27, 2012 10:29 AM:
Add some basic helpers to retrieve a DMA controller device_node
and the DMA request line number.
For legacy reason another API will export the DMA request number
into a Linux resource of type IORESOURCE_DMA.
This API is usable only on system with an unique DMA controller.
This binding looks reasonable to me; it's pretty much exactly what I
was expecting the custom Tegra I2S binding might evolve into. A couple
comments inline...
Well, that does not surprise me since this is your Tegra I2S binding
that made me think that it should be time to define that generic DMA
binding we've been waiting for a while :-)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
+* DMA client
+
+Client drivers should specify the DMA request numbers using a phandle to
+the controller + the DMA request number on that controller.
+
+Required properties:
+- dma-request: List of pair phandle + dma-request per line
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
I think property dma-request-names should be optional; some drives will
simply request by index and hence the property won't be needed. Same as
the common clock binding.
Yes, indeed, and it is optional in the code. I wrongly added that in the
required paragraph. I'll fix that.
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
+int of_get_dma_request(struct device_node *np, int index,
+ struct device_node **ctrl_np)
+{
+ int ret = -EINVAL;
+ struct of_phandle_args dma_spec;
+
+ ret = of_parse_phandle_with_args(np, dma-request, #dma-cells,
+index,dma_spec);
+ if (ret) {
+ pr_debug(%s: can't parse dma property\n, __func__);
+ goto err0;
+ }
+
+ if (dma_spec.args_count 0)
+ ret = dma_spec.args[0];
Doesn't that force #dma-cells 0? What about a DMA controller that only
supports a single DMA request, in which case you might want #dma-cells==0?
OK, if such DMA controller exist, it will make sense.
Having an of_xlate for the controller would be useful here in general:
Is a single int really enough here?
Some DMA controllers have N channels that can be used for arbitrary
things. You may need to specify the DMA request once when allocating the
channel, or maybe individual for each transfer if it can vary. Other
controllers may need a special channel ID for each type of request. There
are probably more cases I haven't thought of.
In my naive view of the DMA controller the channel is something that
will be handled and allocated by the DMA controller upon driver request.
So this is not something that is necessarily HW related, and thus should
not be described in DT.
But, maybe I'm missing your point.
So in general, I think this API should return some kind of cookie that's
meaningful to the DMA controller, and this should be provided back to
the DMA controller with every API that might need it; channel allocation,
DMA transfer request, etc.
Forgive my ignorance, but the only DMA controller I've been using for a
while is the OMAP2+ SDMA, hence this simplistic API that fit perfectly
the OMAP need.
So I guess that having an xlate function like GPIO and IRQ will make
sense if we have to handle these kind of variants.
I suppose a controller may be able to represent that cookie in a single
int, but perhaps not, e.g. if a binding needs #dma-cells=4 for some
reason. Perhaps returning a void* here would be better, coupled with
of_put_dma_request() to allow the controller to free it if required?
That'd allow individual controller bindings to specify e.g. HW FIFO
width, wrap, FIFO levels for HW flow control, ...
(I vaguely recall that dmaengine addresses some of this already, but
unfortunately I'm not very familiar with it yet)
Me neither, but do we have to handle all this parameters in DT? I guess
that most of the configuration will still be under driver responsibility
for the channel. The DMA controller itself can clearly defined a bunch
of parameters to expose its capabilities, but again so far I do not have
any clue about all these fancy DMA controller variants. Some flexibility
will clearly be needed, but how far should we go?
The goal of that RFC was to start gathering some feedback to understand
the requirements for the DMA bindings, so at least I have a couple of
new ones now :-).
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
+#ifdef CONFIG_OF_GPIO
CONFIG_OF_DMA
Oops, some leftover from the of_gpio.h copy-paste.
Thanks for the good feedback,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
