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

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

[Rajendra Nayak]

This series adds device tree support for OMAP hsmmc
driver. The series is dependent on a couple other series,
to add TWL regulator DT support[1] and another to clean
the pdev->id usage within the hsmmc driver[2]

all patches including the dependent series can be
found here
git://gitorious.org/omap-pm/linux.git for-dt/regulator

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.

[1] http://marc.info/?l=linux-omap&m=132999699905180&w=2
[2] http://marc.info/?l=linux-omap&m=132999646604985&w=2

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      |   31 +++++++
 arch/arm/boot/dts/omap3-beagle.dts                 |    6 ++
 arch/arm/boot/dts/omap3.dtsi                       |   26 ++++++
 arch/arm/boot/dts/omap4-panda.dts                  |   10 +++
 arch/arm/boot/dts/omap4-sdp.dts                    |   16 ++++
 arch/arm/boot/dts/omap4.dtsi                       |   31 +++++++
 drivers/mmc/host/omap_hsmmc.c                      |   83 +++++++++++++++++++-
 7 files changed, 202 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>
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   31 +++++++++
 drivers/mmc/host/omap_hsmmc.c                      |   68 ++++++++++++++++++++
 2 files changed, 99 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..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* 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/3 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)
+
+Example:
+	mmc1: mmc at 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 35f6dc1..0c93d58 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>
@@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
 
 #endif
 
+#ifdef CONFIG_OF
+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;
+	return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+			*of_get_hsmmc_pdata(struct device *dev)
+{
+	return NULL;
+}
+#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;
@@ -1725,6 +1768,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");
@@ -2120,12 +2171,29 @@ 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);
+#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 = of_match_ptr(omap_mmc_of_match),
 	},
 };
 
-- 
1.7.1

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[T Krishnamoorthy, Balaji]

On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak <rnayak@ti.com> 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.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> ?.../devicetree/bindings/mmc/ti-omap-hsmmc.txt ? ? ?| ? 31 +++++++++
> ?drivers/mmc/host/omap_hsmmc.c ? ? ? ? ? ? ? ? ? ? ?| ? 68 ++++++++++++++++++++
> ?2 files changed, 99 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..e4fa8f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -0,0 +1,31 @@
> +* 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/3 controllers

omap_hsmmc is applicable for omap2430 and omap3.
omap2420 has non high speed controller mmci-omap - drivers/mmc/host/omap.c
May be omap3-hsmmc compatible with omap2430 ?

> + 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)
> +
> +Example:
> + ? ? ? mmc1: mmc at 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;
> + ? ? ? };

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Rajendra Nayak]

On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:
> On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak<rnayak@ti.com>  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.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>>   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   31 +++++++++
>>   drivers/mmc/host/omap_hsmmc.c                      |   68 ++++++++++++++++++++
>>   2 files changed, 99 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..e4fa8f0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -0,0 +1,31 @@
>> +* 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/3 controllers
>
> omap_hsmmc is applicable for omap2430 and omap3.
> omap2420 has non high speed controller mmci-omap - drivers/mmc/host/omap.c
> May be omap3-hsmmc compatible with omap2430 ?

Agree. I think its best in that case for me to define a
compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
for omap3. Though the IP blocks are same, I cant think of some
common compatible string without causing confusion.

>
>> + 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)
>> +
>> +Example:
>> +       mmc1: mmc at 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;
>> +       };

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Cousson, Benoit]

On 2/24/2012 12:35 PM, Rajendra Nayak wrote:
> On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:
>> On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak<rnayak@ti.com> 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.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> ---
>>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +++++++++
>>> drivers/mmc/host/omap_hsmmc.c | 68 ++++++++++++++++++++
>>> 2 files changed, 99 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..e4fa8f0
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> @@ -0,0 +1,31 @@
>>> +* 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/3 controllers
>>
>> omap_hsmmc is applicable for omap2430 and omap3.
>> omap2420 has non high speed controller mmci-omap -
>> drivers/mmc/host/omap.c
>> May be omap3-hsmmc compatible with omap2430 ?
>
> Agree. I think its best in that case for me to define a
> compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
> for omap3. Though the IP blocks are same, I cant think of some
> common compatible string without causing confusion.

It depends, can we detect that using HW revision?
In that case, there is no need to differentiate again with compatible.

Regards,
Benoit

>
>>
>>> + 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)
>>> +
>>> +Example:
>>> + mmc1: mmc at 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;
>>> + };
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Rajendra Nayak]

On Friday 24 February 2012 06:21 PM, Cousson, Benoit wrote:
> On 2/24/2012 12:35 PM, Rajendra Nayak wrote:
>> On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:
>>> On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak<rnayak@ti.com> 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.
>>>>
>>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>>> ---
>>>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +++++++++
>>>> drivers/mmc/host/omap_hsmmc.c | 68 ++++++++++++++++++++
>>>> 2 files changed, 99 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..e4fa8f0
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>> @@ -0,0 +1,31 @@
>>>> +* 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/3 controllers
>>>
>>> omap_hsmmc is applicable for omap2430 and omap3.
>>> omap2420 has non high speed controller mmci-omap -
>>> drivers/mmc/host/omap.c
>>> May be omap3-hsmmc compatible with omap2430 ?
>>
>> Agree. I think its best in that case for me to define a
>> compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
>> for omap3. Though the IP blocks are same, I cant think of some
>> common compatible string without causing confusion.
>
> It depends, can we detect that using HW revision?

We don't need to. The driver does not do anything different for
2430 or omap3.

> In that case, there is no need to differentiate again with compatible.

Thats perfectly fine. But what *common* compatible string would you
use?

>
> Regards,
> Benoit
>
>>
>>>
>>>> + 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)
>>>> +
>>>> +Example:
>>>> + mmc1: mmc at 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;
>>>> + };
>>
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Cousson, Benoit]

On 2/24/2012 1:58 PM, Rajendra Nayak wrote:
> On Friday 24 February 2012 06:21 PM, Cousson, Benoit wrote:
>> On 2/24/2012 12:35 PM, Rajendra Nayak wrote:
>>> On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:
>>>> On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak<rnayak@ti.com> wrote:
...
>>>>> +Required properties:
>>>>> +- compatible:
>>>>> + Should be "ti,omap2-hsmmc", for OMAP2/3 controllers
>>>>
>>>> omap_hsmmc is applicable for omap2430 and omap3.
>>>> omap2420 has non high speed controller mmci-omap -
>>>> drivers/mmc/host/omap.c
>>>> May be omap3-hsmmc compatible with omap2430 ?
>>>
>>> Agree. I think its best in that case for me to define a
>>> compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
>>> for omap3. Though the IP blocks are same, I cant think of some
>>> common compatible string without causing confusion.
>>
>> It depends, can we detect that using HW revision?
>
> We don't need to. The driver does not do anything different for
> 2430 or omap3.

I was thinking of OMAP2420 vs OMAP2430. But I'm now wondering if we are 
using the same driver for the non-HS controller?

>> In that case, there is no need to differentiate again with compatible.
>
> Thats perfectly fine. But what *common* compatible string would you
> use?

I think that "ti,omap2-hsmmc" is still fine, because OMAP2420 will have 
"ti,omap2-mmc" and thus we can differentiate the 2 versions.

Does that make sense?

Regards,
Benoit

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Rajendra Nayak]

On Friday 24 February 2012 06:32 PM, Cousson, Benoit wrote:
> On 2/24/2012 1:58 PM, Rajendra Nayak wrote:
>> On Friday 24 February 2012 06:21 PM, Cousson, Benoit wrote:
>>> On 2/24/2012 12:35 PM, Rajendra Nayak wrote:
>>>> On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:
>>>>> On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayak<rnayak@ti.com> wrote:
> ...
>>>>>> +Required properties:
>>>>>> +- compatible:
>>>>>> + Should be "ti,omap2-hsmmc", for OMAP2/3 controllers
>>>>>
>>>>> omap_hsmmc is applicable for omap2430 and omap3.
>>>>> omap2420 has non high speed controller mmci-omap -
>>>>> drivers/mmc/host/omap.c
>>>>> May be omap3-hsmmc compatible with omap2430 ?
>>>>
>>>> Agree. I think its best in that case for me to define a
>>>> compatible "ti,omap2430-hsmmc" for omap2430 and "ti,omap3-hsmmc"
>>>> for omap3. Though the IP blocks are same, I cant think of some
>>>> common compatible string without causing confusion.
>>>
>>> It depends, can we detect that using HW revision?
>>
>> We don't need to. The driver does not do anything different for
>> 2430 or omap3.
>
> I was thinking of OMAP2420 vs OMAP2430. But I'm now wondering if we are
> using the same driver for the non-HS controller?

No, we don't. there is a different driver for 2420.

>
>>> In that case, there is no need to differentiate again with compatible.
>>
>> Thats perfectly fine. But what *common* compatible string would you
>> use?
>
> I think that "ti,omap2-hsmmc" is still fine, because OMAP2420 will have
> "ti,omap2-mmc" and thus we can differentiate the 2 versions.
>
> Does that make sense?

yup, that makes sense. So I don't need to change anything :-)

>
> Regards,
> Benoit

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Rajendra Nayak]

Hi Rob/Grant,

On Thursday 23 February 2012 05:31 PM, 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.

Any comments on these bindings for omap hsmmc? All the dependent
patches/series on which this series was based have now made it to
the respective -next of Mark and Chris.

regards,
Rajendra

>
> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> ---
>   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   31 +++++++++
>   drivers/mmc/host/omap_hsmmc.c                      |   68 ++++++++++++++++++++
>   2 files changed, 99 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..e4fa8f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -0,0 +1,31 @@
> +* 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/3 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)
> +
> +Example:
> +	mmc1: mmc at 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 35f6dc1..0c93d58 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>
> @@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
>
>   #endif
>
> +#ifdef CONFIG_OF
> +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;
> +	return pdata;
> +}
> +#else
> +static inline struct omap_mmc_platform_data
> +			*of_get_hsmmc_pdata(struct device *dev)
> +{
> +	return NULL;
> +}
> +#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;
> @@ -1725,6 +1768,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");
> @@ -2120,12 +2171,29 @@ 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);
> +#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 = of_match_ptr(omap_mmc_of_match),
>   	},
>   };
>

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Rob Herring]

On 03/07/2012 09:46 PM, Rajendra Nayak wrote:
> Hi Rob/Grant,
> 
> On Thursday 23 February 2012 05:31 PM, 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.
> 
> Any comments on these bindings for omap hsmmc? All the dependent
> patches/series on which this series was based have now made it to
> the respective -next of Mark and Chris.
> 

Acked-by: Rob Herring <rob.herring@calxeda.com>

> 
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>>   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   31 +++++++++
>>   drivers/mmc/host/omap_hsmmc.c                      |   68
>> ++++++++++++++++++++
>>   2 files changed, 99 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..e4fa8f0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -0,0 +1,31 @@
>> +* 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/3 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)
>> +
>> +Example:
>> +    mmc1: mmc at 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 35f6dc1..0c93d58 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>
>> @@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host
>> *mmc)
>>
>>   #endif
>>
>> +#ifdef CONFIG_OF
>> +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;
>> +    return pdata;
>> +}
>> +#else
>> +static inline struct omap_mmc_platform_data
>> +            *of_get_hsmmc_pdata(struct device *dev)
>> +{
>> +    return NULL;
>> +}
>> +#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;
>> @@ -1725,6 +1768,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");
>> @@ -2120,12 +2171,29 @@ 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);
>> +#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 = of_match_ptr(omap_mmc_of_match),
>>       },
>>   };
>>
> 

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Grant Likely]

On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayak <rnayak@ti.com> 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.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   31 +++++++++
>  drivers/mmc/host/omap_hsmmc.c                      |   68 ++++++++++++++++++++
>  2 files changed, 99 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..e4fa8f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -0,0 +1,31 @@
> +* 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/3 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)

Binding looks okay.  A couple comments below...

[...]
> +static const struct of_device_id omap_mmc_of_match[];

If you move the omap_mmc_of_match[] table up to here then there is no
need for the forward declaration.

> +
>  static int __init omap_hsmmc_probe(struct platform_device *pdev)
>  {
>  	struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
> @@ -1725,6 +1768,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;

Blech on the ugly cast.  It is slightly safer to do thusly:

	u16 *offsetp = match->data;
	pdata->reg_offset = *offsetp

> +	}
>  
>  	if (pdata == NULL) {
>  		dev_err(&pdev->dev, "Platform Data is missing\n");
> @@ -2120,12 +2171,29 @@ 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);
> +#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 = of_match_ptr(omap_mmc_of_match),
>  	},
>  };
>  
> -- 
> 1.7.1
> 
> 
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev

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

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

[Rajendra Nayak]

Hi Grant,

On Friday 09 March 2012 11:12 AM, Grant Likely wrote:
> On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayak<rnayak@ti.com>  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.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>>   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |   31 +++++++++
>>   drivers/mmc/host/omap_hsmmc.c                      |   68 ++++++++++++++++++++
>>   2 files changed, 99 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..e4fa8f0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -0,0 +1,31 @@
>> +* 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/3 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)
>
> Binding looks okay.  A couple comments below...
>
> [...]
>> +static const struct of_device_id omap_mmc_of_match[];
>
> If you move the omap_mmc_of_match[] table up to here then there is no
> need for the forward declaration.
>
>> +
>>   static int __init omap_hsmmc_probe(struct platform_device *pdev)
>>   {
>>   	struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
>> @@ -1725,6 +1768,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;
>
> Blech on the ugly cast.  It is slightly safer to do thusly:
>
> 	u16 *offsetp = match->data;
> 	pdata->reg_offset = *offsetp

thanks for the review. I'll repost with these changes.

regards,
Rajendra

>
>> +	}
>>
>>   	if (pdata == NULL) {
>>   		dev_err(&pdev->dev, "Platform Data is missing\n");
>> @@ -2120,12 +2171,29 @@ 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);
>> +#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 = of_match_ptr(omap_mmc_of_match),
>>   	},
>>   };
>>
>> --
>> 1.7.1
>>
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev at lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>

[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 0c93d58..dffde8d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -245,6 +245,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);
@@ -1537,7 +1544,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 |   10 ++++++++++
 arch/arm/boot/dts/omap4-sdp.dts   |   16 ++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi      |   31 +++++++++++++++++++++++++++++++
 3 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 29646dc..9fe51b9 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -52,3 +52,13 @@
 &i2c4 {
 	clock-frequency = <400000>;
 };
+
+&mmc1 {
+	vmmc-supply = <&vmmc>;
+	ti,bus-width = <8>;
+};
+
+&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..2fca7a3 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,3 +70,19 @@
 		reg = <0x1e>;
 	};
 };
+
+&mmc1 {
+	vmmc-supply = <&vmmc>;
+	ti,bus-width = <8>;
+};
+
+&mmc2 {
+	vmmc-supply = <&vaux1>;
+	ti,bus-width = <8>;
+	ti,non-removable;
+};
+
+&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..9204f60 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
 		serial1 = &uart2;
 		serial2 = &uart3;
 		serial3 = &uart4;
+		mmc1 = &mmc1;
+		mmc2 = &mmc2;
+		mmc3 = &mmc3;
+		mmc4 = &mmc4;
+		mmc5 = &mmc5;
 	};
 
 	cpus {
@@ -155,5 +160,31 @@
 			#size-cells = <0>;
 			ti,hwmods = "i2c4";
 		};
+
+		mmc1: mmc at 1 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+		};
+
+		mmc2: mmc at 2 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc2";
+		};
+
+		mmc3: mmc at 3 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc3";
+		};
+
+		mmc4: mmc at 4 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc4";
+		};
+
+		mmc5: mmc at 5 {
+			compatible = "ti,omap4-hsmmc";
+			ti,hwmods = "mmc5";
+		};
 	};
 };
-- 
1.7.1

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

[T Krishnamoorthy, Balaji]

> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index 29f4589..9204f60 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -25,6 +25,11 @@
> ? ? ? ? ? ? ? ?serial1 = &uart2;
> ? ? ? ? ? ? ? ?serial2 = &uart3;
> ? ? ? ? ? ? ? ?serial3 = &uart4;
> + ? ? ? ? ? ? ? mmc1 = &mmc1;
> + ? ? ? ? ? ? ? mmc2 = &mmc2;
> + ? ? ? ? ? ? ? mmc3 = &mmc3;
> + ? ? ? ? ? ? ? mmc4 = &mmc4;
> + ? ? ? ? ? ? ? mmc5 = &mmc5;
> ? ? ? ?};
>
> ? ? ? ?cpus {
> @@ -155,5 +160,31 @@
> ? ? ? ? ? ? ? ? ? ? ? ?#size-cells = <0>;
> ? ? ? ? ? ? ? ? ? ? ? ?ti,hwmods = "i2c4";
> ? ? ? ? ? ? ? ?};
> +
> + ? ? ? ? ? ? ? mmc1: mmc at 1 {
> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc1";
> + ? ? ? ? ? ? ? ? ? ? ? ti,dual-volt;
> + ? ? ? ? ? ? ? };
> +
> + ? ? ? ? ? ? ? mmc2: mmc at 2 {
> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc2";
> + ? ? ? ? ? ? ? };

Hi Rajendra,
Is there a way to control the device registration order,
eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
irrespective of whether SD card is mount or not on mmc1 card slot.
So that bootargs would not have to be modified when filesystem is on eMMC.

> +
> + ? ? ? ? ? ? ? mmc3: mmc at 3 {
> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc3";
> + ? ? ? ? ? ? ? };
> +
> + ? ? ? ? ? ? ? mmc4: mmc at 4 {
> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc4";
> + ? ? ? ? ? ? ? };
> +
> + ? ? ? ? ? ? ? mmc5: mmc at 5 {
> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc5";
> + ? ? ? ? ? ? ? };
> ? ? ? ?};
> ?};
> --
> 1.7.1
>

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

[Rajendra Nayak]

On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:
>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>> index 29f4589..9204f60 100644
>> --- a/arch/arm/boot/dts/omap4.dtsi
>> +++ b/arch/arm/boot/dts/omap4.dtsi
>> @@ -25,6 +25,11 @@
>>                 serial1 =&uart2;
>>                 serial2 =&uart3;
>>                 serial3 =&uart4;
>> +               mmc1 =&mmc1;
>> +               mmc2 =&mmc2;
>> +               mmc3 =&mmc3;
>> +               mmc4 =&mmc4;
>> +               mmc5 =&mmc5;
>>         };
>>
>>         cpus {
>> @@ -155,5 +160,31 @@
>>                         #size-cells =<0>;
>>                         ti,hwmods = "i2c4";
>>                 };
>> +
>> +               mmc1: mmc at 1 {
>> +                       compatible = "ti,omap4-hsmmc";
>> +                       ti,hwmods = "mmc1";
>> +                       ti,dual-volt;
>> +               };
>> +
>> +               mmc2: mmc at 2 {
>> +                       compatible = "ti,omap4-hsmmc";
>> +                       ti,hwmods = "mmc2";
>> +               };
>
> Hi Rajendra,
> Is there a way to control the device registration order,
> eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
> irrespective of whether SD card is mount or not on mmc1 card slot.
> So that bootargs would not have to be modified when filesystem is on eMMC.

I don't know if we can, but even if we could, we take care of the same
bootargs working on two boards (say sdp and panda) *if* on sdp I have my
filesystem on eMMC and on panda I have it on external card.
What happens if I want to use my filesystem on both boards on external
card?

>
>> +
>> +               mmc3: mmc at 3 {
>> +                       compatible = "ti,omap4-hsmmc";
>> +                       ti,hwmods = "mmc3";
>> +               };
>> +
>> +               mmc4: mmc at 4 {
>> +                       compatible = "ti,omap4-hsmmc";
>> +                       ti,hwmods = "mmc4";
>> +               };
>> +
>> +               mmc5: mmc at 5 {
>> +                       compatible = "ti,omap4-hsmmc";
>> +                       ti,hwmods = "mmc5";
>> +               };
>>         };
>>   };
>> --
>> 1.7.1
>>

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

[Russell King - ARM Linux]

On Fri, Feb 24, 2012 at 03:56:52PM +0530, Rajendra Nayak wrote:
> I don't know if we can, but even if we could, we take care of the same
> bootargs working on two boards (say sdp and panda) *if* on sdp I have my
> filesystem on eMMC and on panda I have it on external card.
> What happens if I want to use my filesystem on both boards on external
> card?

This is why the bootargs should be part of the information the boot
loader passes to the kernel, and not part of the kernel configuration
or DT.

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

[T Krishnamoorthy, Balaji]

On Fri, Feb 24, 2012 at 3:56 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:
>>>
>>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
>>> index 29f4589..9204f60 100644
>>> --- a/arch/arm/boot/dts/omap4.dtsi
>>> +++ b/arch/arm/boot/dts/omap4.dtsi
>>> @@ -25,6 +25,11 @@
>>> ? ? ? ? ? ? ? ?serial1 =&uart2;
>>> ? ? ? ? ? ? ? ?serial2 =&uart3;
>>> ? ? ? ? ? ? ? ?serial3 =&uart4;
>>> + ? ? ? ? ? ? ? mmc1 =&mmc1;
>>> + ? ? ? ? ? ? ? mmc2 =&mmc2;
>>> + ? ? ? ? ? ? ? mmc3 =&mmc3;
>>> + ? ? ? ? ? ? ? mmc4 =&mmc4;
>>> + ? ? ? ? ? ? ? mmc5 =&mmc5;
>>> ? ? ? ?};
>>>
>>> ? ? ? ?cpus {
>>> @@ -155,5 +160,31 @@
>>> ? ? ? ? ? ? ? ? ? ? ? ?#size-cells =<0>;
>>> ? ? ? ? ? ? ? ? ? ? ? ?ti,hwmods = "i2c4";
>>> ? ? ? ? ? ? ? ?};
>>> +
>>> + ? ? ? ? ? ? ? mmc1: mmc at 1 {
>>> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
>>> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc1";
>>> + ? ? ? ? ? ? ? ? ? ? ? ti,dual-volt;
>>> + ? ? ? ? ? ? ? };
>>> +
>>> + ? ? ? ? ? ? ? mmc2: mmc at 2 {
>>> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
>>> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc2";
>>> + ? ? ? ? ? ? ? };
>>
>>
>> Hi Rajendra,
>> Is there a way to control the device registration order,
>> eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
>> irrespective of whether SD card is mount or not on mmc1 card slot.
>> So that bootargs would not have to be modified when filesystem is on eMMC.
>
>
> I don't know if we can, but even if we could, we take care of the same
> bootargs working on two boards (say sdp and panda) *if* on sdp I have my
> filesystem on eMMC and on panda I have it on external card.
> What happens if I want to use my filesystem on both boards on external
> card?

While booting if SD card is present in the card slot, SD is detected
as /dev/mmcblk0
and eMMC as /dev/mmcblk1
If SD card is not present, then eMMC is detected as /dev/mmcblk0
When filesystem is in eMMC then bootargs has to switch between mmcblk0
or mmcblk1
depending on whether SD is present or not.

By changing the device order, eMMC will always be mmcblk0 independent
of SD card status.

>
>
>>
>>> +
>>> + ? ? ? ? ? ? ? mmc3: mmc at 3 {
>>> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
>>> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc3";
>>> + ? ? ? ? ? ? ? };
>>> +
>>> + ? ? ? ? ? ? ? mmc4: mmc at 4 {
>>> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
>>> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc4";
>>> + ? ? ? ? ? ? ? };
>>> +
>>> + ? ? ? ? ? ? ? mmc5: mmc at 5 {
>>> + ? ? ? ? ? ? ? ? ? ? ? compatible = "ti,omap4-hsmmc";
>>> + ? ? ? ? ? ? ? ? ? ? ? ti,hwmods = "mmc5";
>>> + ? ? ? ? ? ? ? };
>>> ? ? ? ?};
>>> ?};
>>> --
>>> 1.7.1
>>>
>

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

[Grant Likely]

On Fri, 24 Feb 2012 15:56:52 +0530, Rajendra Nayak <rnayak@ti.com> wrote:
> On Friday 24 February 2012 03:46 PM, T Krishnamoorthy, Balaji wrote:
> >> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> >> index 29f4589..9204f60 100644
> >> --- a/arch/arm/boot/dts/omap4.dtsi
> >> +++ b/arch/arm/boot/dts/omap4.dtsi
> >> @@ -25,6 +25,11 @@
> >>                 serial1 =&uart2;
> >>                 serial2 =&uart3;
> >>                 serial3 =&uart4;
> >> +               mmc1 =&mmc1;
> >> +               mmc2 =&mmc2;
> >> +               mmc3 =&mmc3;
> >> +               mmc4 =&mmc4;
> >> +               mmc5 =&mmc5;
> >>         };
> >>
> >>         cpus {
> >> @@ -155,5 +160,31 @@
> >>                         #size-cells =<0>;
> >>                         ti,hwmods = "i2c4";
> >>                 };
> >> +
> >> +               mmc1: mmc at 1 {
> >> +                       compatible = "ti,omap4-hsmmc";
> >> +                       ti,hwmods = "mmc1";
> >> +                       ti,dual-volt;
> >> +               };
> >> +
> >> +               mmc2: mmc at 2 {
> >> +                       compatible = "ti,omap4-hsmmc";
> >> +                       ti,hwmods = "mmc2";
> >> +               };
> >
> > Hi Rajendra,
> > Is there a way to control the device registration order,
> > eMMC connected to mmc2 needs to be registered as /dev/mmcblk0p ...
> > irrespective of whether SD card is mount or not on mmc1 card slot.
> > So that bootargs would not have to be modified when filesystem is on eMMC.
> 
> I don't know if we can, but even if we could, we take care of the same
> bootargs working on two boards (say sdp and panda) *if* on sdp I have my
> filesystem on eMMC and on panda I have it on external card.
> What happens if I want to use my filesystem on both boards on external
> card?

of_alias_get_id() may be able to help you here.  It will extract the id
numbering from the /aliases node.  That is the safe way to do global
enumeration of devices in the device tree (instead of 'cell-index' which
is strongly discouraged)

g.

> 
> >
> >> +
> >> +               mmc3: mmc at 3 {
> >> +                       compatible = "ti,omap4-hsmmc";
> >> +                       ti,hwmods = "mmc3";
> >> +               };
> >> +
> >> +               mmc4: mmc at 4 {
> >> +                       compatible = "ti,omap4-hsmmc";
> >> +                       ti,hwmods = "mmc4";
> >> +               };
> >> +
> >> +               mmc5: mmc at 5 {
> >> +                       compatible = "ti,omap4-hsmmc";
> >> +                       ti,hwmods = "mmc5";
> >> +               };
> >>         };
> >>   };
> >> --
> >> 1.7.1
> >>
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[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 |    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 at 1 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc1";
+			ti,dual-volt;
+		};
+
+		mmc2: mmc at 2 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc2";
+		};
+
+		mmc3: mmc at 3 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc3";
+		};
+
+		mmc4: mmc at 4 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc4";
+		};
+
+		mmc5: mmc at 5 {
+			compatible = "ti,omap2-hsmmc";
+			ti,hwmods = "mmc5";
+		};
 	};
 };
-- 
1.7.1

[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 at 1 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc1";
> +			ti,dual-volt;
> +		};
> +
> +		mmc2: mmc at 2 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc2";
> +		};
> +
> +		mmc3: mmc at 3 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc3";
> +		};
> +
> +		mmc4: mmc at 4 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc4";
> +		};
> +
> +		mmc5: mmc at 5 {
> +			compatible = "ti,omap2-hsmmc";
> +			ti,hwmods = "mmc5";
> +		};
>  	};
>  };

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

Tony

[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 at 1 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc1";
>> +			ti,dual-volt;
>> +		};
>> +
>> +		mmc2: mmc at 2 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc2";
>> +		};
>> +
>> +		mmc3: mmc at 3 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc3";
>> +		};
>> +
>> +		mmc4: mmc at 4 {
>> +			compatible = "ti,omap2-hsmmc";
>> +			ti,hwmods = "mmc4";
>> +		};
>> +
>> +		mmc5: mmc at 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

[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 at 1 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc1";
>>> + ti,dual-volt;
>>> + };
>>> +
>>> + mmc2: mmc at 2 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc2";
>>> + };
>>> +
>>> + mmc3: mmc at 3 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc3";
>>> + };
>>> +
>>> + mmc4: mmc at 4 {
>>> + compatible = "ti,omap2-hsmmc";
>>> + ti,hwmods = "mmc4";
>>> + };
>>> +
>>> + mmc5: mmc at 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

[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 at 1 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc1";
> >>+			ti,dual-volt;
> >>+		};
> >>+
> >>+		mmc2: mmc at 2 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc2";
> >>+		};
> >>+
> >>+		mmc3: mmc at 3 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc3";
> >>+		};
> >>+
> >>+		mmc4: mmc at 4 {
> >>+			compatible = "ti,omap2-hsmmc";
> >>+			ti,hwmods = "mmc4";
> >>+		};
> >>+
> >>+		mmc5: mmc at 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

[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 at 1 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc1";
> > >>+			ti,dual-volt;
> > >>+		};
> > >>+
> > >>+		mmc2: mmc at 2 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc2";
> > >>+		};
> > >>+
> > >>+		mmc3: mmc at 3 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc3";
> > >>+		};
> > >>+
> > >>+		mmc4: mmc at 4 {
> > >>+			compatible = "ti,omap2-hsmmc";
> > >>+			ti,hwmods = "mmc4";
> > >>+		};
> > >>+
> > >>+		mmc5: mmc at 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.

[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

[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 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 at 1 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc1";
>>>>> +			ti,dual-volt;
>>>>> +		};
>>>>> +
>>>>> +		mmc2: mmc at 2 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc2";
>>>>> +		};
>>>>> +
>>>>> +		mmc3: mmc at 3 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc3";
>>>>> +		};
>>>>> +
>>>>> +		mmc4: mmc at 4 {
>>>>> +			compatible = "ti,omap2-hsmmc";
>>>>> +			ti,hwmods = "mmc4";
>>>>> +		};
>>>>> +
>>>>> +		mmc5: mmc at 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.

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

[Rajendra Nayak]

On Thursday 23 February 2012 05:31 PM, Rajendra Nayak wrote:
> This series adds device tree support for OMAP hsmmc
> driver. The series is dependent on a couple other series,
> to add TWL regulator DT support[1] and another to clean
> the pdev->id usage within the hsmmc driver[2]
>
> all patches including the dependent series can be
> found here
> git://gitorious.org/omap-pm/linux.git for-dt/regulator

sorry, the right branch is for-dt/mmc

>
> 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.
>
> [1] http://marc.info/?l=linux-omap&m=132999699905180&w=2
> [2] http://marc.info/?l=linux-omap&m=132999646604985&w=2
>
> 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      |   31 +++++++
>   arch/arm/boot/dts/omap3-beagle.dts                 |    6 ++
>   arch/arm/boot/dts/omap3.dtsi                       |   26 ++++++
>   arch/arm/boot/dts/omap4-panda.dts                  |   10 +++
>   arch/arm/boot/dts/omap4-sdp.dts                    |   16 ++++
>   arch/arm/boot/dts/omap4.dtsi                       |   31 +++++++
>   drivers/mmc/host/omap_hsmmc.c                      |   83 +++++++++++++++++++-
>   7 files changed, 202 insertions(+), 1 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>

[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 0/4] omap hsmmc device tree support

[T Krishnamoorthy, Balaji]

On Mon, Mar 12, 2012 at 8:32 PM, Rajendra Nayak <rnayak@ti.com> 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@ti.com>

>
> 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 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@laptop.org>   <http://printf.net/>
One Laptop Per Child