[PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Rajendra Nayak]

Add omap mmc related device tree data for OMAP3.
Currenly limited to only omap3-beagle board.

Signed-off-by: Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/omap3-beagle.dts |    6 ++++++
 arch/arm/boot/dts/omap3.dtsi       |   26 ++++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 54556b1..c7b92e6 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -53,3 +53,9 @@
 		reg = <0x50>;
 	};
 };
+
+&mmc1 {
+	vmmc-supply = <&vmmc1>;
+	vmmc_aux-supply = <&vsim>;
+	ti,bus-width = <8>;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ca37ba5..598467c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c3";
 		};
+
+		mmc1: mmc@1 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+		};
+
+		mmc2: mmc@2 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc2";
+		};
+
+		mmc3: mmc@3 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc3";
+		};
+
+		mmc4: mmc@4 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc4";
+		};
+
+		mmc5: mmc@5 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc5";
+		};
 	};
 };
-- 
1.7.1

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Tony Lindgren]

> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -113,5 +113,31 @@
>  			#size-cells = <0>;
>  			ti,hwmods = "i2c3";
>  		};
> +
> +		mmc1: mmc@1 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc1";
> +			ti,dual-volt;
> +		};
> +
> +		mmc2: mmc@2 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc2";
> +		};
> +
> +		mmc3: mmc@3 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc3";
> +		};
> +
> +		mmc4: mmc@4 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc4";
> +		};
> +
> +		mmc5: mmc@5 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc5";
> +		};
>  	};
>  };

These all should all be "ti,omap3-hsmmc" I guess?

Tony

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Rajendra Nayak]

On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -113,5 +113,31 @@
>>   			#size-cells =<0>;
>>   			ti,hwmods = "i2c3";
>>   		};
>> +
>> +		mmc1: mmc@1 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc1";
>> +			ti,dual-volt;
>> +		};
>> +
>> +		mmc2: mmc@2 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc2";
>> +		};
>> +
>> +		mmc3: mmc@3 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc3";
>> +		};
>> +
>> +		mmc4: mmc@4 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc4";
>> +		};
>> +
>> +		mmc5: mmc@5 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc5";
>> +		};
>>   	};
>>   };
>
> These all should all be "ti,omap3-hsmmc" I guess?

Well, I defined the binding such that both omap2 and omap3
can use the same compatible "ti,omap2-hsmmc" since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.

>
> Tony

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Cousson, Benoit]

On 2/24/2012 5:00 AM, Rajendra Nayak wrote:
> On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
>>> --- a/arch/arm/boot/dts/omap3.dtsi
>>> +++ b/arch/arm/boot/dts/omap3.dtsi
>>> @@ -113,5 +113,31 @@
>>> #size-cells =<0>;
>>> ti,hwmods = "i2c3";
>>> };
>>> +
>>> + mmc1: mmc@1 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc1";
>>> + ti,dual-volt;
>>> + };
>>> +
>>> + mmc2: mmc@2 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc2";
>>> + };
>>> +
>>> + mmc3: mmc@3 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc3";
>>> + };
>>> +
>>> + mmc4: mmc@4 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc4";
>>> + };
>>> +
>>> + mmc5: mmc@5 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc5";
>>> + };
>>> };
>>> };
>>
>> These all should all be "ti,omap3-hsmmc" I guess?
>
> Well, I defined the binding such that both omap2 and omap3
> can use the same compatible "ti,omap2-hsmmc" since there is
> no difference in the way they are defined or handled. If thats
> confusing, I can have separate compatibles.
> Btw, I guess we do the same with a few other re-used IPs as well,
> I just checked and mcpsi does the same.

Yes, the goal is mainly to identify the IP version, so since OMAP3 is 
using OMAP2 IP, I do not think there is a need to add a new compatible 
string for OMAP3. The should only be documented in the binding potentially.
The advantage is that that will avoid adding an extra compatible string 
in the driver as well whereas there is no change in the IP.

Regards,
Benoit

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Tony Lindgren]

* Rajendra Nayak <rnayak@ti.com> [120223 19:29]:
> On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
> >>--- a/arch/arm/boot/dts/omap3.dtsi
> >>+++ b/arch/arm/boot/dts/omap3.dtsi
> >>@@ -113,5 +113,31 @@
> >>  			#size-cells =<0>;
> >>  			ti,hwmods = "i2c3";
> >>  		};
> >>+
> >>+		mmc1: mmc@1 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc1";
> >>+			ti,dual-volt;
> >>+		};
> >>+
> >>+		mmc2: mmc@2 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc2";
> >>+		};
> >>+
> >>+		mmc3: mmc@3 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc3";
> >>+		};
> >>+
> >>+		mmc4: mmc@4 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc4";
> >>+		};
> >>+
> >>+		mmc5: mmc@5 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc5";
> >>+		};
> >>  	};
> >>  };
> >
> >These all should all be "ti,omap3-hsmmc" I guess?
> 
> Well, I defined the binding such that both omap2 and omap3
> can use the same compatible "ti,omap2-hsmmc" since there is
> no difference in the way they are defined or handled. If thats
> confusing, I can have separate compatibles.
> Btw, I guess we do the same with a few other re-used IPs as well,
> I just checked and mcpsi does the same.

Yeah let's use separate compatibles to avoid confusion.
For omap2 we also have the ti,omap2-mmc in addition to
ti,omap2-hsmmc..

Regards,

Tony

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Grant Likely]

On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgren <tony@atomide.com> wrote:
> * Rajendra Nayak <rnayak@ti.com> [120223 19:29]:
> > On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
> > >>--- a/arch/arm/boot/dts/omap3.dtsi
> > >>+++ b/arch/arm/boot/dts/omap3.dtsi
> > >>@@ -113,5 +113,31 @@
> > >>  			#size-cells =<0>;
> > >>  			ti,hwmods = "i2c3";
> > >>  		};
> > >>+
> > >>+		mmc1: mmc@1 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc1";
> > >>+			ti,dual-volt;
> > >>+		};
> > >>+
> > >>+		mmc2: mmc@2 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc2";
> > >>+		};
> > >>+
> > >>+		mmc3: mmc@3 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc3";
> > >>+		};
> > >>+
> > >>+		mmc4: mmc@4 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc4";
> > >>+		};
> > >>+
> > >>+		mmc5: mmc@5 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc5";
> > >>+		};
> > >>  	};
> > >>  };
> > >
> > >These all should all be "ti,omap3-hsmmc" I guess?
> > 
> > Well, I defined the binding such that both omap2 and omap3
> > can use the same compatible "ti,omap2-hsmmc" since there is
> > no difference in the way they are defined or handled. If thats
> > confusing, I can have separate compatibles.
> > Btw, I guess we do the same with a few other re-used IPs as well,
> > I just checked and mcpsi does the same.
> 
> Yeah let's use separate compatibles to avoid confusion.
> For omap2 we also have the ti,omap2-mmc in addition to
> ti,omap2-hsmmc..

Yes, absolutely use separate compatible values.  It is always important
to be specific as to the silicon implementing the IP.  The omap3 instance
can also carry the omap2 string in its compatible list:

	compatible = "ti,omap3-hsmmc", "ti,omap2-hsmmc";

g.

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Paul Walmsley]

On Thu, 8 Mar 2012, Grant Likely wrote:

> Yes, absolutely use separate compatible values.  It is always important
> to be specific as to the silicon implementing the IP.

In that case, it is probably best to use the full chip name in the 
compatible string, e.g., omap2420 or omap2430 rather than just "omap2".  
Particularly in the case of "OMAP3," which is a largely meaningless group 
these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are 
quite different from each other...


- Paul

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Rajendra Nayak]

On Friday 09 March 2012 11:16 AM, Grant Likely wrote:
> On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgren<tony@atomide.com>  wrote:
>> * Rajendra Nayak<rnayak@ti.com>  [120223 19:29]:
>>> On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
>>>>> --- a/arch/arm/boot/dts/omap3.dtsi
>>>>> +++ b/arch/arm/boot/dts/omap3.dtsi
>>>>> @@ -113,5 +113,31 @@
>>>>>   			#size-cells =<0>;
>>>>>   			ti,hwmods = "i2c3";
>>>>>   		};
>>>>> +
>>>>> +		mmc1: mmc@1 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc1";
>>>>> +			ti,dual-volt;
>>>>> +		};
>>>>> +
>>>>> +		mmc2: mmc@2 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc2";
>>>>> +		};
>>>>> +
>>>>> +		mmc3: mmc@3 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc3";
>>>>> +		};
>>>>> +
>>>>> +		mmc4: mmc@4 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc4";
>>>>> +		};
>>>>> +
>>>>> +		mmc5: mmc@5 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc5";
>>>>> +		};
>>>>>   	};
>>>>>   };
>>>>
>>>> These all should all be "ti,omap3-hsmmc" I guess?
>>>
>>> Well, I defined the binding such that both omap2 and omap3
>>> can use the same compatible "ti,omap2-hsmmc" since there is
>>> no difference in the way they are defined or handled. If thats
>>> confusing, I can have separate compatibles.
>>> Btw, I guess we do the same with a few other re-used IPs as well,
>>> I just checked and mcpsi does the same.
>>
>> Yeah let's use separate compatibles to avoid confusion.
>> For omap2 we also have the ti,omap2-mmc in addition to
>> ti,omap2-hsmmc..
>
> Yes, absolutely use separate compatible values.  It is always important
> to be specific as to the silicon implementing the IP.  The omap3 instance
> can also carry the omap2 string in its compatible list:
>
> 	compatible = "ti,omap3-hsmmc", "ti,omap2-hsmmc";

Sure, will repost with seperate compatible strings. Also missed adding
the 'status = "disable";' for unused mmc blocks in the board .dts file
causing unused mmc modules to get probed too. Will fix that as well.

thanks,
Rajendra

>
> g.

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Rajendra Nayak]

Hi Paul,

On Friday 09 March 2012 12:21 PM, Paul Walmsley wrote:
> On Thu, 8 Mar 2012, Grant Likely wrote:
>
>> Yes, absolutely use separate compatible values.  It is always important
>> to be specific as to the silicon implementing the IP.
>
> In that case, it is probably best to use the full chip name in the
> compatible string, e.g., omap2420 or omap2430 rather than just "omap2".

Since omap2420 and omap2430 have different MMC controllers (and these
bindings only cover the hsmmc controller used in 2430 and beyond, I
haven't done the bindings for the legacy one yet), the idea was
to differentiate between omap2420 and omap2430 by using
compatible of "ti,omap2-hsmmc" for the High-Speed controller used in
OMAP2 (2430) and "ti,omap2-mmc" for the legacy one used in OMAP2 (2420).
Does that sound good to you?

> Particularly in the case of "OMAP3," which is a largely meaningless group
> these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are
> quite different from each other...

But these bindings are specific and limited to HSMMC module which is
not quite different in the different SoC variants. There is a single
driver to handle hsmmc module on all the SoCs which does not need to
differentiate which SoC it is on.

regards,
Rajendra

>
>
> - Paul

[PATCH v2 0/4] omap hsmmc device tree support

[Rajendra Nayak]

The series adds device tree support for OMAP hsmmc
driver.

Changes in V2:
-1- Minor fixes based on comments from Grant.
-2- Added a seperate compatible for omap3.
-3- Added a new binding "ti,needs-special-reset"
to handle some mmc modules which need special
softreset sequence.
-4- Updated board dts files with "status = disable;"
for unused mmc modules.

Rob,
I retained your ack on patch 1 despite the additional
binding that I added to handle the special softreset
sequence. Let me know if you have any issues with it.

Chris.
Patch 1 and Patch 2 apply cleanly on mmc-next and can
be taken in from the mmc tree after relevent acks from
DT folks.
Patch 3 and Patch 4 which update dts files, I plan to
push via linux-omap/Tony's tree.

The series is tested on omap4sdp (both external and emmc),
omap4panda amd omap3beagle boards.

Things to do:
-1- Card detect isn't functional and needs twl4030 gpio
to be DT converted.
-2- pbias cell programming is missing and needs an OMAP
control module driver.

Rajendra Nayak (4):
  mmc: omap_hsmmc: Convert hsmmc driver to use device tree
  mmc: omap_hsmmc: Avoid a regulator voltage change with dt
  arm/dts: OMAP4: Add mmc controller nodes and board data
  arm/dts: OMAP3: Add mmc controller nodes and board data

 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   33 +++++++
 arch/arm/boot/dts/omap3-beagle.dts                 |   14 +++
 arch/arm/boot/dts/omap3.dtsi                       |   16 ++++
 arch/arm/boot/dts/omap4-panda.dts                  |   22 +++++
 arch/arm/boot/dts/omap4-sdp.dts                    |   24 ++++++
 arch/arm/boot/dts/omap4.dtsi                       |   31 +++++++
 drivers/mmc/host/omap_hsmmc.c                      |   88 +++++++++++++++++++-
 7 files changed, 227 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use 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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   33 +++++++++
 drivers/mmc/host/omap_hsmmc.c                      |   73 ++++++++++++++++++++
 2 files changed, 106 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..dbd4368
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,33 @@
+* 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,omap2-hsmmc", for OMAP2 controllers
+ Should be "ti,omap3-hsmmc", for OMAP3 controllers
+ Should be "ti,omap4-hsmmc", 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,dual-volt: boolean, supports dual voltage cards
+<supply-name>-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+ti,needs-special-reset: Requires a special softreset sequence
+
+Example:
+	mmc1: mmc@0x4809c000 {
+		compatible = "ti,omap4-hsmmc";
+		reg = <0x4809c000 0x400>;
+		ti,hwmods = "mmc1";
+		ti,dual-volt;
+		ti,bus-width = <4>;
+		vmmc-supply = <&vmmc>; /* phandle to regulator node */
+		ti,non-removable;
+	};
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82583bf..38ae8c0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -26,6 +26,9 @@
 #include <linux/platform_device.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>
@@ -1690,6 +1693,65 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
 
 #endif
 
+#ifdef CONFIG_OF
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+	{
+		.compatible = "ti,omap2-hsmmc",
+	},
+	{
+		.compatible = "ti,omap3-hsmmc",
+	},
+	{
+		.compatible = "ti,omap4-hsmmc",
+		.data = &omap4_reg_offset,
+	},
+	{},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
+{
+	struct omap_mmc_platform_data *pdata;
+	struct device_node *np = dev->of_node;
+	u32 bus_width;
+
+	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return NULL; /* out of memory */
+
+	if (of_find_property(np, "ti,dual-volt", NULL))
+		pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+	/* This driver only supports 1 slot */
+	pdata->nr_slots = 1;
+	pdata->slots[0].switch_pin = of_get_named_gpio(np, "cd-gpios", 0);
+	pdata->slots[0].gpio_wp = of_get_named_gpio(np, "wp-gpios", 0);
+
+	if (of_find_property(np, "ti,non-removable", NULL)) {
+		pdata->slots[0].nonremovable = true;
+		pdata->slots[0].no_regulator_off_init = true;
+	}
+	of_property_read_u32(np, "ti,bus-width", &bus_width);
+	if (bus_width == 4)
+		pdata->slots[0].caps |= MMC_CAP_4_BIT_DATA;
+	else if (bus_width == 8)
+		pdata->slots[0].caps |= MMC_CAP_8_BIT_DATA;
+
+	if (of_find_property(np, "ti,needs-special-reset", NULL))
+		pdata->slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+
+	return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+			*of_get_hsmmc_pdata(struct device *dev)
+{
+	return NULL;
+}
+#endif
+
 static int __init omap_hsmmc_probe(struct platform_device *pdev)
 {
 	struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1697,6 +1759,16 @@ 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(of_match_ptr(omap_mmc_of_match), &pdev->dev);
+	if (match) {
+		pdata = of_get_hsmmc_pdata(&pdev->dev);
+		if (match->data) {
+			u16 *offsetp = match->data;
+			pdata->reg_offset = *offsetp;
+		}
+	}
 
 	if (pdata == NULL) {
 		dev_err(&pdev->dev, "Platform Data is missing\n");
@@ -2102,6 +2174,7 @@ static struct platform_driver omap_hsmmc_driver = {
 		.name = DRIVER_NAME,
 		.owner = THIS_MODULE,
 		.pm = &omap_hsmmc_dev_pm_ops,
+		.of_match_table = of_match_ptr(omap_mmc_of_match),
 	},
 };
 
-- 
1.7.1

[PATCH v2 2/4] mmc: omap_hsmmc: Avoid a regulator voltage change with dt

[Rajendra Nayak]

When booting with Device tree, the omap_hsmmc driver does not
program the pbias cell (inside OMAP control module) during
a regulator voltage change.
In case of non-dt boot, this is handled using callbacks
from within platform_data and implemented in machine code.
To be able to do this with device tree, without invoking
any machine code, a OMAP control module driver is needed
which is yet missing.

The pbias cell is used to provide a 1.8v or 3.0v reference
to the mmc/sd/sdio1 interface supporting both 1.8v and 3.0v
voltages.

Until a OMAP control module driver is available to handle this,
when booting with a device tree blob, never change the regulator
voltage which might then require a pbias cell re-program.
There are 2 instances where in the mmc regulator voltage can be
changed.
-1- when the regulator is turned OFF.
-2- when attempting a switch to 1.8v from 3.0v for dual volt cards

This patch avoids a voltage change in both cases when booting from
device tree, and hence compromises on power savings.
Once the OMAP control module driver is available and hsmmc driver
is modified to then do pbias programming even when booting
with device tree, these limitaions can be removed to achieve better
power savings.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 drivers/mmc/host/omap_hsmmc.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 38ae8c0..f29e1a2 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -244,6 +244,13 @@ static int omap_hsmmc_set_power(struct device *dev, int slot, int power_on,
 	 */
 	if (!host->vcc)
 		return 0;
+	/*
+	 * With DT, never turn OFF the regulator. This is because
+	 * the pbias cell programming support is still missing when
+	 * booting with Device tree
+	 */
+	if (of_have_populated_dt() && !vdd)
+		return 0;
 
 	if (mmc_slot(host).before_set_reg)
 		mmc_slot(host).before_set_reg(dev, slot, power_on, vdd);
@@ -1516,7 +1523,13 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 		 * of external transceiver; but they all handle 1.8V.
 		 */
 		if ((OMAP_HSMMC_READ(host->base, HCTL) & SDVSDET) &&
-			(ios->vdd == DUAL_VOLT_OCR_BIT)) {
+			(ios->vdd == DUAL_VOLT_OCR_BIT) &&
+			/*
+			 * With pbias cell programming missing, this
+			 * can't be allowed when booting with device
+			 * tree.
+			 */
+			(!of_have_populated_dt())) {
 				/*
 				 * The mmc_select_voltage fn of the core does
 				 * not seem to set the power_mode to
-- 
1.7.1

[PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data

[Rajendra Nayak]

Add omap mmc related device tree data for OMAP4.
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 |   22 ++++++++++++++++++++++
 arch/arm/boot/dts/omap4-sdp.dts   |   24 ++++++++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi      |   31 +++++++++++++++++++++++++++++++
 3 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 29646dc..ea6f5bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -52,3 +52,25 @@
 &i2c4 {
 	clock-frequency = <400000>;
 };
+
+&mmc1 {
+	vmmc-supply = <&vmmc>;
+	ti,bus-width = <8>;
+};
+
+&mmc2 {
+	status = "disable";
+};
+
+&mmc3 {
+	status = "disable";
+};
+
+&mmc4 {
+	status = "disable";
+};
+
+&mmc5 {
+	ti,non-removable;
+	ti,bus-width = <4>;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 01db8b7..852657a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,3 +70,27 @@
 		reg = <0x1e>;
 	};
 };
+
+&mmc1 {
+	vmmc-supply = <&vmmc>;
+	ti,bus-width = <8>;
+};
+
+&mmc2 {
+	vmmc-supply = <&vaux1>;
+	ti,bus-width = <8>;
+	ti,non-removable;
+};
+
+&mmc3 {
+	status = "disable";
+};
+
+&mmc4 {
+	status = "disable";
+};
+
+&mmc5 {
+	ti,bus-width = <4>;
+	ti,non-removable;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9226543 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -155,5 +155,36 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c4";
 		};
+
+		mmc1: mmc@1 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+			ti,needs-special-reset;
+		};
+
+		mmc2: mmc@2 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc2";
+			ti,needs-special-reset;
+		};
+
+		mmc3: mmc@3 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc3";
+			ti,needs-special-reset;
+		};
+
+		mmc4: mmc@4 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc4";
+			ti,needs-special-reset;
+		};
+
+		mmc5: mmc@5 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc5";
+			ti,needs-special-reset;
+		};
 	};
 };
-- 
1.7.1

[PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

[Rajendra Nayak]

Add omap mmc related device tree data for OMAP3.
Currenly limited to only omap3-beagle board.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/boot/dts/omap3-beagle.dts |   14 ++++++++++++++
 arch/arm/boot/dts/omap3.dtsi       |   16 ++++++++++++++++
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 714ba5d..5cf67d1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -47,3 +47,17 @@
 		reg = <0x50>;
 	};
 };
+
+&mmc1 {
+	vmmc-supply = <&vmmc1>;
+	vmmc_aux-supply = <&vsim>;
+	ti,bus-width = <8>;
+};
+
+&mmc2 {
+	status = "disable";
+};
+
+&mmc3 {
+	status = "disable";
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ca37ba5..3892e34 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,21 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c3";
 		};
+
+		mmc1: mmc@1 {
+			compatible = "ti,omap3-hsmmc";
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+		};
+
+		mmc2: mmc@2 {
+			compatible = "ti,omap3-hsmmc";
+			ti,hwmods = "mmc2";
+		};
+
+		mmc3: mmc@3 {
+			compatible = "ti,omap3-hsmmc";
+			ti,hwmods = "mmc3";
+		};
 	};
 };
-- 
1.7.1

Re: [PATCH v2 0/4] omap hsmmc device tree support

[T Krishnamoorthy, Balaji]

On Mon, Mar 12, 2012 at 8:32 PM, Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org> wrote:
> The series adds device tree support for OMAP hsmmc
> driver.
>
> Changes in V2:
> -1- Minor fixes based on comments from Grant.
> -2- Added a seperate compatible for omap3.
> -3- Added a new binding "ti,needs-special-reset"
> to handle some mmc modules which need special
> softreset sequence.
> -4- Updated board dts files with "status = disable;"
> for unused mmc modules.
>
> Rob,
> I retained your ack on patch 1 despite the additional
> binding that I added to handle the special softreset
> sequence. Let me know if you have any issues with it.
>
> Chris.
> Patch 1 and Patch 2 apply cleanly on mmc-next and can
> be taken in from the mmc tree after relevent acks from
> DT folks.
> Patch 3 and Patch 4 which update dts files, I plan to
> push via linux-omap/Tony's tree.
Hi Rajendra,

Tested this series on omap4sdp, so feel free to add
Tested-by: Balaji T K <balajitk-l0cyMroinI0@public.gmane.org>

>
> The series is tested on omap4sdp (both external and emmc),
> omap4panda amd omap3beagle boards.
>
> Things to do:
> -1- Card detect isn't functional and needs twl4030 gpio
> to be DT converted.
> -2- pbias cell programming is missing and needs an OMAP
> control module driver.
>
> Rajendra Nayak (4):
>  mmc: omap_hsmmc: Convert hsmmc driver to use device tree
>  mmc: omap_hsmmc: Avoid a regulator voltage change with dt
>  arm/dts: OMAP4: Add mmc controller nodes and board data
>  arm/dts: OMAP3: Add mmc controller nodes and board data
>
>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   33 +++++++
>  arch/arm/boot/dts/omap3-beagle.dts                 |   14 +++
>  arch/arm/boot/dts/omap3.dtsi                       |   16 ++++
>  arch/arm/boot/dts/omap4-panda.dts                  |   22 +++++
>  arch/arm/boot/dts/omap4-sdp.dts                    |   24 ++++++
>  arch/arm/boot/dts/omap4.dtsi                       |   31 +++++++
>  drivers/mmc/host/omap_hsmmc.c                      |   88 +++++++++++++++++++-
>  7 files changed, 227 insertions(+), 1 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt

Re: [PATCH v2 0/4] omap hsmmc device tree support

[Chris Ball]

Hi,

On Mon, Mar 12 2012, Rajendra Nayak wrote:
> The series adds device tree support for OMAP hsmmc
> driver.
>
> Changes in V2:
> -1- Minor fixes based on comments from Grant.
> -2- Added a seperate compatible for omap3.
> -3- Added a new binding "ti,needs-special-reset"
> to handle some mmc modules which need special
> softreset sequence.
> -4- Updated board dts files with "status = disable;"
> for unused mmc modules.
>
> Rob,
> I retained your ack on patch 1 despite the additional
> binding that I added to handle the special softreset
> sequence. Let me know if you have any issues with it.
>
> Chris.
> Patch 1 and Patch 2 apply cleanly on mmc-next and can
> be taken in from the mmc tree after relevent acks from
> DT folks.
> Patch 3 and Patch 4 which update dts files, I plan to
> push via linux-omap/Tony's tree.

Thanks, I've pushed patches 1 and 2 to mmc-next for 3.4, with Balaji's
Tested-by.

- Chris.
-- 
Chris Ball   <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>   <http://printf.net/>
One Laptop Per Child