[PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA

[PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA

[Jon Hunter]

Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client
bindings are also added for devices that have SPI and MMC bindings
populated. Client binding data is based upon existing HWMOD data for
OMAP and has been checked against OMAP documentation.

Testing includes ...
1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and
   OMAP4460 Panda board with and without device-tree present.
2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430
   Panda board and OMAP4460 Panda board with and without device-tree
   present.

Testing branch available here [1].

Series is based upon v3.8-rc6 on top of the following ...
- Vinod's topic/dmaengine_dt branch [2]
- Matt Porter's series "DMA Engine support for AM33XX" [3]
- Matt Porter's series "omap_hsmmc DT DMA Client support" [4]
- Sourav Poddar's series "add omap mcspi device tree data" [5]

[1] https://github.com/jonhunter/linux/commits/dev-dt-dma
[2] http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt
[3] http://permalink.gmane.org/gmane.linux.kernel.spi.devel/12508
[4] http://permalink.gmane.org/gmane.linux.ports.arm.omap/93165
[5] http://permalink.gmane.org/gmane.linux.kernel/1435002

Jon Hunter (2):
  ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
  dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

 .../devicetree/bindings/dma/omap-sdma.txt          |   44 ++++++++++++++++++++
 arch/arm/boot/dts/omap2.dtsi                       |   12 ++++++
 arch/arm/boot/dts/omap3.dtsi                       |   40 ++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi                       |   41 ++++++++++++++++++
 arch/arm/boot/dts/omap5.dtsi                       |   41 ++++++++++++++++++
 drivers/dma/omap-dma.c                             |   31 +++++++++++++-
 6 files changed, 208 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt

-- 
1.7.10.4

[PATCH 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes

[Jon Hunter]

Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 .../devicetree/bindings/dma/omap-sdma.txt          |   44 ++++++++++++++++++++
 arch/arm/boot/dts/omap2.dtsi                       |   12 ++++++
 arch/arm/boot/dts/omap3.dtsi                       |   40 ++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi                       |   41 ++++++++++++++++++
 arch/arm/boot/dts/omap5.dtsi                       |   41 ++++++++++++++++++
 5 files changed, 178 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt

diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 0000000..5c2c125
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,44 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible: 		Must be "ti,omap-sdma"
+- reg: 			Contains DMA registers location and length.
+- interrupts: 		Contains DMA interrupt information.
+- #dma-cells: 		Must be 1.
+- #dma-channels:	Contains total number of programmable DMA channels.
+- #dma-requests:	Contains total number of DMA requests.
+
+Example:
+
+	sdma: dma-controller@4A056000 {
+		compatible = "ti,omap-sdma";
+		reg = <0x4A056000 0x1000>;
+		interrupts = <0 12 0x4>,
+			     <0 13 0x4>,
+			     <0 14 0x4>,
+			     <0 15 0x4>;
+		#dma-cells = <1>;
+		#dma-channels = <32>;
+		#dma-requests = <127>;
+	};
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas:			List of one or more DMA specifiers, each consisting of
+			- A phandle pointing to DMA controller node
+			- The DMA request number associated with client device
+- dma-names: 		Contains one identifier string for each dma specifier in
+			the dmas property. The specific strings that can be used
+			are defined in the binding of the DMA client device.
+
+Example:
+
+	mmc1: mmc@4809c000 {
+		...
+		dmas = <&sdma 61>,	/* TX channel */
+		       <&sdma 62>;	/* RX channel */
+		dma-names = "tx", "rx";
+		...
+	};
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..7288972 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -49,6 +49,18 @@
 			reg = <0x480FE000 0x1000>;
 		};
 
+		sdma: dma-controller@48056000 {
+			compatible = "ti,omap-sdma";
+			reg = <0x48056000 0x1000>;
+			interrupts = <12>,
+				     <13>,
+				     <14>,
+				     <15>;
+			#dma-cells = <1>;
+			#dma-channels = <32>;
+			#dma-requests = <64>;
+		};
+
 		uart1: serial@4806a000 {
 			compatible = "ti,omap2-uart";
 			ti,hwmods = "uart1";
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..4d63aa2 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -75,6 +75,18 @@
 			reg = <0x48200000 0x1000>;
 		};
 
+		sdma: dma-controller@48056000 {
+			compatible = "ti,omap-sdma";
+			reg = <0x48056000 0x1000>;
+			interrupts = <12>,
+				     <13>,
+				     <14>,
+				     <15>;
+			#dma-cells = <1>;
+			#dma-channels = <32>;
+			#dma-requests = <96>;
+		};
+
 		omap3_pmx_core: pinmux@48002030 {
 			compatible = "ti,omap3-padconf", "pinctrl-single";
 			reg = <0x48002030 0x05cc>;
@@ -192,6 +204,16 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi1";
 			ti,spi-num-cs = <4>;
+			dmas = <&sdma 35>,
+			       <&sdma 36>,
+			       <&sdma 37>,
+			       <&sdma 38>,
+			       <&sdma 39>,
+			       <&sdma 40>,
+			       <&sdma 41>,
+			       <&sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
 		};
 
 		mcspi2: spi@4809a000 {
@@ -200,6 +222,11 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi2";
 			ti,spi-num-cs = <2>;
+			dmas = <&sdma 43>,
+			       <&sdma 44>,
+			       <&sdma 45>,
+			       <&sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
 		};
 
 		mcspi3: spi@480b8000 {
@@ -208,6 +235,11 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi3";
 			ti,spi-num-cs = <2>;
+			dmas = <&sdma 15>,
+			       <&sdma 16>,
+			       <&sdma 23>,
+			       <&sdma 24>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
 		};
 
 		mcspi4: spi@480ba000 {
@@ -216,22 +248,30 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi4";
 			ti,spi-num-cs = <1>;
+			dmas = <&sdma 70>, <&sdma 71>;
+			dma-names = "tx0", "rx0";
 		};
 
 		mmc1: mmc@4809c000 {
 			compatible = "ti,omap3-hsmmc";
 			ti,hwmods = "mmc1";
 			ti,dual-volt;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc2: mmc@480b4000 {
 			compatible = "ti,omap3-hsmmc";
 			ti,hwmods = "mmc2";
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc3: mmc@480ad000 {
 			compatible = "ti,omap3-hsmmc";
 			ti,hwmods = "mmc3";
+			dmas = <&sdma 77>, <&sdma 78>;
+			dma-names = "tx", "rx";
 		};
 
 		wdt2: wdt@48314000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..3af3ccb 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -118,6 +118,18 @@
 			pinctrl-single,function-mask = <0x7fff>;
 		};
 
+		sdma: dma-controller@4A056000 {
+			compatible = "ti,omap-sdma";
+			reg = <0x4A056000 0x1000>;
+			interrupts = <0 12 0x4>,
+				     <0 13 0x4>,
+				     <0 14 0x4>,
+				     <0 15 0x4>;
+			#dma-cells = <1>;
+			#dma-channels = <32>;
+			#dma-requests = <127>;
+		};
+
 		gpio1: gpio@4a310000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x4a310000 0x200>;
@@ -260,6 +272,16 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi1";
 			ti,spi-num-cs = <4>;
+			dmas = <&sdma 35>,
+			       <&sdma 36>,
+			       <&sdma 37>,
+			       <&sdma 38>,
+			       <&sdma 39>,
+			       <&sdma 40>,
+			       <&sdma 41>,
+			       <&sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
 		};
 
 		mcspi2: spi@4809a000 {
@@ -270,6 +292,11 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi2";
 			ti,spi-num-cs = <2>;
+			dmas = <&sdma 43>,
+			       <&sdma 44>,
+			       <&sdma 45>,
+			       <&sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
 		};
 
 		mcspi3: spi@480b8000 {
@@ -280,6 +307,8 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi3";
 			ti,spi-num-cs = <2>;
+			dmas = <&sdma 15>, <&sdma 16>;
+			dma-names = "tx0", "rx0";
 		};
 
 		mcspi4: spi@480ba000 {
@@ -290,6 +319,8 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi4";
 			ti,spi-num-cs = <1>;
+			dmas = <&sdma 70>, <&sdma 71>;
+			dma-names = "tx0", "rx0";
 		};
 
 		mmc1: mmc@4809c000 {
@@ -299,6 +330,8 @@
 			ti,hwmods = "mmc1";
 			ti,dual-volt;
 			ti,needs-special-reset;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc2: mmc@480b4000 {
@@ -307,6 +340,8 @@
 			interrupts = <0 86 0x4>;
 			ti,hwmods = "mmc2";
 			ti,needs-special-reset;
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc3: mmc@480ad000 {
@@ -315,6 +350,8 @@
 			interrupts = <0 94 0x4>;
 			ti,hwmods = "mmc3";
 			ti,needs-special-reset;
+			dmas = <&sdma 77>, <&sdma 78>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc4: mmc@480d1000 {
@@ -323,6 +360,8 @@
 			interrupts = <0 96 0x4>;
 			ti,hwmods = "mmc4";
 			ti,needs-special-reset;
+			dmas = <&sdma 57>, <&sdma 58>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc5: mmc@480d5000 {
@@ -331,6 +370,8 @@
 			interrupts = <0 59 0x4>;
 			ti,hwmods = "mmc5";
 			ti,needs-special-reset;
+			dmas = <&sdma 59>, <&sdma 60>;
+			dma-names = "tx", "rx";
 		};
 
 		wdt2: wdt@4a314000 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 9e182a9..96402a7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -108,6 +108,18 @@
 			      <0x48212000 0x1000>;
 		};
 
+		sdma: dma-controller@4A056000 {
+			compatible = "ti,omap-sdma";
+			reg = <0x4A056000 0x1000>;
+			interrupts = <0 12 0x4>,
+				     <0 13 0x4>,
+				     <0 14 0x4>,
+				     <0 15 0x4>;
+			#dma-cells = <1>;
+			#dma-channels = <32>;
+			#dma-requests = <127>;
+		};
+
 		gpio1: gpio@4ae10000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x4ae10000 0x200>;
@@ -249,6 +261,16 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi1";
 			ti,spi-num-cs = <4>;
+			dmas = <&sdma 35>,
+			       <&sdma 36>,
+			       <&sdma 37>,
+			       <&sdma 38>,
+			       <&sdma 39>,
+			       <&sdma 40>,
+			       <&sdma 41>,
+			       <&sdma 42>;
+			dma-names = "tx0", "rx0", "tx1", "rx1",
+				    "tx2", "rx2", "tx3", "rx3";
 		};
 
 		mcspi2: spi@4809a000 {
@@ -259,6 +281,11 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi2";
 			ti,spi-num-cs = <2>;
+			dmas = <&sdma 43>,
+			       <&sdma 44>,
+			       <&sdma 45>,
+			       <&sdma 46>;
+			dma-names = "tx0", "rx0", "tx1", "rx1";
 		};
 
 		mcspi3: spi@480b8000 {
@@ -269,6 +296,8 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi3";
 			ti,spi-num-cs = <2>;
+			dmas = <&sdma 15>, <&sdma 16>;
+			dma-names = "tx0", "rx0";
 		};
 
 		mcspi4: spi@480ba000 {
@@ -279,6 +308,8 @@
 			#size-cells = <0>;
 			ti,hwmods = "mcspi4";
 			ti,spi-num-cs = <1>;
+			dmas = <&sdma 70>, <&sdma 71>;
+			dma-names = "tx0", "rx0";
 		};
 
 		uart1: serial@4806a000 {
@@ -336,6 +367,8 @@
 			ti,hwmods = "mmc1";
 			ti,dual-volt;
 			ti,needs-special-reset;
+			dmas = <&sdma 61>, <&sdma 62>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc2: mmc@480b4000 {
@@ -344,6 +377,8 @@
 			interrupts = <0 86 0x4>;
 			ti,hwmods = "mmc2";
 			ti,needs-special-reset;
+			dmas = <&sdma 47>, <&sdma 48>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc3: mmc@480ad000 {
@@ -352,6 +387,8 @@
 			interrupts = <0 94 0x4>;
 			ti,hwmods = "mmc3";
 			ti,needs-special-reset;
+			dmas = <&sdma 77>, <&sdma 78>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc4: mmc@480d1000 {
@@ -360,6 +397,8 @@
 			interrupts = <0 96 0x4>;
 			ti,hwmods = "mmc4";
 			ti,needs-special-reset;
+			dmas = <&sdma 57>, <&sdma 58>;
+			dma-names = "tx", "rx";
 		};
 
 		mmc5: mmc@480d5000 {
@@ -368,6 +407,8 @@
 			interrupts = <0 59 0x4>;
 			ti,hwmods = "mmc5";
 			ti,needs-special-reset;
+			dmas = <&sdma 59>, <&sdma 60>;
+			dma-names = "tx", "rx";
 		};
 
 		keypad: keypad@4ae1c000 {
-- 
1.7.10.4

[PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
 drivers/dma/omap-dma.c |   31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 5a31264..a32d81b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/of_dma.h>
+#include <linux/of_device.h>
 
 #include "virt-dma.h"
 
@@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
 	[OMAP_DMA_DATA_TYPE_S32] = 4,
 };
 
+static struct of_dma_filter_info info;
+
 static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
 {
 	return container_of(d, struct omap_dmadev, ddev);
@@ -621,10 +625,25 @@ static int omap_dma_probe(struct platform_device *pdev)
 		pr_warn("OMAP-DMA: failed to register slave DMA engine device: %d\n",
 			rc);
 		omap_dma_free(od);
+		return rc;
 	} else {
 		platform_set_drvdata(pdev, od);
 	}
 
+	if (pdev->dev.of_node) {
+		info.dma_cap = od->ddev.cap_mask;
+		info.filter_fn = omap_dma_filter_fn;
+
+		/* Device-tree DMA controller registration */
+		rc = of_dma_controller_register(pdev->dev.of_node,
+				of_dma_simple_xlate, &info);
+		if (rc) {
+			pr_warn("OMAP-DMA: failed to register DMA controller\n");
+			dma_async_device_unregister(&od->ddev);
+			omap_dma_free(od);
+		}
+	}
+
 	dev_info(&pdev->dev, "OMAP DMA engine driver\n");
 
 	return rc;
@@ -634,18 +653,28 @@ static int omap_dma_remove(struct platform_device *pdev)
 {
 	struct omap_dmadev *od = platform_get_drvdata(pdev);
 
+	if (pdev->dev.of_node)
+		of_dma_controller_free(pdev->dev.of_node);
+
 	dma_async_device_unregister(&od->ddev);
 	omap_dma_free(od);
 
 	return 0;
 }
 
+static const struct of_device_id omap_dma_match[] = {
+	{ .compatible = "ti,omap-sdma", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, omap_dma_match);
+
 static struct platform_driver omap_dma_driver = {
 	.probe	= omap_dma_probe,
 	.remove	= omap_dma_remove,
 	.driver = {
 		.name = "omap-dma-engine",
 		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(omap_dma_match)
 	},
 };
 
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
 {
 	int rc = platform_driver_register(&omap_dma_driver);
 
-	if (rc == 0) {
+	if ((rc == 0) && (!of_have_populated_dt())) {
 		pdev = platform_device_register_full(&omap_dma_dev_info);
 		if (IS_ERR(pdev)) {
 			platform_driver_unregister(&omap_dma_driver);
-- 
1.7.10.4

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

On 02/06/2013 03:03 PM, Jon Hunter wrote:
> If the device-tree blob is present during boot, then register the SDMA
> controller with the device-tree DMA driver so that we can use device-tree
> to look-up DMA client information.
> 
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
>  drivers/dma/omap-dma.c |   31 ++++++++++++++++++++++++++++++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 5a31264..a32d81b 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -16,6 +16,8 @@
>  #include <linux/platform_device.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
> +#include <linux/of_dma.h>
> +#include <linux/of_device.h>
>  
>  #include "virt-dma.h"
>  
> @@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
>  	[OMAP_DMA_DATA_TYPE_S32] = 4,
>  };
>  
> +static struct of_dma_filter_info info;
> +
>  static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
>  {
>  	return container_of(d, struct omap_dmadev, ddev);
> @@ -621,10 +625,25 @@ static int omap_dma_probe(struct platform_device *pdev)
>  		pr_warn("OMAP-DMA: failed to register slave DMA engine device: %d\n",
>  			rc);
>  		omap_dma_free(od);
> +		return rc;
>  	} else {
>  		platform_set_drvdata(pdev, od);
>  	}

I realise now that I could get rid of the else here and just call
platform_set_drvdata(), if we don't return.

Anyway, I will wait for other comments before changing.

Cheers
Jon

Re: [PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Wed, Feb 06, 2013 at 03:03:14PM -0600, Jon Hunter wrote:
> Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client
> bindings are also added for devices that have SPI and MMC bindings
> populated. Client binding data is based upon existing HWMOD data for
> OMAP and has been checked against OMAP documentation.
> 
> Testing includes ...
> 1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and
>    OMAP4460 Panda board with and without device-tree present.
> 2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430
>    Panda board and OMAP4460 Panda board with and without device-tree
>    present.

looks alright to me:

Reviewed-by: Felipe Balbi <balbi@ti.com>

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA

[Peter Ujfalusi]

Hi Jon,

On 02/06/2013 10:03 PM, Jon Hunter wrote:
> Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client
> bindings are also added for devices that have SPI and MMC bindings
> populated. Client binding data is based upon existing HWMOD data for
> OMAP and has been checked against OMAP documentation.
> 
> Testing includes ...
> 1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and
>    OMAP4460 Panda board with and without device-tree present.
> 2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430
>    Panda board and OMAP4460 Panda board with and without device-tree
>    present.

I looked briefly around in the mentioned code and I wonder how this is going
to work with audio (ASoC).
When we boot with DT it looks like we are _not_ creating the DMA resources for
the device as it is done for the IRQ and IO/MEM. So this means that we can not
use get_resource*() for DMA anymore when we move to DT.
This might be OK for (OMAP)mmc, (OMAP)spi, etc. But in audio we have a common
library used by all platforms to deal with the dmaengine.
I don't think we can switch to use dma_request_slave_channel_compat() in
soc-dmaengine-pcm.c. We need to pass the dma channel number to the lib from
the ASoC platform drivers. Or we need to synchronize the order of the dmas and
the dma-names around all SOCs in existence?

Has anyone thought about this?

CC-ing Mark Brown and Lars-Peter Clausen they might already know the answer to
this.

> 
> Testing branch available here [1].
> 
> Series is based upon v3.8-rc6 on top of the following ...
> - Vinod's topic/dmaengine_dt branch [2]
> - Matt Porter's series "DMA Engine support for AM33XX" [3]
> - Matt Porter's series "omap_hsmmc DT DMA Client support" [4]
> - Sourav Poddar's series "add omap mcspi device tree data" [5]
> 
> [1] https://github.com/jonhunter/linux/commits/dev-dt-dma
> [2] http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt
> [3] http://permalink.gmane.org/gmane.linux.kernel.spi.devel/12508
> [4] http://permalink.gmane.org/gmane.linux.ports.arm.omap/93165
> [5] http://permalink.gmane.org/gmane.linux.kernel/1435002
> 
> Jon Hunter (2):
>   ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
>   dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
> 
>  .../devicetree/bindings/dma/omap-sdma.txt          |   44 ++++++++++++++++++++
>  arch/arm/boot/dts/omap2.dtsi                       |   12 ++++++
>  arch/arm/boot/dts/omap3.dtsi                       |   40 ++++++++++++++++++
>  arch/arm/boot/dts/omap4.dtsi                       |   41 ++++++++++++++++++
>  arch/arm/boot/dts/omap5.dtsi                       |   41 ++++++++++++++++++
>  drivers/dma/omap-dma.c                             |   31 +++++++++++++-
>  6 files changed, 208 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
> 


-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA

[Arnd Bergmann]

On Thursday 07 February 2013 14:18:05 Peter Ujfalusi wrote:
> I looked briefly around in the mentioned code and I wonder how this is going
> to work with audio (ASoC).
> When we boot with DT it looks like we are _not_ creating the DMA resources for
> the device as it is done for the IRQ and IO/MEM. So this means that we can not
> use get_resource*() for DMA anymore when we move to DT.

Yes, this is very much intentional. The use of DMA resources is not
really possible across platforms, and I would like to kill it off
entirely, as it is not clearly defined what they actually mean.
In many cases, a single number cannot express the configuration
for a DMA channel, e.g. when you have multiple DMA engines in the
system, or you have one that can drive multiple masters for instance.

While we could in theory extend the infrastructure around DMA resources
to behave like IRQ resources, which can deal with all of that, this
would require a lot of code, and go against the trend: in case of
GPIO numbers and IRQ numbers, people are generally trying to
find ways to get rid of a flat number space and use a more structured
interface.

> This might be OK for (OMAP)mmc, (OMAP)spi, etc. But in audio we have a common
> library used by all platforms to deal with the dmaengine.
>
> I don't think we can switch to use dma_request_slave_channel_compat() in
> soc-dmaengine-pcm.c. We need to pass the dma channel number to the lib from
> the ASoC platform drivers. Or we need to synchronize the order of the dmas and
> the dma-names around all SOCs in existence?
> 
> Has anyone thought about this?

It's the first time I look at the sounds specific portion of this,
but it seems straightforward:

snd_dmaengine_pcm_open is a wrapper around dma_request_channel
and requires a filter function plus data as arguments. We don't
want to use filter functions here any more because they don't
do what we need, so the logical conclusion is to add a similar
wrapper around dma_request_slave_channel, and port drivers to
use that instead.

I see no connection in ASoC between the use of IORESOURCE_DMA
and snd_dmaengine_pcm_open. About half of the drivers calling
that function get the argument from a dma resource, while the
other ones don't. Similarly, not all ASoC drivers using DMA
resources pass the contents of that into snd_dmaengine_pcm_open.

	Arnd

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Arnd Bergmann]

On Wednesday 06 February 2013, Jon Hunter wrote:
> +static struct of_dma_filter_info info;

Both members of this structure are constant, so you can just initialize it here,
and it would be nice to give it a more descriptive name, such as omap_dmadev_info.

>  static struct platform_driver omap_dma_driver = {
>  	.probe	= omap_dma_probe,
>  	.remove	= omap_dma_remove,
>  	.driver = {
>  		.name = "omap-dma-engine",
>  		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(omap_dma_match)
>  	},
>  };

please end the new line with a comma.
  
> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
>  {
>  	int rc = platform_driver_register(&omap_dma_driver);
>  
> -	if (rc == 0) {
> +	if ((rc == 0) && (!of_have_populated_dt())) {
>  		pdev = platform_device_register_full(&omap_dma_dev_info);
>  		if (IS_ERR(pdev)) {
>  			platform_driver_unregister(&omap_dma_driver);

There is already a patch in linux-next that makes this obsolete.
The device is now registered in arch/arm/mach-omap2/dma.c, so
I guess you have to change that location now.

	Arnd

Re: [PATCH 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes

[Arnd Bergmann]

On Wednesday 06 February 2013, Jon Hunter wrote:
> Add SDMA controller binding for OMAP2+ devices and populate DMA client
> information for SPI and MMC periperhal on OMAP3+ devices. Please note
> that OMAP24xx devices do not have SPI and MMC bindings available yet and
> so DMA client information is not populated.
> 
> Signed-off-by: Jon Hunter <jon-hunter-l0cyMroinI0@public.gmane.org>

Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

On 02/07/2013 08:39 AM, Arnd Bergmann wrote:
> On Wednesday 06 February 2013, Jon Hunter wrote:
>> +static struct of_dma_filter_info info;
> 
> Both members of this structure are constant, so you can just initialize it here,
> and it would be nice to give it a more descriptive name, such as omap_dmadev_info.
> 
>>  static struct platform_driver omap_dma_driver = {
>>  	.probe	= omap_dma_probe,
>>  	.remove	= omap_dma_remove,
>>  	.driver = {
>>  		.name = "omap-dma-engine",
>>  		.owner = THIS_MODULE,
>> +		.of_match_table = of_match_ptr(omap_dma_match)
>>  	},
>>  };
> 
> please end the new line with a comma.

Ok.

>> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
>>  {
>>  	int rc = platform_driver_register(&omap_dma_driver);
>>  
>> -	if (rc == 0) {
>> +	if ((rc == 0) && (!of_have_populated_dt())) {
>>  		pdev = platform_device_register_full(&omap_dma_dev_info);
>>  		if (IS_ERR(pdev)) {
>>  			platform_driver_unregister(&omap_dma_driver);
> 
> There is already a patch in linux-next that makes this obsolete.
> The device is now registered in arch/arm/mach-omap2/dma.c, so
> I guess you have to change that location now.

Thanks. Will rebase on top of linux-next.

Cheers
Jon

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Arnd Bergmann]

On Thursday 07 February 2013 09:51:11 Jon Hunter wrote:
> >> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
> >>  {
> >>      int rc = platform_driver_register(&omap_dma_driver);
> >>  
> >> -    if (rc == 0) {
> >> +    if ((rc == 0) && (!of_have_populated_dt())) {
> >>              pdev = platform_device_register_full(&omap_dma_dev_info);
> >>              if (IS_ERR(pdev)) {
> >>                      platform_driver_unregister(&omap_dma_driver);
> > 
> > There is already a patch in linux-next that makes this obsolete.
> > The device is now registered in arch/arm/mach-omap2/dma.c, so
> > I guess you have to change that location now.
> 
> Thanks. Will rebase on top of linux-next.

Actually, there is another problem with that, because then
you may get into the situation where nobody can apply your
patch.

You should never build work on top of linux-next, because
then your base gets rebuilt every day. Instead, you should
/test/ your branch merged with linux-next to ensure it works
with all the other things in place, and when you see conflicts
like this, you have to find out what they are and then decide
whether you need to rebase it, and to what.

Example:

$ git log --oneline next/master drivers/dma/omap-dma.c | head
be1f948 ARM: OMAP: Fix dmaengine init for multiplatform
45c3eb7 ARM: OMAP: Move plat-omap/dma-omap.h to include/linux/omap-dma.h
8280960 ARM: OMAP: Remove cpu_is_omap usage from plat-omap/dma.c
94c6578 Merge branch 'omap-for-v3.8/cleanup-headers-dma' into omap-for-v3.8/cleanup-headers
27615a9 ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
2b6c4e7 ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h
f5a246e Merge tag 'sound-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
2dde5b9 dmaengine: omap-dma: Add support to suppress interrupts in cyclic mode
ec8b5e4 dmaengine: Pass flags via device_prep_dma_cyclic() callback
2dcdf57 dmaengine: omap: Add support for pause/resume in cyclic dma mode

The topmost patch in linux-next is what has the conflict, so let's
see how that got there:

$ git log --oneline --ancestry-path --merges be1f948..next/master | tail
669166d Merge branch 'next/cleanup' into for-next
82fe557 Merge branch 'next/cleanup' into for-next
2f9adc9 Merge branch 'next/soc' into for-next
91ae65c Merge branch 'next/multiplatform' into for-next
2fd73eb Merge tag 'vt8500-multiplatform-3.9' of git://server.prisktech.co.nz/git/linuxwmt into next/multiplatform
33740d2 Merge branch 'fixes' into for-next
b75baf8 Merge branch 'next/multiplatform' into for-next
6130133 Merge tag 'omap-for-v3.9/multiplatform-enable-signed-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/multiplatform
3613f45 Merge branch 'next/multiplatform' into for-next
45f6a1d Merge tag 'omap-for-v3.9/multiplatform-enable-signed-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/multiplatform


At the bottom, you can see where it got merged. The commit was
in Tony's omap-for-v3.9/multiplatform-enable-signed-v2, which
subsequently got merged into arm-soc/next/multiplatform,
arm-soc/for-next and next/master.

The logical step is to base your patch on top of
omap-for-v3.9/multiplatform-enable-signed-v2, and work with
Tony and/or Olof and me to get that upstream.

	Arnd

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

On 02/07/2013 10:07 AM, Arnd Bergmann wrote:
> On Thursday 07 February 2013 09:51:11 Jon Hunter wrote:
>>>> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
>>>>  {
>>>>      int rc = platform_driver_register(&omap_dma_driver);
>>>>  
>>>> -    if (rc == 0) {
>>>> +    if ((rc == 0) && (!of_have_populated_dt())) {
>>>>              pdev = platform_device_register_full(&omap_dma_dev_info);
>>>>              if (IS_ERR(pdev)) {
>>>>                      platform_driver_unregister(&omap_dma_driver);
>>>
>>> There is already a patch in linux-next that makes this obsolete.
>>> The device is now registered in arch/arm/mach-omap2/dma.c, so
>>> I guess you have to change that location now.
>>
>> Thanks. Will rebase on top of linux-next.
> 
> Actually, there is another problem with that, because then
> you may get into the situation where nobody can apply your
> patch.

Yes Tony mentioned always using a proper branch for pulls. I will base
upon his omap-for-v3.9/multiplatform-v2 (per your inputs, thanks!).
 
> You should never build work on top of linux-next, because
> then your base gets rebuilt every day. Instead, you should
> /test/ your branch merged with linux-next to ensure it works
> with all the other things in place, and when you see conflicts
> like this, you have to find out what they are and then decide
> whether you need to rebase it, and to what.

Ugh, looks like linux-next is broken for omap2+ boards at the moment
and is panic'ing in the twl i2c code ... some else to look into ...

Peter have you seen this on linux-next? I am seeing this on omap2-4 boards.

[    2.286132] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    2.294738] pgd = c0004000
[    2.297576] [00000000] *pgd=00000000
[    2.301361] Internal error: Oops: 5 [#1] SMP ARM
[    2.306243] Modules linked in:
[    2.309448] CPU: 0    Not tainted  (3.8.0-rc6-next-20130207-00016-g735c237 #35)
[    2.317169] PC is at twl_i2c_read+0x3c/0xec
[    2.321563] LR is at twl_i2c_read+0x1c/0xec
[    2.325988] pc : [<c0333950>]    lr : [<c0333930>]    psr: 80000153
[    2.325988] sp : c702fed0  ip : 00000000  fp : 00000000
[    2.338043] r10: c702e000  r9 : c06e84e8  r8 : c06e51c8
[    2.343536] r7 : 00000001  r6 : 00000006  r5 : c702fef6  r4 : 00000004
[    2.350402] r3 : c129508c  r2 : 00000006  r1 : c702fef6  r0 : 0000000e
[    2.357269] Flags: Nzcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    2.365051] Control: 10c5387d  Table: 80004019  DAC: 00000017
[    2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240)
[    2.377410] Stack: (0xc702fed0 to 0xc7030000)
[    2.382019] fec0:                                     c0d42180 c0d429d0 c70a7640 c07354c4
[    2.390624] fee0: 00000001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac 00000000 c07354c4
[    2.399230] ff00: 00000007 c06f2d64 00000017 c06fb308 00000000 c06f07a4 c0cb8580 c06edee0
[    2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 0000009e c00611b4 00000001 00000000
[    2.416442] ff40: c061994c c06b7548 00000007 00000007 00000000 c07354c4 00000007 c0719798
[    2.425048] ff60: c0d42180 c06e51c8 c07197a0 0000009e 00000000 c06e590c 00000007 00000007
[    2.433654] ff80: c06e51c8 00000000 00000000 c04d26ec 00000000 00000000 00000000 00000000
[    2.442260] ffa0: 00000000 c04d26f4 00000000 c00137b0 00000000 00000000 00000000 00000000
[    2.450866] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.459472] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 80fb6c10 71bbcd20
[    2.468078] [<c0333950>] (twl_i2c_read+0x3c/0xec) from [<c06f2cc0>] (omap3_twl_set_sr_bit+0x3c/0xb4)
[    2.477722] [<c06f2cc0>] (omap3_twl_set_sr_bit+0x3c/0xb4) from [<c06f2d64>] (omap3_twl_init+0x2c/0x70)
[    2.487518] [<c06f2d64>] (omap3_twl_init+0x2c/0x70) from [<c06fb308>] (omap_pmic_late_init+0x18/0x24)
[    2.497222] [<c06fb308>] (omap_pmic_late_init+0x18/0x24) from [<c06f07a4>] (omap2_common_pm_late_init+0x18/0xd0)
[    2.507934] [<c06f07a4>] (omap2_common_pm_late_init+0x18/0xd0) from [<c06edee0>] (omap3_init_late+0xc/0x18)
[    2.518188] [<c06edee0>] (omap3_init_late+0xc/0x18) from [<c06e8504>] (init_machine_late+0x1c/0x28)
[    2.527740] [<c06e8504>] (init_machine_late+0x1c/0x28) from [<c0008768>] (do_one_initcall+0x100/0x16c)
[    2.537536] [<c0008768>] (do_one_initcall+0x100/0x16c) from [<c06e590c>] (kernel_init_freeable+0xfc/0x1c8)
[    2.547698] [<c06e590c>] (kernel_init_freeable+0xfc/0x1c8) from [<c04d26f4>] (kernel_init+0x8/0xe4)
[    2.557250] [<c04d26f4>] (kernel_init+0x8/0xe4) from [<c00137b0>] (ret_from_fork+0x14/0x24)

Cheers
Jon

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Tony Lindgren]

* Jon Hunter <jon-hunter@ti.com> [130207 16:55]:
> 
> Ugh, looks like linux-next is broken for omap2+ boards at the moment
> and is panic'ing in the twl i2c code ... some else to look into ...
> 
> Peter have you seen this on linux-next? I am seeing this on omap2-4 boards.

Does not happen with arm-soc/for-next, probably related to the
drivers/mfd/*twl* changes?

Tony
 
> [    2.286132] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [    2.294738] pgd = c0004000
> [    2.297576] [00000000] *pgd=00000000
> [    2.301361] Internal error: Oops: 5 [#1] SMP ARM
> [    2.306243] Modules linked in:
> [    2.309448] CPU: 0    Not tainted  (3.8.0-rc6-next-20130207-00016-g735c237 #35)
> [    2.317169] PC is at twl_i2c_read+0x3c/0xec
> [    2.321563] LR is at twl_i2c_read+0x1c/0xec
> [    2.325988] pc : [<c0333950>]    lr : [<c0333930>]    psr: 80000153
> [    2.325988] sp : c702fed0  ip : 00000000  fp : 00000000
> [    2.338043] r10: c702e000  r9 : c06e84e8  r8 : c06e51c8
> [    2.343536] r7 : 00000001  r6 : 00000006  r5 : c702fef6  r4 : 00000004
> [    2.350402] r3 : c129508c  r2 : 00000006  r1 : c702fef6  r0 : 0000000e
> [    2.357269] Flags: Nzcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> [    2.365051] Control: 10c5387d  Table: 80004019  DAC: 00000017
> [    2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240)
> [    2.377410] Stack: (0xc702fed0 to 0xc7030000)
> [    2.382019] fec0:                                     c0d42180 c0d429d0 c70a7640 c07354c4
> [    2.390624] fee0: 00000001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac 00000000 c07354c4
> [    2.399230] ff00: 00000007 c06f2d64 00000017 c06fb308 00000000 c06f07a4 c0cb8580 c06edee0
> [    2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 0000009e c00611b4 00000001 00000000
> [    2.416442] ff40: c061994c c06b7548 00000007 00000007 00000000 c07354c4 00000007 c0719798
> [    2.425048] ff60: c0d42180 c06e51c8 c07197a0 0000009e 00000000 c06e590c 00000007 00000007
> [    2.433654] ff80: c06e51c8 00000000 00000000 c04d26ec 00000000 00000000 00000000 00000000
> [    2.442260] ffa0: 00000000 c04d26f4 00000000 c00137b0 00000000 00000000 00000000 00000000
> [    2.450866] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    2.459472] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 80fb6c10 71bbcd20
> [    2.468078] [<c0333950>] (twl_i2c_read+0x3c/0xec) from [<c06f2cc0>] (omap3_twl_set_sr_bit+0x3c/0xb4)
> [    2.477722] [<c06f2cc0>] (omap3_twl_set_sr_bit+0x3c/0xb4) from [<c06f2d64>] (omap3_twl_init+0x2c/0x70)
> [    2.487518] [<c06f2d64>] (omap3_twl_init+0x2c/0x70) from [<c06fb308>] (omap_pmic_late_init+0x18/0x24)
> [    2.497222] [<c06fb308>] (omap_pmic_late_init+0x18/0x24) from [<c06f07a4>] (omap2_common_pm_late_init+0x18/0xd0)
> [    2.507934] [<c06f07a4>] (omap2_common_pm_late_init+0x18/0xd0) from [<c06edee0>] (omap3_init_late+0xc/0x18)
> [    2.518188] [<c06edee0>] (omap3_init_late+0xc/0x18) from [<c06e8504>] (init_machine_late+0x1c/0x28)
> [    2.527740] [<c06e8504>] (init_machine_late+0x1c/0x28) from [<c0008768>] (do_one_initcall+0x100/0x16c)
> [    2.537536] [<c0008768>] (do_one_initcall+0x100/0x16c) from [<c06e590c>] (kernel_init_freeable+0xfc/0x1c8)
> [    2.547698] [<c06e590c>] (kernel_init_freeable+0xfc/0x1c8) from [<c04d26f4>] (kernel_init+0x8/0xe4)
> [    2.557250] [<c04d26f4>] (kernel_init+0x8/0xe4) from [<c00137b0>] (ret_from_fork+0x14/0x24)
> 
> Cheers
> Jon

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

On 02/07/2013 08:39 AM, Arnd Bergmann wrote:
> On Wednesday 06 February 2013, Jon Hunter wrote:
>> +static struct of_dma_filter_info info;
> 
> Both members of this structure are constant, so you can just initialize it here,
> and it would be nice to give it a more descriptive name, such as omap_dmadev_info.

No problem. By the way, I see the dma_cap_mask_t is defined as follows ...

typedef struct { DECLARE_BITMAP(bits, DMA_TX_TYPE_END); } dma_cap_mask_t;

Is there a good way to statically initialise this?

Cheers
Jon

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Jon Hunter]

On 02/07/2013 07:44 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter-l0cyMroinI0@public.gmane.org> [130207 16:55]:
>>
>> Ugh, looks like linux-next is broken for omap2+ boards at the moment
>> and is panic'ing in the twl i2c code ... some else to look into ...
>>
>> Peter have you seen this on linux-next? I am seeing this on omap2-4 boards.
> 
> Does not happen with arm-soc/for-next, probably related to the
> drivers/mfd/*twl* changes?

Looks like it is caused by ...

commit 8a6aaa33bc6db516b7cb286c9b8d3ed90a0f06f9
Author: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Date:   Wed Jan 16 14:53:57 2013 +0100

    mfd: twl-core: Collect global variables behind one private structure (global)
    
    Gather the global variables under a single structure and allocate it with
    devm_kzalloc(). It is easier to see them and if in the future we try to add
    support for multiple instance of twl in the system it is going to be much
    simpler.
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
    Signed-off-by: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

Here is a fix. I will send out for review later ...

>From 141fcbbdee6bdc14d5a444ff20fad6b3440215dc Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter-l0cyMroinI0@public.gmane.org>
Date: Fri, 8 Feb 2013 12:42:20 -0600
Subject: [PATCH] ARM: OMAP2+: Fix kernel panic on boot

Commit 8a6aaa3 (mfd: twl-core: Collect global variables behind one
private structure (global)) removed the variable "inuse" that is used
to determine if the device has been initialised and now use the
twl_priv structure instead. This is causing the kernel to panic on all
OMAP2+ devices, because we try to access the twl_priv->ready member
before checking if twl_priv is initialised. Fix this and move this test
to the beginning of the twl_i2c_read/write function because
twl_get_last_module() also uses the twl_priv structure.

Signed-off-by: Jon Hunter <jon-hunter-l0cyMroinI0@public.gmane.org>
---
 drivers/mfd/twl-core.c |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 557f9ee..89ab4d9 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -316,12 +316,12 @@ int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes)
 	int sid;
 	struct twl_client *twl;
 
-	if (unlikely(mod_no >= twl_get_last_module())) {
-		pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
+	if (unlikely(!twl_priv || !twl_priv->ready)) {
+		pr_err("%s: not initialized\n", DRIVER_NAME);
 		return -EPERM;
 	}
-	if (unlikely(!twl_priv->ready)) {
-		pr_err("%s: not initialized\n", DRIVER_NAME);
+	if (unlikely(mod_no >= twl_get_last_module())) {
+		pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
 		return -EPERM;
 	}
 
@@ -355,12 +355,12 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes)
 	int sid;
 	struct twl_client *twl;
 
-	if (unlikely(mod_no >= twl_get_last_module())) {
-		pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
+	if (unlikely(!twl_priv || !twl_priv->ready)) {
+		pr_err("%s: not initialized\n", DRIVER_NAME);
 		return -EPERM;
 	}
-	if (unlikely(!twl_priv->ready)) {
-		pr_err("%s: not initialized\n", DRIVER_NAME);
+	if (unlikely(mod_no >= twl_get_last_module())) {
+		pr_err("%s: invalid module number %d\n", DRIVER_NAME, mod_no);
 		return -EPERM;
 	}
 
-- 
1.7.10.4

Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver

[Russell King - ARM Linux]

On Wed, Feb 06, 2013 at 03:03:16PM -0600, Jon Hunter wrote:
> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
>  {
>  	int rc = platform_driver_register(&omap_dma_driver);
>  
> -	if (rc == 0) {
> +	if ((rc == 0) && (!of_have_populated_dt())) {

Looks good, the worst I can find is this over-use of parens...