lkml.org 
[lkml]   [2016]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed
    On Thu, Oct 06, 2016 at 10:03:56AM +0200, Ulf Hansson wrote:
    > On 5 October 2016 at 22:03, Rob Herring <robh+dt@kernel.org> wrote:
    > > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
    > >> On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> 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@ni.com>
    > >>> ---
    > >>> 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.

    \
     
     \ /
      Last update: 2016-10-18 00:23    [W:5.181 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site