• Douglas Anderson's avatar
    mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes · 6fc09244
    Douglas Anderson authored
    This reverts commit 4ac0d5f245e1 ("mmc: sdhci-of-arasan: Always power
    the PHY off/on when clock changes"), resolving conflicts with other
    patches that have come after.  It appears that on some boards / with
    some eMMC devices that the patch is causing problems.
    
    Presumably turning the phy off and on again at the wrong time while
    initially setting up the card is confusing the card, the host, or the
    PHY.  We have lots of power cycles while initially setting up the card
    because the main sdhci driver often turns off the clock by clearing
    SDHCI_CLOCK_CARD_EN and then calls host->ops->set_clock() to set the
    clock again.  With all of those, we ended up with lots of power cycles.
    
    Presumably the arguments made in the original patch still hold.  That
    is, whenever the card clock is turned off and on again (or changed) we
    really should wait for the DLL to lock again.  However, perhaps it's
    really not that critical for the lower speeds.
    
    It's possible that the right answer here is:
    * Whenever set_clock() is called we should double-check that the DLL is
      locked.
    * Whenever set_clock() is called and we're actually changing clocks we
      should do a power cycle around that.
    * When we're doing a power cycle just because the clock changed, we
      probably shouldn't do quite as many things (maybe don't need to
      recalibarate, etc).
    
    Unfortunately the interaction between SDHCI and the PHY is extremely
    limited because of the limited PHY API.  The PHY does have a reference
    to the card clock and could theoretically register for notifications,
    except that our clock is query only (it uses CLK_GET_RATE_NOCACHE) and
    so can't really be notified about updates.  I believe we would need a
    major redesign of clock handling in SDHCI core to do better than that,
    or we would need to make our one fake notifications.  :(
    
    Let's hope that we can eventually get more information from Arasan on
    how all this should be handled before doing tons more work.  Until then,
    let's get back to a known working state.  Note that the rest of the
    patches in the 150 MHz series should still work fine even without this
    one.
    Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
    Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
    6fc09244
sdhci-of-arasan.c 17.2 KB