* [RFC 0/2] Ignore capability registers when it comes to speeds and use DT binding instead. @ 2016-10-18 21:05 Zach Brown [not found] ` <1476824736-9337-1-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org> 2016-10-18 21:05 ` [RFC 2/2] mmc: sdhci: Ignore capability register when it comes to speeds and use DT binding instead when sdhci-cap-speed-modes-broken is set Zach Brown 0 siblings, 2 replies; 5+ messages in thread From: Zach Brown @ 2016-10-18 21:05 UTC (permalink / raw) To: ulf.hansson Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree, linux-kernel, zach.brown The first patch add documentation about a new devicetree property sdhci-cap-speed-modes-broken. The second patch makes the sdhci use the DT binding instead of the caps register for determining which speed modes are supported by the controller. This RFC is an alternative to another patch set I sent up. https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1251944.html Zach Brown (2): mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken mmc: sdhci: Ignore capability register when it comes to speeds and use DT binding instead when sdhci-cap-speed-modes-broken is set. Documentation/devicetree/bindings/mmc/mmc.txt | 3 +++ drivers/mmc/host/sdhci.c | 31 +++++++++++++++++++++++++++ 2 files changed, 34 insertions(+) -- 2.7.4 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <1476824736-9337-1-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org>]
* [RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken [not found] ` <1476824736-9337-1-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org> @ 2016-10-18 21:05 ` Zach Brown 2016-10-26 21:03 ` Rob Herring 0 siblings, 1 reply; 5+ messages in thread From: Zach Brown @ 2016-10-18 21:05 UTC (permalink / raw) To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A Cc: adrian.hunter-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-mmc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, zach.brown-acOepvfBmUk On some systems the sdhci capabilty registers are incorrect for one reason or another. The sdhci-cap-speed-modes-broken property will let the driver know that the sdhci capability registers should not be relied on for speed modes. Instead the driver should check the mmc generic DT bindings. Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> --- Documentation/devicetree/bindings/mmc/mmc.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a37782..671d6c0 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -52,6 +52,9 @@ Optional properties: - no-sdio: controller is limited to send sdio cmd during initialization - no-sd: controller is limited to send sd cmd during initialization - no-mmc: controller is limited to send mmc cmd during initialization +- sdhci-cap-speed-modes-broken: One or more of the bits in the sdhci + capabilities registers representing speed modes are incorrect. All the bits + representing speed modes should be ignored. *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted" -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken 2016-10-18 21:05 ` [RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken Zach Brown @ 2016-10-26 21:03 ` Rob Herring 0 siblings, 0 replies; 5+ messages in thread From: Rob Herring @ 2016-10-26 21:03 UTC (permalink / raw) To: Zach Brown Cc: ulf.hansson, adrian.hunter, mark.rutland, linux-mmc, devicetree, linux-kernel On Tue, Oct 18, 2016 at 04:05:35PM -0500, Zach Brown wrote: > On some systems the sdhci capabilty registers are incorrect for one > reason or another. > > The sdhci-cap-speed-modes-broken property will let the driver know that > the sdhci capability registers should not be relied on for speed modes. > Instead the driver should check the mmc generic DT bindings. > > Signed-off-by: Zach Brown <zach.brown@ni.com> > --- > Documentation/devicetree/bindings/mmc/mmc.txt | 3 +++ > 1 file changed, 3 insertions(+) Acked-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 5+ messages in thread
* [RFC 2/2] mmc: sdhci: Ignore capability register when it comes to speeds and use DT binding instead when sdhci-cap-speed-modes-broken is set. 2016-10-18 21:05 [RFC 0/2] Ignore capability registers when it comes to speeds and use DT binding instead Zach Brown [not found] ` <1476824736-9337-1-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org> @ 2016-10-18 21:05 ` Zach Brown [not found] ` <1476824736-9337-3-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org> 1 sibling, 1 reply; 5+ messages in thread From: Zach Brown @ 2016-10-18 21:05 UTC (permalink / raw) To: ulf.hansson Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree, linux-kernel, zach.brown When the sdhci-cap-speed-modes-broken DT property is set, the driver will ignore the bits of the capability registers that correspond to speed modes and will read the of properties of the device to determine which speeds are supported. Signed-off-by: Zach Brown <zach.brown@ni.com> --- drivers/mmc/host/sdhci.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 1e25b01..100649a 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -22,6 +22,7 @@ #include <linux/scatterlist.h> #include <linux/regulator/consumer.h> #include <linux/pm_runtime.h> +#include <linux/of.h> #include <linux/leds.h> @@ -3020,6 +3021,32 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1) } EXPORT_SYMBOL_GPL(__sdhci_read_caps); +void sdhci_get_speed_caps_from_of(struct sdhci_host *host) +{ + struct mmc_host *mmc = host->mmc; + + host->caps &= ~SDHCI_CAN_DO_HISPD; + + if (of_property_read_bool(mmc_dev(mmc)->of_node, "cap-sd-highspeed")) + host->caps |= SDHCI_CAN_DO_HISPD; + + if (host->version < SDHCI_SPEC_300) + return; + + host->caps1 &= ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_SDR104 | + SDHCI_SUPPORT_DDR50); + + if (of_property_read_bool(mmc_dev(mmc)->of_node, "sd-uhs-sdr50")) + host->caps1 |= SDHCI_SUPPORT_SDR50; + + if (of_property_read_bool(mmc_dev(mmc)->of_node, "sd-uhs-sdr104")) + host->caps1 |= SDHCI_SUPPORT_SDR104; + + if (of_property_read_bool(mmc_dev(mmc)->of_node, "sd-uhs-ddr50")) + host->caps1 |= SDHCI_SUPPORT_DDR50; + +} + int sdhci_setup_host(struct sdhci_host *host) { struct mmc_host *mmc; @@ -3046,6 +3073,10 @@ int sdhci_setup_host(struct sdhci_host *host) return ret; sdhci_read_caps(host); + if (of_property_read_bool(mmc_dev(mmc)->of_node, + "sdhci-cap-speed-modes-broken")) + sdhci_get_speed_caps_from_of(host); + override_timeout_clk = host->timeout_clk; -- 2.7.4 ^ permalink raw reply related [flat|nested] 5+ messages in thread
[parent not found: <1476824736-9337-3-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org>]
* Re: [RFC 2/2] mmc: sdhci: Ignore capability register when it comes to speeds and use DT binding instead when sdhci-cap-speed-modes-broken is set. [not found] ` <1476824736-9337-3-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org> @ 2016-10-19 7:10 ` Ulf Hansson 0 siblings, 0 replies; 5+ messages in thread From: Ulf Hansson @ 2016-10-19 7:10 UTC (permalink / raw) To: Zach Brown Cc: Adrian Hunter, Rob Herring, Mark Rutland, linux-mmc, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 18 October 2016 at 23:05, Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> wrote: > When the sdhci-cap-speed-modes-broken DT property is set, the driver > will ignore the bits of the capability registers that correspond to > speed modes and will read the of properties of the device to determine > which speeds are supported. To me this seems like a great idea. Yeah, I proposed it so I guess that's why. :-) Anyway, it's Adrian call to decide how he want to go with this. He might consider the other option [1] to be better. Some more comments below. > > Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> > --- > drivers/mmc/host/sdhci.c | 31 +++++++++++++++++++++++++++++++ > 1 file changed, 31 insertions(+) > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 1e25b01..100649a 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -22,6 +22,7 @@ > #include <linux/scatterlist.h> > #include <linux/regulator/consumer.h> > #include <linux/pm_runtime.h> > +#include <linux/of.h> > > #include <linux/leds.h> > > @@ -3020,6 +3021,32 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1) > } > EXPORT_SYMBOL_GPL(__sdhci_read_caps); > > +void sdhci_get_speed_caps_from_of(struct sdhci_host *host) > +{ > + struct mmc_host *mmc = host->mmc; > + > + host->caps &= ~SDHCI_CAN_DO_HISPD; > + > + if (of_property_read_bool(mmc_dev(mmc)->of_node, "cap-sd-highspeed")) > + host->caps |= SDHCI_CAN_DO_HISPD; > + > + if (host->version < SDHCI_SPEC_300) > + return; > + > + host->caps1 &= ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_SDR104 | > + SDHCI_SUPPORT_DDR50); > + > + if (of_property_read_bool(mmc_dev(mmc)->of_node, "sd-uhs-sdr50")) > + host->caps1 |= SDHCI_SUPPORT_SDR50; > + > + if (of_property_read_bool(mmc_dev(mmc)->of_node, "sd-uhs-sdr104")) > + host->caps1 |= SDHCI_SUPPORT_SDR104; > + > + if (of_property_read_bool(mmc_dev(mmc)->of_node, "sd-uhs-ddr50")) > + host->caps1 |= SDHCI_SUPPORT_DDR50; > + I don't think you need a separate OF parsing function. Instead the SDHCI variant drivers may call mmc_of_parse() to parse the generic mmc OF properties and then read the SDHCI caps registers (in some way or the other). As reading the SDHCI caps registers is done in __sdhci_read_caps(), you could instead check for the OF property "sdhci-cap-speed-modes-broken" in there, and if it's set, clear the related bits. I think that's all you need. Note, the above code considers only SD speed modes, I assume we should include eMMC speed modes to be broken as well!? > +} > + > int sdhci_setup_host(struct sdhci_host *host) > { > struct mmc_host *mmc; > @@ -3046,6 +3073,10 @@ int sdhci_setup_host(struct sdhci_host *host) > return ret; > > sdhci_read_caps(host); > + if (of_property_read_bool(mmc_dev(mmc)->of_node, > + "sdhci-cap-speed-modes-broken")) > + sdhci_get_speed_caps_from_of(host); > + > > override_timeout_clk = host->timeout_clk; > > -- > 2.7.4 > Kind regards Uffe [1] http://www.spinics.net/lists/devicetree/msg146401.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-26 21:03 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-18 21:05 [RFC 0/2] Ignore capability registers when it comes to speeds and use DT binding instead Zach Brown [not found] ` <1476824736-9337-1-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org> 2016-10-18 21:05 ` [RFC 1/2] mmc: sdhci: dt: Add device tree property sdhci-cap-speed-modes-broken Zach Brown 2016-10-26 21:03 ` Rob Herring 2016-10-18 21:05 ` [RFC 2/2] mmc: sdhci: Ignore capability register when it comes to speeds and use DT binding instead when sdhci-cap-speed-modes-broken is set Zach Brown [not found] ` <1476824736-9337-3-git-send-email-zach.brown-acOepvfBmUk@public.gmane.org> 2016-10-19 7:10 ` Ulf Hansson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).