Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420636 > unrolled thread

Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on  card clock Shawn Lin <shawn.lin@rock-chips.com> - 2016-06-13 11:00 +0200
    Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on  card clock Doug Anderson <dianders@chromium.org> - 2016-06-14 01:10 +0200
      Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on  card clock Shawn Lin <shawn.lin@rock-chips.com> - 2016-06-14 02:30 +0200
        Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on  card clock Doug Anderson <dianders@chromium.org> - 2016-06-14 02:50 +0200

#1420636 — Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

On 2016/6/8 6:44, Douglas Anderson wrote:
> 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.

Thanks for doing this, but I think we should limit freq if assigning
max-frequency from DT more explicitly since the PHY could only support
50/100/150/200M for hs200/400? Otherwise I can't say if the PHY could
always work well. i.e if geting 125000000 ... 174999999 , you code make
the phyctrl_frqsel to be 150M, so it will be 15% missing of precision
for tuning delay element. Ideally, the sample point should be in the
middle of window, but I don't know if there is a bad HW	design makes
the window small enough which need special care about it.



>
> [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>  drivers/phy/phy-rockchip-emmc.c | 74 +++++++++++++++++++++++++++++++----------
>  1 file changed, 57 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/phy/phy-rockchip-emmc.c b/drivers/phy/phy-rockchip-emmc.c
> index 8336053aea5c..0fce7359d468 100644
> --- a/drivers/phy/phy-rockchip-emmc.c
> +++ b/drivers/phy/phy-rockchip-emmc.c
> @@ -14,6 +14,7 @@
>   * GNU General Public License for more details.
>   */
>
> +#include <linux/clk.h>
>  #include <linux/delay.h>
>  #include <linux/mfd/syscon.h>
>  #include <linux/module.h>
> @@ -78,16 +79,61 @@
>  struct rockchip_emmc_phy {
>  	unsigned int	reg_offset;
>  	struct regmap	*reg_base;
> +	struct clk	*emmcclk;
>  };
>
> -static int rockchip_emmc_phy_power(struct rockchip_emmc_phy *rk_phy,
> -				   bool on_off)
> +static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>  {
> +	struct rockchip_emmc_phy *rk_phy = phy_get_drvdata(phy);
>  	unsigned int caldone;
>  	unsigned int dllrdy;
> +	unsigned int freqsel = PHYCTRL_FREQSEL_200M;
>  	unsigned long timeout;
>
>  	/*
> +	 * We purposely get the clock here and not in probe to avoid the
> +	 * circular dependency problem.  We expect:
> +	 * - PHY driver to probe
> +	 * - USB driver to start probe
> +	 * - USB driver to register it's clock
> +	 * - USB driver to get the PHY
> +	 * - USB driver to power on the PHY

USB?

> +	 */
> +	if (!rk_phy->emmcclk) {
> +		rk_phy->emmcclk = devm_clk_get(&phy->dev, "emmcclk");
> +
> +		/* Don't expect defer at this point; try next time */
> +		if (PTR_ERR(rk_phy->emmcclk) == -EPROBE_DEFER) {
> +			dev_warn(&phy->dev, "Unexpected emmcclk defer\n");
> +			rk_phy->emmcclk = NULL;
> +		}
> +	}
> +
> +	if (!IS_ERR_OR_NULL(rk_phy->emmcclk)) {
> +		unsigned long rate = clk_get_rate(rk_phy->emmcclk);
> +
> +		switch (rate) {
> +		case 0 ... 74999999:
> +			/* Nominal  50 MHz */
> +			freqsel = PHYCTRL_FREQSEL_50M;
> +			break;
> +		case 75000000 ... 124999999:
> +			/* Nominal 100 MHz */
> +			freqsel = PHYCTRL_FREQSEL_100M;
> +			break;
> +		case 125000000 ... 174999999:
> +			/* Nominal 150 MHz */
> +			freqsel = PHYCTRL_FREQSEL_150M;
> +			break;
> +		default:
> +			if (rate > 200000000)
> +				dev_warn(&phy->dev, "Unsupported rate: %lu\n",
> +					 rate);
> +			break;
> +		};
> +	}
> +
> +	/*
>  	 * Keep phyctrl_pdb and phyctrl_endll low to allow
>  	 * initialization of CALIO state M/C DFFs
>  	 */
> @@ -132,6 +178,13 @@ static int rockchip_emmc_phy_power(struct rockchip_emmc_phy *rk_phy,
>  		return -ETIMEDOUT;
>  	}
>
> +	/* Set the frequency of the DLL operation */
> +	regmap_write(rk_phy->reg_base,
> +		     rk_phy->reg_offset + GRF_EMMCPHY_CON0,
> +		     HIWORD_UPDATE(freqsel, PHYCTRL_FREQSEL_MASK,
> +				   PHYCTRL_FREQSEL_SHIFT));
> +
> +	/* Turn on the DLL */
>  	regmap_write(rk_phy->reg_base,
>  		     rk_phy->reg_offset + GRF_EMMCPHY_CON6,
>  		     HIWORD_UPDATE(PHYCTRL_ENDLL_ENABLE,
> @@ -167,15 +220,8 @@ static int rockchip_emmc_phy_power(struct rockchip_emmc_phy *rk_phy,
>
>  static int rockchip_emmc_phy_power_off(struct phy *phy)
>  {
> -	struct rockchip_emmc_phy *rk_phy = phy_get_drvdata(phy);
> -	int ret = 0;
> -
>  	/* Power down emmc phy analog blocks */
> -	ret = rockchip_emmc_phy_power(rk_phy, PHYCTRL_PDB_PWR_OFF);
> -	if (ret)
> -		return ret;
> -
> -	return 0;
> +	return rockchip_emmc_phy_power(phy, PHYCTRL_PDB_PWR_OFF);
>  }
>
>  static int rockchip_emmc_phy_power_on(struct phy *phy)
> @@ -183,12 +229,6 @@ static int rockchip_emmc_phy_power_on(struct phy *phy)
>  	struct rockchip_emmc_phy *rk_phy = phy_get_drvdata(phy);
>  	int ret = 0;
>
> -	/* DLL operation: 200 MHz */
> -	regmap_write(rk_phy->reg_base,
> -		     rk_phy->reg_offset + GRF_EMMCPHY_CON0,
> -		     HIWORD_UPDATE(PHYCTRL_FREQSEL_200M,
> -				   PHYCTRL_FREQSEL_MASK,
> -				   PHYCTRL_FREQSEL_SHIFT));
>
>  	/* Drive impedance: 50 Ohm */
>  	regmap_write(rk_phy->reg_base,
> @@ -212,7 +252,7 @@ static int rockchip_emmc_phy_power_on(struct phy *phy)
>  				   PHYCTRL_OTAPDLYSEL_SHIFT));
>
>  	/* Power up emmc phy analog blocks */
> -	ret = rockchip_emmc_phy_power(rk_phy, PHYCTRL_PDB_PWR_ON);
> +	ret = rockchip_emmc_phy_power(phy, PHYCTRL_PDB_PWR_ON);
>  	if (ret)
>  		return ret;
>
>


-- 
Best Regards
Shawn Lin

[toc] | [next] | [standalone]

#1421438

Shawn,

On Mon, Jun 13, 2016 at 1:54 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> On 2016/6/8 6:44, Douglas Anderson wrote:
>>
>> 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.
>
>
> Thanks for doing this, but I think we should limit freq if assigning
> max-frequency from DT more explicitly since the PHY could only support
> 50/100/150/200M for hs200/400? Otherwise I can't say if the PHY could
> always work well. i.e if geting 125000000 ... 174999999 , you code make
> the phyctrl_frqsel to be 150M, so it will be 15% missing of precision
> for tuning delay element. Ideally, the sample point should be in the
> middle of window, but I don't know if there is a bad HW design makes
> the window small enough which need special care about it.

What would you suggest as a valid range, then?

From the public Arasan datasheet they seem to indicate +/- 15 MHz is
sane.  Does that sound OK?  Presuming that all of your numbers
(50/100/150/200) are centers, that means that we could support clock
rates of:

35 MHz - 65 MHz
85 MHz - 115 MHz
135 MHz - 165 MHz
185 MHz - 200 MHz


So how about if we add a warning for things that are outside of those
ranges?  ...except no warning for < 35 MHz since presumably we're not
using high speed modes when the DLL is that slow and so we're OK.


NOTE: In rk3399 it's actually quite important to handle clocks that
aren't exactly the right MHz.  When you ask for 150 MHz you actually
end up a child of GPLL and actually end up at 148.5 MHz.  This should
be close enough, but it's not exactly 150 MHz.  If we can't handle
148.5 MHz then the 150 MHz setting in the PHY is useless.

Also note that on rk3399 we're fairly limited on the number of rates
we can actually make since they need to be even divisors of 594 MHz or
800 MHz (assuming you don't rejigger all the PLLs in the SoC or
something).  Most of the rates are actually in those ranges...


-Doug

[toc] | [prev] | [next] | [standalone]

#1421467

在 2016/6/14 7:05, Doug Anderson 写道:
> Shawn,
>
> On Mon, Jun 13, 2016 at 1:54 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>> On 2016/6/8 6:44, Douglas Anderson wrote:
>>>
>>> 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.
>>
>>
>> Thanks for doing this, but I think we should limit freq if assigning
>> max-frequency from DT more explicitly since the PHY could only support
>> 50/100/150/200M for hs200/400? Otherwise I can't say if the PHY could
>> always work well. i.e if geting 125000000 ... 174999999 , you code make
>> the phyctrl_frqsel to be 150M, so it will be 15% missing of precision
>> for tuning delay element. Ideally, the sample point should be in the
>> middle of window, but I don't know if there is a bad HW design makes
>> the window small enough which need special care about it.
>
> What would you suggest as a valid range, then?
>
>>From the public Arasan datasheet they seem to indicate +/- 15 MHz is
> sane.  Does that sound OK?  Presuming that all of your numbers
> (50/100/150/200) are centers, that means that we could support clock
> rates of:
>
> 35 MHz - 65 MHz
> 85 MHz - 115 MHz
> 135 MHz - 165 MHz
> 185 MHz - 200 MHz
>
>
> So how about if we add a warning for things that are outside of those
> ranges?  ...except no warning for < 35 MHz since presumably we're not
> using high speed modes when the DLL is that slow and so we're OK.

a warning should be ok.
If we ask 150M, but PLL only provide 175M maybe, then should we
fallback it to 150M or promote it to 200M when setting?

>
>
> NOTE: In rk3399 it's actually quite important to handle clocks that
> aren't exactly the right MHz.  When you ask for 150 MHz you actually
> end up a child of GPLL and actually end up at 148.5 MHz.  This should
> be close enough, but it's not exactly 150 MHz.  If we can't handle
> 148.5 MHz then the 150 MHz setting in the PHY is useless.
>
> Also note that on rk3399 we're fairly limited on the number of rates
> we can actually make since they need to be even divisors of 594 MHz or
> 800 MHz (assuming you don't rejigger all the PLLs in the SoC or
> something).  Most of the rates are actually in those ranges...

Yes I don't.

>
>
> -Doug
>
>
>


-- 
Best Regards
Shawn Lin

[toc] | [prev] | [next] | [standalone]

#1421477

Shawn,

On Mon, Jun 13, 2016 at 5:24 PM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>> From the public Arasan datasheet they seem to indicate +/- 15 MHz is
>>
>> sane.  Does that sound OK?  Presuming that all of your numbers
>> (50/100/150/200) are centers, that means that we could support clock
>> rates of:
>>
>> 35 MHz - 65 MHz
>> 85 MHz - 115 MHz
>> 135 MHz - 165 MHz
>> 185 MHz - 200 MHz
>>
>>
>> So how about if we add a warning for things that are outside of those
>> ranges?  ...except no warning for < 35 MHz since presumably we're not
>> using high speed modes when the DLL is that slow and so we're OK.
>
>
> a warning should be ok.
> If we ask 150M, but PLL only provide 175M maybe, then should we
> fallback it to 150M or promote it to 200M when setting?

I made it a warning in V2 but still picked the closest reasonable
value.  See what you think.  The PHY really isn't in control of this
clock, so the warning is the best it can do.  Presumably someone
designing a system with this PHY in it would see the warning an
realize that they should make SDHCI run at more reasonable rates...

-Doug

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web