From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753021AbcJFIEH (ORCPT ); Thu, 6 Oct 2016 04:04:07 -0400 Received: from mail-wm0-f49.google.com ([74.125.82.49]:36097 "EHLO mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751917AbcJFIEA (ORCPT ); Thu, 6 Oct 2016 04:04:00 -0400 MIME-Version: 1.0 In-Reply-To: References: <1474660869-15532-1-git-send-email-zach.brown@ni.com> <1474660869-15532-2-git-send-email-zach.brown@ni.com> From: Ulf Hansson Date: Thu, 6 Oct 2016 10:03:56 +0200 Message-ID: Subject: Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed To: Rob Herring Cc: Zach Brown , Adrian Hunter , Mark Rutland , linux-mmc , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5 October 2016 at 22:03, Rob Herring wrote: > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson wrote: >> On 23 September 2016 at 22:01, Zach Brown wrote: >>> 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 >>> --- >>> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed Date: Thu, 6 Oct 2016 10:03:56 +0200 Message-ID: References: <1474660869-15532-1-git-send-email-zach.brown@ni.com> <1474660869-15532-2-git-send-email-zach.brown@ni.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Zach Brown , Adrian Hunter , Mark Rutland , linux-mmc , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On 5 October 2016 at 22:03, Rob Herring wrote: > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson wrote: >> On 23 September 2016 at 22:01, Zach Brown wrote: >>> 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 >>> --- >>> 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