Next round of DT enablement for ux500/Snowball

It is believed that the i2c compatible match entry is too long and cumbersome in its current form. This patch takes steps to decrease its length by using ST-Mircroelectrics' abbreviation ST.

Signed-off-by Lee Jones <[email protected]>

It is believed that the gpio compatible match entry is too long and cumbersome in its current form. This patch takes steps to decrease its length by using ST-Mircroelectrics' abbreviation ST.

Signed-off-by Lee Jones <[email protected]>

Quoted 5 lines · Lee Jones

It is believed that the gpio compatible match entry is too long and cumbersome in its current form. This patch takes steps to decrease its length by using ST-Mircroelectrics' abbreviation ST.

Signed-off-by Lee Jones<[email protected]>

Applied with the proper spelling and Arnds ACK.

Signed-off-by Lee Jones <[email protected]>

---

?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(-)

Signed-off-by Lee Jones <[email protected]>

---
 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(-)

arch/arm/boot/dts/db8500.dtsi +18 -0

index 421e15f..57d3d35 100644
@@ -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 {

arch/arm/boot/dts/snowball.dts +5 -5

index 359c6d6..738959d 100644
@@ -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>;
 		};
 	};
 

arch/arm/mach-ux500/board-mop500.c +12 -0

index 77d03c1..5064140 100644
@@ -746,10 +746,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("st,nomadik-gpio", 0x8012e000, "gpio.0", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8012e080, "gpio.1", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8000e000, "gpio.2", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8000e080, "gpio.3", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8000e100, "gpio.4", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8000e180, "gpio.5", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8011e000, "gpio.6", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0x8011e080, "gpio.7", NULL),
+	OF_DEV_AUXDATA("st,nomadik-gpio", 0xa03fe000, "gpio.8", NULL),
 	{},
 };
 

drivers/gpio/gpio-nomadik.c +1 -0

index 839624f..65c7e8e 100644
@@ -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;

drivers/gpio/gpio-nomadik.c +10 -0

+
+		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) {

drivers/gpio/gpio-nomadik.c +2 -0

 	/*
 	 * 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));
 

drivers/gpio/gpio-nomadik.c +10 -0

 	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 = "st,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,
 };

Signature · 1 line

1.7.9.1

Quoted 1 line · Lee Jones

Signed-off-by Lee Jones<[email protected]>

Looks pretty good to me. A few comments below, but otherwise you can add my:

Acked-by Grant Likely<[email protected]>

Does this need to be merged via the arm-soc tree?

drivers/gpio/gpio-nomadik.c static int __devinit nmk_gpio_probe(struct platform_device *dev) · line 1089

Quoted 2 lines

drivers/gpio/gpio-nomadik.c +2 -0

+	if (np) {
+		pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);

devm_kzalloc()

drivers/gpio/gpio-nomadik.c static int __devinit nmk_gpio_probe(struct platform_device *dev) · line 1094

Quoted 5 lines

drivers/gpio/gpio-nomadik.c +5 -0

+		if (!pdata)
+			return -ENOMEM;
+
+		if (of_get_property(np, "supports-sleepmode", NULL))
+			pdata->supports_sleepmode = true;

I believe these properties were going to be updated to add an "stericsson," prefix.

Quoted 11 lines

drivers/gpio/gpio-nomadik.c +10 -0

+
+		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;
+	}

drivers/gpio/gpio-nomadik.c static int __devinit nmk_gpio_probe(struct platform_device *dev) · line 1141

Quoted 7 lines

  	res = platform_get_resource(dev, IORESOURCE_MEM, 0);
  	if (!res) {

drivers/gpio/gpio-nomadik.c +1 -0

@@ -1117,6 +1138,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
  		ret = -ENOMEM;
  		goto out_clk;
  	}
+

Nit: unrelated whitespace change.

Quoted 19 lines

drivers/gpio/gpio-nomadik.c +3 -0

  	/*
  	 * 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);
 

drivers/gpio/gpio-nomadik.c static int __devinit nmk_gpio_probe(struct platform_device *dev) · line 1179

Quoted 6 lines

drivers/gpio/gpio-nomadik.c +2 -2

  	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);
+

Nit: unrelated change

Quoted 30 lines

drivers/gpio/gpio-nomadik.c +10 -1

  	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 = "st,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

Grant's comments also taken heed of here:

From: Lee Jones <[email protected]>
Date: Wed, 4 Apr 2012 17:06:41 +0100
Subject: [PATCH 4/7] drivers/gpio: gpio-nomadik: Provide documentation for ?Device Tree bindings

Add required documentation for specific gpio-nomadik DT bindings.

Signed-off-by Lee Jones <[email protected]>

drivers/mmc/host/mmci.c static const struct mmc_host_ops mmci_ops = { · line 1212

Quoted 7 lines · Lee Jones

drivers/mmc/host/mmci.c +7 -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;

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...

Quoted 9 lines · Pawel Moll

Quoted 7 lines · Lee Jones

drivers/mmc/host/mmci.c +7 -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;

Quoted 2 lines

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.

Quoted 10 lines · Arnd Bergmann

Quoted 9 lines · Pawel Moll

Quoted 7 lines · Lee Jones

drivers/mmc/host/mmci.c +7 -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;

Quoted 2 lines

Quoted 2 lines

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...

Quoted 2 lines

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.

Quoted 11 lines · Lee Jones

Quoted 10 lines · Arnd Bergmann

Quoted 9 lines · Pawel Moll

Quoted 7 lines · Lee Jones

drivers/mmc/host/mmci.c +7 -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;

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

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 ;-)

Quoted 5 lines

Quoted 2 lines

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

Different patch series.

Quoted 2 lines

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.

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 <[email protected]>

---

?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(-)

Quoted 6 lines · 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.

Quoted 8 lines

Signed-off-by Lee Jones<[email protected]>

---
  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

Quoted 2 lines · Linus Walleij

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.

Quoted 6 lines · Lee Jones

drivers/mmc/host/mmci.c +4 -0

+	/* Must have platform data or Device Tree. */
+	if (!plat&&  !np) {
+		dev_err(&dev->dev, "No plat data or DT found\n");
+		return -EINVAL;
  	}

drivers/mmc/host/mmci.c static const struct mmc_host_ops mmci_ops = { · line 1262

Quoted 2 lines

drivers/mmc/host/mmci.c +2 -0

+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);

Please tell me what happens if plat is NULL, but we're running on a DT enabled platform. Something tells me that you might just want to fix that case _before_ I apply your patch.

drivers/mmc/host/mmci.c +49 -1

+#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;
+	int ret, freeplat = 0;
+
+	/* Must have platform data or Device Tree. */

drivers/mmc/host/mmci.c +9 -0

+		if (!plat)
+			return -ENOMEM;
+		freeplat = 1;
 	}
 
+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);
+
 	ret = amba_request_regions(dev, DRIVER_NAME);
 	if (ret)
 		goto out;

@@ -1448,6 +1505,9 @@ static int __devinit mmci_probe(struct amba_device *dev,
  rel_regions:
 	amba_release_regions(dev);
  out:
+	if (freeplat)
+		kfree(plat);
+
 	return ret;
 }
 

Signature · 1 line

1.7.9.5

Quoted 57 lines · Lee Jones

drivers/mmc/host/mmci.c +49 -1

+#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;
+	int ret, freeplat = 0;
+
+	/* Must have platform data or Device Tree. */

drivers/mmc/host/mmci.c static const struct mmc_host_ops mmci_ops = { · line 1262

Quoted 10 lines

drivers/mmc/host/mmci.c +5 -3

+	if (!plat&&  !np) {
+		dev_err(&dev->dev, "No plat data or DT found\n");
+		return -EINVAL;
+	}
 
-	/* must have platform data */
  	if (!plat) {
-		ret = -EINVAL;
-		goto out;
+		plat = kzalloc(sizeof(*plat), GFP_KERNEL);

I think this will leak memory - consider what happens if the driver gets bound and unbound from the same device a number of times.

How about using devm_kzalloc() instead, so that when probe fails or the driver is unbound, the memory is automatically freed? No need for that freeplat variable either...

Quoted 23 lines

drivers/mmc/host/mmci.c +9 -1

+		if (!plat)
+			return -ENOMEM;
+		freeplat = 1;
  	}
 
+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);
+
  	ret = amba_request_regions(dev, DRIVER_NAME);
  	if (ret)
  		goto out;

@@ -1448,6 +1505,9 @@ static int __devinit mmci_probe(struct amba_device *dev,
   rel_regions:
  	amba_release_regions(dev);
   out:
+	if (freeplat)
+		kfree(plat);
+
  	return ret;
  }
 
--

1.7.9.5

From: Lee Jones <[email protected]>
Date: Mon, 16 Apr 2012 10:18:43 +0100
Subject: [PATCH 01/19] MMC: mmci: Enable Device Tree support for ux500
variants

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.

Acked-by Linus Walleij <[email protected]>

Acked-by Arnd Bergmann <[email protected]>

Signed-off-by Lee Jones <[email protected]>

---
 drivers/mmc/host/mmci.c |   62 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 59 insertions(+), 3 deletions(-)

drivers/mmc/host/mmci.c +59 -3

index 032b847..c2bd5ea 100644
@@ -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,76 @@ 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 */
+	/* Must have platform data or Device Tree. */
+	if (!plat && !np) {
+		dev_err(&dev->dev, "No plat data or DT found\n");
+		return -EINVAL;
+	}
+
 	if (!plat) {
-		ret = -EINVAL;
-		goto out;
+		plat = devm_kzalloc(&dev->dev, sizeof(*plat), GFP_KERNEL);
+		if (!plat)
+			return -ENOMEM;
 	}
 
+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);
+
 	ret = amba_request_regions(dev, DRIVER_NAME);
 	if (ret)
 		goto out;

Signature · 1 line

1.7.9.5

Quoted 11 lines · Lee Jones

From: Lee Jones<[email protected]>
Date: Mon, 16 Apr 2012 10:18:43 +0100
Subject: [PATCH 01/19] MMC: mmci: Enable Device Tree support for ux500
variants

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.

Quoted 3 lines

Acked-by Linus Walleij<[email protected]>

Acked-by Arnd Bergmann<[email protected]>

Signed-off-by Lee Jones<[email protected]>

This looks fine now, thanks.

Quoted 98 lines

---
  drivers/mmc/host/mmci.c |   62 ++++++++++++++++++++++++++++++++++++++++++++---
  1 file changed, 59 insertions(+), 3 deletions(-)

drivers/mmc/host/mmci.c +59 -4

index 032b847..c2bd5ea 100644
@@ -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,76 @@ 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 */
+	/* Must have platform data or Device Tree. */
+	if (!plat&&  !np) {
+		dev_err(&dev->dev, "No plat data or DT found\n");
+		return -EINVAL;
+	}
+
  	if (!plat) {
-		ret = -EINVAL;
-		goto out;
+		plat = devm_kzalloc(&dev->dev, sizeof(*plat), GFP_KERNEL);
+		if (!plat)
+			return -ENOMEM;
  	}
 
+	if (np)
+		mmci_dt_populate_generic_pdata(np, plat);
+
  	ret = amba_request_regions(dev, DRIVER_NAME);
  	if (ret)
  		goto out;
--

1.7.9.5

Would you be kind enough to cast your eye over the documentation patch as well please? I believe Chris is waiting on an Ack from you before he will pull it.

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

Quoted 4 lines · Lee Jones

Would you be kind enough to cast your eye over the documentation patch as well please? I believe Chris is waiting on an Ack from you before he will pull it.

Quoted 1 line

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

I'm not sure I'm the right person for doing that because I've hardly touched DT stuff.

Provided the properties are sanely named, and the common properties between drivers is already sensibly separated, then I don't see there's much to comment on.

One thing that might help is if the format of these descriptions were changed so that there was one file per subsystem documenting the common options, rather than (eg) every MMC driver documentating the same base options time and time again.

Quoted 4 lines · Russell King - ARM Linux

One thing that might help is if the format of these descriptions were changed so that there was one file per subsystem documenting the common options, rather than (eg) every MMC driver documentating the same base options time and time again.

I'm afraid that's not really for me to decide, however Grant is on CC. Perhaps that's a point he'd like to drive. If he's stopped reading this thread and fails to reply, I will endeavor to poke him about it while we're in Hong Kong.

Quoted 6 lines · Lee Jones

Quoted 4 lines · Russell King - ARM Linux

One thing that might help is if the format of these descriptions were changed so that there was one file per subsystem documenting the common options, rather than (eg) every MMC driver documentating the same base options time and time again.

Quoted 4 lines

I'm afraid that's not really for me to decide, however Grant is on CC. Perhaps that's a point he'd like to drive. If he's stopped reading this thread and fails to reply, I will endeavor to poke him about it while we're in Hong Kong.

It's what we're already doing for other things where there's a lot of commonality like regulators, I don't think there's any conroversy, it's just reminding people to not cut'n'paste.

Quoted 5 lines · Lee Jones

Would you be kind enough to cast your eye over the documentation patch as well please? I believe Chris is waiting on an Ack from you before he will pull it.

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

I'm not sure I'm the right person for doing that because I've hardly touched DT stuff.

Provided the properties are sanely named, and the common properties between drivers is already sensibly separated, then I don't see there's much to comment on.

One thing that might help is if the format of these descriptions were changed so that there was one file per subsystem documenting the common options, rather than (eg) every MMC driver documentating the same base options time and time again.

Hi,

Quoted 10 lines · Russell King - ARM Linux

Quoted 5 lines · Lee Jones

Would you be kind enough to cast your eye over the documentation patch as well please? I believe Chris is waiting on an Ack from you before he will pull it.

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

I'm not sure I'm the right person for doing that because I've hardly touched DT stuff.

Quoted 8 lines

Provided the properties are sanely named, and the common properties between drivers is already sensibly separated, then I don't see there's much to comment on.

One thing that might help is if the format of these descriptions were changed so that there was one file per subsystem documenting the common options, rather than (eg) every MMC driver documentating the same base options time and time again.

Arnd has a patch to add a single file description of MMC bindings, but it's been a while since the last revision -- Arnd, is there anything we can do to help get your bindings patch merged soon?

Lee, Arnd's Acked-by is fine for this patch, I can take it via MMC if the MMC patches are self-contained. I'm having trouble finding the latest patchset in one place, though; could you send me a pointer to it, or repost it to me and the MMC list with your ACKs included?

Thanks very much,

I can either do that, or push it through Arnd's tree if you like (and it's okay with him), as I will be supplying him with another pull request after my next patch-set has been scrutinised. Would that suit you better?

Hi,

Quoted 4 lines · Lee Jones

I can either do that, or push it through Arnd's tree if you like (and it's okay with him), as I will be supplying him with another pull request after my next patch-set has been scrutinised. Would that suit you better?

If the MMC patches are self-contained and it doesn't break anything to merge them separately, my preference is to merge them via the MMC tree (to avoid creating conflicts against other MMC patches in there).

If there are dependencies, going via Arnd instead is fine.

Quoted 5 lines · Chris Ball

Hi,

Quoted 1 line · Lee Jones

Quoted 7 lines

Quoted 4 lines

I can either do that, or push it through Arnd's tree if you like (and it's okay with him), as I will be supplying him with another pull request after my next patch-set has been scrutinised. Would that suit you better?

If the MMC patches are self-contained and it doesn't break anything to

Quoted 4 lines

merge them separately, my preference is to merge them via the MMC tree (to avoid creating conflicts against other MMC patches in there).

If there are dependencies, going via Arnd instead is fine.

Okay, I'll knock up a small patch-set and send it to you.

I think it's 3 patches.

--
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

_______________________________________________
linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 6 lines · Lee Jones

Quoted 5 lines · Chris Ball

Hi,

Quoted 1 line · Lee Jones

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

I can either do that, or push it through Arnd's tree if you like (and it's okay with him), as I will be supplying him with another pull request after my next patch-set has been scrutinised. Would that suit you better?

If the MMC patches are self-contained and it doesn't break anything to

Hi All,

The version of these patches that just appeared in linux-next is causing build fails on about 5 different configs (versatile_defconfig etc).

It isn't hard to see (with hindsight) that the new function is declared in an #ifdef CONFIG_OF block, but it's callers are not similarly guarded. So you get things like this:

http://kisskb.ellerman.id.au/kisskb/buildresult/6272348/

If you can get a fixed up version into the linux-next queue ASAP, that would be great.

Quoted 9 lines

Quoted 4 lines

merge them separately, my preference is to merge them via the MMC tree (to avoid creating conflicts against other MMC patches in there).

If there are dependencies, going via Arnd instead is fine.

Okay, I'll knock up a small patch-set and send it to you.

I think it's 3 patches.

I've fixed the issue. How would you like the fix?

As a fix patch, or a replacement for the broken one?

Here you go Chris.

From: Lee Jones <[email protected]>
Date: Tue, 8 May 2012 13:40:02 +0100
Subject: [PATCH] MMC: mmci: Fix compiler error when CONFIG_OF is not set

error: implicit declaration of function 'mmci_dt_populate_generic_pdata'

This is due to the '#if CONFIG_OF' guards placed around mmci_dt_populate_generic_pdata(), but not around the call to it. We repair this by inserting a stub which elegantly returns when CONFIG_OF is not set.

Signed-off-by Lee Jones <[email protected]>

---
 drivers/mmc/host/mmci.c |    6 ++++++
 1 file changed, 6 insertions(+)

drivers/mmc/host/mmci.c +0 -0

index 2303a16..efc822d 100644
@@ -1241,6 +1241,12 @@ static void mmci_dt_populate_generic_pdata(struct device_node *np,
 		pr_warn("%s: Unsupported bus width\n", np->full_name);
 	}

Here you go Chris.

From: Lee Jones <[email protected]>
Date: Tue, 8 May 2012 13:40:02 +0100
Subject: [PATCH] MMC: mmci: Fix compiler error when CONFIG_OF is not set

error: implicit declaration of function 'mmci_dt_populate_generic_pdata'

This is due to the '#if CONFIG_OF' guards placed around mmci_dt_populate_generic_pdata(), but not around the call to it. We repair this by inserting a stub which elegantly returns when CONFIG_OF is not set.

Signed-off-by Lee Jones <[email protected]>

---
?drivers/mmc/host/mmci.c | ? ?6 ++++++
?1 file changed, 6 insertions(+)

drivers/mmc/host/mmci.c +6 -0

index 2303a16..efc822d 100644
@@ -1241,6 +1241,12 @@ static void mmci_dt_populate_generic_pdata(struct device_node *np,
 ? ? ? ? ? ? ? ?pr_warn("%s: Unsupported bus width\n", np->full_name);
 ? ? ? ?}
 ?}
+#else
+static void mmci_dt_populate_generic_pdata(struct device_node *np,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct mmci_platform_data *pdata)
+{
+ ? ? ? return;
+}

?#endif

?static int __devinit mmci_probe(struct amba_device *dev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

Quoted 13 lines · Lee Jones

Here you go Chris.

From: Lee Jones <[email protected]>
Date: Tue, 8 May 2012 13:40:02 +0100
Subject: [PATCH] MMC: mmci: Fix compiler error when CONFIG_OF is not set

error: implicit declaration of function 'mmci_dt_populate_generic_pdata'

This is due to the '#if CONFIG_OF' guards placed around mmci_dt_populate_generic_pdata(), but not around the call to it. We repair this by inserting a stub which elegantly returns when CONFIG_OF is not set.

Quoted 1 line

Signed-off-by Lee Jones <[email protected]>

Please if possible, do not neglect to add the Reported-by: line when appropriate. I've been at this long enough that it really won't change my life any if it is there or not there, but for someone new to linux, it might make the difference between an "I'm glad I reported that" vs. a "Screw them, I'm not reporting anything else in the future."

Hi Paul,

Quoted 14 lines · Paul Gortmaker

Quoted 13 lines · Lee Jones

Here you go Chris.

From: Lee Jones <[email protected]>
Date: Tue, 8 May 2012 13:40:02 +0100
Subject: [PATCH] MMC: mmci: Fix compiler error when CONFIG_OF is not set

error: implicit declaration of function 'mmci_dt_populate_generic_pdata'

This is due to the '#if CONFIG_OF' guards placed around mmci_dt_populate_generic_pdata(), but not around the call to it. We repair this by inserting a stub which elegantly returns when CONFIG_OF is not set.

Quoted 7 lines

Quoted 1 line

Signed-off-by Lee Jones <[email protected]>

Please if possible, do not neglect to add the Reported-by: line when appropriate. I've been at this long enough that it really won't change my life any if it is there or not there, but for someone new to linux, it might make the difference between an "I'm glad I reported that" vs. a "Screw them, I'm not reporting anything else in the future."

Agreed -- I added a Reported-by line when I applied the patch:

http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=c0a120a4bc68f5dc5f5238e76013cc18bac0ffed

Thanks,

- Chris.

Signature · 2 lines

Chris Ball   <[email protected]>   <http://printf.net/>
One Laptop Per Child

The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a:

Linux 3.4-rc5 (2012-04-29 15:19:10 -0700)

are available in the git repository at:

git://git.linaro.org/people/ljones/linux-3.0-ux500.git mmc-for-chrisb

for you to fetch changes up to b6e0fdd89668db08a40f8cbe687b23f1eaf15b5a:

drivers/mmc: MMCI: Use correct GPIO binding for IRQ requests
(2012-05-04 14:47:28 +0100)

----------------------------------------------------------------
Lee Jones (3):
MMC: mmci: Enable Device Tree support for ux500 variants
MMC: mmci: Add required documentation for Device Tree bindings drivers/mmc: MMCI: Use correct GPIO binding for IRQ requests

 Documentation/devicetree/bindings/mmc/mmci.txt |   19 ++++++++
 drivers/mmc/host/mmci.c                        |   59
++++++++++++++++++++++--
 2 files changed, 74 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmci.txt

From: Lee Jones <[email protected]>
Date: Mon, 16 Apr 2012 10:18:43 +0100
Subject: [PATCH 6.2/7] MMC: mmci: Enable Device Tree support for ux500 variants

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.

Acked-by Linus Walleij <[email protected]>

Acked-by Arnd Bergmann <[email protected]>

Signed-off-by Lee Jones <[email protected]>

---
 drivers/mmc/host/mmci.c |   58 +++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 54 insertions(+), 4 deletions(-)

drivers/mmc/host/mmci.c +54 -4

index 032b847..5a7da17 100644
@@ -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;

Signature · 1 line

1.7.9.1

So why is this buggy patch now merged in the mainline kernel?

Quoted 11 lines · Lee Jones

From: Lee Jones<[email protected]>
Date: Mon, 16 Apr 2012 10:18:43 +0100
Subject: [PATCH 01/19] MMC: mmci: Enable Device Tree support for ux500
variants

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.

Quoted 3 lines

Acked-by Linus Walleij<[email protected]>

Acked-by Arnd Bergmann<[email protected]>

Signed-off-by Lee Jones<[email protected]>

This looks fine now, thanks.

Quoted 1 line · Russell King - ARM Linux

So why is this buggy patch now merged in the mainline kernel?

I guess Chris took it because you said it was fine?

Quoted 4 lines · Lee Jones

Quoted 1 line · Russell King - ARM Linux

So why is this buggy patch now merged in the mainline kernel?

I guess Chris took it because you said it was fine?

Err, no. ?If you re-read the thread, you'll see that I said your subsequent patch posted on Thu, 03 May 2012 16:30:48 +0100 with the devm_kzalloc() was fine.

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

So why is this buggy patch now merged in the mainline kernel?

I guess Chris took it because you said it was fine?

Err, no. If you re-read the thread, you'll see that I said your subsequent patch posted on Thu, 03 May 2012 16:30:48 +0100 with the devm_kzalloc() was fine.

Quoted 4 lines

Lee can you provide an incremental fixup that makes the current

code textually equivalent to what Russell ACKed (devm_kzalloc()), and funnel to Chris for the -rc:s ASAP?

Lee can you provide an incremental fixup that makes the current code textually equivalent to what Russell ACKed (devm_kzalloc()), and funnel to Chris for the -rc:s ASAP?

From: Lee Jones <[email protected]>
Date: Mon, 11 Jun 2012 10:41:00 +0100
Subject: [PATCH] mmc: mmci: Allocate platform memory during Device Tree boot

When booting with Device Tree enabled, platform specific information is gathered by parsing the DT binary. Platform data is subsequently populated with the result. The memory required for this is not automatically allocated during Device Tree boot, so we'll do it here instead.

Signed-off-by Lee Jones <[email protected]>

+Required properties:
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.

Quoted 2 lines · Lee Jones

+Required properties:
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.

I'd say that this is _very_ optional (as in: don't use this, unless you know what are you doing ;-)

Also, how are you planning to represent the ".ocr_mask" part of the platform data? (I'm asking about this particular one, because it's the only I need on vexpress ;-)

Quoted 2 lines · Lee Jones

+Required properties:
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.

I'd say that this is _very_ optional (as in: don't use this, unless you know what are you doing ;-)

Also, how are you planning to represent the ".ocr_mask" part of the platform data? (I'm asking about this particular one, because it's the only I need on vexpress ;-)

Quoted 6 lines · Pawel Moll

Quoted 2 lines · Lee Jones

+Required properties:
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.

I'd say that this is _very_ optional (as in: don't use this, unless you know what are you doing ;-)

Okay.

Who is pulling this patch by the way? Chris is it you?

Hi,

Quoted 8 lines · Lee Jones

Quoted 6 lines · Pawel Moll

Quoted 2 lines · Lee Jones

+Required properties:
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID.

I'd say that this is _very_ optional (as in: don't use this, unless you know what are you doing ;-)

Quoted 3 lines

Okay.

Who is pulling this patch by the way? Chris is it you?

Russell King is maintaining MMCI (although I don't think MAINTAINERS has caught up with that yet) -- it would be ideal for me if you could get an ACK from him so that I can merge it to mmc-next and send it to Linus.

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 <[email protected]>

---
 Documentation/devicetree/bindings/mmc/mmci.txt |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmci.txt

Documentation/devicetree/bindings/mmc/mmci.txt new file +19 -0

new file mode 100644
index 0000000..14a81d5
@@ -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
+- max-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

Signature · 1 line

1.7.9.1

In this patch-set we change a couple of DT compatible entries to something less cumbersome. 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.