linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: Douglas Anderson <dianders@chromium.org>,
	ulf.hansson@linaro.org, kishon@ti.com,
	Heiko Stuebner <heiko@sntech.de>,
	robh+dt@kernel.org
Cc: shawn.lin@rock-chips.com, xzy.xu@rock-chips.com,
	briannorris@chromium.org, adrian.hunter@intel.com,
	linux-rockchip@lists.infradead.org, linux-mmc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 01/11] phy: rockchip-emmc: Increase lock time allowance
Date: Tue, 14 Jun 2016 08:28:46 +0800	[thread overview]
Message-ID: <1c62147b-0464-6ecc-3ba4-2ec9ddf19111@rock-chips.com> (raw)
In-Reply-To: <1465859076-4868-2-git-send-email-dianders@chromium.org>

在 2016/6/14 7:04, Douglas Anderson 写道:
> 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.
>

Looks good to me.

Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>

> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> Changes in v2:
> - Indicate that 5.1 ms is calculated (Shawn).
>
>  drivers/phy/phy-rockchip-emmc.c | 28 ++++++++++++++++++++--------
>  1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c
> index a69f53630e67..2d059c046978 100644
> --- a/drivers/phy/phy-rockchip-emmc.c
> +++ b/drivers/phy/phy-rockchip-emmc.c
> @@ -85,6 +85,7 @@ static int rockchip_emmc_phy_power(struct rockchip_emmc_phy *rk_phy,
>  {
>  	unsigned int caldone;
>  	unsigned int dllrdy;
> +	unsigned long timeout;
>
>  	/*
>  	 * Keep phyctrl_pdb and phyctrl_endll low to allow
> @@ -137,15 +138,26 @@ static int rockchip_emmc_phy_power(struct rockchip_emmc_phy *rk_phy,
>  				   PHYCTRL_ENDLL_MASK,
>  				   PHYCTRL_ENDLL_SHIFT));
>  	/*
> -	 * After enable analog DLL circuits, we need an extra 10.2us
> -	 * for dll to be ready for work. But according to testing, we
> -	 * find some chips need more than 25us.
> +	 * After enabling analog DLL circuits docs say that we need 10.2 us if
> +	 * our source clock is at 50 MHz and that lock time scales linearly
> +	 * with clock speed.  If we are powering on the PHY and the card clock
> +	 * is super slow (like 100 kHZ) this could take as long as 5.1 ms as
> +	 * 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.
>  	 */
> -	udelay(30);
> -	regmap_read(rk_phy->reg_base,
> -		    rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
> -		    &dllrdy);
> -	dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
> +	timeout = jiffies + msecs_to_jiffies(10);
> +	do {
> +		udelay(1);
> +
> +		regmap_read(rk_phy->reg_base,
> +			rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
> +			&dllrdy);
> +		dllrdy = (dllrdy >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK;
> +		if (dllrdy == PHYCTRL_DLLRDY_DONE)
> +			break;
> +	} while (!time_after(jiffies, timeout));
> +
>  	if (dllrdy != PHYCTRL_DLLRDY_DONE) {
>  		pr_err("rockchip_emmc_phy_power: dllrdy timeout.\n");
>  		return -ETIMEDOUT;
>


-- 
Best Regards
Shawn Lin

  reply	other threads:[~2016-06-14  0:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-13 23:04 [PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399 Douglas Anderson
2016-06-13 23:04 ` [PATCH v2 01/11] phy: rockchip-emmc: Increase lock time allowance Douglas Anderson
2016-06-14  0:28   ` Shawn Lin [this message]
2016-06-20 13:03   ` Kishon Vijay Abraham I
2016-06-13 23:04 ` [PATCH v2 02/11] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes Douglas Anderson
2016-06-14  0:30   ` Shawn Lin
2016-06-13 23:04 ` [PATCH v2 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs Douglas Anderson
2016-06-14  0:33   ` Shawn Lin
2016-06-18 14:15   ` Heiko Stübner
2016-06-13 23:04 ` [PATCH v2 04/11] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399 Douglas Anderson
2016-06-18 17:59   ` Heiko Stuebner
2016-06-13 23:04 ` [PATCH v2 05/11] arm64: dts: rockchip: Add soc-ctl-syscon to sdhci for rk3399 Douglas Anderson
2016-06-18 12:49   ` Heiko Stübner
2016-06-13 23:04 ` [PATCH v2 06/11] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock Douglas Anderson
2016-06-18 18:02   ` Heiko Stuebner
2016-06-13 23:04 ` [PATCH v2 07/11] " Douglas Anderson
2016-06-15 16:40   ` Doug Anderson
2016-06-13 23:04 ` [PATCH v2 08/11] Documentation: phy: Let the rockchip eMMC PHY get an exported " Douglas Anderson
2016-06-16 18:42   ` Rob Herring
2016-06-18 21:48   ` Heiko Stübner
2016-06-20 13:04   ` Kishon Vijay Abraham I
2016-06-13 23:04 ` [PATCH v2 09/11] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off() Douglas Anderson
2016-06-14  0:36   ` Shawn Lin
2016-06-20 13:04   ` Kishon Vijay Abraham I
2016-06-13 23:04 ` [PATCH v2 10/11] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock Douglas Anderson
2016-06-18 12:20   ` Heiko Stübner
2016-06-20 16:48     ` Doug Anderson
2016-06-20 13:08   ` Kishon Vijay Abraham I
2016-06-13 23:04 ` [PATCH v2 11/11] arm64: dts: rockchip: Provide emmcclk to PHY for rk3399 Douglas Anderson
2016-06-18 12:07   ` Heiko Stübner
2016-06-16 23:39 ` [PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399 Heiko Stuebner
2016-06-17 12:39 ` Kishon Vijay Abraham I
2016-06-17 15:37   ` Doug Anderson

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=1c62147b-0464-6ecc-3ba4-2ec9ddf19111@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --cc=adrian.hunter@intel.com \
    --cc=briannorris@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@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=robh+dt@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=xzy.xu@rock-chips.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).