linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock source
Date: Thu, 24 May 2018 08:37:50 +0300	[thread overview]
Message-ID: <56552c53-8868-af50-232e-b12e3c247ecd@gmail.com> (raw)
In-Reply-To: <20180524043040.25pld3ezs4lpabro@vireshk-i7>

On 24.05.2018 07:30, Viresh Kumar wrote:
> On 23-05-18, 19:00, Dmitry Osipenko wrote:
>> PLL_C is running at 600MHz which is significantly higher than the 216MHz
>> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
>> running on that PLL. Let's use PLL_C as intermediate clock source, making
>> CPU snappier a tad during of the frequency transition.
>>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>>  drivers/cpufreq/tegra20-cpufreq.c | 25 +++++++++++++++++++++----
>>  1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/cpufreq/tegra20-cpufreq.c b/drivers/cpufreq/tegra20-cpufreq.c
>> index 3ad6bded6efc..4bf5ba7da40b 100644
>> --- a/drivers/cpufreq/tegra20-cpufreq.c
>> +++ b/drivers/cpufreq/tegra20-cpufreq.c
>> @@ -25,12 +25,13 @@
>>  #include <linux/types.h>
>>  
>>  #define PLL_P_FREQ	216000
>> +#define PLL_C_FREQ	600000
>>  
>>  static struct cpufreq_frequency_table freq_table[] = {
>>  	{ .frequency = 216000 },
>>  	{ .frequency = 312000 },
>>  	{ .frequency = 456000 },
>> -	{ .frequency = 608000 },
>> +	{ .frequency = 600000 },
>>  	{ .frequency = 760000 },
>>  	{ .frequency = 816000 },
>>  	{ .frequency = 912000 },
>> @@ -44,6 +45,7 @@ struct tegra20_cpufreq {
>>  	struct clk *cpu_clk;
>>  	struct clk *pll_x_clk;
>>  	struct clk *pll_p_clk;
>> +	struct clk *pll_c_clk;
>>  	bool pll_x_prepared;
>>  };
>>  
>> @@ -58,7 +60,10 @@ static unsigned int tegra_get_intermediate(struct cpufreq_policy *policy,
>>  	if (index == 0 || policy->cur == PLL_P_FREQ)
>>  		return 0;
>>  
>> -	return PLL_P_FREQ;
>> +	if (index == 3 || policy->cur == PLL_C_FREQ)
>> +		return 0;
> 
> So we can choose between two different intermediate frequencies ? And
> I didn't like the way magic number 3 is used here. Its prone to errors
> and we better use a macro or something else here.
> 
> Like instead of doing index == 3, what about freq_table[index].freq ==
> PLL_C_FREQ ? Same for the previous patch as well.

The frequency is determined by the parent clock of CCLK (CPU clock), we can
choose between different parents for the CCLK. PLL_C as PLL_P and PLL_X are
among the available parents for the CCLK to choose from and there some others.

I don't mind to use freq_table[index].freq, though I'd like to keep compiled
assembly minimal where possible. Hence the freq_table should be made constant to
tell compiler that it doesn't need to emit data fetches for the table values and
could embed the constants into the code where appropriate.

Could we constify the "struct cpufreq_frequency_table" within the cpufreq core?
Seems nothing prevents this (I already tried to constify - there are no
obstacles), unless some cpufreq driver would try to modify
policy->freq_table->... within the cpufreq callback implementation.

  reply	other threads:[~2018-05-24  5:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-23 16:00 [PATCH v1 1/2] cpufreq: tegra20: Constify rate value of the intermediate clk Dmitry Osipenko
2018-05-23 16:00 ` [PATCH v1 2/2] cpufreq: tegra20: Use PLL_C as intermediate clock source Dmitry Osipenko
2018-05-24  4:30   ` Viresh Kumar
2018-05-24  5:37     ` Dmitry Osipenko [this message]
2018-05-24  8:01       ` Rafael J. Wysocki
2018-05-24 12:28         ` Dmitry Osipenko
2018-05-25  8:14           ` Rafael J. Wysocki
2018-05-25  8:36             ` Rafael J. Wysocki
2018-05-25  8:41               ` Dmitry Osipenko
2018-05-24 10:04   ` Peter De Schrijver
2018-05-24 12:49     ` Dmitry Osipenko
2018-05-25  6:32       ` Peter De Schrijver
2018-05-25  8:28         ` Dmitry Osipenko
2018-05-24  4:27 ` [PATCH v1 1/2] cpufreq: tegra20: Constify rate value of the intermediate clk Viresh Kumar

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=56552c53-8868-af50-232e-b12e3c247ecd@gmail.com \
    --to=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=rjw@rjwysocki.net \
    --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 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).