All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter De Schrijver <pdeschrijver@nvidia.com>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org, linux-clk@vger.kernel.org,
	mturquette@baylibre.com, sboyd@codeaurora.org,
	robh+dt@kernel.org, mark.rutland@arm.com,
	devicetree@vger.kernel.org, lgirdwood@gmail.com,
	broonie@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/11] cpufreq: tegra124-cpufreq: extend to support Tegra210
Date: Tue, 13 Mar 2018 11:51:17 +0200	[thread overview]
Message-ID: <20180313095117.GX6190@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <85edea04-6aaf-3609-1da9-0d542ac98e7d@nvidia.com>

On Mon, Mar 12, 2018 at 12:15:22PM +0000, Jon Hunter wrote:
> 
> On 06/02/18 16:34, Peter De Schrijver wrote:
> > Tegra210 has a very similar CPU clocking scheme than Tegra124. So add
> > support in this driver. Also allow for the case where the CPU voltage is
> > controlled directly by the DFLL rather than by a separate regulator object.
> > 
> > Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> > ---
> >  drivers/cpufreq/tegra124-cpufreq.c | 15 ++++++++-------
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c
> > index 4353025..f8e01a8 100644
> > --- a/drivers/cpufreq/tegra124-cpufreq.c
> > +++ b/drivers/cpufreq/tegra124-cpufreq.c
> > @@ -64,7 +64,8 @@ static void tegra124_cpu_switch_to_pllx(struct tegra124_cpufreq_priv *priv)
> >  {
> >  	clk_set_parent(priv->cpu_clk, priv->pllp_clk);
> >  	clk_disable_unprepare(priv->dfll_clk);
> > -	regulator_sync_voltage(priv->vdd_cpu_reg);
> > +	if (priv->vdd_cpu_reg)
> > +		regulator_sync_voltage(priv->vdd_cpu_reg);
> >  	clk_set_parent(priv->cpu_clk, priv->pllx_clk);
> >  }
> 
> OK, so this bit does not make sense to me. In the above we are switching
> from the DFLL to the PLL (ie. disabling the DFLL) and so to ensure we
> are operating at the correct voltage after disabling the DFLL we need to
> sync the voltage. Seems we would need to do this for all devices, no?
> How is the different between Tegra124 and Tegra210?

Yes. So in case of i2c the regulator framework will reapply the voltage it
knows which in our case is the boot voltage for VDD_CPU because noone else
from a regulator framework pov has ever changed the voltage. In case of PWM
putting the PWM output pad in tri state will cause the OVR regulator to output
a hardware defined voltage. This is done as part of the dfll_clk_disable()
function. To summarize:

switch from pll_x to DFLL for i2c regulator:

entry: voltage is boot voltage set bootloader
1) set dfll rate to pll_x rate
2) set parent to pll_p so we run at 408MHz which is below Fmax@Vmin when
   running from PLL
3) enable DFLL this will switch to closed loop mode and start controlling
   the voltage via i2c, however because we are below Fmax@Vmin there's no
   V/f curve violation.
4) change parent from pll_x to DFLL

switch from DFLL to pll_x for i2c regulator:

entry: voltage is whatever the DFLL has programmed but not lower than Vmin
1) set parent to pll_p so we run at 408MHz (below Fmax@Vmin)
2) disable DFLL, this will cause the voltage to be the last value programmed
   by the DFLL.
3) go back to the voltage as programmed by the boot loader using
   regulator_sync_voltage().
4) change parent from DFLL to pll_x. Because pll_x is still programmed at
   the bootloader frequency, we're within the V/f curve.

switch from pll_x to DFLL for PWM regulator:

entry: voltage is boot voltage set by hardware because PWM pin is in tristate
1) set dfll rate to pll_x rate
2) set parent to pll_p so we run at 408MHz which is below Fmax@Vmin when
   running from PLL
3) enable DFLL this will set the PWM pad to output, switch to closed loop mode
   and start controlling the voltage via PWM, however because we are below
   Fmax@Vmin there's no V/f curve violation.
4) change parent from pll_x to DFLL

switch from DFLL to pll_x for PWM regulator:

entry: voltage is whatever the DFLL has programmed but not lower than Vmin
1) set parent to pll_p so we run at 408MHz (below Fmax@Vmin)
2) disable DFLL, this will cause the PWM pad to be programmed to tristate
   and the voltage to change back to the hardware defined voltage.
3) change parent from DFLL to pll_x. Because pll_x is still programmed at
   the bootloader frequency, we're within the V/f curve.

Peter.

WARNING: multiple messages have this Message-ID (diff)
From: Peter De Schrijver <pdeschrijver@nvidia.com>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: <linux-tegra@vger.kernel.org>, <linux-clk@vger.kernel.org>,
	<mturquette@baylibre.com>, <sboyd@codeaurora.org>,
	<robh+dt@kernel.org>, <mark.rutland@arm.com>,
	<devicetree@vger.kernel.org>, <lgirdwood@gmail.com>,
	<broonie@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 09/11] cpufreq: tegra124-cpufreq: extend to support Tegra210
Date: Tue, 13 Mar 2018 11:51:17 +0200	[thread overview]
Message-ID: <20180313095117.GX6190@tbergstrom-lnx.Nvidia.com> (raw)
In-Reply-To: <85edea04-6aaf-3609-1da9-0d542ac98e7d@nvidia.com>

On Mon, Mar 12, 2018 at 12:15:22PM +0000, Jon Hunter wrote:
> 
> On 06/02/18 16:34, Peter De Schrijver wrote:
> > Tegra210 has a very similar CPU clocking scheme than Tegra124. So add
> > support in this driver. Also allow for the case where the CPU voltage is
> > controlled directly by the DFLL rather than by a separate regulator object.
> > 
> > Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> > ---
> >  drivers/cpufreq/tegra124-cpufreq.c | 15 ++++++++-------
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c
> > index 4353025..f8e01a8 100644
> > --- a/drivers/cpufreq/tegra124-cpufreq.c
> > +++ b/drivers/cpufreq/tegra124-cpufreq.c
> > @@ -64,7 +64,8 @@ static void tegra124_cpu_switch_to_pllx(struct tegra124_cpufreq_priv *priv)
> >  {
> >  	clk_set_parent(priv->cpu_clk, priv->pllp_clk);
> >  	clk_disable_unprepare(priv->dfll_clk);
> > -	regulator_sync_voltage(priv->vdd_cpu_reg);
> > +	if (priv->vdd_cpu_reg)
> > +		regulator_sync_voltage(priv->vdd_cpu_reg);
> >  	clk_set_parent(priv->cpu_clk, priv->pllx_clk);
> >  }
> 
> OK, so this bit does not make sense to me. In the above we are switching
> from the DFLL to the PLL (ie. disabling the DFLL) and so to ensure we
> are operating at the correct voltage after disabling the DFLL we need to
> sync the voltage. Seems we would need to do this for all devices, no?
> How is the different between Tegra124 and Tegra210?

Yes. So in case of i2c the regulator framework will reapply the voltage it
knows which in our case is the boot voltage for VDD_CPU because noone else
from a regulator framework pov has ever changed the voltage. In case of PWM
putting the PWM output pad in tri state will cause the OVR regulator to output
a hardware defined voltage. This is done as part of the dfll_clk_disable()
function. To summarize:

switch from pll_x to DFLL for i2c regulator:

entry: voltage is boot voltage set bootloader
1) set dfll rate to pll_x rate
2) set parent to pll_p so we run at 408MHz which is below Fmax@Vmin when
   running from PLL
3) enable DFLL this will switch to closed loop mode and start controlling
   the voltage via i2c, however because we are below Fmax@Vmin there's no
   V/f curve violation.
4) change parent from pll_x to DFLL

switch from DFLL to pll_x for i2c regulator:

entry: voltage is whatever the DFLL has programmed but not lower than Vmin
1) set parent to pll_p so we run at 408MHz (below Fmax@Vmin)
2) disable DFLL, this will cause the voltage to be the last value programmed
   by the DFLL.
3) go back to the voltage as programmed by the boot loader using
   regulator_sync_voltage().
4) change parent from DFLL to pll_x. Because pll_x is still programmed at
   the bootloader frequency, we're within the V/f curve.

switch from pll_x to DFLL for PWM regulator:

entry: voltage is boot voltage set by hardware because PWM pin is in tristate
1) set dfll rate to pll_x rate
2) set parent to pll_p so we run at 408MHz which is below Fmax@Vmin when
   running from PLL
3) enable DFLL this will set the PWM pad to output, switch to closed loop mode
   and start controlling the voltage via PWM, however because we are below
   Fmax@Vmin there's no V/f curve violation.
4) change parent from pll_x to DFLL

switch from DFLL to pll_x for PWM regulator:

entry: voltage is whatever the DFLL has programmed but not lower than Vmin
1) set parent to pll_p so we run at 408MHz (below Fmax@Vmin)
2) disable DFLL, this will cause the PWM pad to be programmed to tristate
   and the voltage to change back to the hardware defined voltage.
3) change parent from DFLL to pll_x. Because pll_x is still programmed at
   the bootloader frequency, we're within the V/f curve.

Peter.

  reply	other threads:[~2018-03-13  9:51 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-06 16:34 [PATCH v3 00/11] Tegra210 DFLL implementation Peter De Schrijver
2018-02-06 16:34 ` Peter De Schrijver
     [not found] ` <1517934852-23255-1-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-02-06 16:34   ` [PATCH v3 01/11] regulator: core: add API to get voltage constraints Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-02-06 16:35     ` Mark Brown
     [not found]       ` <20180206163544.GI5681-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2018-02-07  8:47         ` Peter De Schrijver
2018-02-07  8:47           ` Peter De Schrijver
2018-02-07 10:43           ` Mark Brown
     [not found]             ` <20180207104351.GA6003-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2018-02-07 12:37               ` Peter De Schrijver
2018-02-07 12:37                 ` Peter De Schrijver
     [not found]                 ` <20180207123750.GA5850-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2018-02-07 14:18                   ` Mark Brown
2018-02-07 14:18                     ` Mark Brown
2018-02-07 14:32                     ` Peter De Schrijver
2018-02-07 14:32                       ` Peter De Schrijver
     [not found]                       ` <20180207143213.GB5850-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2018-02-07 15:01                         ` Mark Brown
2018-02-07 15:01                           ` Mark Brown
2018-02-07 15:20                           ` Peter De Schrijver
2018-02-07 15:20                             ` Peter De Schrijver
     [not found]                             ` <20180207152045.GC5850-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2018-02-07 15:37                               ` Mark Brown
2018-02-07 15:37                                 ` Mark Brown
     [not found]                                 ` <20180207153711.GE6003-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2018-02-08 10:04                                   ` Laxman Dewangan
2018-02-08 10:04                                     ` Laxman Dewangan
     [not found]                                     ` <86cd40ac-d255-f4b9-87cb-0cd34efba7d8-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-02-08 14:58                                       ` Mark Brown
2018-02-08 14:58                                         ` Mark Brown
2018-02-06 16:34   ` [PATCH v3 02/11] clk: tegra: retrieve regulator info from framework Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:26     ` Jon Hunter
2018-03-08 22:26       ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 03/11] clk: tegra: dfll registration for multiple SoCs Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:15     ` Jon Hunter
2018-03-08 22:15       ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 04/11] clk: tegra: add CVB tables for Tegra210 CPU DFLL Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:28     ` Jon Hunter
2018-03-08 22:28       ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 05/11] clk: tegra: prepare dfll driver for PWM regulator Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 22:50     ` Jon Hunter
2018-03-08 22:50       ` Jon Hunter
2018-03-12  9:14       ` Peter De Schrijver
2018-03-12  9:14         ` Peter De Schrijver
2018-03-12 11:08         ` Jon Hunter
2018-03-12 11:08           ` Jon Hunter
2018-03-13  9:03           ` Peter De Schrijver
2018-03-13  9:03             ` Peter De Schrijver
2018-03-13 10:07             ` Jon Hunter
2018-03-13 10:07               ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 07/11] dt-bindings: tegra: Update DFLL binding " Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
     [not found]     ` <1517934852-23255-8-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-02-09 23:19       ` Rob Herring
2018-02-09 23:19         ` Rob Herring
2018-03-08 23:21     ` Jon Hunter
2018-03-08 23:21       ` Jon Hunter
2018-03-12  9:10       ` Peter De Schrijver
2018-03-12  9:10         ` Peter De Schrijver
2018-02-06 16:34   ` [PATCH v3 09/11] cpufreq: tegra124-cpufreq: extend to support Tegra210 Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-03-08 23:25     ` Jon Hunter
2018-03-08 23:25       ` Jon Hunter
2018-03-09  8:14       ` Peter De Schrijver
2018-03-09  8:14         ` Peter De Schrijver
2018-03-12 10:14         ` Jon Hunter
2018-03-12 10:14           ` Jon Hunter
2018-03-13  9:28           ` Peter De Schrijver
2018-03-13  9:28             ` Peter De Schrijver
2018-03-09  9:11     ` Viresh Kumar
2018-03-12 12:15     ` Jon Hunter
2018-03-12 12:15       ` Jon Hunter
2018-03-13  9:51       ` Peter De Schrijver [this message]
2018-03-13  9:51         ` Peter De Schrijver
2018-03-13 10:20         ` Jon Hunter
2018-03-13 10:20           ` Jon Hunter
2018-02-06 16:34   ` [PATCH v3 10/11] arm64: dts: tegra: Add Tegra210 DFLL definition Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-02-06 16:34   ` [PATCH v3 11/11] arm64: dts: nvidia: Tegra210 CPU clock definition Peter De Schrijver
2018-02-06 16:34     ` Peter De Schrijver
2018-02-06 16:34 ` [PATCH v3 06/11] clk: tegra: dfll: support PWM regulator control Peter De Schrijver
2018-02-06 16:34   ` Peter De Schrijver
2018-03-08 23:15   ` Jon Hunter
2018-03-08 23:15     ` Jon Hunter
2018-03-09  8:12     ` Peter De Schrijver
2018-03-09  8:12       ` Peter De Schrijver
2018-02-06 16:34 ` [PATCH v3 08/11] clk: tegra: build clk-dfll.c for Tegra124 and Tegra210 Peter De Schrijver
2018-02-06 16:34   ` Peter De Schrijver
2018-03-08 23:22   ` Jon Hunter
2018-03-08 23:22     ` Jon Hunter

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=20180313095117.GX6190@tbergstrom-lnx.Nvidia.com \
    --to=pdeschrijver@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.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.