From: Douglas Anderson <dianders@chromium.org> To: Heiko Stuebner <heiko@sntech.de>, ulf.hansson@linaro.org, kishon@ti.com Cc: shawn.lin@rock-chips.com, linux-rockchip@lists.infradead.org, linux-mmc@vger.kernel.org, briannorris@chromium.org, Douglas Anderson <dianders@chromium.org>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/3] phy: rockchip-emmc: Wait even longer for the DLL to lock Date: Mon, 27 Jun 2016 10:39:27 -0700 [thread overview] Message-ID: <1467049167-14628-4-git-send-email-dianders@chromium.org> (raw) In-Reply-To: <1467049167-14628-1-git-send-email-dianders@chromium.org> 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> --- drivers/phy/phy-rockchip-emmc.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c index a2aa6aca7dec..fd57345ffed2 100644 --- a/drivers/phy/phy-rockchip-emmc.c +++ b/drivers/phy/phy-rockchip-emmc.c @@ -206,8 +206,18 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off) * per the math: 10.2 us * (50000000 Hz / 100000 Hz) => 5.1 ms * Hopefully we won't be running at 100 kHz, but we should still make * sure we wait long enough. + * + * NOTE: There appear to be corner cases where the DLL seems to take + * extra long to lock for reasons that aren't understood. In some + * extreme cases we've seen it take up to over 10ms (!). We'll be + * generous and give it 50ms. We still busy wait here because: + * - In most cases it should be super fast. + * - This is not called lots during normal operation so it shouldn't + * be a power or performance problem to busy wait. We expect it + * only at boot / resume. In both cases, eMMC is probably on the + * critical path so busy waiting a little extra time should be OK. */ - timeout = jiffies + msecs_to_jiffies(10); + timeout = jiffies + msecs_to_jiffies(50); do { udelay(1); -- 2.8.0.rc3.226.g39d4020
WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Douglas Anderson) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 3/3] phy: rockchip-emmc: Wait even longer for the DLL to lock Date: Mon, 27 Jun 2016 10:39:27 -0700 [thread overview] Message-ID: <1467049167-14628-4-git-send-email-dianders@chromium.org> (raw) In-Reply-To: <1467049167-14628-1-git-send-email-dianders@chromium.org> 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> --- drivers/phy/phy-rockchip-emmc.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c index a2aa6aca7dec..fd57345ffed2 100644 --- a/drivers/phy/phy-rockchip-emmc.c +++ b/drivers/phy/phy-rockchip-emmc.c @@ -206,8 +206,18 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off) * per the math: 10.2 us * (50000000 Hz / 100000 Hz) => 5.1 ms * Hopefully we won't be running at 100 kHz, but we should still make * sure we wait long enough. + * + * NOTE: There appear to be corner cases where the DLL seems to take + * extra long to lock for reasons that aren't understood. In some + * extreme cases we've seen it take up to over 10ms (!). We'll be + * generous and give it 50ms. We still busy wait here because: + * - In most cases it should be super fast. + * - This is not called lots during normal operation so it shouldn't + * be a power or performance problem to busy wait. We expect it + * only at boot / resume. In both cases, eMMC is probably on the + * critical path so busy waiting a little extra time should be OK. */ - timeout = jiffies + msecs_to_jiffies(10); + timeout = jiffies + msecs_to_jiffies(50); do { udelay(1); -- 2.8.0.rc3.226.g39d4020
next prev parent reply other threads:[~2016-06-27 17:40 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-27 17:39 [PATCH 0/3] mmc: Fixes for 150 MHz Rockchip eMMC series Douglas Anderson 2016-06-27 17:39 ` Douglas Anderson 2016-06-27 17:39 ` [PATCH 1/3] mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes Douglas Anderson 2016-06-27 17:39 ` Douglas Anderson 2016-07-21 10:09 ` Adrian Hunter 2016-07-21 10:09 ` Adrian Hunter 2016-06-27 17:39 ` [PATCH 2/3] phy: rockchip-emmc: Be tolerant to card clock of 0 in power on Douglas Anderson 2016-06-27 17:39 ` Douglas Anderson 2016-06-29 13:49 ` Kishon Vijay Abraham I 2016-06-29 13:49 ` Kishon Vijay Abraham I 2016-06-29 13:49 ` Kishon Vijay Abraham I 2016-06-29 15:18 ` Doug Anderson 2016-06-29 15:18 ` Doug Anderson 2016-06-29 15:18 ` Doug Anderson 2016-07-23 9:39 ` Ulf Hansson 2016-07-23 9:39 ` Ulf Hansson 2016-07-23 9:39 ` Ulf Hansson 2016-07-25 5:57 ` Kishon Vijay Abraham I 2016-07-25 5:57 ` Kishon Vijay Abraham I 2016-07-25 5:57 ` Kishon Vijay Abraham I 2016-07-25 7:37 ` Ulf Hansson 2016-07-25 7:37 ` Ulf Hansson 2016-07-25 7:37 ` Ulf Hansson 2016-07-25 14:19 ` Doug Anderson 2016-07-25 14:19 ` Doug Anderson 2016-07-25 14:19 ` Doug Anderson 2016-06-27 17:39 ` Douglas Anderson [this message] 2016-06-27 17:39 ` [PATCH 3/3] phy: rockchip-emmc: Wait even longer for the DLL to lock Douglas Anderson 2016-06-29 13:50 ` Kishon Vijay Abraham I 2016-06-29 13:50 ` Kishon Vijay Abraham I 2016-06-29 13:50 ` Kishon Vijay Abraham I 2016-07-25 8:49 ` [PATCH 0/3] mmc: Fixes for 150 MHz Rockchip eMMC series Ulf Hansson 2016-07-25 8:49 ` Ulf Hansson
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1467049167-14628-4-git-send-email-dianders@chromium.org \ --to=dianders@chromium.org \ --cc=briannorris@chromium.org \ --cc=heiko@sntech.de \ --cc=kishon@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=shawn.lin@rock-chips.com \ --cc=ulf.hansson@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.