On Thu, Oct 06, 2016 at 10:03:56AM +0200, Ulf Hansson wrote: > On 5 October 2016 at 22:03, Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > >> On 23 September 2016 at 22:01, Zach Brown <zach.brown@xxxxxx> 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 <zach.brown@xxxxxx> > >>> --- > >>> 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 "sdhci-cap-broken" seems too aggressive. There might only be one capability that the register incorrectly advertises. "sdhci-cap-speed-modes-broken" makes more sense and I will re-create this patch set using that idea. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
