summaryrefslogtreecommitdiff
path: root/drivers/phy/phy-rockchip-emmc.c
AgeCommit message (Collapse)AuthorFilesLines
2016-07-25phy: rockchip-emmc: Wait even longer for the DLL to lockDouglas Anderson1-1/+11
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 <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: Be tolerant to card clock of 0 in power onDouglas Anderson1-22/+37
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 <dianders@chromium.org> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: Set phyctrl_frqsel based on card clockDouglas Anderson1-12/+89
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 <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off()Douglas Anderson1-12/+2
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 <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: Increase lock time allowanceDouglas Anderson1-8/+20
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 <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: reindent the register definitionsBrian Norris1-38/+38
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 <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: configure default output tap delayBrian Norris1-0/+19
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 <shawn.lin@rock-chips.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: configure frequency range and drive impedanceShawn Lin1-0/+27
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 <shawn.lin@rock-chips.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-07-25phy: rockchip-emmc: give DLL some extra time to be readyShawn Lin1-3/+4
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 <shawn.lin@rock-chips.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-04-13phy: rockchip-emmc: should be a child device of the GRFHeiko Stuebner1-1/+4
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 <heiko@sntech.de> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2016-03-01phy: add a driver for the Rockchip SoC internal eMMC PHYShawn Lin1-0/+229
This patch to add a generic PHY driver for ROCKCHIP eMMC PHY. Access the PHY via registers provided by GRF (general register files) module. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-24 03:25:21 +0000