All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
To: Douglas Anderson
	<dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Cc: shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
	briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 2/3] phy: rockchip-emmc: Be tolerant to card clock of 0 in power on
Date: Wed, 29 Jun 2016 19:19:49 +0530	[thread overview]
Message-ID: <5773D1FD.8020601@ti.com> (raw)
In-Reply-To: <1467049167-14628-3-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Hi,

On Monday 27 June 2016 11:09 PM, Douglas Anderson wrote:
> 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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>  drivers/phy/phy-rockchip-emmc.c | 59 ++++++++++++++++++++++++++---------------
>  1 file changed, 37 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c
> index 9dce958233a0..a2aa6aca7dec 100644
> --- a/drivers/phy/phy-rockchip-emmc.c
> +++ b/drivers/phy/phy-rockchip-emmc.c
> @@ -88,15 +88,36 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  	unsigned int caldone;
>  	unsigned int dllrdy;
>  	unsigned int freqsel = PHYCTRL_FREQSEL_200M;
> +	unsigned long rate;
>  	unsigned long timeout;
>  
> -	if (rk_phy->emmcclk != NULL) {
> -		unsigned long rate = clk_get_rate(rk_phy->emmcclk);
> +	/*
> +	 * Keep phyctrl_pdb and phyctrl_endll low to allow
> +	 * initialization of CALIO state M/C DFFs
> +	 */
> +	regmap_write(rk_phy->reg_base,
> +		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> +		     HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
> +				   PHYCTRL_PDB_MASK,
> +				   PHYCTRL_PDB_SHIFT));
> +	regmap_write(rk_phy->reg_base,
> +		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> +		     HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
> +				   PHYCTRL_ENDLL_MASK,
> +				   PHYCTRL_ENDLL_SHIFT));
> +
> +	/* Already finish power_off above */
> +	if (on_off == PHYCTRL_PDB_PWR_OFF)
> +		return 0;
> +
> +	rate = clk_get_rate(rk_phy->emmcclk);
> +
> +	if (rate != 0) {
>  		unsigned long ideal_rate;
>  		unsigned long diff;
>  
>  		switch (rate) {
> -		case 0 ... 74999999:
> +		case 1 ... 74999999:
>  			ideal_rate = 50000000;
>  			freqsel = PHYCTRL_FREQSEL_50M;
>  			break;
> @@ -127,25 +148,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  	}
>  
>  	/*
> -	 * Keep phyctrl_pdb and phyctrl_endll low to allow
> -	 * initialization of CALIO state M/C DFFs
> -	 */
> -	regmap_write(rk_phy->reg_base,
> -		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> -		     HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
> -				   PHYCTRL_PDB_MASK,
> -				   PHYCTRL_PDB_SHIFT));
> -	regmap_write(rk_phy->reg_base,
> -		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> -		     HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
> -				   PHYCTRL_ENDLL_MASK,
> -				   PHYCTRL_ENDLL_SHIFT));
> -
> -	/* Already finish power_off above */
> -	if (on_off == PHYCTRL_PDB_PWR_OFF)
> -		return 0;
> -
> -	/*
>  	 * According to the user manual, calpad calibration
>  	 * cycle takes more than 2us without the minimal recommended
>  	 * value, so we may need a little margin here
> @@ -183,6 +185,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  		     HIWORD_UPDATE(PHYCTRL_ENDLL_ENABLE,
>  				   PHYCTRL_ENDLL_MASK,
>  				   PHYCTRL_ENDLL_SHIFT));
> +
> +	/*
> +	 * We turned on the DLL even though the rate was 0 because we the
> +	 * clock might be turned on later.  ...but we can't wait for the DLL
> +	 * to lock when the rate is 0 because it will never lock with no
> +	 * input clock.
> +	 *
> +	 * Technically we should be checking the lock later when the clock
> +	 * is turned on, but for now we won't.
> +	 */
> +	if (rate == 0)
> +		return 0;

Why not return initially from rockchip_emmc_phy_power if the clock rate is '0'.
Are there other functions to lock the DLL apart from phy_power?

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: kishon@ti.com (Kishon Vijay Abraham I)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] phy: rockchip-emmc: Be tolerant to card clock of 0 in power on
Date: Wed, 29 Jun 2016 19:19:49 +0530	[thread overview]
Message-ID: <5773D1FD.8020601@ti.com> (raw)
In-Reply-To: <1467049167-14628-3-git-send-email-dianders@chromium.org>

Hi,

On Monday 27 June 2016 11:09 PM, Douglas Anderson wrote:
> 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>
> ---
>  drivers/phy/phy-rockchip-emmc.c | 59 ++++++++++++++++++++++++++---------------
>  1 file changed, 37 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c
> index 9dce958233a0..a2aa6aca7dec 100644
> --- a/drivers/phy/phy-rockchip-emmc.c
> +++ b/drivers/phy/phy-rockchip-emmc.c
> @@ -88,15 +88,36 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  	unsigned int caldone;
>  	unsigned int dllrdy;
>  	unsigned int freqsel = PHYCTRL_FREQSEL_200M;
> +	unsigned long rate;
>  	unsigned long timeout;
>  
> -	if (rk_phy->emmcclk != NULL) {
> -		unsigned long rate = clk_get_rate(rk_phy->emmcclk);
> +	/*
> +	 * Keep phyctrl_pdb and phyctrl_endll low to allow
> +	 * initialization of CALIO state M/C DFFs
> +	 */
> +	regmap_write(rk_phy->reg_base,
> +		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> +		     HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
> +				   PHYCTRL_PDB_MASK,
> +				   PHYCTRL_PDB_SHIFT));
> +	regmap_write(rk_phy->reg_base,
> +		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> +		     HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
> +				   PHYCTRL_ENDLL_MASK,
> +				   PHYCTRL_ENDLL_SHIFT));
> +
> +	/* Already finish power_off above */
> +	if (on_off == PHYCTRL_PDB_PWR_OFF)
> +		return 0;
> +
> +	rate = clk_get_rate(rk_phy->emmcclk);
> +
> +	if (rate != 0) {
>  		unsigned long ideal_rate;
>  		unsigned long diff;
>  
>  		switch (rate) {
> -		case 0 ... 74999999:
> +		case 1 ... 74999999:
>  			ideal_rate = 50000000;
>  			freqsel = PHYCTRL_FREQSEL_50M;
>  			break;
> @@ -127,25 +148,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  	}
>  
>  	/*
> -	 * Keep phyctrl_pdb and phyctrl_endll low to allow
> -	 * initialization of CALIO state M/C DFFs
> -	 */
> -	regmap_write(rk_phy->reg_base,
> -		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> -		     HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
> -				   PHYCTRL_PDB_MASK,
> -				   PHYCTRL_PDB_SHIFT));
> -	regmap_write(rk_phy->reg_base,
> -		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> -		     HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
> -				   PHYCTRL_ENDLL_MASK,
> -				   PHYCTRL_ENDLL_SHIFT));
> -
> -	/* Already finish power_off above */
> -	if (on_off == PHYCTRL_PDB_PWR_OFF)
> -		return 0;
> -
> -	/*
>  	 * According to the user manual, calpad calibration
>  	 * cycle takes more than 2us without the minimal recommended
>  	 * value, so we may need a little margin here
> @@ -183,6 +185,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  		     HIWORD_UPDATE(PHYCTRL_ENDLL_ENABLE,
>  				   PHYCTRL_ENDLL_MASK,
>  				   PHYCTRL_ENDLL_SHIFT));
> +
> +	/*
> +	 * We turned on the DLL even though the rate was 0 because we the
> +	 * clock might be turned on later.  ...but we can't wait for the DLL
> +	 * to lock when the rate is 0 because it will never lock with no
> +	 * input clock.
> +	 *
> +	 * Technically we should be checking the lock later when the clock
> +	 * is turned on, but for now we won't.
> +	 */
> +	if (rate == 0)
> +		return 0;

Why not return initially from rockchip_emmc_phy_power if the clock rate is '0'.
Are there other functions to lock the DLL apart from phy_power?

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Douglas Anderson <dianders@chromium.org>,
	Heiko Stuebner <heiko@sntech.de>, <ulf.hansson@linaro.org>
Cc: <shawn.lin@rock-chips.com>, <linux-rockchip@lists.infradead.org>,
	<linux-mmc@vger.kernel.org>, <briannorris@chromium.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/3] phy: rockchip-emmc: Be tolerant to card clock of 0 in power on
Date: Wed, 29 Jun 2016 19:19:49 +0530	[thread overview]
Message-ID: <5773D1FD.8020601@ti.com> (raw)
In-Reply-To: <1467049167-14628-3-git-send-email-dianders@chromium.org>

Hi,

On Monday 27 June 2016 11:09 PM, Douglas Anderson wrote:
> 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>
> ---
>  drivers/phy/phy-rockchip-emmc.c | 59 ++++++++++++++++++++++++++---------------
>  1 file changed, 37 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c
> index 9dce958233a0..a2aa6aca7dec 100644
> --- a/drivers/phy/phy-rockchip-emmc.c
> +++ b/drivers/phy/phy-rockchip-emmc.c
> @@ -88,15 +88,36 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  	unsigned int caldone;
>  	unsigned int dllrdy;
>  	unsigned int freqsel = PHYCTRL_FREQSEL_200M;
> +	unsigned long rate;
>  	unsigned long timeout;
>  
> -	if (rk_phy->emmcclk != NULL) {
> -		unsigned long rate = clk_get_rate(rk_phy->emmcclk);
> +	/*
> +	 * Keep phyctrl_pdb and phyctrl_endll low to allow
> +	 * initialization of CALIO state M/C DFFs
> +	 */
> +	regmap_write(rk_phy->reg_base,
> +		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> +		     HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
> +				   PHYCTRL_PDB_MASK,
> +				   PHYCTRL_PDB_SHIFT));
> +	regmap_write(rk_phy->reg_base,
> +		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> +		     HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
> +				   PHYCTRL_ENDLL_MASK,
> +				   PHYCTRL_ENDLL_SHIFT));
> +
> +	/* Already finish power_off above */
> +	if (on_off == PHYCTRL_PDB_PWR_OFF)
> +		return 0;
> +
> +	rate = clk_get_rate(rk_phy->emmcclk);
> +
> +	if (rate != 0) {
>  		unsigned long ideal_rate;
>  		unsigned long diff;
>  
>  		switch (rate) {
> -		case 0 ... 74999999:
> +		case 1 ... 74999999:
>  			ideal_rate = 50000000;
>  			freqsel = PHYCTRL_FREQSEL_50M;
>  			break;
> @@ -127,25 +148,6 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  	}
>  
>  	/*
> -	 * Keep phyctrl_pdb and phyctrl_endll low to allow
> -	 * initialization of CALIO state M/C DFFs
> -	 */
> -	regmap_write(rk_phy->reg_base,
> -		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> -		     HIWORD_UPDATE(PHYCTRL_PDB_PWR_OFF,
> -				   PHYCTRL_PDB_MASK,
> -				   PHYCTRL_PDB_SHIFT));
> -	regmap_write(rk_phy->reg_base,
> -		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
> -		     HIWORD_UPDATE(PHYCTRL_ENDLL_DISABLE,
> -				   PHYCTRL_ENDLL_MASK,
> -				   PHYCTRL_ENDLL_SHIFT));
> -
> -	/* Already finish power_off above */
> -	if (on_off == PHYCTRL_PDB_PWR_OFF)
> -		return 0;
> -
> -	/*
>  	 * According to the user manual, calpad calibration
>  	 * cycle takes more than 2us without the minimal recommended
>  	 * value, so we may need a little margin here
> @@ -183,6 +185,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  		     HIWORD_UPDATE(PHYCTRL_ENDLL_ENABLE,
>  				   PHYCTRL_ENDLL_MASK,
>  				   PHYCTRL_ENDLL_SHIFT));
> +
> +	/*
> +	 * We turned on the DLL even though the rate was 0 because we the
> +	 * clock might be turned on later.  ...but we can't wait for the DLL
> +	 * to lock when the rate is 0 because it will never lock with no
> +	 * input clock.
> +	 *
> +	 * Technically we should be checking the lock later when the clock
> +	 * is turned on, but for now we won't.
> +	 */
> +	if (rate == 0)
> +		return 0;

Why not return initially from rockchip_emmc_phy_power if the clock rate is '0'.
Are there other functions to lock the DLL apart from phy_power?

Thanks
Kishon

  parent reply	other threads:[~2016-06-29 13:49 UTC|newest]

Thread overview: 28+ 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
     [not found]   ` <1467049167-14628-3-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2016-06-29 13:49     ` Kishon Vijay Abraham I [this message]
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-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  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-06-27 17:39 ` [PATCH 3/3] phy: rockchip-emmc: Wait even longer for the DLL to lock Douglas Anderson
2016-06-27 17:39   ` Douglas Anderson
     [not found]   ` <1467049167-14628-4-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
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=5773D1FD.8020601@ti.com \
    --to=kishon-l0cymroini0@public.gmane.org \
    --cc=briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
    --cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.