linux-toradex.git/drivers/phy/phy-rockchip-emmc.c, branch v4.9.95

phy: rockchip-emmc: Wait even longer for the DLL to lock

2016-07-25T08:38:00+00:00

Two times out of 2000 reboots I ran into the error message
"rockchip_emmc_phy_power: dllrdy timeout".  Presumably there is some
corner case where the DLL just takes a little longer to timeout.  Let's
give it even more time to handle these corner cases.

Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: Be tolerant to card clock of 0 in power on

2016-07-25T08:38:00+00:00

It's possible that there are some reasons to turn the PHY on while the
clock is 0.  In this case we just won't wait for the DLL to lock.

This is a bit of a stopgap until we figure out exactly when we're
supposed to wait for the DLL to lock and when we're supposed to power
cycle the PHY.

Note: this patch should help with suspend/resume where the system will
try to turn the PHY back on when the clock is 0.

Signed-off-by: Douglas Anderson 
Reviewed-by: Kishon Vijay Abraham I 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

2016-07-25T08:34:20+00:00

The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the
frequency range of DLL operation".  Although the Rockchip variant of
this PHY has different ranges than the reference Arasan PHY it appears
as if the functionality is similar.  We should set this phyctrl field
properly.

Note: as per Rockchip engineers, apparently the "phyctrl_frqsel" is
actually only useful in HS200 / HS400 modes even though the DLL itself
it used for some purposes in all modes.  See the discussion in the
earlier change in this series: ("mmc: sdhci-of-arasan: Always power the
PHY off/on when clock changes").  In any case, it shouldn't hurt to set
this always.

Note that this change should allow boards to run at HS200 / HS400 speed
modes while running at 100 MHz or 150 MHz.  In fact, running HS400 at
150 MHz (giving 300 MB/s) is the main motivation of this series, since
performance is still good but signal integrity problems are less
prevelant at 150 MHz.

[1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf

Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off()

2016-07-25T08:34:20+00:00

There's no reason to store the return value of rockchip_emmc_phy_power()
in a variable nor to check it.  Just return it.

Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Reviewed-by: Shawn Lin 
Tested-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: Increase lock time allowance

2016-07-25T08:34:16+00:00

Previous PHY code waited a fixed amount of time for the DLL to lock at
power on time.  Unfortunately, the time for the DLL to lock is actually
a bit more dynamic and can be longer if the card clock is slower.

Instead of waiting a fixed 30 us, let's now dynamically wait until the
lock bit gets set.  We'll wait up to 10 ms which should be OK even if
the card clock is at the super slow 100 kHz.

On its own, this change makes the PHY power on code a little more
robust.  Before this change the PHY was relying on the eMMC code to make
sure the PHY was only powered on when the card clock was set to at least
50 MHz before, though this reliance wasn't documented anywhere.

This change will be even more useful in future changes where we actually
need to be able to wait for a DLL lock at slower clock speeds.

Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Reviewed-by: Shawn Lin 
Tested-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: reindent the register definitions

2016-07-25T08:34:16+00:00

Some of the spacing was wrong (spaces instead of tabs), and due to
longer entries added later, the columns weren't aligned. Let's get
everything consistent.

Signed-off-by: Brian Norris 
Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Reviewed-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: configure default output tap delay

2016-07-25T08:34:15+00:00

The output tap delay controls helps maintain the hold requirements for
eMMC. The exact value is dependent on the SoC and other factors, though
it isn't really an exact science. But the default of 0 is not very good,
as it doesn't give the eMMC much hold time, so let's bump up to 4
(approx 90 degree phase?). If we need to configure this any further
(e.g., based on board or speed factors), we may need to consider a
device tree representation.

Suggested-by: Shawn Lin 
Signed-off-by: Brian Norris 
Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Tested-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: configure frequency range and drive impedance

2016-07-25T08:34:15+00:00

Signal integrity analysis has suggested we set these values. Do this in
power_on(), so that they get reconfigured after suspend/resume.

Signed-off-by: Shawn Lin 
Signed-off-by: Brian Norris 
Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Tested-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: give DLL some extra time to be ready

2016-07-25T08:34:14+00:00

According to the databook, 10.2us is the max time for dll to be ready to
work. However in testing, some chips need 20us for dll to be ready. This
patch adds some extra margin for dllrdy to be ready, fixing our
-ETIMEDOUT issues.

Signed-off-by: Shawn Lin 
Signed-off-by: Brian Norris 
Signed-off-by: Douglas Anderson 
Acked-by: Kishon Vijay Abraham I 
Tested-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

phy: rockchip-emmc: should be a child device of the GRF

2016-04-13T13:03:05+00:00

The emmc-phy is fully enclosed in the general register files (GRF).
Therefore as seen from the device-tree it shouldn't be a separate platform-
device but instead a sub-device of the GRF - using the simply-mfd mechanism.

The driver entered the kernel in the current merge-window, so we can still
adapt the binding without needing a fallback, as the binding hasn't been
released with a full kernel yet.

Signed-off-by: Heiko Stuebner 
Acked-by: Rob Herring 
Reviewed-by: Shawn Lin 
Signed-off-by: Kishon Vijay Abraham I