[PATCH 0/4] omap hsmmc device tree support

[PATCH 0/4] omap hsmmc device tree support

[Rajendra Nayak]

This series adds device tree support for omap hsmmc
driver. The series is currently based on my patch
series[1] to add dt support for twl-regulators, since
hsmmc requires regulators to work.
I have also pulled the patch from Thomas Abraham which
adds mmc host controller bindings[2]
'mmc: Add OF bindings support for mmc host controller capabilities'

The series currently adds supports for only omap4-panda and
omap4-sdp boards and uses auxdata to pass platform specific
function pointers to the driver.

All the dependent patches along with this series can be found here
git://gitorious.org/omap-pm/linux.git for-dt/regulator-i2c-twl-mmc

regards,
Rajendra

[1] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-October/009185.html
[2] http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-November/009237.html

Rajendra Nayak (4):
  mmc: Add additional binding for mmc host controller
  mmc: omap: adapt the hsmmc driver to device tree
  omap4: mmc: Pass SoC and board data for omap4 mmc from dt
  omap4: mmc: use auxdata to pass platform function ptrs

 .../devicetree/bindings/mmc/linux-mmc-host.txt     |    1 +
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   50 ++++++++
 arch/arm/boot/dts/omap4-panda.dts                  |   23 ++++
 arch/arm/boot/dts/omap4-sdp.dts                    |   33 +++++
 arch/arm/boot/dts/omap4.dtsi                       |   46 +++++++
 arch/arm/mach-omap2/board-generic.c                |   19 +++-
 arch/arm/mach-omap2/hsmmc.c                        |    9 +-
 arch/arm/mach-omap2/hsmmc.h                        |    5 +
 drivers/mmc/core/host.c                            |    2 +
 drivers/mmc/host/omap_hsmmc.c                      |  125 ++++++++++++++++++++
 10 files changed, 307 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

[PATCH 1/4] mmc: Add additional binding for mmc host controller

[Rajendra Nayak]

Add mmc host controller capability binding to support
'MMC_CAP_POWER_OFF_CARD' powering off of the card after boot.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 .../devicetree/bindings/mmc/linux-mmc-host.txt     |    1 +
 drivers/mmc/core/host.c                            |    2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
index 714b2b1..cf893ed 100644
--- a/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
+++ b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
@@ -11,3 +11,4 @@ specific mmc host controller capabilities.
 - linux,mmc_cap_disable - Host can be disabled and re-enabled to save power
 - linux,mmc_cap_nonremovable - Host is connected to nonremovable media
 - linux,mmc_cap_erase - Host allows erase/trim commands
+- linux,mmc_cap_power_off_card - Host can power off the card after boot
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 4ee2e43..822337a 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -413,6 +413,8 @@ void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps)
 		*caps |= MMC_CAP_NONREMOVABLE;
 	if (of_find_property(np, "linux,mmc_cap_erase", NULL))
 		*caps |= MMC_CAP_ERASE;
+	if (of_find_property(np, "linux,mmc_cap_power_off_card", NULL))
+		*caps |= MMC_CAP_POWER_OFF_CARD;
 }
 EXPORT_SYMBOL(mmc_of_parse_host_caps);
 #endif /* CONFIG_OF */
-- 
1.7.1

[PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Rajendra Nayak]

Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree node.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   50 +++++++++
 drivers/mmc/host/omap_hsmmc.c                      |  117 ++++++++++++++++++++
 2 files changed, 167 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 0000000..370af1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,50 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
+n is controller instance starting 0, for OMAP2/3 controllers
+- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
+n is controller instance starting 0, for OMAP4 controllers
+- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards
+ti,hsmmc-nr-slots: Number of mmc slots
+<supply-name>-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,hsmmc-has-pbias: Has PBIAS cell support
+ti,hsmmc-has-special-reset: Requires a special softreset sequence
+
+For every supported slot a slot node can be defined
+with the following optional properties
+
+ti,hsmmc-slot-name: Name assocaited to the mmc slot
+ti,hsmmc-gpio-cd: gpio for card detect
+ti,hsmmc-gpio-wp: gpio for write protect
+ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask
+ti,hsmmc-non-removable: non-removable slot (like eMMC)
+
+One or more of the linux specific mmc host bindings can also be used.
+See Documentation/devicetree/bindings/mmc/linux-mmc-host.txt for all the
+linux mmc host controller specific bindings.
+
+Example:
+	mmc1: mmc@0x4809c000 {
+		compatible = "ti,omap-hsmmc0", "ti,omap4-hsmmc";
+		reg = <0x4809c000 0x400>;
+		ti,hwmods = "mmc1";
+		ti,hsmmc-supports-dual-volt;
+		ti,hsmmc-nr-slots = <1>;
+		vmmc-supply = <&vmmc>; /* phandle to regulator node */
+		slot@1 {
+			ti,hsmmc-slot-name = "wlan";
+			linux,mmc_cap_4_bit_data;
+			linux,mmc_cap_power_off_card;
+			ti,hsmmc-ocr-mask = <0x80>;
+			ti,hsmmc-nonremovable;
+		};
+	};
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..90b4a61 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -27,6 +27,9 @@
 #include <linux/workqueue.h>
 #include <linux/timer.h>
 #include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/of_device.h>
 #include <linux/mmc/host.h>
 #include <linux/mmc/core.h>
 #include <linux/mmc/mmc.h>
@@ -117,6 +120,7 @@
 #define OMAP_MMC3_DEVID		2
 #define OMAP_MMC4_DEVID		3
 #define OMAP_MMC5_DEVID		4
+#define OMAP_MMC_DEV_MAX	5
 
 #define MMC_AUTOSUSPEND_DELAY	100
 #define MMC_TIMEOUT_MS		20
@@ -1862,6 +1866,90 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
 
 #endif
 
+#ifdef CONFIG_OF
+static unsigned int of_get_hsmmc_instance(struct device_node *np)
+{
+	int i;
+	char comp[32];
+
+	for (; i < OMAP_MMC_DEV_MAX; i++) {
+		snprintf(comp, 32, "ti,omap-hsmmc%d", i);
+		if (of_device_is_compatible(np, comp))
+			break;
+	}
+	return i;
+}
+
+static void of_get_hsmmc_slot_data(struct device_node *np,
+			struct omap_mmc_platform_data **pdata)
+{
+	struct device_node *child;
+	int i = 0;
+	unsigned long *caps;
+
+	for_each_child_of_node(np, child) {
+		(*pdata)->slots[i].switch_pin =
+			of_get_named_gpio(child, "ti,hsmmc-gpio-cd", 0);
+		(*pdata)->slots[i].gpio_wp =
+			of_get_named_gpio(child, "ti,hsmmc-gpio-wp", 0);
+		(*pdata)->slots[i].name = of_get_property(child,
+					"ti,hsmmc-slot-name", NULL);
+		if (of_find_property(child, "ti,hsmmc-nonremovable", NULL))
+			(*pdata)->slots[i].nonremovable = true;
+		if (of_find_property(child, "ti,hsmmc-has-pbias", NULL))
+			(*pdata)->slots[i].features |= HSMMC_HAS_PBIAS;
+		if (of_find_property(child, "ti,hsmmc-has-special-reset", NULL))
+			(*pdata)->slots[i].features |= HSMMC_HAS_UPDATED_RESET;
+		of_property_read_u32(child, "ti,hsmmc-ocr-mask",
+					&(*pdata)->slots[i].ocr_mask);
+		caps = (unsigned long *)&(*pdata)->slots[i].caps;
+		mmc_of_parse_host_caps(child, caps);
+		i++;
+	}
+}
+
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
+{
+	struct omap_mmc_platform_data *pdata;
+	const __be32 *nr_slots;
+	const __be64 *dma_mask;
+	struct device_node *np = dev->of_node;
+
+	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return NULL; /* out of memory */
+
+	nr_slots = of_get_property(np, "ti,hsmmc-nr-slots", NULL);
+	if (nr_slots) {
+		pdata->nr_slots = be32_to_cpu(*nr_slots);
+		of_get_hsmmc_slot_data(np, &pdata);
+	}
+
+	dma_mask = of_get_property(np, "ti,hsmmc-dma-mask", NULL);
+	if (dma_mask)
+		pdata->dma_mask = be64_to_cpu(*dma_mask);
+	if (of_find_property(np, "ti,hsmmc-supports-dual-volt", NULL))
+		pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+	return pdata;
+}
+#else
+static inline void of_get_hsmmc_slot_data(struct device_node *np,
+			struct omap_mmc_platform_data **pdata)
+{}
+static inline struct omap_mmc_platform_data
+			*of_get_hsmmc_pdata(struct device *dev)
+{
+	return NULL;
+}
+static inline unsigned int of_get_hsmmc_instance(struct device_node *np)
+{
+	return -1;
+}
+#endif
+
+static const struct of_device_id omap_mmc_of_match[];
+
 static int __init omap_hsmmc_probe(struct platform_device *pdev)
 {
 	struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
 	struct omap_hsmmc_host *host = NULL;
 	struct resource *res;
 	int ret, irq;
+	const struct of_device_id *match;
+
+	match = of_match_device(omap_mmc_of_match, &pdev->dev);
+	if (match) {
+		pdata = of_get_hsmmc_pdata(&pdev->dev);
+		if (match->data)
+			pdata->reg_offset = *(u16 *)match->data;
+	}
 
 	if (pdata == NULL) {
 		dev_err(&pdev->dev, "Platform Data is missing\n");
@@ -1910,6 +2006,8 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
 	host->dma_ch	= -1;
 	host->irq	= irq;
 	host->id	= pdev->id;
+	if (pdev->dev.of_node)
+		host->id = of_get_hsmmc_instance(pdev->dev.of_node);
 	host->slot_id	= 0;
 	host->mapbase	= res->start;
 	host->base	= ioremap(host->mapbase, SZ_4K);
@@ -2269,12 +2367,31 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
 	.runtime_resume = omap_hsmmc_runtime_resume,
 };
 
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+	{
+		.compatible = "ti,omap2-hsmmc",
+	},
+	{
+		.compatible = "ti,omap4-hsmmc",
+		.data = &omap4_reg_offset,
+	},
+	{},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+#else
+#define omap_mmc_of_match NULL
+#endif
+
 static struct platform_driver omap_hsmmc_driver = {
 	.remove		= omap_hsmmc_remove,
 	.driver		= {
 		.name = DRIVER_NAME,
 		.owner = THIS_MODULE,
 		.pm = &omap_hsmmc_dev_pm_ops,
+		.of_match_table = omap_mmc_of_match,
 	},
 };
 
-- 
1.7.1

[PATCH 3/4] omap4: mmc: Pass SoC and board data for omap4 mmc from dt

[Rajendra Nayak]

Pass all omap4-hsmmc related data from device tree.
Currenly limited to only omap4-panda and omap4-sdp
boards.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/boot/dts/omap4-panda.dts |   23 ++++++++++++++++++
 arch/arm/boot/dts/omap4-sdp.dts   |   33 ++++++++++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi      |   46 +++++++++++++++++++++++++++++++++++++
 3 files changed, 102 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4c3069f..07c5433 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -105,3 +105,26 @@
 &i2c4 {
 	clock-frequency = <400000>;
 };
+
+&mmc1 {
+	ti,hsmmc-nr-slots = <1>;
+	vmmc-supply = <&vmmc>;
+	slot@1 {
+		linux,mmc_cap_4_bit_data;
+		linux,mmc_cap_8_bit_data;
+		ti,hsmmc-has-special-reset;
+	};
+};
+
+&mmc5 {
+	ti,hsmmc-nr-slots = <1>;
+	vmmc-supply = <&vwl1271>;
+	slot@1 {
+		ti,hsmmc-slot-name = "wl1271";
+		linux,mmc_cap_4_bit_data;
+		linux,mmc_cap_power_off_card;
+		ti,hsmmc-ocr-mask = <0x80>;
+		ti,hsmmc-nonremovable;
+		ti,hsmmc-has-special-reset;
+	};
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index adc7faf..d37d416 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -125,3 +125,36 @@
 		reg = <0x1e>;
 	};
 };
+
+&mmc1 {
+	ti,hsmmc-nr-slots = <1>;
+	vmmc-supply = <&vmmc>;
+	slots@1 {
+		linux,mmc_cap_4_bit_data;
+		linux,mmc_cap_8_bit_data;
+		ti,hsmmc-has-special-reset;
+	};
+};
+
+&mmc2 {
+	ti,hsmmc-nr-slots = <1>;
+	vmmc-supply = <&vaux1>;
+	slots@1 {
+		linux,mmc_cap_4_bit_data;
+		linux,mmc_cap_8_bit_data;
+		ti,hsmmc-nonremovable;
+		ti,hsmmc-ocr-mask = <0x20000>;
+		ti,hsmmc-has-special-reset;
+	};
+};
+
+&mmc5 {
+	ti,hsmmc-nr-slots = <1>;
+	slots@1 {
+		linux,mmc_cap_4_bit_data;
+		linux,mmc_cap_power_off_card;
+		ti,hsmmc-nonremovable;
+		ti,hsmmc-ocr-mask = <0x80>;
+		ti,hsmmc-has-special-reset;
+	};
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 447f482..f4e0540 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
 		i2c2 = &i2c2;
 		i2c3 = &i2c3;
 		i2c4 = &i2c4;
+		mmc1 = &mmc1;
+		mmc2 = &mmc2;
+		mmc3 = &mmc3;
+		mmc4 = &mmc4;
+		mmc5 = &mmc5;
 	};
 
 	cpus {
@@ -205,5 +210,46 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c4";
 		};
+
+		mmc1: mmc@0x4809c000 {
+			compatible = "ti,omap-hsmmc0", "ti,omap4-hsmmc";
+			reg = <0x4809c000 0x400>;
+			ti,hwmods = "mmc1";
+			ti,hsmmc-supports-dual-volt;
+			ti,hsmmc-dma-mask = <0xffffffff>;
+			ti,hsmmc-has-pbias;
+		};
+
+		mmc2: mmc@0x480b4000 {
+			compatible = "ti,omap-hsmmc1", "ti,omap4-hsmmc";
+			reg = <0x480b4000 0x400>;
+			ti,hwmods = "mmc2";
+			ti,hsmmc-dma-mask = <0xffffffff>;
+			ti,hsmmc-has-pbias;
+		};
+
+		mmc3: mmc@0x480ad000 {
+			compatible = "ti,omap-hsmmc2", "ti,omap4-hsmmc";
+			reg = <0x480ad000 0x400>;
+			ti,hwmods = "mmc3";
+			ti,hsmmc-dma-mask = <0xffffffff>;
+			ti,hsmmc-has-pbias;
+		};
+
+		mmc4: mmc@0x480d1000 {
+			compatible = "ti,omap-hsmmc3", "ti,omap4-hsmmc";
+			reg = <0x480d1000 0x400>;
+			ti,hwmods = "mmc4";
+			ti,hsmmc-dma-mask = <0xffffffff>;
+			ti,hsmmc-has-pbias;
+		};
+
+		mmc5: mmc@0x480d5000 {
+			compatible = "ti,omap-hsmmc4", "ti,omap4-hsmmc";
+			reg = <0x480d5000 0x400>;
+			ti,hwmods = "mmc5";
+			ti,hsmmc-dma-mask = <0xffffffff>;
+			ti,hsmmc-has-pbias;
+		};
 	};
 };
-- 
1.7.1

[PATCH 4/4] omap4: mmc: use auxdata to pass platform function ptrs

[Rajendra Nayak]

mmc driver still relies on platform specific functions
being invoked from the driver by means of function pointers
being passed through platform_data structure.
use the auxdata for now to pass these the same way until
we find a way to get rid of these calls from the driver.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/board-generic.c |   19 +++++++++++++++++--
 arch/arm/mach-omap2/hsmmc.c         |    9 +++++----
 arch/arm/mach-omap2/hsmmc.h         |    5 +++++
 drivers/mmc/host/omap_hsmmc.c       |    8 ++++++++
 4 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 62c6b2e..af2fdd9 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,14 +15,29 @@
 #include <linux/io.h>
 #include <linux/of_platform.h>
 #include <linux/irqdomain.h>
+#include <linux/i2c/twl.h>
 
 #include <mach/hardware.h>
 #include <asm/mach/arch.h>
 
 #include <plat/board.h>
 #include <plat/common.h>
+#include <plat/mmc.h>
 #include <mach/omap4-common.h>
+#include "hsmmc.h"
+
+struct omap_mmc_platform_data omap4_mmc1_pdata = {
+	.init = twl6030_mmc_card_detect_config,
+	.slots[0] = {
+		.before_set_reg = omap4_hsmmc1_before_set_reg,
+		.after_set_reg = omap4_hsmmc1_after_set_reg,
+	},
+};
 
+struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("ti,omap-hsmmc0", 0x4809c000, "omap_hsmmc.0", &omap4_mmc1_pdata),
+	{}
+};
 
 static struct of_device_id omap_dt_match_table[] __initdata = {
 	{ .compatible = "simple-bus", },
@@ -44,8 +59,8 @@ static void __init omap_generic_init(void)
 
 	omap_serial_init();
 	omap_sdrc_init(NULL, NULL);
-
-	of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+	omap2_hsmmc_init(NULL);
+	of_platform_populate(NULL, omap_dt_match_table, omap_auxdata_lookup, NULL);
 }
 
 #if defined(CONFIG_SOC_OMAP2420)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 7708584..dc698be 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -120,7 +120,7 @@ static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
 	}
 }
 
-static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
+void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
 				  int power_on, int vdd)
 {
 	u32 reg;
@@ -141,7 +141,7 @@ static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
 	omap4_ctrl_pad_writel(reg, control_pbias_offset);
 }
 
-static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
+void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
 				 int power_on, int vdd)
 {
 	u32 reg;
@@ -495,8 +495,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
 		omap4_ctrl_pad_writel(reg, control_mmc1);
 	}
 
-	for (; controllers->mmc; controllers++)
-		omap_init_hsmmc(controllers, controllers->mmc);
+	if (controllers)
+		for (; controllers->mmc; controllers++)
+			omap_init_hsmmc(controllers, controllers->mmc);
 
 }
 
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index f757e78..543ab4d 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -34,6 +34,11 @@ struct omap2_hsmmc_info {
 #if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
 
 void omap2_hsmmc_init(struct omap2_hsmmc_info *);
+extern void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
+				int power_on, int vdd);
+extern void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
+				int power_on, int vdd);
+
 
 #else
 
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 90b4a61..5fb5a95 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1953,6 +1953,7 @@ static const struct of_device_id omap_mmc_of_match[];
 static int __init omap_hsmmc_probe(struct platform_device *pdev)
 {
 	struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
+	struct omap_mmc_platform_data *aux_pdata = pdev->dev.platform_data;
 	struct mmc_host *mmc;
 	struct omap_hsmmc_host *host = NULL;
 	struct resource *res;
@@ -1964,6 +1965,13 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
 		pdata = of_get_hsmmc_pdata(&pdev->dev);
 		if (match->data)
 			pdata->reg_offset = *(u16 *)match->data;
+		if (aux_pdata) {
+			pdata->init = aux_pdata->init;
+			pdata->slots[0].before_set_reg =
+				 aux_pdata->slots[0].before_set_reg;
+			pdata->slots[0].after_set_reg =
+				 aux_pdata->slots[0].after_set_reg;
+		}
 	}
 
 	if (pdata == NULL) {
-- 
1.7.1

Re: [PATCH 1/4] mmc: Add additional binding for mmc host controller

[Olof Johansson]

On Fri, Nov 04, 2011 at 05:20:38PM +0530, Rajendra Nayak wrote:
> Add mmc host controller capability binding to support
> 'MMC_CAP_POWER_OFF_CARD' powering off of the card after boot.

This adds a new undocumented property (also, see comments on Thomas Abraham's
patch for more comments on that approach and why it's the wrong thing to do).

This needs to be handled differently.


-Olof

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Olof Johansson]

On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
> Define dt bindings for the ti-omap-hsmmc, and adapt
> the driver to extract data (which was earlier passed as
> platform_data) from device tree node.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   50 +++++++++
>  drivers/mmc/host/omap_hsmmc.c                      |  117 ++++++++++++++++++++
>  2 files changed, 167 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> 
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> new file mode 100644
> index 0000000..370af1b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -0,0 +1,50 @@
> +* TI Highspeed MMC host controller for OMAP
> +
> +The Highspeed MMC Host Controller on TI OMAP family
> +provides an interface for MMC, SD, and SDIO types of memory cards.
> +
> +Required properties:
> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
> +n is controller instance starting 0, for OMAP2/3 controllers

No, no, no. You should not have to specify the unit-address in the compatible
field. They are all programmed the same way, right?

Also, they should go from the specific to the generic, but the first property
is the same for 2/3 and 4. That's wrong.

> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
> +n is controller instance starting 0, for OMAP4 controllers
> +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1

I didn't think hwmod bindings were settled on yet?

> +- reg : should contain hsmmc registers location and length
> +
> +Optional properties:
> +ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards

ti,dual-voltage is a better name here (by definition, if it has the property it
supports it, the word "supports" is redundant).

> +ti,hsmmc-nr-slots: Number of mmc slots

You shouldn't have to specify this, it can be derived from the number of child
nodes.

> +<supply-name>-supply: phandle to the regulator device tree node
> +"supply-name" examples are "vmmc", "vmmc_aux" etc
> +ti,hsmmc-has-pbias: Has PBIAS cell support
> +ti,hsmmc-has-special-reset: Requires a special softreset sequence

you can drop hsmmc- from the properties here

> +
> +For every supported slot a slot node can be defined
> +with the following optional properties
> +
> +ti,hsmmc-slot-name: Name assocaited to the mmc slot
> +ti,hsmmc-gpio-cd: gpio for card detect
> +ti,hsmmc-gpio-wp: gpio for write protect

Please use the same standard as the other mmc controllers for CD/WP.

> +ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask

What is OCR mask?

> +ti,hsmmc-non-removable: non-removable slot (like eMMC)

Same here, non-removable should be standardized.


-Olof

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Cousson, Benoit]

Hi Olof,

On 11/4/2011 9:04 PM, Olof Johansson wrote:
> On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
>> Define dt bindings for the ti-omap-hsmmc, and adapt
>> the driver to extract data (which was earlier passed as
>> platform_data) from device tree node.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>>   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   50 +++++++++
>>   drivers/mmc/host/omap_hsmmc.c                      |  117 ++++++++++++++++++++
>>   2 files changed, 167 insertions(+), 0 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> new file mode 100644
>> index 0000000..370af1b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -0,0 +1,50 @@
>> +* TI Highspeed MMC host controller for OMAP
>> +
>> +The Highspeed MMC Host Controller on TI OMAP family
>> +provides an interface for MMC, SD, and SDIO types of memory cards.
>> +
>> +Required properties:
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>> +n is controller instance starting 0, for OMAP2/3 controllers
>
> No, no, no. You should not have to specify the unit-address in the compatible
> field. They are all programmed the same way, right?

AFAIR, 2 instances contain a DMA engine, but that should anyway be 
detected using a "ti,had-dma-engine" extra property and not like that.

Checking the code in #2, it is used to get the instance of the MMC.

+static unsigned int of_get_hsmmc_instance(struct device_node *np)
+{
+	int i;
+	char comp[32];
+
+	for (; i < OMAP_MMC_DEV_MAX; i++) {
+		snprintf(comp, 32, "ti,omap-hsmmc%d", i);
+		if (of_device_is_compatible(np, comp))
+			break;
+	}
+	return i;
+}

Which does not seems to be a good usage of the compatible property anyway.
For a similar issue someone on the list suggested using the "cell-index" 
property. But the definition I found in some binding documentation seems 
to reserve that to: "enumerate logical devices within an IP core."
Ideally the driver should probably get rid of the need for an index.
I didn't check the original driver, but that should be needed for some 
legacy reason.

> Also, they should go from the specific to the generic, but the first property
> is the same for 2/3 and 4. That's wrong.
>
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
>> +n is controller instance starting 0, for OMAP4 controllers
>> +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
>
> I didn't think hwmod bindings were settled on yet?

Why did you think that?

That binding was pretty straightforward and mandatory for starting any 
OMAP device tree migration until we have the proper reg-names, irq-names 
and dma-names generic binding.

Did you had any concern with that binding?

Regards,
Benoit

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Olof Johansson]

On Fri, Nov 4, 2011 at 2:25 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Hi Olof,
>
> On 11/4/2011 9:04 PM, Olof Johansson wrote:
>>
>> On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
>>>
>>> Define dt bindings for the ti-omap-hsmmc, and adapt
>>> the driver to extract data (which was earlier passed as
>>> platform_data) from device tree node.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> ---
>>>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   50 +++++++++
>>>  drivers/mmc/host/omap_hsmmc.c                      |  117
>>> ++++++++++++++++++++
>>>  2 files changed, 167 insertions(+), 0 deletions(-)
>>>  create mode 100644
>>> Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> new file mode 100644
>>> index 0000000..370af1b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> @@ -0,0 +1,50 @@
>>> +* TI Highspeed MMC host controller for OMAP
>>> +
>>> +The Highspeed MMC Host Controller on TI OMAP family
>>> +provides an interface for MMC, SD, and SDIO types of memory cards.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>>> +n is controller instance starting 0, for OMAP2/3 controllers
>>
>> No, no, no. You should not have to specify the unit-address in the
>> compatible
>> field. They are all programmed the same way, right?
>
> AFAIR, 2 instances contain a DMA engine, but that should anyway be detected
> using a "ti,had-dma-engine" extra property and not like that.

Yep, it should be described by properties instead, such that future
products won't need new bindings unless they add new hardware features
(i.e. just new combinations of existing features should just work,
more or less).

>> I didn't think hwmod bindings were settled on yet?
>
> Why did you think that?
>
> That binding was pretty straightforward and mandatory for starting any OMAP
> device tree migration until we have the proper reg-names, irq-names and
> dma-names generic binding.
>
> Did you had any concern with that binding?

Nope, just wasn't sure if it had settled down since I hadn't followed
it closely. No concerns.


-Olof

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Segher Boessenkool]

>> +ti,hsmmc-non-removable: non-removable slot (like eMMC)
>
> Same here, non-removable should be standardized.

CHRP has a "built-in" property for this.  That was standardised in 1998,
you could reuse it :-)


Segher

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Rajendra Nayak]

On Saturday 05 November 2011 02:55 AM, Cousson, Benoit wrote:
>>> +Required properties:
>>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>>> +n is controller instance starting 0, for OMAP2/3 controllers
>>
>> No, no, no. You should not have to specify the unit-address in the
>> compatible
>> field. They are all programmed the same way, right?
>
> AFAIR, 2 instances contain a DMA engine, but that should anyway be
> detected using a "ti,had-dma-engine" extra property and not like that.
>
> Checking the code in #2, it is used to get the instance of the MMC.
>
> +static unsigned int of_get_hsmmc_instance(struct device_node *np)
> +{
> +    int i;
> +    char comp[32];
> +
> +    for (; i < OMAP_MMC_DEV_MAX; i++) {
> +        snprintf(comp, 32, "ti,omap-hsmmc%d", i);
> +        if (of_device_is_compatible(np, comp))
> +            break;
> +    }
> +    return i;
> +}
>
> Which does not seems to be a good usage of the compatible property anyway.
> For a similar issue someone on the list suggested using the "cell-index"
> property. But the definition I found in some binding documentation seems
> to reserve that to: "enumerate logical devices within an IP core."
> Ideally the driver should probably get rid of the need for an index.
> I didn't check the original driver, but that should be needed for some
> legacy reason.

yes, there are a bunch of things done inside the driver based on the
instance id which seem wrong, but I agree, encoding the instance
in the compatible property seems really bad and non-scalable.
Will look at how some of this legacy code in the driver can be
removed/cleaned up.

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Rajendra Nayak]

On Saturday 05 November 2011 01:34 AM, Olof Johansson wrote:
> On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
>> Define dt bindings for the ti-omap-hsmmc, and adapt
>> the driver to extract data (which was earlier passed as
>> platform_data) from device tree node.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>>   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   50 +++++++++
>>   drivers/mmc/host/omap_hsmmc.c                      |  117 ++++++++++++++++++++
>>   2 files changed, 167 insertions(+), 0 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> new file mode 100644
>> index 0000000..370af1b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -0,0 +1,50 @@
>> +* TI Highspeed MMC host controller for OMAP
>> +
>> +The Highspeed MMC Host Controller on TI OMAP family
>> +provides an interface for MMC, SD, and SDIO types of memory cards.
>> +
>> +Required properties:
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>> +n is controller instance starting 0, for OMAP2/3 controllers
>
> No, no, no. You should not have to specify the unit-address in the compatible
> field. They are all programmed the same way, right?
>
> Also, they should go from the specific to the generic, but the first property
> is the same for 2/3 and 4. That's wrong.

agreed, will get rid of instance number from the compatible property.
>
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
>> +n is controller instance starting 0, for OMAP4 controllers
>> +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
>
> I didn't think hwmod bindings were settled on yet?
>
>> +- reg : should contain hsmmc registers location and length
>> +
>> +Optional properties:
>> +ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards
>
> ti,dual-voltage is a better name here (by definition, if it has the property it
> supports it, the word "supports" is redundant).

Ok.
>
>> +ti,hsmmc-nr-slots: Number of mmc slots
>
> You shouldn't have to specify this, it can be derived from the number of child
> nodes.

right, will do that.

>
>> +<supply-name>-supply: phandle to the regulator device tree node
>> +"supply-name" examples are "vmmc", "vmmc_aux" etc
>> +ti,hsmmc-has-pbias: Has PBIAS cell support
>> +ti,hsmmc-has-special-reset: Requires a special softreset sequence
>
> you can drop hsmmc- from the properties here

Ok.
>
>> +
>> +For every supported slot a slot node can be defined
>> +with the following optional properties
>> +
>> +ti,hsmmc-slot-name: Name assocaited to the mmc slot
>> +ti,hsmmc-gpio-cd: gpio for card detect
>> +ti,hsmmc-gpio-wp: gpio for write protect
>
> Please use the same standard as the other mmc controllers for CD/WP.

Ok.
>
>> +ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask
>
> What is OCR mask?

Its used to derive the vdd range the card supports. I hadn't
looked at this closely, but looks like this isn't something that
needs to be told to the driver anyway, it can always just query the
card about the voltages it supports and derive the ocrmask internally.
One more of the hacks in the driver to be cleaned up. Will drop this
property completely.

>
>> +ti,hsmmc-non-removable: non-removable slot (like eMMC)
>
> Same here, non-removable should be standardized.

You mean there is already a binding available for this?

Thanks for the review.

regards,
Rajendra

>
>
> -Olof

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Tony Lindgren]

* Rajendra Nayak <rnayak@ti.com> [111104 04:16]:
> @@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
>  	struct omap_hsmmc_host *host = NULL;
>  	struct resource *res;
>  	int ret, irq;
> +	const struct of_device_id *match;
> +
> +	match = of_match_device(omap_mmc_of_match, &pdev->dev);
> +	if (match) {
> +		pdata = of_get_hsmmc_pdata(&pdev->dev);
> +		if (match->data)
> +			pdata->reg_offset = *(u16 *)match->data;
> +	}

So this is now using both DT and pdata?

We want to use DT only, and get rid of pdata. Other than the
deferred probe, is there some other dependency remaining to
having to use the pdata also?

Regards,

Tony

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Rajendra Nayak]

On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
> * Rajendra Nayak<rnayak@ti.com>  [111104 04:16]:
>> @@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
>>   	struct omap_hsmmc_host *host = NULL;
>>   	struct resource *res;
>>   	int ret, irq;
>> +	const struct of_device_id *match;
>> +
>> +	match = of_match_device(omap_mmc_of_match,&pdev->dev);
>> +	if (match) {
>> +		pdata = of_get_hsmmc_pdata(&pdev->dev);
>> +		if (match->data)
>> +			pdata->reg_offset = *(u16 *)match->data;
>> +	}
>
> So this is now using both DT and pdata?
>
> We want to use DT only, and get rid of pdata. Other than the
> deferred probe, is there some other dependency remaining to
> having to use the pdata also?

We are using pdata today mainly for the platform function pointers
that get passed for MMC, which can never be passed from DT.

The  omap_mmc_platform_data structure today has '17' function pointers.
Most might be sparingly used, nevertheless, its an awfully large number.

Here's the list...
---------
int (*switch_slot)(struct device *dev, int slot);
int (*init)(struct device *dev);
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, int slot);
int (*resume)(struct device *dev, int slot);
int (*get_context_loss_count)(struct device *dev);

per-slot functions

int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
                                  int power_on, int vdd);
int (*get_ro)(struct device *dev, int slot);
int (*set_sleep)(struct device *dev, int slot, int sleep,
                                  int vdd, int cardsleep);
void (*remux)(struct device *dev, int slot, int power_on);
void (*before_set_reg)(struct device *dev, int slot,
                                        int power_on, int vdd);
void (*after_set_reg)(struct device *dev, int slot,
                                       int power_on, int vdd);
void (*init_card)(struct mmc_card *card);
int (*get_cover_state)(struct device *dev, int slot);
int (*card_detect)(struct device *dev, int slot);
---------

regards,
Rajendra

> Regards,
>
> Tony
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree

[Tony Lindgren]

* Rajendra Nayak <rnayak@ti.com> [111114 19:40]:
> On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
> >* Rajendra Nayak<rnayak@ti.com>  [111104 04:16]:
> >>@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
> >>  	struct omap_hsmmc_host *host = NULL;
> >>  	struct resource *res;
> >>  	int ret, irq;
> >>+	const struct of_device_id *match;
> >>+
> >>+	match = of_match_device(omap_mmc_of_match,&pdev->dev);
> >>+	if (match) {
> >>+		pdata = of_get_hsmmc_pdata(&pdev->dev);
> >>+		if (match->data)
> >>+			pdata->reg_offset = *(u16 *)match->data;
> >>+	}
> >
> >So this is now using both DT and pdata?
> >
> >We want to use DT only, and get rid of pdata. Other than the
> >deferred probe, is there some other dependency remaining to
> >having to use the pdata also?
> 
> We are using pdata today mainly for the platform function pointers
> that get passed for MMC, which can never be passed from DT.
> 
> The  omap_mmc_platform_data structure today has '17' function pointers.
> Most might be sparingly used, nevertheless, its an awfully large number.

Yeah OK.
 
> Here's the list...
> ---------
> int (*switch_slot)(struct device *dev, int slot);
> int (*init)(struct device *dev);
> void (*cleanup)(struct device *dev);
> void (*shutdown)(struct device *dev);
> int (*suspend)(struct device *dev, int slot);
> int (*resume)(struct device *dev, int slot);
> int (*get_context_loss_count)(struct device *dev);
> 
> per-slot functions
> 
> int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
> int (*set_power)(struct device *dev, int slot,
>                                  int power_on, int vdd);
> int (*get_ro)(struct device *dev, int slot);
> int (*set_sleep)(struct device *dev, int slot, int sleep,
>                                  int vdd, int cardsleep);
> void (*remux)(struct device *dev, int slot, int power_on);
> void (*before_set_reg)(struct device *dev, int slot,
>                                        int power_on, int vdd);
> void (*after_set_reg)(struct device *dev, int slot,
>                                       int power_on, int vdd);
> void (*init_card)(struct mmc_card *card);
> int (*get_cover_state)(struct device *dev, int slot);
> int (*card_detect)(struct device *dev, int slot);
> ---------

To me it seems we should move these into drivers/mmc/host/omap_hsmmc.c
and set them based on DT compatible (or some other) property.

If these functions tinker with some internal registers, then we need
to fix those too to use regulator/gpio API.

This way we don't need the platform_data any longer.

Regards,

Tony