[0/7] Next round of DT enablement for ux500/Snowball

[0/7] Next round of DT enablement for ux500/Snowball

[Lee Jones]

This patch-set lays some simple foundations which will ease
the DT enablement process for future one-by-one device
enablement. Then we have a second stab at enabling DT for
mmci. Only this time keeping it simple and continuing to use
current DMA initialisation code. We'll change that once the
generic bindings for DMA have been mainlined. Finally we 
enable Snowball's GPIO controller.

 .../devicetree/bindings/gpio/gpio-nmk.txt          |   29 ++++++++++
 Documentation/devicetree/bindings/mmc/mmci.txt     |   19 +++++++
 arch/arm/boot/dts/db8500.dtsi                      |   18 ++++++
 arch/arm/boot/dts/snowball.dts                     |   39 +++++++++----
 arch/arm/mach-ux500/board-mop500-sdi.c             |    4 +-
 arch/arm/mach-ux500/board-mop500.c                 |   35 +++++++++++--
 arch/arm/mach-ux500/board-mop500.h                 |    4 ++
 arch/arm/mach-ux500/cpu-db8500.c                   |   22 ++++++++
 arch/arm/mach-ux500/include/mach/setup.h           |    3 +
 drivers/gpio/gpio-nomadik.c                        |   41 +++++++++++++-
 drivers/mmc/host/mmci.c                            |   58 ++++++++++++++++++--
 11 files changed, 247 insertions(+), 25 deletions(-)

[PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement

[Lee Jones]

During Device Tree enablement it is necessary to remove
snowball_<device>* platform_data segments one at at time,
as and when particular devices are DT enabled. This patch
provides a temporary solution. Once this new struct is
empty it will be removed again.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c |   18 ++++++++++++++++--
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 77d03c1..29e0ade 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -609,6 +609,13 @@ static struct platform_device *snowball_platform_devs[] __initdata = {
 	&ab8500_device,
 };
 
+static struct platform_device *snowball_of_platform_devs[] __initdata = {
+	&snowball_led_dev,
+	&snowball_key_dev,
+	&snowball_sbnet_dev,
+	&ab8500_device,
+};
+
 static void __init mop500_init_machine(void)
 {
 	struct device *parent = NULL;
@@ -786,8 +793,15 @@ static void __init u8500_init_machine(void)
 		mop500_sdi_init(parent);
 	} else if (of_machine_is_compatible("calaosystems,snowball-a9500")) {
 		snowball_pins_init();
-		platform_add_devices(snowball_platform_devs,
-				ARRAY_SIZE(snowball_platform_devs));
+
+		/* Devices to be DT:ed:
+		     snowball_led_dev   = todo
+		     snowball_key_dev   = todo
+		     snowball_sbnet_dev = todo
+		     ab8500_device      = todo
+		*/
+		platform_add_devices(snowball_of_platform_devs,
+				ARRAY_SIZE(snowball_of_platform_devs));
 
 		snowball_sdi_init(parent);
 	} else if (of_machine_is_compatible("st-ericsson,hrefv60+")) {
-- 
1.7.9.1

[PATCH 2/7] ARM: ux500: New DT:ed u8500_init_devices for one-by-one device enablement

[Lee Jones]

During Device Tree enablement it is necessary to remove
<hw_component>_add_<device> calls one at at time, as and when
particular devices are DT enabled. This patch provides a
temporary solution. Once the new *of_init_devices function
has been fully unpopulated it will be removed again.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/mach-ux500/board-mop500.c       |    2 +-
 arch/arm/mach-ux500/cpu-db8500.c         |   22 ++++++++++++++++++++++
 arch/arm/mach-ux500/include/mach/setup.h |    3 +++
 3 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 29e0ade..4d4aeda 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -772,7 +772,7 @@ static void __init u8500_init_machine(void)
 	int i2c0_devs;
 	int i;
 
-	parent = u8500_init_devices();
+	parent = u8500_of_init_devices();
 	i2c0_devs = ARRAY_SIZE(mop500_i2c0_devices);
 
 	for (i = 0; i < ARRAY_SIZE(mop500_platform_devs); i++)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index 9bd8163..c19c8b8 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -206,3 +206,25 @@ struct device * __init u8500_init_devices(void)
 
 	return parent;
 }
+
+// TODO: Once all pieces are DT:ed, remove completely
+struct device * __init u8500_of_init_devices(void)
+{
+	struct device *parent;
+	int i;
+
+	parent = db8500_soc_device_init();
+
+	db8500_add_rtc(parent);
+	db8500_add_usb(parent, usb_db8500_rx_dma_cfg, usb_db8500_tx_dma_cfg);
+
+	platform_device_register_data(parent,
+		"cpufreq-u8500", -1, NULL, 0);
+
+	for (i = 0; i < ARRAY_SIZE(platform_devs); i++)
+		platform_devs[i]->dev.parent = parent;
+
+	platform_add_devices(platform_devs, ARRAY_SIZE(platform_devs));
+
+	return parent;
+}
diff --git a/arch/arm/mach-ux500/include/mach/setup.h b/arch/arm/mach-ux500/include/mach/setup.h
index 3dc00ff..a792c2a 100644
--- a/arch/arm/mach-ux500/include/mach/setup.h
+++ b/arch/arm/mach-ux500/include/mach/setup.h
@@ -21,6 +21,9 @@ extern void __init u8500_map_io(void);
 extern struct device * __init u5500_init_devices(void);
 extern struct device * __init u8500_init_devices(void);
 
+// TODO: Once all pieces are DT:ed, remove completely
+extern struct device * __init u8500_of_init_devices(void);
+
 extern void __init ux500_init_irq(void);
 
 extern void __init u5500_sdi_init(struct device *parent);
-- 
1.7.9.1

[PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings

[Lee Jones]

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/db8500.dtsi      |   18 +++++++++++++++
 arch/arm/boot/dts/snowball.dts     |   10 ++++----
 arch/arm/mach-ux500/board-mop500.c |   12 ++++++++++
 drivers/gpio/gpio-nomadik.c        |   41 +++++++++++++++++++++++++++++++++--
 4 files changed, 73 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/db8500.dtsi b/arch/arm/boot/dts/db8500.dtsi
index d73dce6..b8591fa 100644
--- a/arch/arm/boot/dts/db8500.dtsi
+++ b/arch/arm/boot/dts/db8500.dtsi
@@ -61,6 +61,8 @@
 			interrupts = <0 119 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <0>;
 		};
 
 		gpio1: gpio at 8012e080 {
@@ -70,6 +72,8 @@
 			interrupts = <0 120 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <1>;
 		};
 
 		gpio2: gpio at 8000e000 {
@@ -79,6 +83,8 @@
 			interrupts = <0 121 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <2>;
 		};
 
 		gpio3: gpio at 8000e080 {
@@ -88,6 +94,8 @@
 			interrupts = <0 122 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <3>;
 		};
 
 		gpio4: gpio at 8000e100 {
@@ -97,6 +105,8 @@
 			interrupts = <0 123 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <4>;
 		};
 
 		gpio5: gpio at 8000e180 {
@@ -106,6 +116,8 @@
 			interrupts = <0 124 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <5>;
 		};
 
 		gpio6: gpio at 8011e000 {
@@ -115,6 +127,8 @@
 			interrupts = <0 125 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <6>;
 		};
 
 		gpio7: gpio at 8011e080 {
@@ -124,6 +138,8 @@
 			interrupts = <0 126 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <7>;
 		};
 
 		gpio8: gpio at a03fe000 {
@@ -133,6 +149,8 @@
 			interrupts = <0 127 0x4>;
 			supports-sleepmode;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-bank = <8>;
 		};
 
 		usb at a03e0000 {
diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 359c6d6..738959d 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -30,35 +30,35 @@
 			wakeup = <1>;
 			linux,code = <2>;
 			label = "userpb";
-			gpios = <&gpio1 0>;
+			gpios = <&gpio1 0 0>;
 		};
 		button at 2 {
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <3>;
 			label = "userpb";
-			gpios = <&gpio4 23>;
+			gpios = <&gpio4 23 0>;
 		};
 		button at 3 {
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <4>;
 			label = "userpb";
-			gpios = <&gpio4 23>;
+			gpios = <&gpio4 24 0>;
 		};
 		button at 4 {
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <5>;
 			label = "userpb";
-			gpios = <&gpio5 1>;
+			gpios = <&gpio5 1 0>;
 		};
 		button at 5 {
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <6>;
 			label = "userpb";
-			gpios = <&gpio5 2>;
+			gpios = <&gpio5 2 0>;
 		};
 	};
 
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 4d4aeda..a47d6bd 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -753,10 +753,22 @@ MACHINE_END
 #ifdef CONFIG_MACH_UX500_DT
 
 struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
+	/* Requires DMA and call-back bindings. */
 	OF_DEV_AUXDATA("arm,pl011", 0x80120000, "uart0", &uart0_plat),
 	OF_DEV_AUXDATA("arm,pl011", 0x80121000, "uart1", &uart1_plat),
 	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
+	/* Requires DMA bindings. */
 	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
+	/* Requires clock name bindings. */
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e080, "gpio.3", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e100, "gpio.4", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e180, "gpio.5", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e000, "gpio.6", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e080, "gpio.7", NULL),
+	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0xa03fe000, "gpio.8", NULL),
 	{},
 };
 
diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c
index 839624f..750a971 100644
--- a/drivers/gpio/gpio-nomadik.c
+++ b/drivers/gpio/gpio-nomadik.c
@@ -1071,6 +1071,7 @@ void nmk_gpio_read_pull(int gpio_bank, u32 *pull_up)
 static int __devinit nmk_gpio_probe(struct platform_device *dev)
 {
 	struct nmk_gpio_platform_data *pdata = dev->dev.platform_data;
+	struct device_node *np = dev->dev.of_node;
 	struct nmk_gpio_chip *nmk_chip;
 	struct gpio_chip *chip;
 	struct resource *res;
@@ -1079,8 +1080,28 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
 	int irq;
 	int ret;
 
-	if (!pdata)
+	if (!pdata && !np) {
+		dev_err(&dev->dev, "No platform data or device tree found\n");
 		return -ENODEV;
+	}
+
+	if (np) {
+		pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+		if (!pdata)
+			return -ENOMEM;
+
+		if (of_get_property(np, "supports-sleepmode", NULL))
+			pdata->supports_sleepmode = true;
+
+		if (of_property_read_u32(np, "gpio-bank", &dev->id)) {
+			dev_err(&dev->dev, "gpio-bank property not found\n");
+			ret = -EINVAL;
+			goto out_dt;
+		}
+
+		pdata->first_gpio = dev->id * NMK_GPIO_PER_CHIP;
+		pdata->num_gpio   = NMK_GPIO_PER_CHIP;
+	}
 
 	res = platform_get_resource(dev, IORESOURCE_MEM, 0);
 	if (!res) {
@@ -1117,6 +1138,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
 		ret = -ENOMEM;
 		goto out_clk;
 	}
+
 	/*
 	 * The virt address in nmk_chip->addr is in the nomadik register space,
 	 * so we can simply convert the resource address, without remapping
@@ -1139,6 +1161,8 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
 	chip->dev = &dev->dev;
 	chip->owner = THIS_MODULE;
 
+	chip->of_node = np;
+
 	ret = gpiochip_add(&nmk_chip->chip);
 	if (ret)
 		goto out_free;
@@ -1146,12 +1170,13 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
 	BUG_ON(nmk_chip->bank >= ARRAY_SIZE(nmk_gpio_chips));
 
 	nmk_gpio_chips[nmk_chip->bank] = nmk_chip;
+
 	platform_set_drvdata(dev, nmk_chip);
 
 	nmk_gpio_init_irq(nmk_chip);
 
-	dev_info(&dev->dev, "at address %p\n",
-		 nmk_chip->addr);
+	dev_info(&dev->dev, "at address %p\n", nmk_chip->addr);
+
 	return 0;
 
 out_free:
@@ -1164,13 +1189,23 @@ out_release:
 out:
 	dev_err(&dev->dev, "Failure %i for GPIO %i-%i\n", ret,
 		  pdata->first_gpio, pdata->first_gpio+31);
+out_dt:
+	if (np)
+		kfree(pdata);
+
 	return ret;
 }
 
+static const struct of_device_id nmk_gpio_match[] = {
+	{ .compatible = "stmicroelectronics,nomadik-gpio", },
+	{}
+};
+
 static struct platform_driver nmk_gpio_driver = {
 	.driver = {
 		.owner = THIS_MODULE,
 		.name = "gpio",
+		.of_match_table = nmk_gpio_match,
 	},
 	.probe = nmk_gpio_probe,
 };
-- 
1.7.9.1

[PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings

[Lee Jones]

Add required documentation for specific gpio-nomadik DT bindings.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 .../devicetree/bindings/gpio/gpio-nmk.txt          |   29 ++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
new file mode 100644
index 0000000..1555029
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
@@ -0,0 +1,29 @@
+Nomadik GPIO controller
+
+Required properties:
+- compatible           : Should be "stmicroelectronics,nomadik-gpio".
+- reg                  : Physical base address and length of the controller's registers.
+- interrupts           : The interrupt outputs from the controller.
+- #gpio-cells          : Should be two:
+                           The first cell is the pin number.
+                           The second cell is used to specify optional parameters:
+                             - bits[3:0] trigger type and level flags:
+                                 1 = low-to-high edge triggered.
+                                 2 = high-to-low edge triggered.
+                                 4 = active high level-sensitive.
+                                 8 = active low level-sensitive.
+- gpio-controller      : Marks the device node as a GPIO controller.
+- supports-sleepmode   : Specifies whether controller can sleep or not
+- gpio-bank            : Specifies which bank a controller owns.
+
+Example:
+
+                gpio1: gpio at 8012e080 {
+                        compatible = "stmicroelectronics,nomadik-gpio";
+                        reg =  <0x8012e080 0x80>;
+                        interrupts = <0 120 0x4>;
+                        #gpio-cells = <2>;
+                        gpio-controller;
+                        supports-sleepmode;
+                        gpio-bank = <1>;
+                };
-- 
1.7.9.1

[PATCH 5/7] ARM: ux500: Rename gpio_keys in the Device Tree file

[Lee Jones]

Ensure each button is individually identifiable by using
their correct unique given device names.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/snowball.dts |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 738959d..0cec47b 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -36,28 +36,28 @@
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <3>;
-			label = "userpb";
+			label = "extkb1";
 			gpios = <&gpio4 23 0>;
 		};
 		button at 3 {
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <4>;
-			label = "userpb";
+			label = "extkb2";
 			gpios = <&gpio4 24 0>;
 		};
 		button at 4 {
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <5>;
-			label = "userpb";
+			label = "extkb3";
 			gpios = <&gpio5 1 0>;
 		};
 		button at 5 {
 			debounce_interval = <50>;
 			wakeup = <1>;
 			linux,code = <6>;
-			label = "userpb";
+			label = "extkb4";
 			gpios = <&gpio5 2 0>;
 		};
 	};
-- 
1.7.9.1

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Lee Jones]

Provide a means to collect attributes specific to ST-Ericsson's
ux500 variant series. This patch registers itself as the AMBA
driver to be called during the probe process. Once all
attributes and ux500 specifics are are collected the normal
mmci core probe is called.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/snowball.dts         |   21 ++++++++++--
 arch/arm/mach-ux500/board-mop500-sdi.c |    4 +-
 arch/arm/mach-ux500/board-mop500.c     |    3 +-
 arch/arm/mach-ux500/board-mop500.h     |    4 ++
 drivers/mmc/host/mmci.c                |   58 +++++++++++++++++++++++++++++--
 5 files changed, 80 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 0cec47b..8e2a609 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -87,13 +87,28 @@
 			};
 		};
 
+		// External Micro SD slot
 		sdi at 80126000 {
-			status = "enabled";
-			cd-gpios = <&gpio6 26>;
+			arm,primecell-periphid = <0x10480180>;
+			clock-frequency = <50000000>;
+			bus-width = <8>;
+			mmc-cap-mmc-highspeed;
+
+			#gpio-cells = <1>;
+			cd-gpios  = <&gpio6 26>; // 218
+			cd-inverted;
+
+			status = "okay";
 		};
 
+		// On-board eMMC
 		sdi at 80114000 {
-			status = "enabled";
+			arm,primecell-periphid = <0x10480180>;
+		        clock-frequency = <50000000>;
+			bus-width = <8>;
+			mmc-cap-mmc-highspeed;
+
+			status = "okay";
 		};
 
 		uart at 80120000 {
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 920251c..18ff781 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -80,7 +80,7 @@ static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
 };
 #endif
 
-static struct mmci_platform_data mop500_sdi0_data = {
+struct mmci_platform_data mop500_sdi0_data = {
 	.ios_handler	= mop500_sdi0_ios_handler,
 	.ocr_mask	= MMC_VDD_29_30,
 	.f_max		= 50000000,
@@ -227,7 +227,7 @@ static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
 };
 #endif
 
-static struct mmci_platform_data mop500_sdi4_data = {
+struct mmci_platform_data mop500_sdi4_data = {
 	.ocr_mask	= MMC_VDD_29_30,
 	.f_max		= 50000000,
 	.capabilities	= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA |
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index a47d6bd..d2c3a5c 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -759,6 +759,8 @@ struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
 	/* Requires DMA bindings. */
 	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  &mop500_sdi0_data),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  &mop500_sdi4_data),
 	/* Requires clock name bindings. */
 	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
 	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
@@ -815,7 +817,6 @@ static void __init u8500_init_machine(void)
 		platform_add_devices(snowball_of_platform_devs,
 				ARRAY_SIZE(snowball_of_platform_devs));
 
-		snowball_sdi_init(parent);
 	} else if (of_machine_is_compatible("st-ericsson,hrefv60+")) {
 		/*
 		 * The HREFv60 board removed a GPIO expander and routed
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index fdcfa87..384baf7 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -7,6 +7,8 @@
 #ifndef __BOARD_MOP500_H
 #define __BOARD_MOP500_H
 
+#include <linux/amba/mmci.h>
+
 /* Snowball specific GPIO assignments, this board has no GPIO expander */
 #define SNOWBALL_ACCEL_INT1_GPIO	163
 #define SNOWBALL_ACCEL_INT2_GPIO	164
@@ -74,6 +76,8 @@
 #define SNOWBALL_EN_3V3_ETH_GPIO	MOP500_AB8500_PIN_GPIO(26)	/* GPIO26 */
 
 struct i2c_board_info;
+extern struct mmci_platform_data mop500_sdi0_data;
+extern struct mmci_platform_data mop500_sdi4_data;
 
 extern void mop500_sdi_init(struct device *parent);
 extern void snowball_sdi_init(struct device *parent);
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 032b847..8538d55 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -15,6 +15,7 @@
 #include <linux/device.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
+#include <linux/slab.h>
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/highmem.h>
@@ -1196,21 +1197,70 @@ static const struct mmc_host_ops mmci_ops = {
 	.get_cd		= mmci_get_cd,
 };
 
+#ifdef CONFIG_OF
+static void mmci_dt_populate_generic_pdata(struct device_node *np,
+					struct mmci_platform_data *pdata)
+{
+	int bus_width = 0;
+
+	of_property_read_u32(np, "wp-gpios", &pdata->gpio_wp);
+	if (!pdata->gpio_wp)
+		pdata->gpio_wp = -1;
+
+	of_property_read_u32(np, "cd-gpios", &pdata->gpio_cd);
+	if (!pdata->gpio_cd)
+		pdata->gpio_cd = -1;
+
+	if (of_get_property(np, "cd-inverted", NULL))
+		pdata->cd_invert = true;
+	else
+		pdata->cd_invert = false;
+
+	of_property_read_u32(np, "clock-frequency", &pdata->f_max);
+	if (!pdata->f_max)
+		pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
+
+	if (of_get_property(np, "mmc-cap-mmc-highspeed", NULL))
+		pdata->capabilities |= MMC_CAP_MMC_HIGHSPEED;
+	if (of_get_property(np, "mmc-cap-sd-highspeed", NULL))
+		pdata->capabilities |= MMC_CAP_SD_HIGHSPEED;
+
+	of_property_read_u32(np, "bus-width", &bus_width);
+	switch (bus_width) {
+	case 0 :
+		/* No bus-width supplied. */
+		break;
+	case 4 :
+		pdata->capabilities |= MMC_CAP_4_BIT_DATA;
+		break;
+	case 8 :
+		pdata->capabilities |= MMC_CAP_8_BIT_DATA;
+		break;
+	default :
+		pr_warn("%s: Unsupported bus width\n", np->full_name);
+	}
+}
+#endif
+
 static int __devinit mmci_probe(struct amba_device *dev,
 	const struct amba_id *id)
 {
 	struct mmci_platform_data *plat = dev->dev.platform_data;
+	struct device_node *np = dev->dev.of_node;
 	struct variant_data *variant = id->data;
 	struct mmci_host *host;
 	struct mmc_host *mmc;
 	int ret;
 
-	/* must have platform data */
-	if (!plat) {
-		ret = -EINVAL;
-		goto out;
+	/* Must have platform data or Device Tree. */
+	if (!plat && !np) {
+		dev_err(&dev->dev, "No plat data or DT found\n");
+		return -EINVAL;
 	}
 
+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);
+
 	ret = amba_request_regions(dev, DRIVER_NAME);
 	if (ret)
 		goto out;
-- 
1.7.9.1

[PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings

[Lee Jones]

This provides full documentation detailing each compulsory,
optional and device (variant) specific properties available
for use within the MMCI Device Tree.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 Documentation/devicetree/bindings/mmc/mmci.txt |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmci.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
new file mode 100644
index 0000000..16502a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -0,0 +1,19 @@
+* ARM PrimeCell MultiMedia Card Interface (MMCI) PL180/1
+
+The ARM PrimeCell MMCI PL180 and PL181 provides and interface for
+reading and writing to MultiMedia and SD cards alike.
+
+Required properties:
+- compatible             : contains "arm,pl18x", "arm,primecell".
+- reg                    : contains pl18x registers and length.
+- interrupts             : contains the device IRQ(s).
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.
+
+Optional properties:
+- wp-gpios               : contains any write protect (ro) gpios
+- cd-gpios               : contains any card detection gpios
+- cd-inverted            : indicates whether the cd gpio is inverted
+- clock-frequency        : contains the maximum operating frequency
+- bus-width              : Number of data lines, can be <1>, <4>, or <8>
+- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
+- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
-- 
1.7.9.1

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Russell King - ARM Linux]

On Thu, Apr 05, 2012 at 10:55:47AM +0100, Lee Jones wrote:
> +	of_property_read_u32(np, "clock-frequency", &pdata->f_max);
> +	if (!pdata->f_max)
> +		pr_warn("%s has no 'clock-frequency' property\n", np->full_name);

To be anal about this (which is what we should be about DT bindings)
this is not a 'clock frequency' but a maximum clock frequency for the
bus.  Or to put it another way, a clock frequency limit.

A 'clock-frequency' property suggests (at least to me) that it's
specifying the rate of the MCLK signal, which is not what it's doing.

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Lee Jones]

On 05/04/12 13:36, Russell King - ARM Linux wrote:
> On Thu, Apr 05, 2012 at 10:55:47AM +0100, Lee Jones wrote:
>> +	of_property_read_u32(np, "clock-frequency",&pdata->f_max);
>> +	if (!pdata->f_max)
>> +		pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
>
> To be anal about this (which is what we should be about DT bindings)
> this is not a 'clock frequency' but a maximum clock frequency for the
> bus.  Or to put it another way, a clock frequency limit.
>
> A 'clock-frequency' property suggests (at least to me) that it's
> specifying the rate of the MCLK signal, which is not what it's doing.

Sounds sensible.

I initially had it as 'f-max', but was told to change it to 
'clock-frequency'. I'm happy to take other suggestions however.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Grant Likely]

On Thu, 05 Apr 2012 14:45:02 +0100, Lee Jones <lee.jones@linaro.org> wrote:
> On 05/04/12 13:36, Russell King - ARM Linux wrote:
> > On Thu, Apr 05, 2012 at 10:55:47AM +0100, Lee Jones wrote:
> >> +	of_property_read_u32(np, "clock-frequency",&pdata->f_max);
> >> +	if (!pdata->f_max)
> >> +		pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
> >
> > To be anal about this (which is what we should be about DT bindings)
> > this is not a 'clock frequency' but a maximum clock frequency for the
> > bus.  Or to put it another way, a clock frequency limit.
> >
> > A 'clock-frequency' property suggests (at least to me) that it's
> > specifying the rate of the MCLK signal, which is not what it's doing.
> 
> Sounds sensible.
> 
> I initially had it as 'f-max', but was told to change it to 
> 'clock-frequency'. I'm happy to take other suggestions however.

Yes, "clock-frequency" already has established usage as an exact clock
specification.  If it is a maximum as you say then something like
"max-frequency" makes more sense.

Someone was working on a common MMC DT binding.  Really all of the MMC
drivers should use the same binding for the common bits.

g.

[PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings

[Grant Likely]

On Thu,  5 Apr 2012 10:55:45 +0100, Lee Jones <lee.jones@linaro.org> wrote:
> Add required documentation for specific gpio-nomadik DT bindings.
> 
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>  .../devicetree/bindings/gpio/gpio-nmk.txt          |   29 ++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> new file mode 100644
> index 0000000..1555029
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> @@ -0,0 +1,29 @@
> +Nomadik GPIO controller
> +
> +Required properties:
> +- compatible           : Should be "stmicroelectronics,nomadik-gpio".

"stmicroelectronics," is a really long prefix.  You can use simply
"st," here since it has already been defined and documented in
Documentation/devicetree/bindings/vendor-prefixes.txt

> +- reg                  : Physical base address and length of the controller's registers.
> +- interrupts           : The interrupt outputs from the controller.
> +- #gpio-cells          : Should be two:
> +                           The first cell is the pin number.
> +                           The second cell is used to specify optional parameters:
> +                             - bits[3:0] trigger type and level flags:
> +                                 1 = low-to-high edge triggered.
> +                                 2 = high-to-low edge triggered.
> +                                 4 = active high level-sensitive.
> +                                 8 = active low level-sensitive.

Those look like interrupt flags, not gpio flags.  If the gpio lines
can be used as generic irq input lines, then this node should also
declare itself as an interrupt controller.

> +- gpio-controller      : Marks the device node as a GPIO controller.
> +- supports-sleepmode   : Specifies whether controller can sleep or not

Typically, custom properites that are for a specific device should be
prefixed with the manufacturer name.  So, something like:
"st,has-sleepmode".

> +- gpio-bank            : Specifies which bank a controller owns.

What is this for (how is it used)?  It shouldn't be needed to specify
a bank number.

> +
> +Example:
> +
> +                gpio1: gpio at 8012e080 {
> +                        compatible = "stmicroelectronics,nomadik-gpio";
> +                        reg =  <0x8012e080 0x80>;
> +                        interrupts = <0 120 0x4>;
> +                        #gpio-cells = <2>;
> +                        gpio-controller;
> +                        supports-sleepmode;
> +                        gpio-bank = <1>;
> +                };
> -- 
> 1.7.9.1
> 

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies,Ltd.

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Arnd Bergmann]

On Friday 06 April 2012, Grant Likely wrote:
> Yes, "clock-frequency" already has established usage as an exact clock
> specification.  If it is a maximum as you say then something like
> "max-frequency" makes more sense.
> 
> Someone was working on a common MMC DT binding.  Really all of the MMC
> drivers should use the same binding for the common bits.

Agreed.

Should we use max-frequency or clock-frequency for sdhci though? It looks
like this is both the maximum frequency that it can use and the base frequency
that the actual clock rate is derived from (can be a fraction).

	Arnd

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Chris Ball]

Hi,

On Mon, Apr 09 2012, Arnd Bergmann wrote:
> Agreed.
>
> Should we use max-frequency or clock-frequency for sdhci though? It looks
> like this is both the maximum frequency that it can use and the base frequency
> that the actual clock rate is derived from (can be a fraction).

This is ultimately setting the "f_max" ("maximum operating frequency")
field in the MMC core, so I'm happy naming the property "max-frequency".

It's true that this doesn't explain the derivation to clock rate --
but we weren't doing that before the DT binding either, and I think that
having a discrepancy between the DT property and the core's naming would
lead to confusion/mistakes.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

[PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings

[Lee Jones]

On 06/04/12 05:20, Grant Likely wrote:
> On Thu,  5 Apr 2012 10:55:45 +0100, Lee Jones<lee.jones@linaro.org>  wrote:
>> Add required documentation for specific gpio-nomadik DT bindings.
>>
>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>> ---
>>   .../devicetree/bindings/gpio/gpio-nmk.txt          |   29 ++++++++++++++++++++
>>   1 files changed, 29 insertions(+), 0 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
>> new file mode 100644
>> index 0000000..1555029
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
>> @@ -0,0 +1,29 @@
>> +Nomadik GPIO controller
>> +
>> +Required properties:
>> +- compatible           : Should be "stmicroelectronics,nomadik-gpio".
>
> "stmicroelectronics," is a really long prefix.  You can use simply
> "st," here since it has already been defined and documented in
> Documentation/devicetree/bindings/vendor-prefixes.txt

Absolutely.

>> +- reg                  : Physical base address and length of the controller's registers.
>> +- interrupts           : The interrupt outputs from the controller.
>> +- #gpio-cells          : Should be two:
>> +                           The first cell is the pin number.
>> +                           The second cell is used to specify optional parameters:
>> +                             - bits[3:0] trigger type and level flags:
>> +                                 1 = low-to-high edge triggered.
>> +                                 2 = high-to-low edge triggered.
>> +                                 4 = active high level-sensitive.
>> +                                 8 = active low level-sensitive.
>
> Those look like interrupt flags, not gpio flags.  If the gpio lines
> can be used as generic irq input lines, then this node should also
> declare itself as an interrupt controller.

They can and it will do in an up-coming patch.

>> +- gpio-controller      : Marks the device node as a GPIO controller.
>> +- supports-sleepmode   : Specifies whether controller can sleep or not
>
> Typically, custom properites that are for a specific device should be
> prefixed with the manufacturer name.  So, something like:
> "st,has-sleepmode".

No problem.

>> +- gpio-bank            : Specifies which bank a controller owns.
>
> What is this for (how is it used)?  It shouldn't be needed to specify
> a bank number.

Briefly, it is used like this:

of_property_read_u32(np, "gpio-bank", &bank);
chip->base = bank * NMK_GPIO_PER_CHIP;
nmk_chip->bank = bank;

Is that wrong? If so, is there a better way to do it?

Thanks Grant.

Kind regards,
Lee

>> +
>> +Example:
>> +
>> +                gpio1: gpio at 8012e080 {
>> +                        compatible = "stmicroelectronics,nomadik-gpio";
>> +                        reg =<0x8012e080 0x80>;
>> +                        interrupts =<0 120 0x4>;
>> +                        #gpio-cells =<2>;
>> +                        gpio-controller;
>> +                        supports-sleepmode;
>> +                        gpio-bank =<1>;
>> +                };
>> --
>> 1.7.9.1
>>
>


-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement

[Linus Walleij]

On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:

> During Device Tree enablement it is necessary to remove
> snowball_<device>* platform_data segments one at at time,
> as and when particular devices are DT enabled. This patch
> provides a temporary solution. Once this new struct is
> empty it will be removed again.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

This is not exactly elegant and I cannot quite see how the pieces
fit together.

> ---
> ?arch/arm/mach-ux500/board-mop500.c | ? 18 ++++++++++++++++--
> ?1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
> index 77d03c1..29e0ade 100644
> --- a/arch/arm/mach-ux500/board-mop500.c
> +++ b/arch/arm/mach-ux500/board-mop500.c
> @@ -609,6 +609,13 @@ static struct platform_device *snowball_platform_devs[] __initdata = {
> ? ? ? ?&ab8500_device,
> ?};
>
> +static struct platform_device *snowball_of_platform_devs[] __initdata = {
> + ? ? ? &snowball_led_dev,
> + ? ? ? &snowball_key_dev,
> + ? ? ? &snowball_sbnet_dev,
> + ? ? ? &ab8500_device,
> +};

So above this array is an identical array which is going to become
unused, then why
not just rename the other array with _of_ or just skip the whole
business altogether?

> +
> ?static void __init mop500_init_machine(void)
> ?{
> ? ? ? ?struct device *parent = NULL;
> @@ -786,8 +793,15 @@ static void __init u8500_init_machine(void)
> ? ? ? ? ? ? ? ?mop500_sdi_init(parent);
> ? ? ? ?} else if (of_machine_is_compatible("calaosystems,snowball-a9500")) {
> ? ? ? ? ? ? ? ?snowball_pins_init();
> - ? ? ? ? ? ? ? platform_add_devices(snowball_platform_devs,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(snowball_platform_devs));

So first you remove ths use of that array...

> +
> + ? ? ? ? ? ? ? /* Devices to be DT:ed:
> + ? ? ? ? ? ? ? ? ? ?snowball_led_dev ? = todo
> + ? ? ? ? ? ? ? ? ? ?snowball_key_dev ? = todo
> + ? ? ? ? ? ? ? ? ? ?snowball_sbnet_dev = todo
> + ? ? ? ? ? ? ? ? ? ?ab8500_device ? ? ?= todo
> + ? ? ? ? ? ? ? */

/*
 * Comment style
 */

> + ? ? ? ? ? ? ? platform_add_devices(snowball_of_platform_devs,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ARRAY_SIZE(snowball_of_platform_devs));

And insert an identical array?

The only change is that you now have an *unused* array with all it's
parents set and then an array with all parents set to NULL which you
use. I don't get it ...

Yours,
Linus Walleij

[PATCH 2/7] ARM: ux500: New DT:ed u8500_init_devices for one-by-one device enablement

[Linus Walleij]

On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:

> +// TODO: Once all pieces are DT:ed, remove completely

/* Comment style, no C99 comments in the kernel */

> +// TODO: Once all pieces are DT:ed, remove completely

Dito.

> +extern struct device * __init u8500_of_init_devices(void);
> +

No cheating with external, add it to the header file instead.

Yours,
Linus Walleij

[PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings

[Linus Walleij]

On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:

> + ? ? ? /* Requires clock name bindings. */
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e080, "gpio.3", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e100, "gpio.4", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e180, "gpio.5", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e000, "gpio.6", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e080, "gpio.7", NULL),
> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0xa03fe000, "gpio.8", NULL),

Needs updating to use the st,foo prefix I guess.

Please use the defined block offset addresses from <mach/db8500-regs.h>
U8500_GPIO0_BASE etc. instead of hardcoded values.

Yours,
Linus Walleij

[PATCH 5/7] ARM: ux500: Rename gpio_keys in the Device Tree file

[Linus Walleij]

On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:

> Ensure each button is individually identifiable by using
> their correct unique given device names.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 3/7] drivers/gpio: gpio-nomadik: Apply Device Tree bindings

[Linus Walleij]

On Tue, Apr 10, 2012 at 11:14 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
>> + ? ? ? /* Requires clock name bindings. */
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e080, "gpio.3", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e100, "gpio.4", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8000e180, "gpio.5", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e000, "gpio.6", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8011e080, "gpio.7", NULL),
>> + ? ? ? OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0xa03fe000, "gpio.8", NULL),
>
> Needs updating to use the st,foo prefix I guess.
>
> Please use the defined block offset addresses from <mach/db8500-regs.h>
> U8500_GPIO0_BASE etc. instead of hardcoded values.

On second thought ignore that last thing. We already have the explicit
address in
other auxdata and the goal is to get rid of the register file anyway.

Yours,
Linus Walleij

[PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement

[Lee Jones]

On 10/04/12 10:03, Linus Walleij wrote:
> On Thu, Apr 5, 2012 at 11:55 AM, Lee Jones<lee.jones@linaro.org>  wrote:
>
>> During Device Tree enablement it is necessary to remove
>> snowball_<device>* platform_data segments one at at time,
>> as and when particular devices are DT enabled. This patch
>> provides a temporary solution. Once this new struct is
>> empty it will be removed again.
>>
>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>
> This is not exactly elegant and I cannot quite see how the pieces
> fit together.
>
>> ---
>>   arch/arm/mach-ux500/board-mop500.c |   18 ++++++++++++++++--
>>   1 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
>> index 77d03c1..29e0ade 100644
>> --- a/arch/arm/mach-ux500/board-mop500.c
>> +++ b/arch/arm/mach-ux500/board-mop500.c
>> @@ -609,6 +609,13 @@ static struct platform_device *snowball_platform_devs[] __initdata = {
>>         &ab8500_device,
>>   };
>>
>> +static struct platform_device *snowball_of_platform_devs[] __initdata = {
>> +&snowball_led_dev,
>> +&snowball_key_dev,
>> +&snowball_sbnet_dev,
>> +&ab8500_device,
>> +};
>
> So above this array is an identical array which is going to become
> unused, then why
> not just rename the other array with _of_ or just skip the whole
> business altogether?

Eh? No, that won't help. The other array needs to be kept fully intact 
for non-DT boots. The idea is that each element from the DT array will 
be removed sequentially as they are DT enabled. For instance, I already 
have a patch with enables the SMSC911x chip, which also removes the 
&snowball_sbnet_dev entry. After that something else will be enabled and 
its cohort will be subsequently removed too. Only when all these devices 
have been DT enabled can the struct be removed.

>> +
>>   static void __init mop500_init_machine(void)
>>   {
>>         struct device *parent = NULL;
>> @@ -786,8 +793,15 @@ static void __init u8500_init_machine(void)
>>                 mop500_sdi_init(parent);
>>         } else if (of_machine_is_compatible("calaosystems,snowball-a9500")) {
>>                 snowball_pins_init();
>> -               platform_add_devices(snowball_platform_devs,
>> -                               ARRAY_SIZE(snowball_platform_devs));
>
> So first you remove ths use of that array...
>
>> +
>> +               /* Devices to be DT:ed:
>> +                    snowball_led_dev   = todo
>> +                    snowball_key_dev   = todo
>> +                    snowball_sbnet_dev = todo
>> +                    ab8500_device      = todo
>> +               */
>
> /*
>   * Comment style
>   */

No problem, I'll fix that.

>> +               platform_add_devices(snowball_of_platform_devs,
>> +                               ARRAY_SIZE(snowball_of_platform_devs));
>
> And insert an identical array?
>
> The only change is that you now have an *unused* array with all it's
> parents set and then an array with all parents set to NULL which you
> use. I don't get it ...

Nothing is unused. When DT is disabled snowball_platform_devs will be 
used to add the platform devices. This is, and will remain fully 
populated for non-DT boots. The DT'ed version will decrease in size 
until the final element is removed along with the definition.

I have ran this past Arnd, who thought this was a good idea. It's only a 
temporary solution which well aide us in enabling devices spanned over 
multiple submissions, rather than attempting to enable everything in a 
single patch-set - which isn't going to happen.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement

[Linus Walleij]

On Tue, Apr 10, 2012 at 11:26 AM, Lee Jones <lee.jones@linaro.org> wrote:

> Nothing is unused. When DT is disabled snowball_platform_devs will be used
> to add the platform devices. This is, and will remain fully populated for
> non-DT boots. The DT'ed version will decrease in size until the final
> element is removed along with the definition.

OK then..

> I have ran this past Arnd, who thought this was a good idea. It's only a
> temporary solution which well aide us in enabling devices spanned over
> multiple submissions, rather than attempting to enable everything in a
> single patch-set - which isn't going to happen.

Sure so let's say that I add this patch immediately before the first patch
removing atleast *one* of the entries, because until then it is certainly
not needed.

Yours,
Linus Walleij

[PATCH 1/7] ARM: ux500: New DT:ed snowball_platform_devs for one-by-one device enablement

[Lee Jones]

On 10/04/12 12:02, Linus Walleij wrote:
> On Tue, Apr 10, 2012 at 11:26 AM, Lee Jones<lee.jones@linaro.org>  wrote:
>
>> Nothing is unused. When DT is disabled snowball_platform_devs will be used
>> to add the platform devices. This is, and will remain fully populated for
>> non-DT boots. The DT'ed version will decrease in size until the final
>> element is removed along with the definition.
>
> OK then..
>
>> I have ran this past Arnd, who thought this was a good idea. It's only a
>> temporary solution which well aide us in enabling devices spanned over
>> multiple submissions, rather than attempting to enable everything in a
>> single patch-set - which isn't going to happen.
>
> Sure so let's say that I add this patch immediately before the first patch
> removing atleast *one* of the entries, because until then it is certainly
> not needed.

Sounds sensible, thanks.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings

[Arnd Bergmann]

On Thursday 05 April 2012, Lee Jones wrote:
> This provides full documentation detailing each compulsory,
> optional and device (variant) specific properties available
> for use within the MMCI Device Tree.
> 
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

Acked-by: Arnd Bergmann <arnd@arndb.de>

[PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings

[Pawel Moll]

Hi Arnd,

On Wed, 2012-04-18 at 13:04 +0000, Arnd Bergmann wrote:
> On Thursday 05 April 2012, Lee Jones wrote:
> > This provides full documentation detailing each compulsory,
> > optional and device (variant) specific properties available
> > for use within the MMCI Device Tree.
> > 
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Did you really mean to ack this version or the newer one, with
"max-frequency" instead of "clock-frequency"?

Pawe?

[PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings

[Lee Jones]

On 18/04/12 15:25, Pawel Moll wrote:
> Hi Arnd,
>
> On Wed, 2012-04-18 at 13:04 +0000, Arnd Bergmann wrote:
>> On Thursday 05 April 2012, Lee Jones wrote:
>>> This provides full documentation detailing each compulsory,
>>> optional and device (variant) specific properties available
>>> for use within the MMCI Device Tree.
>>>
>>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>>
>> Acked-by: Arnd Bergmann<arnd@arndb.de>
>
> Did you really mean to ack this version or the newer one, with
> "max-frequency" instead of "clock-frequency"?

He meant the newer one. :)

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 7/7] MMC: mmci: Add required documentation for Device Tree bindings

[Arnd Bergmann]

On Wednesday 18 April 2012, Lee Jones wrote:
> On 18/04/12 15:25, Pawel Moll wrote:
> > Hi Arnd,
> >
> > On Wed, 2012-04-18 at 13:04 +0000, Arnd Bergmann wrote:
> >> On Thursday 05 April 2012, Lee Jones wrote:
> >>> This provides full documentation detailing each compulsory,
> >>> optional and device (variant) specific properties available
> >>> for use within the MMCI Device Tree.
> >>>
> >>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
> >>
> >> Acked-by: Arnd Bergmann<arnd@arndb.de>
> >
> > Did you really mean to ack this version or the newer one, with
> > "max-frequency" instead of "clock-frequency"?
> 
> He meant the newer one. :)
> 

Yes, of course. Sorry for the confusion.

	Arnd

[PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings

[Grant Likely]

On Tue, 10 Apr 2012 08:24:49 +0100, Lee Jones <lee.jones@linaro.org> wrote:
> On 06/04/12 05:20, Grant Likely wrote:
> > On Thu,  5 Apr 2012 10:55:45 +0100, Lee Jones<lee.jones@linaro.org>  wrote:
> >> Add required documentation for specific gpio-nomadik DT bindings.
> >>
> >> Signed-off-by: Lee Jones<lee.jones@linaro.org>
> >> ---
> >>   .../devicetree/bindings/gpio/gpio-nmk.txt          |   29 ++++++++++++++++++++
> >>   1 files changed, 29 insertions(+), 0 deletions(-)
> >>   create mode 100644 Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >> new file mode 100644
> >> index 0000000..1555029
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt
> >> @@ -0,0 +1,29 @@
> >> +Nomadik GPIO controller
> >> +
> >> +Required properties:
> >> +- compatible           : Should be "stmicroelectronics,nomadik-gpio".
> >
> > "stmicroelectronics," is a really long prefix.  You can use simply
> > "st," here since it has already been defined and documented in
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> 
> Absolutely.
> 
> >> +- reg                  : Physical base address and length of the controller's registers.
> >> +- interrupts           : The interrupt outputs from the controller.
> >> +- #gpio-cells          : Should be two:
> >> +                           The first cell is the pin number.
> >> +                           The second cell is used to specify optional parameters:
> >> +                             - bits[3:0] trigger type and level flags:
> >> +                                 1 = low-to-high edge triggered.
> >> +                                 2 = high-to-low edge triggered.
> >> +                                 4 = active high level-sensitive.
> >> +                                 8 = active low level-sensitive.
> >
> > Those look like interrupt flags, not gpio flags.  If the gpio lines
> > can be used as generic irq input lines, then this node should also
> > declare itself as an interrupt controller.
> 
> They can and it will do in an up-coming patch.
> 
> >> +- gpio-controller      : Marks the device node as a GPIO controller.
> >> +- supports-sleepmode   : Specifies whether controller can sleep or not
> >
> > Typically, custom properites that are for a specific device should be
> > prefixed with the manufacturer name.  So, something like:
> > "st,has-sleepmode".
> 
> No problem.
> 
> >> +- gpio-bank            : Specifies which bank a controller owns.
> >
> > What is this for (how is it used)?  It shouldn't be needed to specify
> > a bank number.
> 
> Briefly, it is used like this:
> 
> of_property_read_u32(np, "gpio-bank", &bank);
> chip->base = bank * NMK_GPIO_PER_CHIP;
> nmk_chip->bank = bank;
> 
> Is that wrong? If so, is there a better way to do it?

(sorry for the late reply on this, I've been tied up with other stuff.
I know you've posted updated patches, but I haven't looked at them
yet.  This answer may be obsolete by now, but I'm sending it anyway
for background).

It's not strictly wrong, but it looks a lot like the "cell-index"
pattern which is appropriate sometimes, but always comes under
scrutiny first.  It makes me wonder what the driver needs it for.  ie.
Are the banks all part of a single GPIO device?  If they are really
independent, the the bank number should be irrelevant because the base
address identifies how to control the device.  Or, is there a shared
resource that needs the bank number to access correctly?

If they a single device then a better binding might be a single node
with #gpio-cells = <3> with the first cell specifying a bank and the
second specifying the gpio number.  Or if the GPIOs appear in a flat
number space, then you could use the exact same numbering as found in
the user-manual for the chip.

g.

[PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings

[Linus Walleij]

On Fri, May 11, 2012 at 9:12 PM, Grant Likely <grant.likely@secretlab.ca> wrote:

> Are the banks all part of a single GPIO device?

No. The banks are individual pieces of silicon instance, so they
each have separate reset and clock lines for example.

Apart from that I just vaguely grasp what you're discussing here :-)

Yours,
Linus Walleij

[PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings

[Grant Likely]

On Fri, May 11, 2012 at 4:18 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, May 11, 2012 at 9:12 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> Are the banks all part of a single GPIO device?
>
> No. The banks are individual pieces of silicon instance, so they
> each have separate reset and clock lines for example.
>
> Apart from that I just vaguely grasp what you're discussing here :-)

Don't worry about it. After reading further, it looks okay.

g.

[PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for Device Tree bindings

[Lee Jones]

On 11/05/12 23:24, Grant Likely wrote:
> On Fri, May 11, 2012 at 4:18 PM, Linus Walleij<linus.walleij@linaro.org>  wrote:
>> On Fri, May 11, 2012 at 9:12 PM, Grant Likely<grant.likely@secretlab.ca>  wrote:
>>
>>> Are the banks all part of a single GPIO device?
>>
>> No. The banks are individual pieces of silicon instance, so they
>> each have separate reset and clock lines for example.
>>
>> Apart from that I just vaguely grasp what you're discussing here :-)
>
> Don't worry about it. After reading further, it looks okay.

Great. Thanks for checking Grant.

Kind regards,
Lee

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Linus Walleij]

On Mon, Apr 16, 2012 at 11:06 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On 16/04/12 09:48, Linus Walleij wrote:

>> Can you split this in a clean patch to mmci.c and another patch for all
>> the ux500 stuff? You can add my Acked-by for both.
>
> I can do that. You'll have it by this afternoon.

Then it looks like only runtime dependencies exist between the MMCI
and ux500 patch and they can be merged to different trees right?

I'll be happy to do that if I know that Russell picks the mmci.c portions.

Yours,
Linus Walleij

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Lee Jones]

On 16/04/12 09:48, Linus Walleij wrote:
> On Fri, Apr 13, 2012 at 4:05 PM, Lee Jones<lee.jones@linaro.org>  wrote:
>
>> Provide a means to collect attributes specific to ST-Ericsson's
>> ux500 variant series. This patch registers itself as the AMBA
>> driver to be called during the probe process. Once all
>> attributes and ux500 specifics are are collected the normal
>> mmci core probe is called.
>>
>> Signed-off-by: Lee Jones<lee.jones@linaro.org>
>> ---
>>   arch/arm/boot/dts/snowball.dts         |   21 ++++++++++--
>>   arch/arm/mach-ux500/board-mop500-sdi.c |    4 +-
>>   arch/arm/mach-ux500/board-mop500.c     |    3 +-
>>   arch/arm/mach-ux500/board-mop500.h     |    4 ++
>>   drivers/mmc/host/mmci.c                |   58 +++++++++++++++++++++++++++++--
>>   5 files changed, 80 insertions(+), 10 deletions(-)
>
> Can you split this in a clean patch to mmci.c and another patch for all
> the ux500 stuff? You can add my Acked-by for both.

I can do that. You'll have it by this afternoon.

Thanks.

> Obviously I cannot apply the mmci.c patch without Russell's ACK,
> (or you have to take it through his patch tracker). Russell has
> positively affirmed that he's looking after the MMCI driver.
>
> If you get Russell's ACK I'll behappy to merge it through ux500
> and ARM SoC.
>
> Yours,
> Linus Walleij


-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Linus Walleij]

On Fri, Apr 13, 2012 at 4:05 PM, Lee Jones <lee.jones@linaro.org> wrote:

> Provide a means to collect attributes specific to ST-Ericsson's
> ux500 variant series. This patch registers itself as the AMBA
> driver to be called during the probe process. Once all
> attributes and ux500 specifics are are collected the normal
> mmci core probe is called.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> ?arch/arm/boot/dts/snowball.dts ? ? ? ? | ? 21 ++++++++++--
> ?arch/arm/mach-ux500/board-mop500-sdi.c | ? ?4 +-
> ?arch/arm/mach-ux500/board-mop500.c ? ? | ? ?3 +-
> ?arch/arm/mach-ux500/board-mop500.h ? ? | ? ?4 ++
> ?drivers/mmc/host/mmci.c ? ? ? ? ? ? ? ?| ? 58 +++++++++++++++++++++++++++++--
> ?5 files changed, 80 insertions(+), 10 deletions(-)

Can you split this in a clean patch to mmci.c and another patch for all
the ux500 stuff? You can add my Acked-by for both.

Obviously I cannot apply the mmci.c patch without Russell's ACK,
(or you have to take it through his patch tracker). Russell has
positively affirmed that he's looking after the MMCI driver.

If you get Russell's ACK I'll behappy to merge it through ux500
and ARM SoC.

Yours,
Linus Walleij

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Pawel Moll]

On Fri, 2012-04-13 at 16:16 +0100, Lee Jones wrote:
> Because in it's current state, gpio-nomadik doesn't know how to decode 
> any provided flags and phandles don't work yet, hence the IRQ request 
> really is just a number in this case. In a latter patch-set I provide 
> the GPIO driver with said bindings and swap the simple integer format 
> for one which is more in keeping with the DT format e.g. <32> becomes 
> <&gpio1 1 0x4> for instance.
> 
> This patch does function perfectly well the way it is and provides no 
> breakage. I'm aiming for both patch-sets to be sucked into the v3.5 
> merge window in any case, so all functionality will be provided at -rc1. 
> Only the bleeding edge, hardcore, kernel developers who use the 
> gpio-nomadik driver (so, just me and Linus Walleij then :D ) will ever 
> use this code as-is.

I see, fine by me.

Cheers!

Pawe?

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Lee Jones]

On 13/04/12 16:05, Pawel Moll wrote:
> On Fri, 2012-04-13 at 15:54 +0100, Lee Jones wrote:
>> On 13/04/12 15:51, Arnd Bergmann wrote:
>>> On Friday 13 April 2012, Pawel Moll wrote:
>>>> On Fri, 2012-04-13 at 15:05 +0100, Lee Jones wrote:
>>>>> +     of_property_read_u32(np, "wp-gpios",&pdata->gpio_wp);
>>>>> +     if (!pdata->gpio_wp)
>>>>> +             pdata->gpio_wp = -1;
>>>>> +
>>>>> +     of_property_read_u32(np, "cd-gpios",&pdata->gpio_cd);
>>>>> +     if (!pdata->gpio_cd)
>>>>> +             pdata->gpio_cd = -1;
>>>>
>>>> I think you should use of_gpio_named_count(np, "XX-gpios") here rather
>>>> then of_property_read() - there's more to GPIOs than just a number...
>
> Of course I meant of_get_named_gpio(np, "XX-gpios", 0) not
> _named_count ;-)
>
>>> Hmm, that part was done right in the git tree, I guess something
>>> went wrong when sending out the series.
>>
>> Different patch series.
>>
>> The GPIO bindings aren't in yet. Once this one is accepted, I'll fire
>> off the second patch-set.
>
> Em, I'm not sure I'm following... Why not use the proper API
> immediately?
>
> Generally, except for that, looks good to me.

Because in it's current state, gpio-nomadik doesn't know how to decode 
any provided flags and phandles don't work yet, hence the IRQ request 
really is just a number in this case. In a latter patch-set I provide 
the GPIO driver with said bindings and swap the simple integer format 
for one which is more in keeping with the DT format e.g. <32> becomes 
<&gpio1 1 0x4> for instance.

This patch does function perfectly well the way it is and provides no 
breakage. I'm aiming for both patch-sets to be sucked into the v3.5 
merge window in any case, so all functionality will be provided at -rc1. 
Only the bleeding edge, hardcore, kernel developers who use the 
gpio-nomadik driver (so, just me and Linus Walleij then :D ) will ever 
use this code as-is.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Pawel Moll]

On Fri, 2012-04-13 at 15:54 +0100, Lee Jones wrote:
> On 13/04/12 15:51, Arnd Bergmann wrote:
> > On Friday 13 April 2012, Pawel Moll wrote:
> >> On Fri, 2012-04-13 at 15:05 +0100, Lee Jones wrote:
> >>> +     of_property_read_u32(np, "wp-gpios",&pdata->gpio_wp);
> >>> +     if (!pdata->gpio_wp)
> >>> +             pdata->gpio_wp = -1;
> >>> +
> >>> +     of_property_read_u32(np, "cd-gpios",&pdata->gpio_cd);
> >>> +     if (!pdata->gpio_cd)
> >>> +             pdata->gpio_cd = -1;
> >>
> >> I think you should use of_gpio_named_count(np, "XX-gpios") here rather
> >> then of_property_read() - there's more to GPIOs than just a number...

Of course I meant of_get_named_gpio(np, "XX-gpios", 0) not
_named_count ;-)

> > Hmm, that part was done right in the git tree, I guess something
> > went wrong when sending out the series.
> 
> Different patch series.
> 
> The GPIO bindings aren't in yet. Once this one is accepted, I'll fire 
> off the second patch-set.

Em, I'm not sure I'm following... Why not use the proper API
immediately?

Generally, except for that, looks good to me.

Pawe?

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Lee Jones]

On 13/04/12 15:51, Arnd Bergmann wrote:
> On Friday 13 April 2012, Pawel Moll wrote:
>> On Fri, 2012-04-13 at 15:05 +0100, Lee Jones wrote:
>>> +     of_property_read_u32(np, "wp-gpios",&pdata->gpio_wp);
>>> +     if (!pdata->gpio_wp)
>>> +             pdata->gpio_wp = -1;
>>> +
>>> +     of_property_read_u32(np, "cd-gpios",&pdata->gpio_cd);
>>> +     if (!pdata->gpio_cd)
>>> +             pdata->gpio_cd = -1;
>>
>> I think you should use of_gpio_named_count(np, "XX-gpios") here rather
>> then of_property_read() - there's more to GPIOs than just a number...
>
> Hmm, that part was done right in the git tree, I guess something
> went wrong when sending out the series.

Different patch series.

The GPIO bindings aren't in yet. Once this one is accepted, I'll fire 
off the second patch-set.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
M: +44 77 88 633 515
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Arnd Bergmann]

On Friday 13 April 2012, Pawel Moll wrote:
> On Fri, 2012-04-13 at 15:05 +0100, Lee Jones wrote:
> > +     of_property_read_u32(np, "wp-gpios", &pdata->gpio_wp);
> > +     if (!pdata->gpio_wp)
> > +             pdata->gpio_wp = -1;
> > +
> > +     of_property_read_u32(np, "cd-gpios", &pdata->gpio_cd);
> > +     if (!pdata->gpio_cd)
> > +             pdata->gpio_cd = -1;
> 
> I think you should use of_gpio_named_count(np, "XX-gpios") here rather
> then of_property_read() - there's more to GPIOs than just a number...

Hmm, that part was done right in the git tree, I guess something
went wrong when sending out the series.

	Arnd

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Pawel Moll]

On Fri, 2012-04-13 at 15:05 +0100, Lee Jones wrote:
> +	of_property_read_u32(np, "wp-gpios", &pdata->gpio_wp);
> +	if (!pdata->gpio_wp)
> +		pdata->gpio_wp = -1;
> +
> +	of_property_read_u32(np, "cd-gpios", &pdata->gpio_cd);
> +	if (!pdata->gpio_cd)
> +		pdata->gpio_cd = -1;

I think you should use of_gpio_named_count(np, "XX-gpios") here rather
then of_property_read() - there's more to GPIOs than just a number...

Cheers!

Pawe?

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Lee Jones]

Provide a means to collect attributes specific to ST-Ericsson's
ux500 variant series. This patch registers itself as the AMBA
driver to be called during the probe process. Once all
attributes and ux500 specifics are are collected the normal
mmci core probe is called.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/snowball.dts         |   21 ++++++++++--
 arch/arm/mach-ux500/board-mop500-sdi.c |    4 +-
 arch/arm/mach-ux500/board-mop500.c     |    3 +-
 arch/arm/mach-ux500/board-mop500.h     |    4 ++
 drivers/mmc/host/mmci.c                |   58 +++++++++++++++++++++++++++++--
 5 files changed, 80 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 0cec47b..fb2a037 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -87,13 +87,28 @@
 			};
 		};
 
+		// External Micro SD slot
 		sdi at 80126000 {
-			status = "enabled";
-			cd-gpios = <&gpio6 26>;
+			arm,primecell-periphid = <0x10480180>;
+			max-frequency = <50000000>;
+			bus-width = <8>;
+			mmc-cap-mmc-highspeed;
+
+			#gpio-cells = <1>;
+			cd-gpios  = <&gpio6 26>; // 218
+			cd-inverted;
+
+			status = "okay";
 		};
 
+		// On-board eMMC
 		sdi at 80114000 {
-			status = "enabled";
+			arm,primecell-periphid = <0x10480180>;
+		        max-frequency = <50000000>;
+			bus-width = <8>;
+			mmc-cap-mmc-highspeed;
+
+			status = "okay";
 		};
 
 		uart at 80120000 {
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 920251c..18ff781 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -80,7 +80,7 @@ static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
 };
 #endif
 
-static struct mmci_platform_data mop500_sdi0_data = {
+struct mmci_platform_data mop500_sdi0_data = {
 	.ios_handler	= mop500_sdi0_ios_handler,
 	.ocr_mask	= MMC_VDD_29_30,
 	.f_max		= 50000000,
@@ -227,7 +227,7 @@ static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
 };
 #endif
 
-static struct mmci_platform_data mop500_sdi4_data = {
+struct mmci_platform_data mop500_sdi4_data = {
 	.ocr_mask	= MMC_VDD_29_30,
 	.f_max		= 50000000,
 	.capabilities	= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA |
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 5064140..d68a73c 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -752,6 +752,8 @@ struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
 	/* Requires DMA bindings. */
 	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  &mop500_sdi0_data),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  &mop500_sdi4_data),
 	/* Requires clock name bindings. */
 	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
 	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
@@ -801,7 +803,6 @@ static void __init u8500_init_machine(void)
 		platform_add_devices(snowball_platform_devs,
 				ARRAY_SIZE(snowball_platform_devs));
 
-		snowball_sdi_init(parent);
 	} else if (of_machine_is_compatible("st-ericsson,hrefv60+")) {
 		/*
 		 * The HREFv60 board removed a GPIO expander and routed
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index fdcfa87..384baf7 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -7,6 +7,8 @@
 #ifndef __BOARD_MOP500_H
 #define __BOARD_MOP500_H
 
+#include <linux/amba/mmci.h>
+
 /* Snowball specific GPIO assignments, this board has no GPIO expander */
 #define SNOWBALL_ACCEL_INT1_GPIO	163
 #define SNOWBALL_ACCEL_INT2_GPIO	164
@@ -74,6 +76,8 @@
 #define SNOWBALL_EN_3V3_ETH_GPIO	MOP500_AB8500_PIN_GPIO(26)	/* GPIO26 */
 
 struct i2c_board_info;
+extern struct mmci_platform_data mop500_sdi0_data;
+extern struct mmci_platform_data mop500_sdi4_data;
 
 extern void mop500_sdi_init(struct device *parent);
 extern void snowball_sdi_init(struct device *parent);
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 032b847..5a7da17 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -15,6 +15,7 @@
 #include <linux/device.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
+#include <linux/slab.h>
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/highmem.h>
@@ -1196,21 +1197,70 @@ static const struct mmc_host_ops mmci_ops = {
 	.get_cd		= mmci_get_cd,
 };
 
+#ifdef CONFIG_OF
+static void mmci_dt_populate_generic_pdata(struct device_node *np,
+					struct mmci_platform_data *pdata)
+{
+	int bus_width = 0;
+
+	of_property_read_u32(np, "wp-gpios", &pdata->gpio_wp);
+	if (!pdata->gpio_wp)
+		pdata->gpio_wp = -1;
+
+	of_property_read_u32(np, "cd-gpios", &pdata->gpio_cd);
+	if (!pdata->gpio_cd)
+		pdata->gpio_cd = -1;
+
+	if (of_get_property(np, "cd-inverted", NULL))
+		pdata->cd_invert = true;
+	else
+		pdata->cd_invert = false;
+
+	of_property_read_u32(np, "max-frequency", &pdata->f_max);
+	if (!pdata->f_max)
+		pr_warn("%s has no 'max-frequency' property\n", np->full_name);
+
+	if (of_get_property(np, "mmc-cap-mmc-highspeed", NULL))
+		pdata->capabilities |= MMC_CAP_MMC_HIGHSPEED;
+	if (of_get_property(np, "mmc-cap-sd-highspeed", NULL))
+		pdata->capabilities |= MMC_CAP_SD_HIGHSPEED;
+
+	of_property_read_u32(np, "bus-width", &bus_width);
+	switch (bus_width) {
+	case 0 :
+		/* No bus-width supplied. */
+		break;
+	case 4 :
+		pdata->capabilities |= MMC_CAP_4_BIT_DATA;
+		break;
+	case 8 :
+		pdata->capabilities |= MMC_CAP_8_BIT_DATA;
+		break;
+	default :
+		pr_warn("%s: Unsupported bus width\n", np->full_name);
+	}
+}
+#endif
+
 static int __devinit mmci_probe(struct amba_device *dev,
 	const struct amba_id *id)
 {
 	struct mmci_platform_data *plat = dev->dev.platform_data;
+	struct device_node *np = dev->dev.of_node;
 	struct variant_data *variant = id->data;
 	struct mmci_host *host;
 	struct mmc_host *mmc;
 	int ret;
 
-	/* must have platform data */
-	if (!plat) {
-		ret = -EINVAL;
-		goto out;
+	/* Must have platform data or Device Tree. */
+	if (!plat && !np) {
+		dev_err(&dev->dev, "No plat data or DT found\n");
+		return -EINVAL;
 	}
 
+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);
+
 	ret = amba_request_regions(dev, DRIVER_NAME);
 	if (ret)
 		goto out;
-- 
1.7.9.1

[PATCH 6/7] MMC: mmci: Enable Device Tree support for ux500 variants

[Lee Jones]

Provide a means to collect attributes specific to ST-Ericsson's
ux500 variant series. This patch registers itself as the AMBA
driver to be called during the probe process. Once all
attributes and ux500 specifics are are collected the normal
mmci core probe is called.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/boot/dts/snowball.dts         |   21 ++++++++++--
 arch/arm/mach-ux500/board-mop500-sdi.c |    4 +-
 arch/arm/mach-ux500/board-mop500.c     |    3 +-
 arch/arm/mach-ux500/board-mop500.h     |    4 ++
 drivers/mmc/host/mmci.c                |   58 +++++++++++++++++++++++++++++--
 5 files changed, 80 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/snowball.dts b/arch/arm/boot/dts/snowball.dts
index 0cec47b..8e2a609 100644
--- a/arch/arm/boot/dts/snowball.dts
+++ b/arch/arm/boot/dts/snowball.dts
@@ -87,13 +87,28 @@
 			};
 		};
 
+		// External Micro SD slot
 		sdi at 80126000 {
-			status = "enabled";
-			cd-gpios = <&gpio6 26>;
+			arm,primecell-periphid = <0x10480180>;
+			clock-frequency = <50000000>;
+			bus-width = <8>;
+			mmc-cap-mmc-highspeed;
+
+			#gpio-cells = <1>;
+			cd-gpios  = <&gpio6 26>; // 218
+			cd-inverted;
+
+			status = "okay";
 		};
 
+		// On-board eMMC
 		sdi at 80114000 {
-			status = "enabled";
+			arm,primecell-periphid = <0x10480180>;
+		        clock-frequency = <50000000>;
+			bus-width = <8>;
+			mmc-cap-mmc-highspeed;
+
+			status = "okay";
 		};
 
 		uart at 80120000 {
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 920251c..18ff781 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -80,7 +80,7 @@ static struct stedma40_chan_cfg mop500_sdi0_dma_cfg_tx = {
 };
 #endif
 
-static struct mmci_platform_data mop500_sdi0_data = {
+struct mmci_platform_data mop500_sdi0_data = {
 	.ios_handler	= mop500_sdi0_ios_handler,
 	.ocr_mask	= MMC_VDD_29_30,
 	.f_max		= 50000000,
@@ -227,7 +227,7 @@ static struct stedma40_chan_cfg mop500_sdi4_dma_cfg_tx = {
 };
 #endif
 
-static struct mmci_platform_data mop500_sdi4_data = {
+struct mmci_platform_data mop500_sdi4_data = {
 	.ocr_mask	= MMC_VDD_29_30,
 	.f_max		= 50000000,
 	.capabilities	= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA |
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index a47d6bd..d2c3a5c 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -759,6 +759,8 @@ struct of_dev_auxdata u8500_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("arm,pl011", 0x80007000, "uart2", &uart2_plat),
 	/* Requires DMA bindings. */
 	OF_DEV_AUXDATA("arm,pl022", 0x80002000, "ssp0",  &ssp0_plat),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80126000, "sdi0",  &mop500_sdi0_data),
+	OF_DEV_AUXDATA("arm,pl18x", 0x80114000, "sdi4",  &mop500_sdi4_data),
 	/* Requires clock name bindings. */
 	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
 	OF_DEV_AUXDATA("stmicroelectronics,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
@@ -815,7 +817,6 @@ static void __init u8500_init_machine(void)
 		platform_add_devices(snowball_of_platform_devs,
 				ARRAY_SIZE(snowball_of_platform_devs));
 
-		snowball_sdi_init(parent);
 	} else if (of_machine_is_compatible("st-ericsson,hrefv60+")) {
 		/*
 		 * The HREFv60 board removed a GPIO expander and routed
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index fdcfa87..384baf7 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -7,6 +7,8 @@
 #ifndef __BOARD_MOP500_H
 #define __BOARD_MOP500_H
 
+#include <linux/amba/mmci.h>
+
 /* Snowball specific GPIO assignments, this board has no GPIO expander */
 #define SNOWBALL_ACCEL_INT1_GPIO	163
 #define SNOWBALL_ACCEL_INT2_GPIO	164
@@ -74,6 +76,8 @@
 #define SNOWBALL_EN_3V3_ETH_GPIO	MOP500_AB8500_PIN_GPIO(26)	/* GPIO26 */
 
 struct i2c_board_info;
+extern struct mmci_platform_data mop500_sdi0_data;
+extern struct mmci_platform_data mop500_sdi4_data;
 
 extern void mop500_sdi_init(struct device *parent);
 extern void snowball_sdi_init(struct device *parent);
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 032b847..8538d55 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -15,6 +15,7 @@
 #include <linux/device.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
+#include <linux/slab.h>
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/highmem.h>
@@ -1196,21 +1197,70 @@ static const struct mmc_host_ops mmci_ops = {
 	.get_cd		= mmci_get_cd,
 };
 
+#ifdef CONFIG_OF
+static void mmci_dt_populate_generic_pdata(struct device_node *np,
+					struct mmci_platform_data *pdata)
+{
+	int bus_width = 0;
+
+	of_property_read_u32(np, "wp-gpios", &pdata->gpio_wp);
+	if (!pdata->gpio_wp)
+		pdata->gpio_wp = -1;
+
+	of_property_read_u32(np, "cd-gpios", &pdata->gpio_cd);
+	if (!pdata->gpio_cd)
+		pdata->gpio_cd = -1;
+
+	if (of_get_property(np, "cd-inverted", NULL))
+		pdata->cd_invert = true;
+	else
+		pdata->cd_invert = false;
+
+	of_property_read_u32(np, "clock-frequency", &pdata->f_max);
+	if (!pdata->f_max)
+		pr_warn("%s has no 'clock-frequency' property\n", np->full_name);
+
+	if (of_get_property(np, "mmc-cap-mmc-highspeed", NULL))
+		pdata->capabilities |= MMC_CAP_MMC_HIGHSPEED;
+	if (of_get_property(np, "mmc-cap-sd-highspeed", NULL))
+		pdata->capabilities |= MMC_CAP_SD_HIGHSPEED;
+
+	of_property_read_u32(np, "bus-width", &bus_width);
+	switch (bus_width) {
+	case 0 :
+		/* No bus-width supplied. */
+		break;
+	case 4 :
+		pdata->capabilities |= MMC_CAP_4_BIT_DATA;
+		break;
+	case 8 :
+		pdata->capabilities |= MMC_CAP_8_BIT_DATA;
+		break;
+	default :
+		pr_warn("%s: Unsupported bus width\n", np->full_name);
+	}
+}
+#endif
+
 static int __devinit mmci_probe(struct amba_device *dev,
 	const struct amba_id *id)
 {
 	struct mmci_platform_data *plat = dev->dev.platform_data;
+	struct device_node *np = dev->dev.of_node;
 	struct variant_data *variant = id->data;
 	struct mmci_host *host;
 	struct mmc_host *mmc;
 	int ret;
 
-	/* must have platform data */
-	if (!plat) {
-		ret = -EINVAL;
-		goto out;
+	/* Must have platform data or Device Tree. */
+	if (!plat && !np) {
+		dev_err(&dev->dev, "No plat data or DT found\n");
+		return -EINVAL;
 	}
 
+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);
+
 	ret = amba_request_regions(dev, DRIVER_NAME);
 	if (ret)
 		goto out;
-- 
1.7.9.1