| Message ID | Pine.LNX.4.64.1301231743190.26301@axis700.grange (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Wed, Jan 23, 2013 at 04:45:11PM +0000, Guennadi Liakhovetski wrote: > Many MMC capability flags are platform-dependent and are traditionally set > in platform data. With DT often each such capability requires a special > binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED and > MMC_CAP_POWER_OFF_CARD capabilities. Also add code to DT parser to look > up "keep-power-in-suspend" and "enable-sdio-wakeup" bindings and set > MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ respectively, if found. > I've Cc'd Arnd, who had some related comments a while back: https://lkml.org/lkml/2012/10/15/231 MMC_CAP_POWER_OFF_CARD sounds like something that can be selected in the driver by checking the compatible string or probing the hardware revision, and not something that should be taken directly from the dts where it could be completely invalid for the hardware. > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > --- > > Attention: contains new DT bindings, please, comment! > > Documentation/devicetree/bindings/mmc/mmc.txt | 5 ++++- > drivers/mmc/core/host.c | 11 +++++++++++ > 2 files changed, 15 insertions(+), 1 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt > index e180892..92ec534c 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc.txt > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > @@ -25,8 +25,11 @@ Optional properties: > - max-frequency: maximum operating clock frequency > - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on > this system, even if the controller claims it is. > +- cap-sd-highspeed: SD high-speed timing is supported > +- cap-mmc-highspeed: MMC high-speed timing is supported > +- cap-power-off-card: powering off the card is safe > > -cd-inverted and wp-inverted properties are deprecated ans shouldn't be used, > +cd-inverted and wp-inverted properties are deprecated and shouldn't be used, > instead pleaseuse the OF_GPIO_ACTIVE_LOW flag in respective GPIO bindings. Note, > that the default (as defined by the SDHCI standard) CD and WP polarity is > active-low, so, OF_GPIO_ACTIVE_LOW should normally be set, and only be left > diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c > index e4c1cbd..f3ea268 100644 > --- a/drivers/mmc/core/host.c > +++ b/drivers/mmc/core/host.c > @@ -372,6 +372,17 @@ void mmc_of_parse(struct mmc_host *host) > dev_err(host->parent, > "Failed to request WP GPIO: %d!\n", ret); > } > + > + if (of_find_property(np, "cap-sd-highspeed", &len)) > + host->caps |= MMC_CAP_SD_HIGHSPEED; > + if (of_find_property(np, "cap-mmc-highspeed", &len)) > + host->caps |= MMC_CAP_MMC_HIGHSPEED; > + if (of_find_property(np, "cap-power-off-card", &len)) > + host->caps |= MMC_CAP_POWER_OFF_CARD; > + if (of_find_property(np, "keep-power-in-suspend", &len)) > + host->pm_caps |= MMC_PM_KEEP_POWER; > + if (of_find_property(np, "enable-sdio-wakeup", &len)) > + host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ; > } > > EXPORT_SYMBOL(mmc_of_parse); > -- > 1.7.2.5 > > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mark On Wed, 6 Feb 2013, Mark Rutland wrote: > Hi, > > On Wed, Jan 23, 2013 at 04:45:11PM +0000, Guennadi Liakhovetski wrote: > > Many MMC capability flags are platform-dependent and are traditionally set > > in platform data. With DT often each such capability requires a special > > binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED and > > MMC_CAP_POWER_OFF_CARD capabilities. Also add code to DT parser to look > > up "keep-power-in-suspend" and "enable-sdio-wakeup" bindings and set > > MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ respectively, if found. > > > > I've Cc'd Arnd, who had some related comments a while back: > > https://lkml.org/lkml/2012/10/15/231 > > MMC_CAP_POWER_OFF_CARD sounds like something that can be selected in the driver > by checking the compatible string or probing the hardware revision, and not > something that should be taken directly from the dts where it could be > completely invalid for the hardware. Thank for pointing me out at that thread. However, I don't think MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware revisions. At least I haven't yet come across any sd/mmc hosts, that also supply card power. You could "derive" this flag from the presence of a regulator, capable of changing its status (switching on / off), but even then you're not guaranteed, that you actually can (and want to) power the card off at run-time - the regulator can be shared etc. So, an explicit flag is needed. Thanks Guennadi > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > > --- > > > > Attention: contains new DT bindings, please, comment! > > > > Documentation/devicetree/bindings/mmc/mmc.txt | 5 ++++- > > drivers/mmc/core/host.c | 11 +++++++++++ > > 2 files changed, 15 insertions(+), 1 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt > > index e180892..92ec534c 100644 > > --- a/Documentation/devicetree/bindings/mmc/mmc.txt > > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > > @@ -25,8 +25,11 @@ Optional properties: > > - max-frequency: maximum operating clock frequency > > - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on > > this system, even if the controller claims it is. > > +- cap-sd-highspeed: SD high-speed timing is supported > > +- cap-mmc-highspeed: MMC high-speed timing is supported > > +- cap-power-off-card: powering off the card is safe > > > > -cd-inverted and wp-inverted properties are deprecated ans shouldn't be used, > > +cd-inverted and wp-inverted properties are deprecated and shouldn't be used, > > instead pleaseuse the OF_GPIO_ACTIVE_LOW flag in respective GPIO bindings. Note, > > that the default (as defined by the SDHCI standard) CD and WP polarity is > > active-low, so, OF_GPIO_ACTIVE_LOW should normally be set, and only be left > > diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c > > index e4c1cbd..f3ea268 100644 > > --- a/drivers/mmc/core/host.c > > +++ b/drivers/mmc/core/host.c > > @@ -372,6 +372,17 @@ void mmc_of_parse(struct mmc_host *host) > > dev_err(host->parent, > > "Failed to request WP GPIO: %d!\n", ret); > > } > > + > > + if (of_find_property(np, "cap-sd-highspeed", &len)) > > + host->caps |= MMC_CAP_SD_HIGHSPEED; > > + if (of_find_property(np, "cap-mmc-highspeed", &len)) > > + host->caps |= MMC_CAP_MMC_HIGHSPEED; > > + if (of_find_property(np, "cap-power-off-card", &len)) > > + host->caps |= MMC_CAP_POWER_OFF_CARD; > > + if (of_find_property(np, "keep-power-in-suspend", &len)) > > + host->pm_caps |= MMC_PM_KEEP_POWER; > > + if (of_find_property(np, "enable-sdio-wakeup", &len)) > > + host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ; > > } > > > > EXPORT_SYMBOL(mmc_of_parse); > > -- > > 1.7.2.5 > > > > _______________________________________________ > > devicetree-discuss mailing list > > devicetree-discuss@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/devicetree-discuss > > > > Thanks, > Mark. > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 7 Feb 2013, Arnd Bergmann wrote: > On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote: > > > > Thank for pointing me out at that thread. However, I don't think > > MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware > > revisions. At least I haven't yet come across any sd/mmc hosts, that also > > supply card power. You could "derive" this flag from the presence of a > > regulator, capable of changing its status (switching on / off), but even > > then you're not guaranteed, that you actually can (and want to) power the > > card off at run-time - the regulator can be shared etc. So, an explicit > > flag is needed. > > It sounds like something that should be handled in a controller specific > way I think. E.g. on SDHCI, there seems to always be a method to power > down the card using the SDHCI_POWER_CONTROL register, even without > any external regulators. If I understand correctly, that register only controls card bus power. Further sdhci.c uses regulators (host->vmmc) to power up and down the card. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 06 February 2013, Guennadi Liakhovetski wrote: > > On Thu, 7 Feb 2013, Arnd Bergmann wrote: > > > On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote: > > > > > > Thank for pointing me out at that thread. However, I don't think > > > MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware > > > revisions. At least I haven't yet come across any sd/mmc hosts, that also > > > supply card power. You could "derive" this flag from the presence of a > > > regulator, capable of changing its status (switching on / off), but even > > > then you're not guaranteed, that you actually can (and want to) power the > > > card off at run-time - the regulator can be shared etc. So, an explicit > > > flag is needed. > > > > It sounds like something that should be handled in a controller specific > > way I think. E.g. on SDHCI, there seems to always be a method to power > > down the card using the SDHCI_POWER_CONTROL register, even without > > any external regulators. > > If I understand correctly, that register only controls card bus power. > Further sdhci.c uses regulators (host->vmmc) to power up and down the > card. Ok, that may be true. So a device that can only power down the bus but not the card itself should not set MMC_CAP_POWER_OFF_CARD then? I only saw that it is set unconditionally for the PCI case, which does not use regulators. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote: > > Thank for pointing me out at that thread. However, I don't think > MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware > revisions. At least I haven't yet come across any sd/mmc hosts, that also > supply card power. You could "derive" this flag from the presence of a > regulator, capable of changing its status (switching on / off), but even > then you're not guaranteed, that you actually can (and want to) power the > card off at run-time - the regulator can be shared etc. So, an explicit > flag is needed. It sounds like something that should be handled in a controller specific way I think. E.g. on SDHCI, there seems to always be a method to power down the card using the SDHCI_POWER_CONTROL register, even without any external regulators. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index e180892..92ec534c 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -25,8 +25,11 @@ Optional properties: - max-frequency: maximum operating clock frequency - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on this system, even if the controller claims it is. +- cap-sd-highspeed: SD high-speed timing is supported +- cap-mmc-highspeed: MMC high-speed timing is supported +- cap-power-off-card: powering off the card is safe -cd-inverted and wp-inverted properties are deprecated ans shouldn't be used, +cd-inverted and wp-inverted properties are deprecated and shouldn't be used, instead pleaseuse the OF_GPIO_ACTIVE_LOW flag in respective GPIO bindings. Note, that the default (as defined by the SDHCI standard) CD and WP polarity is active-low, so, OF_GPIO_ACTIVE_LOW should normally be set, and only be left diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index e4c1cbd..f3ea268 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -372,6 +372,17 @@ void mmc_of_parse(struct mmc_host *host) dev_err(host->parent, "Failed to request WP GPIO: %d!\n", ret); } + + if (of_find_property(np, "cap-sd-highspeed", &len)) + host->caps |= MMC_CAP_SD_HIGHSPEED; + if (of_find_property(np, "cap-mmc-highspeed", &len)) + host->caps |= MMC_CAP_MMC_HIGHSPEED; + if (of_find_property(np, "cap-power-off-card", &len)) + host->caps |= MMC_CAP_POWER_OFF_CARD; + if (of_find_property(np, "keep-power-in-suspend", &len)) + host->pm_caps |= MMC_PM_KEEP_POWER; + if (of_find_property(np, "enable-sdio-wakeup", &len)) + host->pm_caps |= MMC_PM_WAKE_SDIO_IRQ; } EXPORT_SYMBOL(mmc_of_parse);
Many MMC capability flags are platform-dependent and are traditionally set in platform data. With DT often each such capability requires a special binding. Add bindings for MMC_CAP_SD_HIGHSPEED, MMC_CAP_MMC_HIGHSPEED and MMC_CAP_POWER_OFF_CARD capabilities. Also add code to DT parser to look up "keep-power-in-suspend" and "enable-sdio-wakeup" bindings and set MMC_PM_KEEP_POWER and MMC_PM_WAKE_SDIO_IRQ respectively, if found. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> --- Attention: contains new DT bindings, please, comment! Documentation/devicetree/bindings/mmc/mmc.txt | 5 ++++- drivers/mmc/core/host.c | 11 +++++++++++ 2 files changed, 15 insertions(+), 1 deletions(-)