mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes

mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes

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: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>