All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Weidong <wangweidong1@huawei.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: viresh.kumar@linaro.org, linux-pm@vger.kernel.org,
	"linux-kernel@vger.kernel.org >>
	\"linux-kernel@vger.kernel.org\"" <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
Date: Sat, 27 Sep 2014 13:32:59 +0800	[thread overview]
Message-ID: <54264C0B.1000607@huawei.com> (raw)
In-Reply-To: <2075276.PKjjuvNeys@vostro.rjw.lan>

On 2014/9/27 7:21, Rafael J. Wysocki wrote:
> On Thursday, August 21, 2014 01:55:15 PM Wang Weidong wrote:
>> As the initialized freq_tables maybe different from the p-states
>> values, so the array index is different as well.
>>
>> p-states value: [2400 2400 2000 ...], while the freq_tables:
>> [2400 2000 ... CPUFREQ_TABLE_END]. After setted the freqs 2000,
>> the perf->state is 3 while the freqs_table's index should be 2.
>> So when call the get_cur_freq_on_cpu, the freqs value we get
>> is 2400.
>>
>> So, fix the problem with the correct tables.
> 
> What you're saying is basically that freq_table and perf->states
> diverge at one point.  Shouldn't we re-generate freq_table in that
> case instead of fixing up get_cur_freq_on_cpu() only in a quite
> indirect way? 
> 
Hi Rafael,

Thanks for your reply.

You mean that we should re-generate the freq_table in that case?
Could we fix the table init like this:

--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -779,7 +779,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)

        /* table init */
        for (i = 0; i < perf->state_count; i++) {
-               if (i > 0 && perf->states[i].core_frequency >=
+               if (i > 0 && perf->states[i].core_frequency >
                    data->freq_table[valid_states-1].frequency / 1000)
                        continue;

when the value is same, we just keep the value into the freq_table.

Regards,
Wang

>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>> ---
>>  drivers/cpufreq/acpi-cpufreq.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
>> index b0c18ed..ac93885 100644
>> --- a/drivers/cpufreq/acpi-cpufreq.c
>> +++ b/drivers/cpufreq/acpi-cpufreq.c
>> @@ -365,6 +365,7 @@ static u32 get_cur_val(const struct cpumask *mask)
>>  static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
>>  {
>>  	struct acpi_cpufreq_data *data = per_cpu(acfreq_data, cpu);
>> +	struct acpi_processor_performance *perf;
>>  	unsigned int freq;
>>  	unsigned int cached_freq;
>>  
>> @@ -375,7 +376,8 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
>>  		return 0;
>>  	}
>>  
>> -	cached_freq = data->freq_table[data->acpi_data->state].frequency;
>> +	perf = data->acpi_data;
>> +	cached_freq = perf->states[perf->state].core_frequency * 1000;
>>  	freq = extract_freq(get_cur_val(cpumask_of(cpu)), data);
>>  	if (freq != cached_freq) {
>>  		/*
>>
> 



WARNING: multiple messages have this Message-ID (diff)
From: Wang Weidong <wangweidong1@huawei.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: <viresh.kumar@linaro.org>, <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org >>
	\"linux-kernel@vger.kernel.org\""  <linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
Date: Sat, 27 Sep 2014 13:32:59 +0800	[thread overview]
Message-ID: <54264C0B.1000607@huawei.com> (raw)
In-Reply-To: <2075276.PKjjuvNeys@vostro.rjw.lan>

On 2014/9/27 7:21, Rafael J. Wysocki wrote:
> On Thursday, August 21, 2014 01:55:15 PM Wang Weidong wrote:
>> As the initialized freq_tables maybe different from the p-states
>> values, so the array index is different as well.
>>
>> p-states value: [2400 2400 2000 ...], while the freq_tables:
>> [2400 2000 ... CPUFREQ_TABLE_END]. After setted the freqs 2000,
>> the perf->state is 3 while the freqs_table's index should be 2.
>> So when call the get_cur_freq_on_cpu, the freqs value we get
>> is 2400.
>>
>> So, fix the problem with the correct tables.
> 
> What you're saying is basically that freq_table and perf->states
> diverge at one point.  Shouldn't we re-generate freq_table in that
> case instead of fixing up get_cur_freq_on_cpu() only in a quite
> indirect way? 
> 
Hi Rafael,

Thanks for your reply.

You mean that we should re-generate the freq_table in that case?
Could we fix the table init like this:

--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -779,7 +779,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)

        /* table init */
        for (i = 0; i < perf->state_count; i++) {
-               if (i > 0 && perf->states[i].core_frequency >=
+               if (i > 0 && perf->states[i].core_frequency >
                    data->freq_table[valid_states-1].frequency / 1000)
                        continue;

when the value is same, we just keep the value into the freq_table.

Regards,
Wang

>> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
>> ---
>>  drivers/cpufreq/acpi-cpufreq.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
>> index b0c18ed..ac93885 100644
>> --- a/drivers/cpufreq/acpi-cpufreq.c
>> +++ b/drivers/cpufreq/acpi-cpufreq.c
>> @@ -365,6 +365,7 @@ static u32 get_cur_val(const struct cpumask *mask)
>>  static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
>>  {
>>  	struct acpi_cpufreq_data *data = per_cpu(acfreq_data, cpu);
>> +	struct acpi_processor_performance *perf;
>>  	unsigned int freq;
>>  	unsigned int cached_freq;
>>  
>> @@ -375,7 +376,8 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
>>  		return 0;
>>  	}
>>  
>> -	cached_freq = data->freq_table[data->acpi_data->state].frequency;
>> +	perf = data->acpi_data;
>> +	cached_freq = perf->states[perf->state].core_frequency * 1000;
>>  	freq = extract_freq(get_cur_val(cpumask_of(cpu)), data);
>>  	if (freq != cached_freq) {
>>  		/*
>>
> 



  reply	other threads:[~2014-09-27  5:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21  5:55 [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states Wang Weidong
2014-08-21  5:55 ` Wang Weidong
2014-08-25 13:41 ` Viresh Kumar
2014-09-26 23:21 ` Rafael J. Wysocki
2014-09-27  5:32   ` Wang Weidong [this message]
2014-09-27  5:32     ` Wang Weidong
2014-09-27 20:01     ` Rafael J. Wysocki
2014-09-30  7:09       ` Wang Weidong
2014-09-30  7:09         ` Wang Weidong

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=54264C0B.1000607@huawei.com \
    --to=wangweidong1@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --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.