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
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@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), }, };
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@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;
- };
On Friday 24 February 2012 05:02 PM, T Krishnamoorthy, Balaji wrote:
On Thu, Feb 23, 2012 at 5:31 PM, Rajendra Nayakrnayak@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 Nayakrnayak@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@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;};
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 Nayakrnayak@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 Nayakrnayak@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@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@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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 Nayakrnayak@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 Nayakrnayak@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@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@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
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 Nayakrnayak@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
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 Nayakrnayak@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
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 Nayakrnayak@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@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),
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 Nayakrnayak@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@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), },
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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi Grant,
On Friday 09 March 2012 11:12 AM, Grant Likely wrote:
On Thu, 23 Feb 2012 17:31:27 +0530, Rajendra Nayakrnayak@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 Nayakrnayak@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@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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
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@1 { + compatible = "ti,omap4-hsmmc"; + ti,hwmods = "mmc1"; + ti,dual-volt; + }; + + mmc2: mmc@2 { + compatible = "ti,omap4-hsmmc"; + ti,hwmods = "mmc2"; + }; + + mmc3: mmc@3 { + compatible = "ti,omap4-hsmmc"; + ti,hwmods = "mmc3"; + }; + + mmc4: mmc@4 { + compatible = "ti,omap4-hsmmc"; + ti,hwmods = "mmc4"; + }; + + mmc5: mmc@5 { + compatible = "ti,omap4-hsmmc"; + ti,hwmods = "mmc5"; + }; }; };
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@1 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc1";
- ti,dual-volt;
- };
- mmc2: mmc@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@3 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc3";
- };
- mmc4: mmc@4 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc4";
- };
- mmc5: mmc@5 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc5";
- };
}; }; -- 1.7.1
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@1 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc1";ti,dual-volt;};mmc2: mmc@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@3 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc3";};mmc4: mmc@4 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc4";};mmc5: mmc@5 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc5";}; };-- 1.7.1
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.
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@1 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc1";
- ti,dual-volt;
- };
- mmc2: mmc@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@3 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc3";
- };
- mmc4: mmc@4 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc4";
- };
- mmc5: mmc@5 {
- compatible = "ti,omap4-hsmmc";
- ti,hwmods = "mmc5";
- };
}; }; -- 1.7.1
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@1 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc1";ti,dual-volt;};mmc2: mmc@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@3 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc3";};mmc4: mmc@4 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc4";};mmc5: mmc@5 {compatible = "ti,omap4-hsmmc";ti,hwmods = "mmc5";}; };-- 1.7.1
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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@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"; + }; }; };
--- 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
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
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
* 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
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.
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
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
On Friday 09 March 2012 11:16 AM, Grant Likely wrote:
On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgrentony@atomide.com wrote:
- Rajendra Nayakrnayak@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.
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
-
Cousson, Benoit -
Grant Likely -
Paul Walmsley -
Rajendra Nayak -
Rob Herring -
Russell King - ARM Linux -
T Krishnamoorthy, Balaji -
Tony Lindgren