Skip to contentSkip to conversation

Device Tree binding for the mvsdio driver and related changes

PATCH Superseded Thomas Petazzoni 2 participants 22 messages Dec 18, 2012

Subsystems (5)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

Hello,

This series of patches adds a Device Tree binding to the mvsdio driver (the driver for the SDIO interface found in many Marvell SoCs), and uses this binding to enable the SDIO interface on Armada 370 and Armada XP platforms, as well as converting the Kirkwood platforms to using the Device Tree to probe the SDIO interface.

This series is obviously 3.9 material.

Here is a short description of the patches:

* Patches 1 and 2 cleanup the mvsdio driver initialization by using the slot-gpio helpers for the card-detect and write-protect GPIOs

* Patch 3 adds the Device Tree binding itself to the mvsdio driver

* Patch 4 adds pinctrl integration to the mvsdio driver

* Patch 5 adds Device Tree information to describe the SDIO interface on the Armada 370 and Armada XP SoCs.

* Patches 6 and 7 add pin muxing options for the SDIO interface on Armada 370 and Armada XP SoCs.

* Patches 8, 9, 10 enable the SDIO interface on the Armada XP DB, Armada 370 DB and Globalscale Mirabox platforms.

* Patch 11 adds Device Tree information to describe the SDIO interface on the Kirkwood SoCs.

* Patches 12, 13, 14 convert the Kirkwood platforms that have been migrated to the Device Tree, to actually use the Device Tree to probe the SDIO interface.

* Patch 15 removes a useless header inclusion related to the SDIO interface to the Kirkwood Dockstar platform.

* Patches 16, 17 and 18 update the mvebu_defconfig to enable the mvsdio driver, as well as Wifi/Bluetooth drivers needed for the SD8787 chip connected over SDIO on the Globalscale Mirabox.

Best regards,

Thomas

#1 lore raw

PATCH 1/18 mmc: mvsdio: use slot-gpio infrastructure for write protect gpio

The MMC core subsystem provides in drivers/mmc/core/slot-gpio.c a nice set of helper functions to simplify the management of the write protect GPIO in MMC host drivers. This patch migrates the mvsdio driver to using those helpers, which will make the ->probe() code simpler, and therefore ease the process of adding a Device Tree binding for this driver.

---
 drivers/mmc/host/mvsdio.c |   34 +++++-----------------------------
 1 file changed, 5 insertions(+), 29 deletions(-)
drivers/mmc/host/mvsdio.c +5 -29
index de4c20b..a24a22f 100644
@@ -22,6 +22,7 @@
 #include <linux/clk.h>
 #include <linux/gpio.h>
 #include <linux/mmc/host.h>
+#include <linux/mmc/slot-gpio.h>
 
 #include <asm/sizes.h>
 #include <asm/unaligned.h>
@@ -54,7 +55,6 @@ struct mvsd_host {
 	int irq;
 	struct clk *clk;
 	int gpio_card_detect;
-	int gpio_write_protect;
 };
 
 #define mvsd_write(offs, val)	writel(val, iobase + (offs))
@@ -566,20 +566,6 @@ static void mvsd_enable_sdio_irq(struct mmc_host *mmc, int enable)
 	spin_unlock_irqrestore(&host->lock, flags);
 }
 
-static int mvsd_get_ro(struct mmc_host *mmc)
-{
-	struct mvsd_host *host = mmc_priv(mmc);
-
-	if (host->gpio_write_protect)
-		return gpio_get_value(host->gpio_write_protect);
-
-	/*
-	 * Board doesn't support read only detection; let the mmc core
-	 * decide what to do.
-	 */
-	return -ENOSYS;
-}
-
 static void mvsd_power_up(struct mvsd_host *host)
 {
 	void __iomem *iobase = host->base;
@@ -676,7 +662,7 @@ static void mvsd_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 static const struct mmc_host_ops mvsd_ops = {
 	.request		= mvsd_request,
-	.get_ro			= mvsd_get_ro,
+	.get_ro			= mmc_gpio_get_ro,
 	.set_ios		= mvsd_set_ios,
 	.enable_sdio_irq	= mvsd_enable_sdio_irq,
 };
@@ -798,15 +784,7 @@ static int __init mvsd_probe(struct platform_device *pdev)
 	if (!host->gpio_card_detect)
 		mmc->caps |= MMC_CAP_NEEDS_POLL;
 
-	if (mvsd_data->gpio_write_protect) {
-		ret = gpio_request(mvsd_data->gpio_write_protect,
-				   DRIVER_NAME " wp");
-		if (ret == 0) {
-			gpio_direction_input(mvsd_data->gpio_write_protect);
-			host->gpio_write_protect =
-				mvsd_data->gpio_write_protect;
-		}
-	}
+	mmc_gpio_request_ro(mmc, mvsd_data->gpio_write_protect);
 
 	setup_timer(&host->timer, mvsd_timeout_timer, (unsigned long)host);
 	platform_set_drvdata(pdev, mmc);
@@ -831,8 +809,7 @@ out:
 			free_irq(gpio_to_irq(host->gpio_card_detect), host);
 			gpio_free(host->gpio_card_detect);
 		}
-		if (host->gpio_write_protect)
-			gpio_free(host->gpio_write_protect);
+		mmc_gpio_free_ro(mmc);
 		if (host->base)
 			iounmap(host->base);
 	}
@@ -861,8 +838,7 @@ static int __exit mvsd_remove(struct platform_device *pdev)
 		}
 		mmc_remove_host(mmc);
 		free_irq(host->irq, host);
-		if (host->gpio_write_protect)
-			gpio_free(host->gpio_write_protect);
+		mmc_gpio_free_ro(mmc);
 		del_timer_sync(&host->timer);
 		mvsd_power_down(host);
 		iounmap(host->base);
Signature · 1 line
1.7.9.5
#2 lore raw

PATCH 2/18 mmc: mvsdio: use slot-gpio for card detect gpio

In reply to Thomas Petazzoni

The MMC core subsystem provides in drivers/mmc/core/slot-gpio.c a nice set of helper functions to simplify the management of the card detect GPIO in MMC host drivers. This patch migrates the mvsdio driver to using those helpers, which will make the ->probe() code simpler, and therefore ease the process of adding a Device Tree binding for this driver.

---
 drivers/mmc/host/mvsdio.c |   44 +++++++++-----------------------------------
 1 file changed, 9 insertions(+), 35 deletions(-)
drivers/mmc/host/mvsdio.c +9 -35
index a24a22f..baf19fc 100644
@@ -54,7 +54,6 @@ struct mvsd_host {
 	struct resource *res;
 	int irq;
 	struct clk *clk;
-	int gpio_card_detect;
 };
 
 #define mvsd_write(offs, val)	writel(val, iobase + (offs))
@@ -540,13 +539,6 @@ static void mvsd_timeout_timer(unsigned long data)
 		mmc_request_done(host->mmc, mrq);
 }
 
-static irqreturn_t mvsd_card_detect_irq(int irq, void *dev)
-{
-	struct mvsd_host *host = dev;
-	mmc_detect_change(host->mmc, msecs_to_jiffies(100));
-	return IRQ_HANDLED;
-}
-
 static void mvsd_enable_sdio_irq(struct mmc_host *mmc, int enable)
 {
 	struct mvsd_host *host = mmc_priv(mmc);
@@ -765,23 +757,11 @@ static int __init mvsd_probe(struct platform_device *pdev)
 		clk_prepare_enable(host->clk);
 	}
 
-	if (mvsd_data->gpio_card_detect) {
-		ret = gpio_request(mvsd_data->gpio_card_detect,
-				   DRIVER_NAME " cd");
-		if (ret == 0) {
-			gpio_direction_input(mvsd_data->gpio_card_detect);
-			irq = gpio_to_irq(mvsd_data->gpio_card_detect);
-			ret = request_irq(irq, mvsd_card_detect_irq,
-					  IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING,
-					  DRIVER_NAME " cd", host);
-			if (ret == 0)
-				host->gpio_card_detect =
-					mvsd_data->gpio_card_detect;
-			else
-				gpio_free(mvsd_data->gpio_card_detect);
-		}
-	}
-	if (!host->gpio_card_detect)
+	if (gpio_is_valid(mvsd_data->gpio_card_detect)) {
+		ret = mmc_gpio_request_cd(mmc, mvsd_data->gpio_card_detect);
+		if (ret)
+			goto out;
+	} else
 		mmc->caps |= MMC_CAP_NEEDS_POLL;
 
 	mmc_gpio_request_ro(mmc, mvsd_data->gpio_write_protect);
@@ -794,9 +774,9 @@ static int __init mvsd_probe(struct platform_device *pdev)
 
 	pr_notice("%s: %s driver initialized, ",
 			   mmc_hostname(mmc), DRIVER_NAME);
-	if (host->gpio_card_detect)
+	if (!(mmc->caps & MMC_CAP_NEEDS_POLL))
 		printk("using GPIO %d for card detection\n",
-		       host->gpio_card_detect);
+		       mvsd_data->gpio_card_detect);
 	else
 		printk("lacking card detect (fall back to polling)\n");
 	return 0;
@@ -805,10 +785,7 @@ out:
 	if (host) {
 		if (host->irq)
 			free_irq(host->irq, host);
-		if (host->gpio_card_detect) {
-			free_irq(gpio_to_irq(host->gpio_card_detect), host);
-			gpio_free(host->gpio_card_detect);
-		}
+		mmc_gpio_free_cd(mmc);
 		mmc_gpio_free_ro(mmc);
 		if (host->base)
 			iounmap(host->base);
@@ -832,10 +809,7 @@ static int __exit mvsd_remove(struct platform_device *pdev)
 	if (mmc) {
 		struct mvsd_host *host = mmc_priv(mmc);
 
-		if (host->gpio_card_detect) {
-			free_irq(gpio_to_irq(host->gpio_card_detect), host);
-			gpio_free(host->gpio_card_detect);
-		}
+		mmc_gpio_free_cd(mmc);
 		mmc_remove_host(mmc);
 		free_irq(host->irq, host);
 		mmc_gpio_free_ro(mmc);
Signature · 1 line
1.7.9.5
#3 lore raw

PATCH 3/18 mmc: mvsdio: implement a Device Tree binding

In reply to Thomas Petazzoni

This patch adds a simple Device Tree binding for the mvsdio driver, as well as the necessary documentation for it. Compatibility with non-DT platforms is preserved, by keeping the platform_data based initialization.

We introduce a small difference between non-DT and DT platforms: DT platforms are required to provide a clocks = <...> property, which the driver uses to get the frequency of the clock that goes to the SDIO IP. The behaviour on non-DT platforms is kept unchanged: a clock reference is not mandatory, but the clock frequency must be passed in the "clock" field of the mvsdio_platform_data structure.

---
 .../devicetree/bindings/mmc/orion-sdio.txt         |   17 ++++++
 drivers/mmc/host/mvsdio.c                          |   60 +++++++++++++++-----
 2 files changed, 62 insertions(+), 15 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/orion-sdio.txt
Documentation/devicetree/bindings/mmc/orion-sdio.txt new file +17 -0
new file mode 100644
index 0000000..84f0ebd
@@ -0,0 +1,17 @@
+* Marvell orion-sdio controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the orion-sdio driver.
+
+- compatible: Should be "marvell,orion-sdio"
+- clocks: reference to the clock of the SDIO interface
+
+Example:
+
+	mvsdio at d00d4000 {
+		compatible = "marvell,orion-sdio";
+		reg = <0xd00d4000 0x200>;
+		interrupts = <54>;
+		clocks = <&gateclk 17>;
+		status = "disabled";
+	};
drivers/mmc/host/mvsdio.c +45 -15

115 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#4 lore raw

PATCH 4/18 mmc: mvsdio: add pinctrl integration

In reply to Thomas Petazzoni

On many Marvell SoCs, the pins used for the SDIO interface are part of the MPP pins, that are muxable pins. In order to get the muxing of those pins correct, this commit integrates the mvsdio driver with the pinctrl infrastructure by calling devm_pinctrl_get_select_default() during ->probe().

Note that we permit this function to fail because not all Marvell platforms have yet been fully converted to using the pinctrl infrastructure.

---
 drivers/mmc/host/mvsdio.c |    6 ++++++
 1 file changed, 6 insertions(+)
drivers/mmc/host/mvsdio.c +6 -0
index 56954bc..feb16bd 100644
@@ -25,6 +25,7 @@
 #include <linux/of_irq.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/slot-gpio.h>
+#include <linux/pinctrl/consumer.h>
 
 #include <asm/sizes.h>
 #include <asm/unaligned.h>
@@ -692,6 +693,7 @@ static int __init mvsd_probe(struct platform_device *pdev)
 	struct resource *r;
 	int ret, irq;
 	int gpio_card_detect, gpio_write_protect;
+	struct pinctrl *pinctrl;
 
 	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	irq = platform_get_irq(pdev, 0);
@@ -713,6 +715,10 @@ static int __init mvsd_probe(struct platform_device *pdev)
 	host->dev = &pdev->dev;
 	host->res = r;
 
+	pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+	if (IS_ERR(pinctrl))
+		dev_warn(&pdev->dev, "no pins associated\n");
+
 	/* Some non-DT platforms do not pass a clock, and the clock
 	   frequency is passed through platform_data. On DT platforms,
 	   a clock must always be passed, even if there is no gatable
Signature · 1 line
1.7.9.5
#5 lore raw

PATCH 5/18 arm: mvebu: add DT information for the SDIO interface of Armada 370/XP

In reply to Thomas Petazzoni

Now that the mvsdio MMC driver has a Device Tree binding, we add the Device Tree informations to describe the SDIO interface available in the Armada 370/XP SoCs.

---
 arch/arm/boot/dts/armada-370-xp.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)
arch/arm/boot/dts/armada-370-xp.dtsi +8 -0
index cf6c48a..41a5b11 100644
@@ -129,6 +129,14 @@
 			clocks = <&coreclk 0>;
 			status = "disabled";
 		};
+
+		mvsdio at d00d4000 {
+			compatible = "marvell,orion-sdio";
+			reg = <0xd00d4000 0x200>;
+			interrupts = <54>;
+			clocks = <&gateclk 17>;
+			status = "disabled";
+		};
 	};
 };
 
Signature · 1 line
1.7.9.5
#6 lore raw

PATCH 6/18 arm: mvebu: add pin muxing options for the SDIO interface on Armada 370

In reply to Thomas Petazzoni

The SDIO interface is available either on pins MPP9/11/12/13/14/15 or MPP47/48/49/50/51/52 on the Armada 370. Even though all combinations are potentially possible, those two muxing options are the most probable ones, so we provide those at the SoC level .dtsi file.

In practice, in turns out the Armada 370 DB board uses the former, while the Armada 370 Mirabox uses the latter.

---
 arch/arm/boot/dts/armada-370.dtsi |   12 ++++++++++++
 1 file changed, 12 insertions(+)
arch/arm/boot/dts/armada-370.dtsi +12 -0
index 636cf7d..88f9bab 100644
@@ -47,6 +47,18 @@
 		pinctrl {
 			compatible = "marvell,mv88f6710-pinctrl";
 			reg = <0xd0018000 0x38>;
+
+			sdio_pins1: sdio-pins1 {
+			      marvell,pins = "mpp9",  "mpp11", "mpp12",
+					     "mpp13", "mpp14", "mpp15";
+			      marvell,function = "sd0";
+			};
+
+			sdio_pins2: sdio-pins2 {
+			      marvell,pins = "mpp47", "mpp48", "mpp49",
+					     "mpp50", "mpp51", "mpp52";
+			      marvell,function = "sd0";
+			};
 	        };
 
 		gpio0: gpio at d0018100 {
Signature · 1 line
1.7.9.5
#7 lore raw

PATCH 7/18 arm: mvebu: add pin muxing options for the SDIO interface on Armada XP

In reply to Thomas Petazzoni

The SDIO interface is only available on pins MPP30/31/32/33/34/35 on the various Armada XP variants, so we provide a pin muxing option for this in the Armada XP .dtsi files.

Even though those muxing options are the same for MV78230, MV78260 and MV78460, we keep them in each .dtsi file, because the number of pins, and therefore the declaration of the pinctrl node, is different for each SoC variant.

---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |    6 ++++++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |    6 ++++++
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |    6 ++++++
 3 files changed, 18 insertions(+)
arch/arm/boot/dts/armada-xp-mv78230.dtsi +6 -0
index c45c7b4..3fa9c84 100644
@@ -40,6 +40,12 @@
 		pinctrl {
 			compatible = "marvell,mv78230-pinctrl";
 			reg = <0xd0018000 0x38>;
+
+			sdio_pins: sdio-pins {
+				marvell,pins = "mpp30", "mpp31", "mpp32",
+					       "mpp33", "mpp34", "mpp35";
+				marvell,function = "sd0";
+			};
 		};
 
 		gpio0: gpio at d0018100 {
arch/arm/boot/dts/armada-xp-mv78260.dtsi +6 -0
index a2aee57..5a907b3 100644
@@ -48,6 +48,12 @@
 		pinctrl {
 			compatible = "marvell,mv78260-pinctrl";
 			reg = <0xd0018000 0x38>;
+
+			sdio_pins: sdio-pins {
+				marvell,pins = "mpp30", "mpp31", "mpp32",
+					       "mpp33", "mpp34", "mpp35";
+				marvell,function = "sd0";
+			};
 		};
 
 		gpio0: gpio at d0018100 {
arch/arm/boot/dts/armada-xp-mv78460.dtsi +6 -0
index da03a12..6dcdc50d 100644
@@ -63,6 +63,12 @@
 		pinctrl {
 			compatible = "marvell,mv78460-pinctrl";
 			reg = <0xd0018000 0x38>;
+
+			sdio_pins: sdio-pins {
+				marvell,pins = "mpp30", "mpp31", "mpp32",
+					       "mpp33", "mpp34", "mpp35";
+				marvell,function = "sd0";
+			};
 		};
 
 		gpio0: gpio at d0018100 {
Signature · 1 line
1.7.9.5
#8 lore raw

PATCH 8/18 arm: mvebu: enable the SD card slot on Armada XP DB board

In reply to Thomas Petazzoni

The Armada XP DB evaluation board has one SD card slot, directly connected to the SDIO IP of the SoC, so we enable this IP. Unfortunately, there are no GPIOs for card-detect and write-protect.

---
 arch/arm/boot/dts/armada-xp-db.dts |    7 +++++++
 1 file changed, 7 insertions(+)
arch/arm/boot/dts/armada-xp-db.dts +7 -0
index 8e53b25..c7035c5 100644
@@ -90,5 +90,12 @@
 			phy = <&phy3>;
 			phy-mode = "sgmii";
 		};
+
+		mvsdio at d00d4000 {
+			pinctrl-0 = <&sdio_pins>;
+			pinctrl-names = "default";
+			status = "okay";
+			/* No CD or WP GPIOs */
+		};
 	};
 };
Signature · 1 line
1.7.9.5
#9 lore raw

PATCH 9/18 arm: mvebu: enable the SD card slot on Armada 370 DB board

In reply to Thomas Petazzoni

The Armada XP DB evaluation board has one SD card slot, directly connected to the SDIO IP of the SoC, so we add a device tree description for it.

However, in the default configuration of the board, the SD card slot is not usable: the connector plugged into CON40 must be changed against a different one, provided with the board by the manufacturer. Since such a manual modification of the hardware is needed, we did not enable the SDIO interface by default, and left it to the board user to modify the Device Tree if needed. Since this board is really only an evaluation board for developers and not a final product, it is not too bad.

---
 arch/arm/boot/dts/armada-370-db.dts |   15 +++++++++++++++
 1 file changed, 15 insertions(+)
arch/arm/boot/dts/armada-370-db.dts +15 -0
index 0004402..43ff156 100644
@@ -59,5 +59,20 @@
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
+
+		mvsdio at d00d4000 {
+			pinctrl-0 = <&sdio_pins1>;
+			pinctrl-names = "default";
+			/*
+			 * This device is disabled by default, because
+			 * using the SD card connector requires
+			 * changing the default CON40 connector
+			 * "DB-88F6710_MPP_2xRGMII_DEVICE_Jumper" to a
+			 * different connector
+			 * "DB-88F6710_MPP_RGMII_SD_Jumper".
+			 */
+			status = "disabled";
+			/* No CD or WP GPIOs */
+		};
 	};
 };
Signature · 1 line
1.7.9.5
#10 lore raw

PATCH 10/18 arm: mvebu: enable the SDIO interface on the Globalscale Mirabox

In reply to Thomas Petazzoni

The Globalscale Mirabox uses the SDIO interface of the Armada 370 to connect to a Wifi/Bluetooth SD8787 chip, so we enable the SDIO interface of this board in its Device Tree file.

---
 arch/arm/boot/dts/armada-370-mirabox.dts |   10 ++++++++++
 1 file changed, 10 insertions(+)
arch/arm/boot/dts/armada-370-mirabox.dts +10 -0
index 3b40713..1864820 100644
@@ -52,5 +52,15 @@
 			phy = <&phy1>;
 			phy-mode = "rgmii-id";
 		};
+
+		mvsdio at d00d4000 {
+			pinctrl-0 = <&sdio_pins2>;
+			pinctrl-names = "default";
+			status = "okay";
+			/*
+			 * No CD or WP GPIOs: SDIO interface used for
+			 * Wifi/Bluetooth chip
+			 */
+		};
 	};
 };
Signature · 1 line
1.7.9.5
#11 lore raw

PATCH 11/18 arm: kirkwood: add Device Tree informations for the SDIO controller

In reply to Thomas Petazzoni

Now that the SDIO controller has a Device Tree binding, let's use it in kirkwood.dtsi.

---
 arch/arm/boot/dts/kirkwood.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)
arch/arm/boot/dts/kirkwood.dtsi +8 -0
index 7735cee..baf1045 100644
@@ -190,5 +190,13 @@
 			clocks = <&gate_clk 17>;
 			status = "okay";
 		};
+
+		mvsdio at 90000 {
+			compatible = "marvell,orion-sdio";
+			reg = <0x90000 0x200>;
+			interrupts = <28>;
+			clocks = <&gate_clk 4>;
+			status = "disabled";
+		};
 	};
 };
Signature · 1 line
1.7.9.5
#12 lore raw

PATCH 12/18 arm: kirkwood: dreamplug: use Device Tree to probe SDIO

In reply to Thomas Petazzoni

Now that the mvsdio driver has a Device Tree binding, and the SDIO controller is declared in kirkwood.dtsi, migrate the dreamplug board to use the Device Tree to probe the SDIO controller.

---
 arch/arm/boot/dts/kirkwood-dreamplug.dts |    5 +++++
 arch/arm/mach-kirkwood/board-dreamplug.c |    5 -----
 2 files changed, 5 insertions(+), 5 deletions(-)
arch/arm/boot/dts/kirkwood-dreamplug.dts +5 -0
index f2d386c..0fceb76 100644
@@ -74,6 +74,11 @@
 			status = "okay";
 			nr-ports = <1>;
 		};
+
+		mvsdio at 90000 {
+			status = "okay";
+			/* No CD or WP GPIOs */
+		};
 	};
 
 	gpio-leds {
arch/arm/mach-kirkwood/board-dreamplug.c +0 -5
index 08248e2..b712b7f 100644
@@ -26,10 +26,6 @@ static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
 };
 
-static struct mvsdio_platform_data dreamplug_mvsdio_data = {
-	/* unfortunately the CD signal has not been connected */
-};
-
 void __init dreamplug_init(void)
 {
 	/*
@@ -37,5 +33,4 @@ void __init dreamplug_init(void)
 	 */
 	kirkwood_ge00_init(&dreamplug_ge00_data);
 	kirkwood_ge01_init(&dreamplug_ge01_data);
-	kirkwood_sdio_init(&dreamplug_mvsdio_data);
 }
Signature · 1 line
1.7.9.5
#13 lore raw

PATCH 12/18 arm: kirkwood: dreamplug: use Device Tree to probe SDIO

Quoted 3 lines · Thomas Petazzoni

Now that the mvsdio driver has a Device Tree binding, and the SDIO controller is declared in kirkwood.dtsi, migrate the dreamplug board to use the Device Tree to probe the SDIO controller.

Hi Thomas

It would be nice to add pinctrl to this. The likely pins are defined in kirkwood-6281.dtsi. dreamplug does not define hogs for these pins, so its relying on grub setting them up and nothing changing them.

Maybe Jason can do this?

arch/arm/mach-kirkwood/board-dreamplug.c

Quoted 27 lines
---
 arch/arm/boot/dts/kirkwood-dreamplug.dts |    5 +++++
 arch/arm/mach-kirkwood/board-dreamplug.c |    5 -----
 2 files changed, 5 insertions(+), 5 deletions(-)
arch/arm/boot/dts/kirkwood-dreamplug.dts +5 -0
index f2d386c..0fceb76 100644
@@ -74,6 +74,11 @@
 			status = "okay";
 			nr-ports = <1>;
 		};
+
+		mvsdio at 90000 {
+			status = "okay";
+			/* No CD or WP GPIOs */
+		};
 	};
 
 	gpio-leds {
arch/arm/mach-kirkwood/board-dreamplug.c +0 -0
index 08248e2..b712b7f 100644

There is probably a header file which can be removed as well.

Thanks
Andrew

Quoted 20 lines
arch/arm/mach-kirkwood/board-dreamplug.c +0 -5
@@ -26,10 +26,6 @@ static struct mv643xx_eth_platform_data dreamplug_ge01_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(1),
 };
 
-static struct mvsdio_platform_data dreamplug_mvsdio_data = {
-	/* unfortunately the CD signal has not been connected */
-};
-
 void __init dreamplug_init(void)
 {
 	/*
@@ -37,5 +33,4 @@ void __init dreamplug_init(void)
 	 */
 	kirkwood_ge00_init(&dreamplug_ge00_data);
 	kirkwood_ge01_init(&dreamplug_ge01_data);
-	kirkwood_sdio_init(&dreamplug_mvsdio_data);
 }
Signature · 1 line
1.7.9.5
#14 lore raw

PATCH 13/18 arm: kirkwood: mplcec4: use Device Tree to probe SDIO

In reply to Thomas Petazzoni

Now that the mvsdio driver has a Device Tree binding, and the SDIO controller is declared in kirkwood.dtsi, migrate the mplcec4 board to use the Device Tree to probe the SDIO controller.

This patch has not been tested, it remains to be tested by a person having access to the hardware.

---
 arch/arm/boot/dts/kirkwood-mplcec4.dts |    6 ++++++
 arch/arm/mach-kirkwood/board-mplcec4.c |    6 ------
 2 files changed, 6 insertions(+), 6 deletions(-)
arch/arm/boot/dts/kirkwood-mplcec4.dts +6 -0
index 262c654..ed10977 100644
@@ -133,6 +133,12 @@
 			status = "okay";
 
 		};
+
+		mvsdio at 90000 {
+			status = "okay";
+			cd-gpios = <&gpio1 15 0>;
+			/* No WP GPIO */
+		};
 	};
 
 	gpio-leds {
arch/arm/mach-kirkwood/board-mplcec4.c +0 -6
index 56bfe5a..183ff8a 100644
@@ -24,11 +24,6 @@ static struct mv643xx_eth_platform_data mplcec4_ge01_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(2),
 };
 
-static struct mvsdio_platform_data mplcec4_mvsdio_data = {
-	.gpio_card_detect = 47,	/* MPP47 used as SD card detect */
-};
-
-
 void __init mplcec4_init(void)
 {
 	/*
@@ -36,7 +31,6 @@ void __init mplcec4_init(void)
 	 */
 	kirkwood_ge00_init(&mplcec4_ge00_data);
 	kirkwood_ge01_init(&mplcec4_ge01_data);
-	kirkwood_sdio_init(&mplcec4_mvsdio_data);
 	kirkwood_pcie_init(KW_PCIE0);
 }
 
Signature · 1 line
1.7.9.5
#15 lore raw

PATCH 13/18 arm: kirkwood: mplcec4: use Device Tree to probe SDIO

Quoted 19 lines · Thomas Petazzoni

Now that the mvsdio driver has a Device Tree binding, and the SDIO controller is declared in kirkwood.dtsi, migrate the mplcec4 board to use the Device Tree to probe the SDIO controller.

This patch has not been tested, it remains to be tested by a person having access to the hardware.

---
 arch/arm/boot/dts/kirkwood-mplcec4.dts |    6 ++++++
 arch/arm/mach-kirkwood/board-mplcec4.c |    6 ------
 2 files changed, 6 insertions(+), 6 deletions(-)
arch/arm/boot/dts/kirkwood-mplcec4.dts +0 -0
index 262c654..ed10977 100644

arch/arm/boot/dts/kirkwood-mplcec4.dts line 142

Quoted 10 lines
arch/arm/boot/dts/kirkwood-mplcec4.dts +6 -0
@@ -133,6 +133,12 @@
 			status = "okay";
 
 		};
+
+		mvsdio at 90000 {
+			status = "okay";
+			cd-gpios = <&gpio1 15 0>;
+			/* No WP GPIO */
+		};
 	};

Hi Thomas

kirkwood-mplcec4.dts contains:

                pinctrl: pinctrl at 10000 {

                        pinctrl-0 = < &pmx_nand &pmx_uart0
                                      &pmx_led_health &pmx_sdio
                                      &pmx_sata0 &pmx_sata1
                                      &pmx_led_user1o
                                      &pmx_led_user1g &pmx_led_user0o
                                      &pmx_led_user0g &pmx_led_misc
                                      &pmx_sdio_cd
                                    >;
                        pinctrl-names = "default";

Should &pmx_sdio and &pmx_sdio_cd be moved out of here and into the mvsdio at 90000 node?

arch/arm/mach-kirkwood/board-mplcec4.c static struct mv643xx_eth_platform_data mplcec4_ge01_data = { · line 25

Quoted 9 lines
arch/arm/boot/dts/kirkwood-mplcec4.dts +0 -0
 	gpio-leds {
arch/arm/mach-kirkwood/board-mplcec4.c +0 -0
index 56bfe5a..183ff8a 100644
@@ -24,11 +24,6 @@ static struct mv643xx_eth_platform_data mplcec4_ge01_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(2),
 };

There is another header file which can be removed.

Thanks
Andrew

#16 lore raw

PATCH 14/18 arm: kirkwood: topkick: use Device Tree to probe SDIO

In reply to Thomas Petazzoni

Now that the mvsdio driver has a Device Tree binding, and the SDIO controller is declared in kirkwood.dtsi, migrate the topkick board to use the Device Tree to probe the SDIO controller.

The patch has been tested on the Topkick hardware. However, due to an apparently unrelated problem, it is unable to detect the Wifi chip connected on the SDIO bus.

---
 arch/arm/boot/dts/kirkwood-topkick.dts     |    7 +++++++
 arch/arm/mach-kirkwood/board-usi_topkick.c |    5 -----
 2 files changed, 7 insertions(+), 5 deletions(-)
arch/arm/boot/dts/kirkwood-topkick.dts +7 -0
index c0de5a7..cb04f47 100644
@@ -54,6 +54,13 @@
 			status = "okay";
 			nr-ports = <1>;
 		};
+
+
+		mvsdio at 90000 {
+			status = "okay";
+			/* No CD or WP GPIOs */
+		};
+
 	};
 
 	gpio-leds {
arch/arm/mach-kirkwood/board-usi_topkick.c +0 -5
index 15e69fc..89316da 100644
@@ -22,10 +22,6 @@ static struct mv643xx_eth_platform_data topkick_ge00_data = {
 	.phy_addr	= MV643XX_ETH_PHY_ADDR(0),
 };
 
-static struct mvsdio_platform_data topkick_mvsdio_data = {
-	/* unfortunately the CD signal has not been connected */
-};
-
 /*
  * GPIO LED layout
  *
@@ -77,5 +73,4 @@ void __init usi_topkick_init(void)
 	gpio_set_value(TOPKICK_SATA0_PWR_ENABLE, 1);
 
 	kirkwood_ge00_init(&topkick_ge00_data);
-	kirkwood_sdio_init(&topkick_mvsdio_data);
 }
Signature · 1 line
1.7.9.5
#17 lore raw

PATCH 15/18 arm: kirkwood: dockstar: remove useless include of SDIO header

In reply to Thomas Petazzoni

The dockstar platform does not register any SDIO controller, therefore it does not need to include the mmc-mvsdio.h header.

---
 arch/arm/mach-kirkwood/dockstar-setup.c |    1 -
 1 file changed, 1 deletion(-)
arch/arm/mach-kirkwood/dockstar-setup.c +0 -1
index 791a98f..272af69 100644
@@ -19,7 +19,6 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <mach/kirkwood.h>
-#include <linux/platform_data/mmc-mvsdio.h>
 #include "common.h"
 #include "mpp.h"
 
Signature · 1 line
1.7.9.5
#18 lore raw

PATCH 16/18 arm: mvebu: enable SDIO support in mvebu_defconfig

In reply to Thomas Petazzoni

Now that the mvsdio driver has gained Device Tree support and the necessary Device Tree informations has been added for Armada 370 and Armada XP platforms, we enable the MMC subsystem and the mvsdio driver in mvebu_defconfig.

---
 arch/arm/configs/mvebu_defconfig |    2 ++
 1 file changed, 2 insertions(+)
arch/arm/configs/mvebu_defconfig +2 -0
index a702fb3..14cb45c 100644
@@ -39,6 +39,8 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
 # CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+CONFIG_MMC_MVSDIO=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_S35390A=y
 CONFIG_DMADEVICES=y
Signature · 1 line
1.7.9.5
#19 lore raw

PATCH 17/18 arm: mvebu: enable mwifiex driver in mvebu_defconfig

In reply to Thomas Petazzoni

The Globalscale Mirabox platform, based on the Armada 370 from Marvell, has a SD8787 Wireless chip connected on the SDIO interface. Now that the mvsdio has a Device Tree binding, and the necessary Device Tree informations have been added at the SoC and board level, let's enable the mwifiex driver for the Wireless part of the SD8787 chip.

For now, the driver gets probed correctly, detects a device and shows the network interfaces. However, scanning Wifi networks doesn't work for now, with a 'CMD_RESP: cmd 0x6 error, result=0x1' message. This will have to be investigated separately.

---
 arch/arm/configs/mvebu_defconfig |    3 +++
 1 file changed, 3 insertions(+)
arch/arm/configs/mvebu_defconfig +3 -0
index 14cb45c..19f0c3d 100644
@@ -24,6 +24,7 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_VFP=y
 CONFIG_NET=y
 CONFIG_INET=y
+CONFIG_CFG80211=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
@@ -31,6 +32,8 @@ CONFIG_SATA_MV=y
 CONFIG_NETDEVICES=y
 CONFIG_MVNETA=y
 CONFIG_MARVELL_PHY=y
+CONFIG_MWIFIEX=y
+CONFIG_MWIFIEX_SDIO=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
Signature · 1 line
1.7.9.5
#20 lore raw

PATCH 17/18 arm: mvebu: enable mwifiex driver in mvebu_defconfig

Quoted 11 lines · Thomas Petazzoni

The Globalscale Mirabox platform, based on the Armada 370 from Marvell, has a SD8787 Wireless chip connected on the SDIO interface. Now that the mvsdio has a Device Tree binding, and the necessary Device Tree informations have been added at the SoC and board level, let's enable the mwifiex driver for the Wireless part of the SD8787 chip.

For now, the driver gets probed correctly, detects a device and shows the network interfaces. However, scanning Wifi networks doesn't work for now, with a 'CMD_RESP: cmd 0x6 error, result=0x1' message. This will have to be investigated separately.

Hi Thomas

Sounds similar to what i see on topkick with the mwifiex driver.

Andrew

#21 lore raw

PATCH 18/18 arm: mvebu: enable btmrvl driver in mvebu_defconfig

In reply to Thomas Petazzoni

The Globalscale Mirabox platform, based on the Armada 370 from Marvell, has a SD8787 Wireless/Bluetooth chip connected on the SDIO interface. Now that the mvsdio has a Device Tree binding, and the necessary Device Tree informations have been added at the SoC and board level, let's enable the btmrvl driver for the Bluetooth part of the SD8787 chip.

For now, the driver gets probed correctly, detects the device but apparently fails to push the firmware to the device:

Bluetooth: vendor=0x2df, device=0x911a, class=255, fn=2
Bluetooth: FW failed to be active in time!
Bluetooth: Downloading firmware failed!
Bluetooth: vendor=0x2df, device=0x911b, class=255, fn=3
Bluetooth: FW failed to be active in time!
Bluetooth: Downloading firmware failed!

This will have to be investigated separately.

---
 arch/arm/configs/mvebu_defconfig |    3 +++
 1 file changed, 3 insertions(+)
arch/arm/configs/mvebu_defconfig +3 -0
index 19f0c3d..f849ac3 100644
@@ -24,6 +24,9 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_VFP=y
 CONFIG_NET=y
 CONFIG_INET=y
+CONFIG_BT=y
+CONFIG_BT_MRVL=y
+CONFIG_BT_MRVL_SDIO=y
 CONFIG_CFG80211=y
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_BLK_DEV_SD=y
Signature · 1 line
1.7.9.5