All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-pm@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH] cpufreq: tegra: add regulator dependency for T124
Date: Thu, 10 Dec 2015 12:12:11 +0000	[thread overview]
Message-ID: <56696C1B.3010503@nvidia.com> (raw)
In-Reply-To: <20151210113541.GL5727@sirena.org.uk>


On 10/12/15 11:35, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Thu, Dec 10, 2015 at 10:07:54AM +0000, Jon Hunter wrote:
>> On 09/12/15 20:10, Mark Brown wrote:
>>> On Wed, Dec 09, 2015 at 05:33:33PM +0000, Jon Hunter wrote:
> 
>>>> Yes, setting the frequency and voltage as defined by a given operating
>>>> mode would make sense. However, I am not sure we have those defined in
>>>> the kernel for this PLL and would have to be added.
> 
>>> I think given how you're describing the hardware that this will be
>>> required in order to provide something robust (and also to get the best
>>> power savings from the hardware).
> 
>> Yes I agree it would be more robust. However, if you care about power
>> savings then you should be using the DFLL/cpufreq anyway.
> 
> Without knowing anything about the hardware this is all a bit confusing
> I'm afraid.  What is "DFLL/cpufreq" as opposed to "the PLL"?

No problem.

The two main clocks sources (there are others) used for the CPU complex
are the PLLX and the DFLL. The PLLX is a normal PLL and you can
configure to run at various frequencies. However, this PLL requires that
you/software set the voltage appropriately. The DFLL has the ability to
control the voltage itself per the frequency requested (no software
management of the voltage required).

There is no reason why you could not use the PLLX in conjunction with
cpufreq, but for T124 we use the DFLL.

Typically, T124 will boot using the PLLX and then if cpufreq is enabled,
the DFLL will be enabled and we will switch to this clock.

We would only ever switch back to the PLLX if cpufreq is removed and
hence the DFLL is disabled. And this is where this patch comes in and I
am wondering if this has ever been tested.

>> From testing the t124 jetson and nyan-big, both of these boards have a
>> different configuration for the PLL at boot time, so although we could
>> pick a safe operating point for all t124 boards, I was thinking of just
>> restoring their initial configuration.
> 
> This seems more complex, and also makes the idea of relying on the
> initial configuration seem slightly concerning - other software seems to
> be already changing the configuration before we get to the kernel so if
> we don't fully understand the configuration we're doing we seem likely
> to find some configuration where we miss things.

I don't think so. At probe time for cpufreq, we know the clock source
for the CPU complex and we can query the voltage and frequency. You may
say what happens if you are already running from the DFLL that happened
to be setup by the bootloader? It is probably not likely as there is
more software setup involved before you can enable the DFLL. However, it
could be handled.

By the way, I am not saying that we should do this, but if we don't we
need to define a safe/default V-F for all devices to operate at. I guess
that it could also be specified in the DTB and if not we use a default.

Jon

WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>, <linux-pm@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Alexandre Courbot <gnurou@gmail.com>,
	<linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>
Subject: Re: [PATCH] cpufreq: tegra: add regulator dependency for T124
Date: Thu, 10 Dec 2015 12:12:11 +0000	[thread overview]
Message-ID: <56696C1B.3010503@nvidia.com> (raw)
In-Reply-To: <20151210113541.GL5727@sirena.org.uk>


On 10/12/15 11:35, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Thu, Dec 10, 2015 at 10:07:54AM +0000, Jon Hunter wrote:
>> On 09/12/15 20:10, Mark Brown wrote:
>>> On Wed, Dec 09, 2015 at 05:33:33PM +0000, Jon Hunter wrote:
> 
>>>> Yes, setting the frequency and voltage as defined by a given operating
>>>> mode would make sense. However, I am not sure we have those defined in
>>>> the kernel for this PLL and would have to be added.
> 
>>> I think given how you're describing the hardware that this will be
>>> required in order to provide something robust (and also to get the best
>>> power savings from the hardware).
> 
>> Yes I agree it would be more robust. However, if you care about power
>> savings then you should be using the DFLL/cpufreq anyway.
> 
> Without knowing anything about the hardware this is all a bit confusing
> I'm afraid.  What is "DFLL/cpufreq" as opposed to "the PLL"?

No problem.

The two main clocks sources (there are others) used for the CPU complex
are the PLLX and the DFLL. The PLLX is a normal PLL and you can
configure to run at various frequencies. However, this PLL requires that
you/software set the voltage appropriately. The DFLL has the ability to
control the voltage itself per the frequency requested (no software
management of the voltage required).

There is no reason why you could not use the PLLX in conjunction with
cpufreq, but for T124 we use the DFLL.

Typically, T124 will boot using the PLLX and then if cpufreq is enabled,
the DFLL will be enabled and we will switch to this clock.

We would only ever switch back to the PLLX if cpufreq is removed and
hence the DFLL is disabled. And this is where this patch comes in and I
am wondering if this has ever been tested.

>> From testing the t124 jetson and nyan-big, both of these boards have a
>> different configuration for the PLL at boot time, so although we could
>> pick a safe operating point for all t124 boards, I was thinking of just
>> restoring their initial configuration.
> 
> This seems more complex, and also makes the idea of relying on the
> initial configuration seem slightly concerning - other software seems to
> be already changing the configuration before we get to the kernel so if
> we don't fully understand the configuration we're doing we seem likely
> to find some configuration where we miss things.

I don't think so. At probe time for cpufreq, we know the clock source
for the CPU complex and we can query the voltage and frequency. You may
say what happens if you are already running from the DFLL that happened
to be setup by the bootloader? It is probably not likely as there is
more software setup involved before you can enable the DFLL. However, it
could be handled.

By the way, I am not saying that we should do this, but if we don't we
need to define a safe/default V-F for all devices to operate at. I guess
that it could also be specified in the DTB and if not we use a default.

Jon

WARNING: multiple messages have this Message-ID (diff)
From: jonathanh@nvidia.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] cpufreq: tegra: add regulator dependency for T124
Date: Thu, 10 Dec 2015 12:12:11 +0000	[thread overview]
Message-ID: <56696C1B.3010503@nvidia.com> (raw)
In-Reply-To: <20151210113541.GL5727@sirena.org.uk>


On 10/12/15 11:35, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> On Thu, Dec 10, 2015 at 10:07:54AM +0000, Jon Hunter wrote:
>> On 09/12/15 20:10, Mark Brown wrote:
>>> On Wed, Dec 09, 2015 at 05:33:33PM +0000, Jon Hunter wrote:
> 
>>>> Yes, setting the frequency and voltage as defined by a given operating
>>>> mode would make sense. However, I am not sure we have those defined in
>>>> the kernel for this PLL and would have to be added.
> 
>>> I think given how you're describing the hardware that this will be
>>> required in order to provide something robust (and also to get the best
>>> power savings from the hardware).
> 
>> Yes I agree it would be more robust. However, if you care about power
>> savings then you should be using the DFLL/cpufreq anyway.
> 
> Without knowing anything about the hardware this is all a bit confusing
> I'm afraid.  What is "DFLL/cpufreq" as opposed to "the PLL"?

No problem.

The two main clocks sources (there are others) used for the CPU complex
are the PLLX and the DFLL. The PLLX is a normal PLL and you can
configure to run at various frequencies. However, this PLL requires that
you/software set the voltage appropriately. The DFLL has the ability to
control the voltage itself per the frequency requested (no software
management of the voltage required).

There is no reason why you could not use the PLLX in conjunction with
cpufreq, but for T124 we use the DFLL.

Typically, T124 will boot using the PLLX and then if cpufreq is enabled,
the DFLL will be enabled and we will switch to this clock.

We would only ever switch back to the PLLX if cpufreq is removed and
hence the DFLL is disabled. And this is where this patch comes in and I
am wondering if this has ever been tested.

>> From testing the t124 jetson and nyan-big, both of these boards have a
>> different configuration for the PLL at boot time, so although we could
>> pick a safe operating point for all t124 boards, I was thinking of just
>> restoring their initial configuration.
> 
> This seems more complex, and also makes the idea of relying on the
> initial configuration seem slightly concerning - other software seems to
> be already changing the configuration before we get to the kernel so if
> we don't fully understand the configuration we're doing we seem likely
> to find some configuration where we miss things.

I don't think so. At probe time for cpufreq, we know the clock source
for the CPU complex and we can query the voltage and frequency. You may
say what happens if you are already running from the DFLL that happened
to be setup by the bootloader? It is probably not likely as there is
more software setup involved before you can enable the DFLL. However, it
could be handled.

By the way, I am not saying that we should do this, but if we don't we
need to define a safe/default V-F for all devices to operate at. I guess
that it could also be specified in the DTB and if not we use a default.

Jon

  reply	other threads:[~2015-12-10 12:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 21:52 [PATCH] cpufreq: tegra: add regulator dependency for T124 Arnd Bergmann
2015-12-08 21:52 ` Arnd Bergmann
2015-12-08 21:52 ` Arnd Bergmann
2015-12-09  2:16 ` Viresh Kumar
2015-12-09  2:16   ` Viresh Kumar
2015-12-09 12:03 ` Jon Hunter
2015-12-09 12:03   ` Jon Hunter
2015-12-09 12:03   ` Jon Hunter
     [not found]   ` <5668188F.2080202-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-12-09 14:47     ` Mark Brown
2015-12-09 14:47       ` Mark Brown
2015-12-09 14:47       ` Mark Brown
2015-12-09 17:33       ` Jon Hunter
2015-12-09 17:33         ` Jon Hunter
2015-12-09 17:33         ` Jon Hunter
2015-12-09 20:10         ` Mark Brown
2015-12-09 20:10           ` Mark Brown
2015-12-10 10:07           ` Jon Hunter
2015-12-10 10:07             ` Jon Hunter
2015-12-10 10:07             ` Jon Hunter
2015-12-10 10:07             ` Jon Hunter
     [not found]             ` <56694EFA.7010901-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2015-12-10 11:35               ` Mark Brown
2015-12-10 11:35                 ` Mark Brown
2015-12-10 11:35                 ` Mark Brown
2015-12-10 12:12                 ` Jon Hunter [this message]
2015-12-10 12:12                   ` Jon Hunter
2015-12-10 12:12                   ` Jon Hunter
2015-12-12  2:26 ` Rafael J. Wysocki
2015-12-12  2:26   ` Rafael J. Wysocki
2015-12-12  2:26   ` Rafael J. Wysocki

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=56696C1B.3010503@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=gnurou@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=swarren@wwwdotorg.org \
    --cc=thierry.reding@gmail.com \
    --cc=viresh.kumar@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.