* [PATCH 1/4] mmc: Add additional binding for mmc host controller
2011-11-04 11:50 [PATCH 0/4] omap hsmmc device tree support Rajendra Nayak
@ 2011-11-04 11:50 ` Rajendra Nayak
2011-11-04 19:58 ` Olof Johansson
2011-11-04 11:50 ` [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree Rajendra Nayak
` (2 subsequent siblings)
3 siblings, 1 reply; 15+ messages in thread
From: Rajendra Nayak @ 2011-11-04 11:50 UTC (permalink / raw)
To: linux-mmc, devicetree-discuss
Cc: linux-omap, linux-arm-kernel, grant.likely, rob.herring,
thomas.abraham, balajitk, cjb, tony, Rajendra Nayak
Add mmc host controller capability binding to support
'MMC_CAP_POWER_OFF_CARD' powering off of the card after boot.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../devicetree/bindings/mmc/linux-mmc-host.txt | 1 +
drivers/mmc/core/host.c | 2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
index 714b2b1..cf893ed 100644
--- a/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
+++ b/Documentation/devicetree/bindings/mmc/linux-mmc-host.txt
@@ -11,3 +11,4 @@ specific mmc host controller capabilities.
- linux,mmc_cap_disable - Host can be disabled and re-enabled to save power
- linux,mmc_cap_nonremovable - Host is connected to nonremovable media
- linux,mmc_cap_erase - Host allows erase/trim commands
+- linux,mmc_cap_power_off_card - Host can power off the card after boot
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 4ee2e43..822337a 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -413,6 +413,8 @@ void mmc_of_parse_host_caps(struct device_node *np, unsigned long *caps)
*caps |= MMC_CAP_NONREMOVABLE;
if (of_find_property(np, "linux,mmc_cap_erase", NULL))
*caps |= MMC_CAP_ERASE;
+ if (of_find_property(np, "linux,mmc_cap_power_off_card", NULL))
+ *caps |= MMC_CAP_POWER_OFF_CARD;
}
EXPORT_SYMBOL(mmc_of_parse_host_caps);
#endif /* CONFIG_OF */
--
1.7.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 1/4] mmc: Add additional binding for mmc host controller
2011-11-04 11:50 ` [PATCH 1/4] mmc: Add additional binding for mmc host controller Rajendra Nayak
@ 2011-11-04 19:58 ` Olof Johansson
0 siblings, 0 replies; 15+ messages in thread
From: Olof Johansson @ 2011-11-04 19:58 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linux-mmc, devicetree-discuss, linux-omap, linux-arm-kernel,
grant.likely, rob.herring, thomas.abraham, balajitk, cjb, tony
On Fri, Nov 04, 2011 at 05:20:38PM +0530, Rajendra Nayak wrote:
> Add mmc host controller capability binding to support
> 'MMC_CAP_POWER_OFF_CARD' powering off of the card after boot.
This adds a new undocumented property (also, see comments on Thomas Abraham's
patch for more comments on that approach and why it's the wrong thing to do).
This needs to be handled differently.
-Olof
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 11:50 [PATCH 0/4] omap hsmmc device tree support Rajendra Nayak
2011-11-04 11:50 ` [PATCH 1/4] mmc: Add additional binding for mmc host controller Rajendra Nayak
@ 2011-11-04 11:50 ` Rajendra Nayak
2011-11-04 20:04 ` Olof Johansson
2011-11-14 21:30 ` Tony Lindgren
2011-11-04 11:50 ` [PATCH 3/4] omap4: mmc: Pass SoC and board data for omap4 mmc from dt Rajendra Nayak
2011-11-04 11:50 ` [PATCH 4/4] omap4: mmc: use auxdata to pass platform function ptrs Rajendra Nayak
3 siblings, 2 replies; 15+ messages in thread
From: Rajendra Nayak @ 2011-11-04 11:50 UTC (permalink / raw)
To: linux-mmc, devicetree-discuss
Cc: linux-omap, linux-arm-kernel, grant.likely, rob.herring,
thomas.abraham, balajitk, cjb, tony, Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree node.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++
drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++
2 files changed, 167 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 0000000..370af1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,50 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
+n is controller instance starting 0, for OMAP2/3 controllers
+- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
+n is controller instance starting 0, for OMAP4 controllers
+- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards
+ti,hsmmc-nr-slots: Number of mmc slots
+<supply-name>-supply: phandle to the regulator device tree node
+"supply-name" examples are "vmmc", "vmmc_aux" etc
+ti,hsmmc-has-pbias: Has PBIAS cell support
+ti,hsmmc-has-special-reset: Requires a special softreset sequence
+
+For every supported slot a slot node can be defined
+with the following optional properties
+
+ti,hsmmc-slot-name: Name assocaited to the mmc slot
+ti,hsmmc-gpio-cd: gpio for card detect
+ti,hsmmc-gpio-wp: gpio for write protect
+ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask
+ti,hsmmc-non-removable: non-removable slot (like eMMC)
+
+One or more of the linux specific mmc host bindings can also be used.
+See Documentation/devicetree/bindings/mmc/linux-mmc-host.txt for all the
+linux mmc host controller specific bindings.
+
+Example:
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap-hsmmc0", "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,hsmmc-supports-dual-volt;
+ ti,hsmmc-nr-slots = <1>;
+ vmmc-supply = <&vmmc>; /* phandle to regulator node */
+ slot@1 {
+ ti,hsmmc-slot-name = "wlan";
+ linux,mmc_cap_4_bit_data;
+ linux,mmc_cap_power_off_card;
+ ti,hsmmc-ocr-mask = <0x80>;
+ ti,hsmmc-nonremovable;
+ };
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..90b4a61 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -27,6 +27,9 @@
#include <linux/workqueue.h>
#include <linux/timer.h>
#include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/of_device.h>
#include <linux/mmc/host.h>
#include <linux/mmc/core.h>
#include <linux/mmc/mmc.h>
@@ -117,6 +120,7 @@
#define OMAP_MMC3_DEVID 2
#define OMAP_MMC4_DEVID 3
#define OMAP_MMC5_DEVID 4
+#define OMAP_MMC_DEV_MAX 5
#define MMC_AUTOSUSPEND_DELAY 100
#define MMC_TIMEOUT_MS 20
@@ -1862,6 +1866,90 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
#endif
+#ifdef CONFIG_OF
+static unsigned int of_get_hsmmc_instance(struct device_node *np)
+{
+ int i;
+ char comp[32];
+
+ for (; i < OMAP_MMC_DEV_MAX; i++) {
+ snprintf(comp, 32, "ti,omap-hsmmc%d", i);
+ if (of_device_is_compatible(np, comp))
+ break;
+ }
+ return i;
+}
+
+static void of_get_hsmmc_slot_data(struct device_node *np,
+ struct omap_mmc_platform_data **pdata)
+{
+ struct device_node *child;
+ int i = 0;
+ unsigned long *caps;
+
+ for_each_child_of_node(np, child) {
+ (*pdata)->slots[i].switch_pin =
+ of_get_named_gpio(child, "ti,hsmmc-gpio-cd", 0);
+ (*pdata)->slots[i].gpio_wp =
+ of_get_named_gpio(child, "ti,hsmmc-gpio-wp", 0);
+ (*pdata)->slots[i].name = of_get_property(child,
+ "ti,hsmmc-slot-name", NULL);
+ if (of_find_property(child, "ti,hsmmc-nonremovable", NULL))
+ (*pdata)->slots[i].nonremovable = true;
+ if (of_find_property(child, "ti,hsmmc-has-pbias", NULL))
+ (*pdata)->slots[i].features |= HSMMC_HAS_PBIAS;
+ if (of_find_property(child, "ti,hsmmc-has-special-reset", NULL))
+ (*pdata)->slots[i].features |= HSMMC_HAS_UPDATED_RESET;
+ of_property_read_u32(child, "ti,hsmmc-ocr-mask",
+ &(*pdata)->slots[i].ocr_mask);
+ caps = (unsigned long *)&(*pdata)->slots[i].caps;
+ mmc_of_parse_host_caps(child, caps);
+ i++;
+ }
+}
+
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
+{
+ struct omap_mmc_platform_data *pdata;
+ const __be32 *nr_slots;
+ const __be64 *dma_mask;
+ struct device_node *np = dev->of_node;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL; /* out of memory */
+
+ nr_slots = of_get_property(np, "ti,hsmmc-nr-slots", NULL);
+ if (nr_slots) {
+ pdata->nr_slots = be32_to_cpu(*nr_slots);
+ of_get_hsmmc_slot_data(np, &pdata);
+ }
+
+ dma_mask = of_get_property(np, "ti,hsmmc-dma-mask", NULL);
+ if (dma_mask)
+ pdata->dma_mask = be64_to_cpu(*dma_mask);
+ if (of_find_property(np, "ti,hsmmc-supports-dual-volt", NULL))
+ pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+ return pdata;
+}
+#else
+static inline void of_get_hsmmc_slot_data(struct device_node *np,
+ struct omap_mmc_platform_data **pdata)
+{}
+static inline struct omap_mmc_platform_data
+ *of_get_hsmmc_pdata(struct device *dev)
+{
+ return NULL;
+}
+static inline unsigned int of_get_hsmmc_instance(struct device_node *np)
+{
+ return -1;
+}
+#endif
+
+static const struct of_device_id omap_mmc_of_match[];
+
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_mmc_of_match, &pdev->dev);
+ if (match) {
+ pdata = of_get_hsmmc_pdata(&pdev->dev);
+ if (match->data)
+ pdata->reg_offset = *(u16 *)match->data;
+ }
if (pdata == NULL) {
dev_err(&pdev->dev, "Platform Data is missing\n");
@@ -1910,6 +2006,8 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
host->dma_ch = -1;
host->irq = irq;
host->id = pdev->id;
+ if (pdev->dev.of_node)
+ host->id = of_get_hsmmc_instance(pdev->dev.of_node);
host->slot_id = 0;
host->mapbase = res->start;
host->base = ioremap(host->mapbase, SZ_4K);
@@ -2269,12 +2367,31 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.runtime_resume = omap_hsmmc_runtime_resume,
};
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
+ {
+ .compatible = "ti,omap2-hsmmc",
+ },
+ {
+ .compatible = "ti,omap4-hsmmc",
+ .data = &omap4_reg_offset,
+ },
+ {},
+}
+MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
+#else
+#define omap_mmc_of_match NULL
+#endif
+
static struct platform_driver omap_hsmmc_driver = {
.remove = omap_hsmmc_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
.pm = &omap_hsmmc_dev_pm_ops,
+ .of_match_table = omap_mmc_of_match,
},
};
--
1.7.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 11:50 ` [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree Rajendra Nayak
@ 2011-11-04 20:04 ` Olof Johansson
2011-11-04 21:25 ` Cousson, Benoit
` (2 more replies)
2011-11-14 21:30 ` Tony Lindgren
1 sibling, 3 replies; 15+ messages in thread
From: Olof Johansson @ 2011-11-04 20:04 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linux-mmc, devicetree-discuss, linux-omap, linux-arm-kernel,
grant.likely, rob.herring, thomas.abraham, balajitk, cjb, tony
On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
> Define dt bindings for the ti-omap-hsmmc, and adapt
> the driver to extract data (which was earlier passed as
> platform_data) from device tree node.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++
> drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++
> 2 files changed, 167 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> new file mode 100644
> index 0000000..370af1b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -0,0 +1,50 @@
> +* TI Highspeed MMC host controller for OMAP
> +
> +The Highspeed MMC Host Controller on TI OMAP family
> +provides an interface for MMC, SD, and SDIO types of memory cards.
> +
> +Required properties:
> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
> +n is controller instance starting 0, for OMAP2/3 controllers
No, no, no. You should not have to specify the unit-address in the compatible
field. They are all programmed the same way, right?
Also, they should go from the specific to the generic, but the first property
is the same for 2/3 and 4. That's wrong.
> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
> +n is controller instance starting 0, for OMAP4 controllers
> +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
I didn't think hwmod bindings were settled on yet?
> +- reg : should contain hsmmc registers location and length
> +
> +Optional properties:
> +ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards
ti,dual-voltage is a better name here (by definition, if it has the property it
supports it, the word "supports" is redundant).
> +ti,hsmmc-nr-slots: Number of mmc slots
You shouldn't have to specify this, it can be derived from the number of child
nodes.
> +<supply-name>-supply: phandle to the regulator device tree node
> +"supply-name" examples are "vmmc", "vmmc_aux" etc
> +ti,hsmmc-has-pbias: Has PBIAS cell support
> +ti,hsmmc-has-special-reset: Requires a special softreset sequence
you can drop hsmmc- from the properties here
> +
> +For every supported slot a slot node can be defined
> +with the following optional properties
> +
> +ti,hsmmc-slot-name: Name assocaited to the mmc slot
> +ti,hsmmc-gpio-cd: gpio for card detect
> +ti,hsmmc-gpio-wp: gpio for write protect
Please use the same standard as the other mmc controllers for CD/WP.
> +ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask
What is OCR mask?
> +ti,hsmmc-non-removable: non-removable slot (like eMMC)
Same here, non-removable should be standardized.
-Olof
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 20:04 ` Olof Johansson
@ 2011-11-04 21:25 ` Cousson, Benoit
2011-11-04 21:28 ` Olof Johansson
2011-11-07 6:14 ` Rajendra Nayak
2011-11-04 22:15 ` Segher Boessenkool
2011-11-07 6:18 ` Rajendra Nayak
2 siblings, 2 replies; 15+ messages in thread
From: Cousson, Benoit @ 2011-11-04 21:25 UTC (permalink / raw)
To: Olof Johansson
Cc: Rajendra Nayak, cjb, balajitk, tony, devicetree-discuss,
linux-mmc, rob.herring, linux-omap, linux-arm-kernel
Hi Olof,
On 11/4/2011 9:04 PM, Olof Johansson wrote:
> On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
>> Define dt bindings for the ti-omap-hsmmc, and adapt
>> the driver to extract data (which was earlier passed as
>> platform_data) from device tree node.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++
>> drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++
>> 2 files changed, 167 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> new file mode 100644
>> index 0000000..370af1b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -0,0 +1,50 @@
>> +* TI Highspeed MMC host controller for OMAP
>> +
>> +The Highspeed MMC Host Controller on TI OMAP family
>> +provides an interface for MMC, SD, and SDIO types of memory cards.
>> +
>> +Required properties:
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>> +n is controller instance starting 0, for OMAP2/3 controllers
>
> No, no, no. You should not have to specify the unit-address in the compatible
> field. They are all programmed the same way, right?
AFAIR, 2 instances contain a DMA engine, but that should anyway be
detected using a "ti,had-dma-engine" extra property and not like that.
Checking the code in #2, it is used to get the instance of the MMC.
+static unsigned int of_get_hsmmc_instance(struct device_node *np)
+{
+ int i;
+ char comp[32];
+
+ for (; i < OMAP_MMC_DEV_MAX; i++) {
+ snprintf(comp, 32, "ti,omap-hsmmc%d", i);
+ if (of_device_is_compatible(np, comp))
+ break;
+ }
+ return i;
+}
Which does not seems to be a good usage of the compatible property anyway.
For a similar issue someone on the list suggested using the "cell-index"
property. But the definition I found in some binding documentation seems
to reserve that to: "enumerate logical devices within an IP core."
Ideally the driver should probably get rid of the need for an index.
I didn't check the original driver, but that should be needed for some
legacy reason.
> Also, they should go from the specific to the generic, but the first property
> is the same for 2/3 and 4. That's wrong.
>
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
>> +n is controller instance starting 0, for OMAP4 controllers
>> +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
>
> I didn't think hwmod bindings were settled on yet?
Why did you think that?
That binding was pretty straightforward and mandatory for starting any
OMAP device tree migration until we have the proper reg-names, irq-names
and dma-names generic binding.
Did you had any concern with that binding?
Regards,
Benoit
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 21:25 ` Cousson, Benoit
@ 2011-11-04 21:28 ` Olof Johansson
2011-11-07 6:14 ` Rajendra Nayak
1 sibling, 0 replies; 15+ messages in thread
From: Olof Johansson @ 2011-11-04 21:28 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Rajendra Nayak, cjb, balajitk, tony, devicetree-discuss,
linux-mmc, rob.herring, linux-omap, linux-arm-kernel
On Fri, Nov 4, 2011 at 2:25 PM, Cousson, Benoit <b-cousson@ti.com> wrote:
> Hi Olof,
>
> On 11/4/2011 9:04 PM, Olof Johansson wrote:
>>
>> On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
>>>
>>> Define dt bindings for the ti-omap-hsmmc, and adapt
>>> the driver to extract data (which was earlier passed as
>>> platform_data) from device tree node.
>>>
>>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>>> ---
>>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++
>>> drivers/mmc/host/omap_hsmmc.c | 117
>>> ++++++++++++++++++++
>>> 2 files changed, 167 insertions(+), 0 deletions(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> new file mode 100644
>>> index 0000000..370af1b
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>> @@ -0,0 +1,50 @@
>>> +* TI Highspeed MMC host controller for OMAP
>>> +
>>> +The Highspeed MMC Host Controller on TI OMAP family
>>> +provides an interface for MMC, SD, and SDIO types of memory cards.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>>> +n is controller instance starting 0, for OMAP2/3 controllers
>>
>> No, no, no. You should not have to specify the unit-address in the
>> compatible
>> field. They are all programmed the same way, right?
>
> AFAIR, 2 instances contain a DMA engine, but that should anyway be detected
> using a "ti,had-dma-engine" extra property and not like that.
Yep, it should be described by properties instead, such that future
products won't need new bindings unless they add new hardware features
(i.e. just new combinations of existing features should just work,
more or less).
>> I didn't think hwmod bindings were settled on yet?
>
> Why did you think that?
>
> That binding was pretty straightforward and mandatory for starting any OMAP
> device tree migration until we have the proper reg-names, irq-names and
> dma-names generic binding.
>
> Did you had any concern with that binding?
Nope, just wasn't sure if it had settled down since I hadn't followed
it closely. No concerns.
-Olof
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 21:25 ` Cousson, Benoit
2011-11-04 21:28 ` Olof Johansson
@ 2011-11-07 6:14 ` Rajendra Nayak
1 sibling, 0 replies; 15+ messages in thread
From: Rajendra Nayak @ 2011-11-07 6:14 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Olof Johansson, cjb, balajitk, tony, devicetree-discuss,
linux-mmc, rob.herring, linux-omap, linux-arm-kernel
On Saturday 05 November 2011 02:55 AM, Cousson, Benoit wrote:
>>> +Required properties:
>>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>>> +n is controller instance starting 0, for OMAP2/3 controllers
>>
>> No, no, no. You should not have to specify the unit-address in the
>> compatible
>> field. They are all programmed the same way, right?
>
> AFAIR, 2 instances contain a DMA engine, but that should anyway be
> detected using a "ti,had-dma-engine" extra property and not like that.
>
> Checking the code in #2, it is used to get the instance of the MMC.
>
> +static unsigned int of_get_hsmmc_instance(struct device_node *np)
> +{
> + int i;
> + char comp[32];
> +
> + for (; i < OMAP_MMC_DEV_MAX; i++) {
> + snprintf(comp, 32, "ti,omap-hsmmc%d", i);
> + if (of_device_is_compatible(np, comp))
> + break;
> + }
> + return i;
> +}
>
> Which does not seems to be a good usage of the compatible property anyway.
> For a similar issue someone on the list suggested using the "cell-index"
> property. But the definition I found in some binding documentation seems
> to reserve that to: "enumerate logical devices within an IP core."
> Ideally the driver should probably get rid of the need for an index.
> I didn't check the original driver, but that should be needed for some
> legacy reason.
yes, there are a bunch of things done inside the driver based on the
instance id which seem wrong, but I agree, encoding the instance
in the compatible property seems really bad and non-scalable.
Will look at how some of this legacy code in the driver can be
removed/cleaned up.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 20:04 ` Olof Johansson
2011-11-04 21:25 ` Cousson, Benoit
@ 2011-11-04 22:15 ` Segher Boessenkool
2011-11-07 6:18 ` Rajendra Nayak
2 siblings, 0 replies; 15+ messages in thread
From: Segher Boessenkool @ 2011-11-04 22:15 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-omap, balajitk, tony, devicetree-discuss, Rajendra Nayak,
linux-mmc, rob.herring, cjb, linux-arm-kernel
>> +ti,hsmmc-non-removable: non-removable slot (like eMMC)
>
> Same here, non-removable should be standardized.
CHRP has a "built-in" property for this. That was standardised in 1998,
you could reuse it :-)
Segher
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 20:04 ` Olof Johansson
2011-11-04 21:25 ` Cousson, Benoit
2011-11-04 22:15 ` Segher Boessenkool
@ 2011-11-07 6:18 ` Rajendra Nayak
2 siblings, 0 replies; 15+ messages in thread
From: Rajendra Nayak @ 2011-11-07 6:18 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-mmc, devicetree-discuss, linux-omap, linux-arm-kernel,
grant.likely, rob.herring, thomas.abraham, balajitk, cjb, tony
On Saturday 05 November 2011 01:34 AM, Olof Johansson wrote:
> On Fri, Nov 04, 2011 at 05:20:39PM +0530, Rajendra Nayak wrote:
>> Define dt bindings for the ti-omap-hsmmc, and adapt
>> the driver to extract data (which was earlier passed as
>> platform_data) from device tree node.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 +++++++++
>> drivers/mmc/host/omap_hsmmc.c | 117 ++++++++++++++++++++
>> 2 files changed, 167 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> new file mode 100644
>> index 0000000..370af1b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -0,0 +1,50 @@
>> +* TI Highspeed MMC host controller for OMAP
>> +
>> +The Highspeed MMC Host Controller on TI OMAP family
>> +provides an interface for MMC, SD, and SDIO types of memory cards.
>> +
>> +Required properties:
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap2-hsmmc";
>> +n is controller instance starting 0, for OMAP2/3 controllers
>
> No, no, no. You should not have to specify the unit-address in the compatible
> field. They are all programmed the same way, right?
>
> Also, they should go from the specific to the generic, but the first property
> is the same for 2/3 and 4. That's wrong.
agreed, will get rid of instance number from the compatible property.
>
>> +- compatible: Should be "ti,omap-hsmmc<n>", "ti,omap4-hsmmc";
>> +n is controller instance starting 0, for OMAP4 controllers
>> +- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1
>
> I didn't think hwmod bindings were settled on yet?
>
>> +- reg : should contain hsmmc registers location and length
>> +
>> +Optional properties:
>> +ti,hsmmc-supports-dual-volt: boolean, supports dual voltage cards
>
> ti,dual-voltage is a better name here (by definition, if it has the property it
> supports it, the word "supports" is redundant).
Ok.
>
>> +ti,hsmmc-nr-slots: Number of mmc slots
>
> You shouldn't have to specify this, it can be derived from the number of child
> nodes.
right, will do that.
>
>> +<supply-name>-supply: phandle to the regulator device tree node
>> +"supply-name" examples are "vmmc", "vmmc_aux" etc
>> +ti,hsmmc-has-pbias: Has PBIAS cell support
>> +ti,hsmmc-has-special-reset: Requires a special softreset sequence
>
> you can drop hsmmc- from the properties here
Ok.
>
>> +
>> +For every supported slot a slot node can be defined
>> +with the following optional properties
>> +
>> +ti,hsmmc-slot-name: Name assocaited to the mmc slot
>> +ti,hsmmc-gpio-cd: gpio for card detect
>> +ti,hsmmc-gpio-wp: gpio for write protect
>
> Please use the same standard as the other mmc controllers for CD/WP.
Ok.
>
>> +ti,hsmmc-ocr-mask: mmc/sd/sdio ocr mask
>
> What is OCR mask?
Its used to derive the vdd range the card supports. I hadn't
looked at this closely, but looks like this isn't something that
needs to be told to the driver anyway, it can always just query the
card about the voltages it supports and derive the ocrmask internally.
One more of the hacks in the driver to be cleaned up. Will drop this
property completely.
>
>> +ti,hsmmc-non-removable: non-removable slot (like eMMC)
>
> Same here, non-removable should be standardized.
You mean there is already a binding available for this?
Thanks for the review.
regards,
Rajendra
>
>
> -Olof
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-04 11:50 ` [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree Rajendra Nayak
2011-11-04 20:04 ` Olof Johansson
@ 2011-11-14 21:30 ` Tony Lindgren
2011-11-15 4:15 ` Rajendra Nayak
1 sibling, 1 reply; 15+ messages in thread
From: Tony Lindgren @ 2011-11-14 21:30 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linux-mmc, devicetree-discuss, linux-omap, linux-arm-kernel,
grant.likely, rob.herring, thomas.abraham, balajitk, cjb
* Rajendra Nayak <rnayak@ti.com> [111104 04:16]:
> @@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
> struct omap_hsmmc_host *host = NULL;
> struct resource *res;
> int ret, irq;
> + const struct of_device_id *match;
> +
> + match = of_match_device(omap_mmc_of_match, &pdev->dev);
> + if (match) {
> + pdata = of_get_hsmmc_pdata(&pdev->dev);
> + if (match->data)
> + pdata->reg_offset = *(u16 *)match->data;
> + }
So this is now using both DT and pdata?
We want to use DT only, and get rid of pdata. Other than the
deferred probe, is there some other dependency remaining to
having to use the pdata also?
Regards,
Tony
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-14 21:30 ` Tony Lindgren
@ 2011-11-15 4:15 ` Rajendra Nayak
2011-11-19 0:21 ` Tony Lindgren
0 siblings, 1 reply; 15+ messages in thread
From: Rajendra Nayak @ 2011-11-15 4:15 UTC (permalink / raw)
To: Tony Lindgren
Cc: cjb, balajitk, devicetree-discuss, linux-mmc, rob.herring,
grant.likely, thomas.abraham, linux-omap, linux-arm-kernel
On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
> * Rajendra Nayak<rnayak@ti.com> [111104 04:16]:
>> @@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
>> struct omap_hsmmc_host *host = NULL;
>> struct resource *res;
>> int ret, irq;
>> + const struct of_device_id *match;
>> +
>> + match = of_match_device(omap_mmc_of_match,&pdev->dev);
>> + if (match) {
>> + pdata = of_get_hsmmc_pdata(&pdev->dev);
>> + if (match->data)
>> + pdata->reg_offset = *(u16 *)match->data;
>> + }
>
> So this is now using both DT and pdata?
>
> We want to use DT only, and get rid of pdata. Other than the
> deferred probe, is there some other dependency remaining to
> having to use the pdata also?
We are using pdata today mainly for the platform function pointers
that get passed for MMC, which can never be passed from DT.
The omap_mmc_platform_data structure today has '17' function pointers.
Most might be sparingly used, nevertheless, its an awfully large number.
Here's the list...
---------
int (*switch_slot)(struct device *dev, int slot);
int (*init)(struct device *dev);
void (*cleanup)(struct device *dev);
void (*shutdown)(struct device *dev);
int (*suspend)(struct device *dev, int slot);
int (*resume)(struct device *dev, int slot);
int (*get_context_loss_count)(struct device *dev);
per-slot functions
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
int power_on, int vdd);
int (*get_ro)(struct device *dev, int slot);
int (*set_sleep)(struct device *dev, int slot, int sleep,
int vdd, int cardsleep);
void (*remux)(struct device *dev, int slot, int power_on);
void (*before_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
void (*after_set_reg)(struct device *dev, int slot,
int power_on, int vdd);
void (*init_card)(struct mmc_card *card);
int (*get_cover_state)(struct device *dev, int slot);
int (*card_detect)(struct device *dev, int slot);
---------
regards,
Rajendra
> Regards,
>
> Tony
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
2011-11-15 4:15 ` Rajendra Nayak
@ 2011-11-19 0:21 ` Tony Lindgren
0 siblings, 0 replies; 15+ messages in thread
From: Tony Lindgren @ 2011-11-19 0:21 UTC (permalink / raw)
To: Rajendra Nayak
Cc: cjb, balajitk, devicetree-discuss, linux-mmc, rob.herring,
grant.likely, thomas.abraham, linux-omap, linux-arm-kernel
* Rajendra Nayak <rnayak@ti.com> [111114 19:40]:
> On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
> >* Rajendra Nayak<rnayak@ti.com> [111104 04:16]:
> >>@@ -1869,6 +1957,14 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
> >> struct omap_hsmmc_host *host = NULL;
> >> struct resource *res;
> >> int ret, irq;
> >>+ const struct of_device_id *match;
> >>+
> >>+ match = of_match_device(omap_mmc_of_match,&pdev->dev);
> >>+ if (match) {
> >>+ pdata = of_get_hsmmc_pdata(&pdev->dev);
> >>+ if (match->data)
> >>+ pdata->reg_offset = *(u16 *)match->data;
> >>+ }
> >
> >So this is now using both DT and pdata?
> >
> >We want to use DT only, and get rid of pdata. Other than the
> >deferred probe, is there some other dependency remaining to
> >having to use the pdata also?
>
> We are using pdata today mainly for the platform function pointers
> that get passed for MMC, which can never be passed from DT.
>
> The omap_mmc_platform_data structure today has '17' function pointers.
> Most might be sparingly used, nevertheless, its an awfully large number.
Yeah OK.
> Here's the list...
> ---------
> int (*switch_slot)(struct device *dev, int slot);
> int (*init)(struct device *dev);
> void (*cleanup)(struct device *dev);
> void (*shutdown)(struct device *dev);
> int (*suspend)(struct device *dev, int slot);
> int (*resume)(struct device *dev, int slot);
> int (*get_context_loss_count)(struct device *dev);
>
> per-slot functions
>
> int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
> int (*set_power)(struct device *dev, int slot,
> int power_on, int vdd);
> int (*get_ro)(struct device *dev, int slot);
> int (*set_sleep)(struct device *dev, int slot, int sleep,
> int vdd, int cardsleep);
> void (*remux)(struct device *dev, int slot, int power_on);
> void (*before_set_reg)(struct device *dev, int slot,
> int power_on, int vdd);
> void (*after_set_reg)(struct device *dev, int slot,
> int power_on, int vdd);
> void (*init_card)(struct mmc_card *card);
> int (*get_cover_state)(struct device *dev, int slot);
> int (*card_detect)(struct device *dev, int slot);
> ---------
To me it seems we should move these into drivers/mmc/host/omap_hsmmc.c
and set them based on DT compatible (or some other) property.
If these functions tinker with some internal registers, then we need
to fix those too to use regulator/gpio API.
This way we don't need the platform_data any longer.
Regards,
Tony
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 3/4] omap4: mmc: Pass SoC and board data for omap4 mmc from dt
2011-11-04 11:50 [PATCH 0/4] omap hsmmc device tree support Rajendra Nayak
2011-11-04 11:50 ` [PATCH 1/4] mmc: Add additional binding for mmc host controller Rajendra Nayak
2011-11-04 11:50 ` [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree Rajendra Nayak
@ 2011-11-04 11:50 ` Rajendra Nayak
2011-11-04 11:50 ` [PATCH 4/4] omap4: mmc: use auxdata to pass platform function ptrs Rajendra Nayak
3 siblings, 0 replies; 15+ messages in thread
From: Rajendra Nayak @ 2011-11-04 11:50 UTC (permalink / raw)
To: linux-mmc, devicetree-discuss
Cc: linux-omap, linux-arm-kernel, grant.likely, rob.herring,
thomas.abraham, balajitk, cjb, tony, Rajendra Nayak
Pass all omap4-hsmmc related data from device tree.
Currenly limited to only omap4-panda and omap4-sdp
boards.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/boot/dts/omap4-panda.dts | 23 ++++++++++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 33 ++++++++++++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 46 +++++++++++++++++++++++++++++++++++++
3 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 4c3069f..07c5433 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -105,3 +105,26 @@
&i2c4 {
clock-frequency = <400000>;
};
+
+&mmc1 {
+ ti,hsmmc-nr-slots = <1>;
+ vmmc-supply = <&vmmc>;
+ slot@1 {
+ linux,mmc_cap_4_bit_data;
+ linux,mmc_cap_8_bit_data;
+ ti,hsmmc-has-special-reset;
+ };
+};
+
+&mmc5 {
+ ti,hsmmc-nr-slots = <1>;
+ vmmc-supply = <&vwl1271>;
+ slot@1 {
+ ti,hsmmc-slot-name = "wl1271";
+ linux,mmc_cap_4_bit_data;
+ linux,mmc_cap_power_off_card;
+ ti,hsmmc-ocr-mask = <0x80>;
+ ti,hsmmc-nonremovable;
+ ti,hsmmc-has-special-reset;
+ };
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index adc7faf..d37d416 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -125,3 +125,36 @@
reg = <0x1e>;
};
};
+
+&mmc1 {
+ ti,hsmmc-nr-slots = <1>;
+ vmmc-supply = <&vmmc>;
+ slots@1 {
+ linux,mmc_cap_4_bit_data;
+ linux,mmc_cap_8_bit_data;
+ ti,hsmmc-has-special-reset;
+ };
+};
+
+&mmc2 {
+ ti,hsmmc-nr-slots = <1>;
+ vmmc-supply = <&vaux1>;
+ slots@1 {
+ linux,mmc_cap_4_bit_data;
+ linux,mmc_cap_8_bit_data;
+ ti,hsmmc-nonremovable;
+ ti,hsmmc-ocr-mask = <0x20000>;
+ ti,hsmmc-has-special-reset;
+ };
+};
+
+&mmc5 {
+ ti,hsmmc-nr-slots = <1>;
+ slots@1 {
+ linux,mmc_cap_4_bit_data;
+ linux,mmc_cap_power_off_card;
+ ti,hsmmc-nonremovable;
+ ti,hsmmc-ocr-mask = <0x80>;
+ ti,hsmmc-has-special-reset;
+ };
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 447f482..f4e0540 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -25,6 +25,11 @@
i2c2 = &i2c2;
i2c3 = &i2c3;
i2c4 = &i2c4;
+ mmc1 = &mmc1;
+ mmc2 = &mmc2;
+ mmc3 = &mmc3;
+ mmc4 = &mmc4;
+ mmc5 = &mmc5;
};
cpus {
@@ -205,5 +210,46 @@
#size-cells = <0>;
ti,hwmods = "i2c4";
};
+
+ mmc1: mmc@0x4809c000 {
+ compatible = "ti,omap-hsmmc0", "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ ti,hwmods = "mmc1";
+ ti,hsmmc-supports-dual-volt;
+ ti,hsmmc-dma-mask = <0xffffffff>;
+ ti,hsmmc-has-pbias;
+ };
+
+ mmc2: mmc@0x480b4000 {
+ compatible = "ti,omap-hsmmc1", "ti,omap4-hsmmc";
+ reg = <0x480b4000 0x400>;
+ ti,hwmods = "mmc2";
+ ti,hsmmc-dma-mask = <0xffffffff>;
+ ti,hsmmc-has-pbias;
+ };
+
+ mmc3: mmc@0x480ad000 {
+ compatible = "ti,omap-hsmmc2", "ti,omap4-hsmmc";
+ reg = <0x480ad000 0x400>;
+ ti,hwmods = "mmc3";
+ ti,hsmmc-dma-mask = <0xffffffff>;
+ ti,hsmmc-has-pbias;
+ };
+
+ mmc4: mmc@0x480d1000 {
+ compatible = "ti,omap-hsmmc3", "ti,omap4-hsmmc";
+ reg = <0x480d1000 0x400>;
+ ti,hwmods = "mmc4";
+ ti,hsmmc-dma-mask = <0xffffffff>;
+ ti,hsmmc-has-pbias;
+ };
+
+ mmc5: mmc@0x480d5000 {
+ compatible = "ti,omap-hsmmc4", "ti,omap4-hsmmc";
+ reg = <0x480d5000 0x400>;
+ ti,hwmods = "mmc5";
+ ti,hsmmc-dma-mask = <0xffffffff>;
+ ti,hsmmc-has-pbias;
+ };
};
};
--
1.7.1
^ permalink raw reply related [flat|nested] 15+ messages in thread* [PATCH 4/4] omap4: mmc: use auxdata to pass platform function ptrs
2011-11-04 11:50 [PATCH 0/4] omap hsmmc device tree support Rajendra Nayak
` (2 preceding siblings ...)
2011-11-04 11:50 ` [PATCH 3/4] omap4: mmc: Pass SoC and board data for omap4 mmc from dt Rajendra Nayak
@ 2011-11-04 11:50 ` Rajendra Nayak
3 siblings, 0 replies; 15+ messages in thread
From: Rajendra Nayak @ 2011-11-04 11:50 UTC (permalink / raw)
To: linux-mmc, devicetree-discuss
Cc: linux-omap, linux-arm-kernel, grant.likely, rob.herring,
thomas.abraham, balajitk, cjb, tony, Rajendra Nayak
mmc driver still relies on platform specific functions
being invoked from the driver by means of function pointers
being passed through platform_data structure.
use the auxdata for now to pass these the same way until
we find a way to get rid of these calls from the driver.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 19 +++++++++++++++++--
arch/arm/mach-omap2/hsmmc.c | 9 +++++----
arch/arm/mach-omap2/hsmmc.h | 5 +++++
drivers/mmc/host/omap_hsmmc.c | 8 ++++++++
4 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 62c6b2e..af2fdd9 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,14 +15,29 @@
#include <linux/io.h>
#include <linux/of_platform.h>
#include <linux/irqdomain.h>
+#include <linux/i2c/twl.h>
#include <mach/hardware.h>
#include <asm/mach/arch.h>
#include <plat/board.h>
#include <plat/common.h>
+#include <plat/mmc.h>
#include <mach/omap4-common.h>
+#include "hsmmc.h"
+
+struct omap_mmc_platform_data omap4_mmc1_pdata = {
+ .init = twl6030_mmc_card_detect_config,
+ .slots[0] = {
+ .before_set_reg = omap4_hsmmc1_before_set_reg,
+ .after_set_reg = omap4_hsmmc1_after_set_reg,
+ },
+};
+struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,omap-hsmmc0", 0x4809c000, "omap_hsmmc.0", &omap4_mmc1_pdata),
+ {}
+};
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = "simple-bus", },
@@ -44,8 +59,8 @@ static void __init omap_generic_init(void)
omap_serial_init();
omap_sdrc_init(NULL, NULL);
-
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ omap2_hsmmc_init(NULL);
+ of_platform_populate(NULL, omap_dt_match_table, omap_auxdata_lookup, NULL);
}
#if defined(CONFIG_SOC_OMAP2420)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 7708584..dc698be 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -120,7 +120,7 @@ static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
}
}
-static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
+void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg;
@@ -141,7 +141,7 @@ static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
-static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
+void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg;
@@ -495,8 +495,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
omap4_ctrl_pad_writel(reg, control_mmc1);
}
- for (; controllers->mmc; controllers++)
- omap_init_hsmmc(controllers, controllers->mmc);
+ if (controllers)
+ for (; controllers->mmc; controllers++)
+ omap_init_hsmmc(controllers, controllers->mmc);
}
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index f757e78..543ab4d 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -34,6 +34,11 @@ struct omap2_hsmmc_info {
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
void omap2_hsmmc_init(struct omap2_hsmmc_info *);
+extern void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
+ int power_on, int vdd);
+extern void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
+ int power_on, int vdd);
+
#else
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 90b4a61..5fb5a95 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1953,6 +1953,7 @@ static const struct of_device_id omap_mmc_of_match[];
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev->dev.platform_data;
+ struct omap_mmc_platform_data *aux_pdata = pdev->dev.platform_data;
struct mmc_host *mmc;
struct omap_hsmmc_host *host = NULL;
struct resource *res;
@@ -1964,6 +1965,13 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)
pdata = of_get_hsmmc_pdata(&pdev->dev);
if (match->data)
pdata->reg_offset = *(u16 *)match->data;
+ if (aux_pdata) {
+ pdata->init = aux_pdata->init;
+ pdata->slots[0].before_set_reg =
+ aux_pdata->slots[0].before_set_reg;
+ pdata->slots[0].after_set_reg =
+ aux_pdata->slots[0].after_set_reg;
+ }
}
if (pdata == NULL) {
--
1.7.1
^ permalink raw reply related [flat|nested] 15+ messages in thread