Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed
From: Ulf Hansson <hidden>
Date: 2016-10-06 08:04:07
Also in:
linux-mmc, lkml
On 5 October 2016 at 22:03, Rob Herring [off-list ref] wrote:
On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson [off-list ref] wrote:quoted
On 23 September 2016 at 22:01, Zach Brown [off-list ref] wrote:quoted
Certain board configurations can make highspeed malfunction due to timing issues. In these cases a way is needed to force the controller and card into standard speed even if they otherwise appear to be capable of highspeed. The sd-broken-highspeed property will let the sdhci driver know that highspeed will not work. Signed-off-by: Zach Brown <redacted> --- Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ 1 file changed, 2 insertions(+)diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a37782..59332ea 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt@@ -52,6 +52,8 @@ 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 +- sd-broken-highspeed: Highspeed is broken, even if the controller and card + themselves claim they support highspeed.Regarding a broken card, that is managed via the card quirks and not in DT. If this is about a controller limitation, we already have the option to describe what it supports, so we don't need an option to tell what it *not* supports. For example "cap-sd-highspeed" tells whether the controller supports SD high-speed, please use that instead.If a controller has a capability register and it lies (perhaps the board has limitations that the SoC does not), then you may need to disable a feature.
I understand, although the SDHCI capabilities register is broken for most SDHCI variants. In principle, we would more or less have to add a *-broken binding for each bit in that register. I don't like that! Maybe a better option is to add a "sdhci-cap-broken" or perhaps "sdhci-cap-speed-modes-broken", which tells the driver to not rely on the capabilities register and instead find out what *is* supported by looking at the other mmc generic DT bindings. What do you think of that? Kind regards Uffe -- 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