All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.