Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
* Rajendra Nayak [14 19:40]:
> On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
> >* Rajendra Nayak [04 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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
On Tuesday 15 November 2011 03:00 AM, Tony Lindgren wrote:
* Rajendra Nayak [04 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-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
* Rajendra Nayak [04 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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
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 --- .../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 000..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", "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", "ti,omap4-hsmmc"; +n is controller instance starting 0, for OMAP4 controllers +- ti,hwmods: Must be "mmc", 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: 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
On Saturday 05 November 2011 02:55 AM, Cousson, Benoit wrote:
+Required properties:
+- compatible: Should be "ti,omap-hsmmc", "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.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
+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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
On Fri, Nov 4, 2011 at 2:25 PM, Cousson, Benoit 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 >>> --- >>> .../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 000..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", "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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
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
---
.../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 000..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", "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", "ti,omap4-hsmmc";
+n is controller instance starting 0, for OMAP4 controllers
+- ti,hwmods: Must be "mmc", 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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
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 > --- > .../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 000..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", "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", "ti,omap4-hsmmc"; > +n is controller instance starting 0, for OMAP4 controllers > +- ti,hwmods: Must be "mmc", 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: 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] mmc: omap: adapt the hsmmc driver to device tree
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
---
.../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 000..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", "ti,omap2-hsmmc";
+n is controller instance starting 0, for OMAP2/3 controllers
+- compatible: Should be "ti,omap-hsmmc", "ti,omap4-hsmmc";
+n is controller instance starting 0, for OMAP4 controllers
+- ti,hwmods: Must be "mmc", 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: 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
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -117,6 +120,7 @@
#define OMAP_MMC3_DEVID2
#define OMAP_MMC4_DEVID3
#define OMAP_MMC5_DEVID4
+#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);
