Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 9月, 2019 1 次提交
  3. 31 5月, 2019 1 次提交
  5. 15 4月, 2019 1 次提交
  7. 17 12月, 2018 1 次提交
    • F
      mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver · 41fd4cae
      由 Faiz Abbas 提交于 
      The host controllers on TI's AM654 SOCs are not compatible with
the phy and consumer model of the sdhci-of-arasan driver. It turns out
that for optimal operation at higher speeds, a special tuning procedure
needs to be implemented which involves configuration of platform
specific phy registers.

Therefore, branch out to a new sdhci_am654 driver and add the phy
register space with all phy configurations to it. Populate AM654
specific callbacks to sdhci_ops and add SDHCI_QUIRKS wherever
applicable.

Only add support for upto High Speed for SD card and upto DDR52 speed
mode for eMMC. Higher speeds will be added in subsequent patches.
Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      41fd4cae
  9. 09 10月, 2018 2 次提交
  11. 08 10月, 2018 1 次提交
  13. 16 7月, 2018 1 次提交
  15. 02 5月, 2018 2 次提交
  17. 16 1月, 2018 1 次提交
  19. 11 12月, 2017 1 次提交
  21. 30 8月, 2017 2 次提交
  23. 20 6月, 2017 1 次提交
  25. 25 4月, 2017 3 次提交
  27. 14 3月, 2017 1 次提交
    • A
      mmc: sdhci-of-arasan: fix incorrect timeout clock · 16681037
      由 Anssi Hannula 提交于 
      sdhci_arasan_get_timeout_clock() divides the frequency it has with (1 <<
(13 + divisor)).

However, the divisor is not some Arasan-specific value, but instead is
just the Data Timeout Counter Value from the SDHCI Timeout Control
Register.

Applying it here like this is wrong as the sdhci driver already takes
that value into account when calculating timeouts, and in fact it *sets*
that register value based on how long a timeout is wanted.

Additionally, sdhci core interprets the .get_timeout_clock callback
return value as if it were read from hardware registers, i.e. the unit
should be kHz or MHz depending on SDHCI_TIMEOUT_CLK_UNIT capability bit.
This bit is set at least on the tested Zynq-7000 SoC.

With the tested hardware (SDHCI_TIMEOUT_CLK_UNIT set) this results in
too high a timeout clock rate being reported, causing the core to use
longer-than-needed timeouts. Additionally, on a partitioned MMC
(therefore having erase_group_def bit set) mmc_calc_max_discard()
disables discard support as it looks like controller does not support
the long timeouts needed for that.

Do not apply the extra divisor and return the timeout clock in the
expected unit.

Tested with a Zynq-7000 SoC and a partitioned Toshiba THGBMAG5A1JBAWR
eMMC card.
Signed-off-by: NAnssi Hannula <anssi.hannula@bitwise.fi>
Fixes: e3ec3a3d ("mmc: arasan: Add driver for Arasan SDHCI")
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      16681037
  29. 10 10月, 2016 2 次提交
  31. 27 9月, 2016 3 次提交
    • Z
      mmc: sdhci-of-arasan: Set controller to test mode when no CD bit · 3794c542
      由 Zach Brown 提交于 
      The sdhci controller on xilinx zynq devices will not function unless
the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
In cases where it is impossible to provide the CD bit in hardware,
setting the controller to test mode and then setting inserted to true
will get the controller to function without the CD bit.

When the device has the property xlnx,fails-without-test-cd the driver
changes the controller to test mode and sets test inserted to true to
make the controller function.
Signed-off-by: NZach Brown <zach.brown@ni.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      3794c542
    • S
      mmc: sdhci-of-arasan: Properly set corecfg_clockmultiplier on rk3399 · b2ca77c9
      由 Shawn Lin 提交于 
      corecfg_clockmultiplier indicates clock multiplier value of
programmable clock generator which should be the same value
of SDHCI_CAPABILITIES_1. The default value of the register,
corecfg_clockmultiplier, is 0x10. But actually it is a mistake
by designer as our intention was to set it to be zero which
means we don't support programmable clock generator. So we have
to make it to be zero on bootloader which seems work fine until
now. But now we find an issue that when deploying genpd support
for it, the remove callback will trigger the genpd to poweroff the
power domain for sdhci-of-arasan which manage the controller, phy
and corecfg_* stuff.

So when we do bind/unbind the driver, we have already reinit
the controller and phy, but without doing that for corecfg_*.
Regarding to only the corecfg_clockmultipler is wrong, let's
fix it by explicitly marking it to be zero when probing. With
this change, we could do bind/unbind successfully.
Reported-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Tested-by: NZiyuan Xu <xzy.xu@rock-chips.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b2ca77c9
    • D
      mmc: sdhci-of-arasan: Don't power PHY w/ slow/no clock · b2db9c67
      由 Douglas Anderson 提交于 
      PHY intended to be used with the Arasan SDHCI 5.1 controller has trouble
turning on when the card clock is slow or off.  Strangely these problems
appear to show up consistently on some boards while other boards work
fine, but on the boards where it shows up the problem reproduces 100% of
the time and is quite consistent in its behavior.

These problems can be fixed by always making sure that we power on the
PHY (and turn on its DLL) when the card clock is faster than about 50
MHz.  Once on, we need to make sure that we never power down the PHY /
turn off its DLL until the clock is faster again.

We'll add logic for handling this into the sdhci-of-arasan driver.  Note
that right now the only user of a PHY in the sdhci-of-arasan driver is
arasan,sdhci-5.1.  It's presumed that all arasan,sdhci-5.1 PHY
implementations need this workaround, so the logic is only contingent on
having a PHY to control.  If future Arasan controllers don't have this
problem we can add code to decide if we want this flow or not.

Also note that we check for slow clocks by checking for <= 400 kHz
rather than checking for 50 MHz.  This keeps things the most consistent
and also means we can power the PHY on at max speed (where the DLL will
lock fastest).  Presumably anyone who intends to run with a card clock
of < 50 MHz and > 400 kHz will be running on a device where this problem
is fixed anyway.

I believe this brings some resolution to the problems reported before.
See the commit 6fc09244 ("mmc: sdhci-of-arasan: Revert: Always power
the PHY off/on when clock changes").
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b2db9c67
  33. 25 7月, 2016 5 次提交
    • D
      mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes · 6fc09244
      由 Douglas Anderson 提交于 
      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: NDouglas Anderson <dianders@chromium.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6fc09244
    • D
      mmc: sdhci-of-arasan: Add ability to export card clock · c390f211
      由 Douglas Anderson 提交于 
      Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work
with arasan,sdhci-5.1) need to know the card clock in order to function
properly.  Let's add the ability to expose this clock.  Any PHY that
needs to know the clock rate can add a reference and query the clock
rate.

At the moment we register a CLK_GET_RATE_NOCACHE clock that simply
allows querying the clock.  This allows us to be less intrusive with
regards to the main SDHCI driver, which has complex logic for adjusting
the SD clock.  Right now we always fully power cycle the PHY when the
clock changes and that gives the PHY a good chance to query our clock.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c390f211
    • D
      mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399 · 3ea4666e
      由 Douglas Anderson 提交于 
      In the the earlier change in this series ("Documentation: mmc:
sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the
mechansim for specifying a syscon to properly set corecfg registers in
sdhci-of-arasan.  Now let's use this mechanism to properly set
corecfg_baseclkfreq on rk3399.

>From [1] the corecfg_baseclkfreq is supposed to be set to:
  Base Clock Frequency for SD Clock.
  This is the frequency of the xin_clk.

This is a relatively easy thing to do.  Note that we assume that xin_clk
is not dynamic and we can check the clock at probe time.  If any real
devices have a dynamic xin_clk future patches could register for
notifiers for the clock.

At the moment, setting corecfg_baseclkfreq is only supported for rk3399
since we need a specific map for each implementation.  The code is
written in a generic way that should make this easy to extend to other
SoCs.  Note that a specific compatible string for rk3399 is already in
use and so we add that to the table to match rk3399.

[1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdfSigned-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      3ea4666e
    • D
      mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes · ca572f46
      由 Douglas Anderson 提交于 
      In commit 802ac39a ("mmc: sdhci-of-arasan: fix set_clock when a phy
is supported") we added code to power the PHY off and on whenever the
clock was changed but we avoided doing the power cycle code when the
clock was low speed.  Let's now do it always.

Although there may be other reasons for power cycling the PHY when the
clock changes, one of the main reasons is that we need to give the DLL a
chance to re-lock with the new clock.

One of the things that the DLL is for is tuning the Receive Clock in
HS200 mode and STRB in HS400 mode.  Thus it is clear that we should make
sure we power cycle the PHY (and wait for the DLL to lock) when we know
we'll be in one of these two speed modes.  That's what the original code
did, though it used the clock rate rather than the speed mode.  However,
even in speed modes other than HS200,/HS400 the DLL is used for
something since it can be clearly observed that the PHY doesn't function
properly if you leave the DLL off.

Although it appears less important to power cycle the PHY and wait for
the DLL to lock when not in HS200/HS400 modes (no bugs were reported),
it still seems wise to let the locking always happen nevertheless.

Note: as part of this, we make sure that we never try to turn the PHY on
when the clock is off (when the clock rate is 0).  The PHY cannot work
when the clock is off since its DLL can't lock.

This change requires ("phy: rockchip-emmc: Increase lock time
allowance") and will cause problems if picked without that change.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ca572f46
    • S
      mmc: sdhci-of-arasan: implement enhanced strobe callback · a05c8465
      由 Shawn Lin 提交于 
      Currently sdhci-arasan 5.1 can support enhanced strobe function,
and we now limit it just for "arasan,sdhci-5.1". Add
mmc-hs400-enhanced-strobe in DT to enable the function if we're
sure our controller can support it.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a05c8465
  35. 04 5月, 2016 1 次提交
  37. 17 3月, 2016 3 次提交
  39. 29 2月, 2016 3 次提交
  41. 27 8月, 2015 1 次提交
  43. 17 8月, 2015 1 次提交
  45. 01 6月, 2015 1 次提交
  47. 08 4月, 2015 1 次提交