[PATCH RESEND v2] acpi-cpufreq: make the freq_table store the same freq value

2014-12-26 Thread Wang Weidong 
ACPI's P-states will report the acpi_processor_px *states to acpi-cpufreq.
When the states likes these:

[index:freq, 0:2400 1:2400 2:2000 3:1600...],

we will initialize the freq_tables to those:

[index:driver_data:freq, 0:0:2400, 1:2:2000 2:3,1600 ... CPUFREQ_TABLE_END]

So when set the freqs to 2000, the data->acpi_data->state is 2
(data->freq_table[1].driver_data), So when call get_cur_freq_on_cpu, we get
the freqs is data->freq_table[2].frequency,the value is 1600.

we can make the freq_table store the same value to fix this case problem.

Signed-off-by: Wang Weidong 
---
Change note: 

v2: to check weather the freq_table will be changeable and clarify the problem.

The set of available states which come from acpi won't change. Just like
the power would be remove, the acpi driver will do that:

 ->acpi_processor_ppc_has_changed
 ->cpufreq_update_policy
 ->acpi_ppc_notifier_block.notifier_call
   ->acpi_processor_ppc_notifier
   ->cpufreq_verify_within_limits

The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).

---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- 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;
 
-- 
1.7.12




.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND v2] acpi-cpufreq: make the freq_table store the same freq value

2014-12-26 Thread Wang Weidong 
ACPI's P-states will report the acpi_processor_px *states to acpi-cpufreq.
When the states likes these:

[index:freq, 0:2400 1:2400 2:2000 3:1600...],

we will initialize the freq_tables to those:

[index:driver_data:freq, 0:0:2400, 1:2:2000 2:3,1600 ... CPUFREQ_TABLE_END]

So when set the freqs to 2000, the data-acpi_data-state is 2
(data-freq_table[1].driver_data), So when call get_cur_freq_on_cpu, we get
the freqs is data-freq_table[2].frequency,the value is 1600.

we can make the freq_table store the same value to fix this case problem.

Signed-off-by: Wang Weidong wangweido...@huawei.com
---
Change note: 

v2: to check weather the freq_table will be changeable and clarify the problem.

The set of available states which come from acpi won't change. Just like
the power would be remove, the acpi driver will do that:

 -acpi_processor_ppc_has_changed
 -cpufreq_update_policy
 -acpi_ppc_notifier_block.notifier_call
   -acpi_processor_ppc_notifier
   -cpufreq_verify_within_limits

The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).

---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- 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;
 
-- 
1.7.12




.




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] fix some problems for cpufreq

2014-12-02 Thread Wang Weidong 
On 2014/12/2 12:38, Viresh Kumar wrote:
> On 30 November 2014 at 13:53, Wang Weidong  wrote:
>> No, there are not utilities and scripts relying on it.
> 
> How can you be so sure about it ? There might be scripts/utils you
> aren't aware of
> and are depending on this..
> 
>> I just confuse that:
>> If the policy->min and policy-max is changed while it shows all available 
>> freqs
>> though scaling_available_frequencies. I can't set all freq-steps, only 
>> [policy->min, policy->max].
>> why should it show all the available freqs.
> 
> That's not the only purpose of those frequencies there. It shows list
> of all possible
> frequencies. Now, there can be issues if those lists are updated.
> 
> Suppose somebody just played with the min/max frequency, now how would anybody
> come to know about the frequencies available above/below the
> user-max/min frequency?
> 
> So as you mentioned in your example above: User space would never know about
> 
> 1.05 Ghz and 2.3GHz anymore.. Unless you remember it or save it somewhere.
> 

Nice, Thanks for your reply.

Got it.

Wang,
Regards

>> Although, it doesn't impact on us. So just ignore the patch#2. :)
> 
> Probably yes.
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] fix some problems for cpufreq

2014-12-02 Thread Wang Weidong 
On 2014/12/2 12:38, Viresh Kumar wrote:
 On 30 November 2014 at 13:53, Wang Weidong wangweido...@huawei.com wrote:
 No, there are not utilities and scripts relying on it.
 
 How can you be so sure about it ? There might be scripts/utils you
 aren't aware of
 and are depending on this..
 
 I just confuse that:
 If the policy-min and policy-max is changed while it shows all available 
 freqs
 though scaling_available_frequencies. I can't set all freq-steps, only 
 [policy-min, policy-max].
 why should it show all the available freqs.
 
 That's not the only purpose of those frequencies there. It shows list
 of all possible
 frequencies. Now, there can be issues if those lists are updated.
 
 Suppose somebody just played with the min/max frequency, now how would anybody
 come to know about the frequencies available above/below the
 user-max/min frequency?
 
 So as you mentioned in your example above: User space would never know about
 
 1.05 Ghz and 2.3GHz anymore.. Unless you remember it or save it somewhere.
 

Nice, Thanks for your reply.

Got it.

Wang,
Regards

 Although, it doesn't impact on us. So just ignore the patch#2. :)
 
 Probably yes.
 
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] acpi-cpufreq: make the freq_table store the same freq value

2014-11-30 Thread Wang Weidong 
ACPI's P-states will report the acpi_processor_px *states to acpi-cpufreq.
When the states likes these:

[index:freq, 0:2400 1:2400 2:2000 3:1600...],

we will initialize the freq_tables to those:

[index:driver_data:freq, 0:0:2400, 1:2:2000 2:3,1600 ... CPUFREQ_TABLE_END]

So when set the freqs to 2000, the data->acpi_data->state is 2
(data->freq_table[1].driver_data), So when call get_cur_freq_on_cpu, we get
the freqs is data->freq_table[2].frequency,the value is 1600.

we can make the freq_table store the same value to fix this case problem.

Signed-off-by: Wang Weidong 
---
Change note: 

v2: to check weather the freq_table will be changeable and clarify the problem.

The set of available states which come from acpi won't change. Just like
the power would be remove, the acpi driver will do that:

 ->acpi_processor_ppc_has_changed
 ->cpufreq_update_policy
 ->acpi_ppc_notifier_block.notifier_call
   ->acpi_processor_ppc_notifier
   ->cpufreq_verify_within_limits

The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).

---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- 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;
 
-- 
1.7.12



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] fix some problems for cpufreq

2014-11-30 Thread Wang Weidong 
On 2014/11/30 6:30, Rafael J. Wysocki wrote:
> On Saturday, November 29, 2014 09:40:02 AM Wang Weidong wrote:
>> On 2014/11/29 9:26, Rafael J. Wysocki wrote:
>>> On Friday, November 28, 2014 10:43:37 AM Wang Weidong wrote:
>>>> Hi Rafael and Viresh
>>>>
>>>> Sorry to trouble you again. As for:
>>>> "acpi-cpufreq: get the cur_freq from acpi_processor_performance states"
>>>> I do it again, and add the other patch.
>>>>
>>>> patch #1: acpi-cpufreq: make the freq_table store the same freq value
>>>>
>>>> I think it can work. The set of available states which come
>>>> from acpi won't change. Just like the power would be remove,
>>>> the acpi driver will do that:
>>>> call
>>>>  ->acpi_processor_ppc_has_changed
>>>>  ->cpufreq_update_policy
>>>>  ->acpi_ppc_notifier_block.notifier_call
>>>>->acpi_processor_ppc_notifier
>>>>->cpufreq_verify_within_limits
>>>> The progress will change the policy's min_freq and max_freq
>>>> while it won't change the set of states(freq_tables).
>>>
>>> OK, so the above information needs to go into the changelog of patch [1/2].
>>> Also, please clarify the problem description in that changelog, it is very
>>> difficult to understand the way it is now.
>>>
>>
>> sure, I should do it.
>>
>>>> patch #2: cpufreq: show the real avail freqs with the freq_table
>>>>
>>>> when the min_freq and max_freq change, we should sync the availble
>>>> freqs.
>>>
>>> Why?  Do any other cpufreq drivers do that?
>>>
>>
>> If some cpufreq drivers support several freqs like this:
>> 1.05 Ghz 1.30Ghz 1.70GHz 2.10GHz 2.3GHz
>>||
>>   min  max
>> So what the available freqs is 1.30GHz 1.70GHz 2.10GHz
>>
>> when we do cpufreq-info or cat scaling_available_frequencies,
>> I think the available freqs table show only show these 3 value,
>> not all the values.
> 
> That changes an existing user space interface, however, and the
> only reason I can figure out from what you're saying is your personal
> opinion.  This isn't a good enough reason, however.
> 
> What if there are utilities and scripts out there relying on the
> current behavior?
> 

No, there are not utilities and scripts relying on it. 

I just confuse that:
If the policy->min and policy-max is changed while it shows all available freqs
though scaling_available_frequencies. I can't set all freq-steps, only 
[policy->min, policy->max].
why should it show all the available freqs.

Although, it doesn't impact on us. So just ignore the patch#2. :)

Wang,
Regards

> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] fix some problems for cpufreq

2014-11-30 Thread Wang Weidong 
On 2014/11/30 6:30, Rafael J. Wysocki wrote:
 On Saturday, November 29, 2014 09:40:02 AM Wang Weidong wrote:
 On 2014/11/29 9:26, Rafael J. Wysocki wrote:
 On Friday, November 28, 2014 10:43:37 AM Wang Weidong wrote:
 Hi Rafael and Viresh

 Sorry to trouble you again. As for:
 acpi-cpufreq: get the cur_freq from acpi_processor_performance states
 I do it again, and add the other patch.

 patch #1: acpi-cpufreq: make the freq_table store the same freq value

 I think it can work. The set of available states which come
 from acpi won't change. Just like the power would be remove,
 the acpi driver will do that:
 call
  -acpi_processor_ppc_has_changed
  -cpufreq_update_policy
  -acpi_ppc_notifier_block.notifier_call
-acpi_processor_ppc_notifier
-cpufreq_verify_within_limits
 The progress will change the policy's min_freq and max_freq
 while it won't change the set of states(freq_tables).

 OK, so the above information needs to go into the changelog of patch [1/2].
 Also, please clarify the problem description in that changelog, it is very
 difficult to understand the way it is now.


 sure, I should do it.

 patch #2: cpufreq: show the real avail freqs with the freq_table

 when the min_freq and max_freq change, we should sync the availble
 freqs.

 Why?  Do any other cpufreq drivers do that?


 If some cpufreq drivers support several freqs like this:
 1.05 Ghz 1.30Ghz 1.70GHz 2.10GHz 2.3GHz
||
   min  max
 So what the available freqs is 1.30GHz 1.70GHz 2.10GHz

 when we do cpufreq-info or cat scaling_available_frequencies,
 I think the available freqs table show only show these 3 value,
 not all the values.
 
 That changes an existing user space interface, however, and the
 only reason I can figure out from what you're saying is your personal
 opinion.  This isn't a good enough reason, however.
 
 What if there are utilities and scripts out there relying on the
 current behavior?
 

No, there are not utilities and scripts relying on it. 

I just confuse that:
If the policy-min and policy-max is changed while it shows all available freqs
though scaling_available_frequencies. I can't set all freq-steps, only 
[policy-min, policy-max].
why should it show all the available freqs.

Although, it doesn't impact on us. So just ignore the patch#2. :)

Wang,
Regards

 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] acpi-cpufreq: make the freq_table store the same freq value

2014-11-30 Thread Wang Weidong 
ACPI's P-states will report the acpi_processor_px *states to acpi-cpufreq.
When the states likes these:

[index:freq, 0:2400 1:2400 2:2000 3:1600...],

we will initialize the freq_tables to those:

[index:driver_data:freq, 0:0:2400, 1:2:2000 2:3,1600 ... CPUFREQ_TABLE_END]

So when set the freqs to 2000, the data-acpi_data-state is 2
(data-freq_table[1].driver_data), So when call get_cur_freq_on_cpu, we get
the freqs is data-freq_table[2].frequency,the value is 1600.

we can make the freq_table store the same value to fix this case problem.

Signed-off-by: Wang Weidong wangweido...@huawei.com
---
Change note: 

v2: to check weather the freq_table will be changeable and clarify the problem.

The set of available states which come from acpi won't change. Just like
the power would be remove, the acpi driver will do that:

 -acpi_processor_ppc_has_changed
 -cpufreq_update_policy
 -acpi_ppc_notifier_block.notifier_call
   -acpi_processor_ppc_notifier
   -cpufreq_verify_within_limits

The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).

---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- 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;
 
-- 
1.7.12



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] fix some problems for cpufreq

2014-11-28 Thread Wang Weidong 
On 2014/11/29 9:26, Rafael J. Wysocki wrote:
> On Friday, November 28, 2014 10:43:37 AM Wang Weidong wrote:
>> Hi Rafael and Viresh
>>
>> Sorry to trouble you again. As for:
>> "acpi-cpufreq: get the cur_freq from acpi_processor_performance states"
>> I do it again, and add the other patch.
>>
>> patch #1: acpi-cpufreq: make the freq_table store the same freq value
>>
>> I think it can work. The set of available states which come
>> from acpi won't change. Just like the power would be remove,
>> the acpi driver will do that:
>> call
>>  ->acpi_processor_ppc_has_changed
>>  ->cpufreq_update_policy
>>  ->acpi_ppc_notifier_block.notifier_call
>>->acpi_processor_ppc_notifier
>>->cpufreq_verify_within_limits
>> The progress will change the policy's min_freq and max_freq
>> while it won't change the set of states(freq_tables).
> 
> OK, so the above information needs to go into the changelog of patch [1/2].
> Also, please clarify the problem description in that changelog, it is very
> difficult to understand the way it is now.
> 

sure, I should do it.

>> patch #2: cpufreq: show the real avail freqs with the freq_table
>>
>> when the min_freq and max_freq change, we should sync the availble
>> freqs.
> 
> Why?  Do any other cpufreq drivers do that?
> 

If some cpufreq drivers support several freqs like this:
1.05 Ghz 1.30Ghz 1.70GHz 2.10GHz 2.3GHz
   ||
  min  max
So what the available freqs is 1.30GHz 1.70GHz 2.10GHz

when we do cpufreq-info or cat scaling_available_frequencies,
I think the available freqs table show only show these 3 value,
not all the values.

Wang,
Regards

> Rafael
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] fix some problems for cpufreq

2014-11-28 Thread Wang Weidong 
On 2014/11/29 9:26, Rafael J. Wysocki wrote:
 On Friday, November 28, 2014 10:43:37 AM Wang Weidong wrote:
 Hi Rafael and Viresh

 Sorry to trouble you again. As for:
 acpi-cpufreq: get the cur_freq from acpi_processor_performance states
 I do it again, and add the other patch.

 patch #1: acpi-cpufreq: make the freq_table store the same freq value

 I think it can work. The set of available states which come
 from acpi won't change. Just like the power would be remove,
 the acpi driver will do that:
 call
  -acpi_processor_ppc_has_changed
  -cpufreq_update_policy
  -acpi_ppc_notifier_block.notifier_call
-acpi_processor_ppc_notifier
-cpufreq_verify_within_limits
 The progress will change the policy's min_freq and max_freq
 while it won't change the set of states(freq_tables).
 
 OK, so the above information needs to go into the changelog of patch [1/2].
 Also, please clarify the problem description in that changelog, it is very
 difficult to understand the way it is now.
 

sure, I should do it.

 patch #2: cpufreq: show the real avail freqs with the freq_table

 when the min_freq and max_freq change, we should sync the availble
 freqs.
 
 Why?  Do any other cpufreq drivers do that?
 

If some cpufreq drivers support several freqs like this:
1.05 Ghz 1.30Ghz 1.70GHz 2.10GHz 2.3GHz
   ||
  min  max
So what the available freqs is 1.30GHz 1.70GHz 2.10GHz

when we do cpufreq-info or cat scaling_available_frequencies,
I think the available freqs table show only show these 3 value,
not all the values.

Wang,
Regards

 Rafael
 
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] cpufreq: show the real avail freqs with the freq_table

2014-11-27 Thread Wang Weidong 
Some time, the policy's max_freq and min_freq will change, so
the avail freqs is not from the cpuinfo_min to cpuinfo_max.
Just add the check for the freq_table.

Signed-off-by: Wang Weidong 
---
 drivers/cpufreq/freq_table.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index df14766..4f86010 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -237,7 +237,9 @@ static ssize_t show_available_freqs(struct cpufreq_policy 
*policy, char *buf,
 * show_boost = false and driver_data != BOOST freq
 * display NON BOOST freqs
 */
-   if (show_boost ^ (pos->flags & CPUFREQ_BOOST_FREQ))
+   if (pos->frequency < policy->min ||
+   pos->frequency > policy->max ||
+   show_boost ^ (pos->flags & CPUFREQ_BOOST_FREQ))
continue;
 
count += sprintf([count], "%d ", pos->frequency);
-- 
1.7.12


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] fix some problems for cpufreq

2014-11-27 Thread Wang Weidong 
Hi Rafael and Viresh

Sorry to trouble you again. As for:
"acpi-cpufreq: get the cur_freq from acpi_processor_performance states"
I do it again, and add the other patch.

patch #1: acpi-cpufreq: make the freq_table store the same freq value

I think it can work. The set of available states which come
from acpi won't change. Just like the power would be remove,
the acpi driver will do that:
call
 ->acpi_processor_ppc_has_changed
 ->cpufreq_update_policy
 ->acpi_ppc_notifier_block.notifier_call
   ->acpi_processor_ppc_notifier
   ->cpufreq_verify_within_limits
The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).

patch #2: cpufreq: show the real avail freqs with the freq_table

when the min_freq and max_freq change, we should sync the availble
freqs.

Regards,
Wang

Wang Weidong (2):
  acpi-cpufreq: make the freq_table store the same freq value
  cpufreq: show the real avail freqs with the freq_table

 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 drivers/cpufreq/freq_table.c   | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
1.7.12


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] acpi-cpufreq: make the freq_table store the same freq value

2014-11-27 Thread Wang Weidong 
As the initialized freq_tables maybe different from the p-states
values, so the array index is different as well.

Although in this case:
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, make the freq_table store the same value as well.

Signed-off-by: Wang Weidong 
---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- 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;
 
-- 
1.7.12


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] fix some problems for cpufreq

2014-11-27 Thread Wang Weidong 
Hi Rafael and Viresh

Sorry to trouble you again. As for:
acpi-cpufreq: get the cur_freq from acpi_processor_performance states
I do it again, and add the other patch.

patch #1: acpi-cpufreq: make the freq_table store the same freq value

I think it can work. The set of available states which come
from acpi won't change. Just like the power would be remove,
the acpi driver will do that:
call
 -acpi_processor_ppc_has_changed
 -cpufreq_update_policy
 -acpi_ppc_notifier_block.notifier_call
   -acpi_processor_ppc_notifier
   -cpufreq_verify_within_limits
The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).

patch #2: cpufreq: show the real avail freqs with the freq_table

when the min_freq and max_freq change, we should sync the availble
freqs.

Regards,
Wang

Wang Weidong (2):
  acpi-cpufreq: make the freq_table store the same freq value
  cpufreq: show the real avail freqs with the freq_table

 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 drivers/cpufreq/freq_table.c   | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
1.7.12


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] acpi-cpufreq: make the freq_table store the same freq value

2014-11-27 Thread Wang Weidong 
As the initialized freq_tables maybe different from the p-states
values, so the array index is different as well.

Although in this case:
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, make the freq_table store the same value as well.

Signed-off-by: Wang Weidong wangweido...@huawei.com
---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- 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;
 
-- 
1.7.12


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] cpufreq: show the real avail freqs with the freq_table

2014-11-27 Thread Wang Weidong 
Some time, the policy's max_freq and min_freq will change, so
the avail freqs is not from the cpuinfo_min to cpuinfo_max.
Just add the check for the freq_table.

Signed-off-by: Wang Weidong wangweido...@huawei.com
---
 drivers/cpufreq/freq_table.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index df14766..4f86010 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -237,7 +237,9 @@ static ssize_t show_available_freqs(struct cpufreq_policy 
*policy, char *buf,
 * show_boost = false and driver_data != BOOST freq
 * display NON BOOST freqs
 */
-   if (show_boost ^ (pos-flags  CPUFREQ_BOOST_FREQ))
+   if (pos-frequency  policy-min ||
+   pos-frequency  policy-max ||
+   show_boost ^ (pos-flags  CPUFREQ_BOOST_FREQ))
continue;
 
count += sprintf(buf[count], %d , pos-frequency);
-- 
1.7.12


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Problem: A divide error 0000 occured when rcv_mss is 0

2014-10-22 Thread Wang Weidong 
Hi everyone,

my kernel is based on linux-stable-3.4.87. And when I do some testing,
I got this Bug:

<4>[18042.394823] divide error:  [#1]
<4>[18042.395178] SMP 
<4>[18042.734309] CPU 2 

...

<4>[18042.734309] RIP: 0010:[]  [] 
tcp_send_dupack+0x54/0xe0
<4>[18042.734309] RSP: 0018:8801c1845af0  EFLAGS: 00010246
<4>[18042.734309] RAX: 000f4240 RBX: 8801604fad00 RCX: 

<4>[18042.734309] RDX:  RSI: 880121cd5400 RDI: 
8801604fad00
<4>[18042.734309] RBP: 8801c1845b00 R08: 355e0308 R09: 
08015603
<4>[18042.734309] R10: 000f R11: 88016095e1cc R12: 
880121cd5400
<4>[18042.734309] R13:  R14: 88014f5d1c62 R15: 
88014f5d1c62
<4>[18042.734309] FS:  7f611dc6d700() GS:8801c184() 
knlGS:
<4>[18042.734309] CS:  0010 DS:  ES:  CR0: 8005003b
<4>[18042.734309] CR2: ff600400 CR3: 00014c83e000 CR4: 
001407e0
<4>[18042.734309] DR0:  DR1:  DR2: 

<4>[18042.734309] DR3:  DR6: 0ff0 DR7: 
0400
<4>[18042.734309] Process CSD_1 (pid: 28654, threadinfo 88019fb92000, task 
880162555c80)
<4>[18042.734309] Stack:
<4>[18042.734309]  2135 8801604fad00 8801c1845b40 
813886b5
<4>[18042.734309]  8801c1845b20 81441aa2 8801604fad00 
880121cd5400
<4>[18042.734309]  88014f5d1c62 88016095e180 8801c1845b90 
8138d0b7
<4>[18042.734309]  88014153e0d0 0001 0002 
8801604fad00
<4>[18042.734309]  88016095e180 0003 88016095e180 
88014f5d1c62
<4>[18042.734309]  8801c1845bc0 81397255 880121cd5400 
88016095e180
<4>[18042.734309]  8801604fad00 88014f5d1c62 8801c1845c10 
81395a70
<4>[18042.734309]  8801000f 811bf0e1 8801c1845c10 
81356d2f
<4>[18042.734309]  880121cd5400 81856680 88016095e180 
88016095e1d0
<4>[18042.734309]  8801c1845c80 81396fc8 8801000f 
880163d5e000
<4>[18042.734309]  8801c1845cb0 000f 81856680 
0a72a8c00801
<4>[18042.734309]  81884600 880121cd5400 8164cc80 
0006
<4>[18042.734309]  81856680 81883920 8801c1845cb0 
813746e9
<4>[18042.734309]  880121cd5400 88014f5d1c4e 0008 
880163d5e000
<4>[18042.734309]  8801c1845ce0 81374a20 88018000 
0008
<4>[18042.734309]  880163d5e000 880121cd5400
<4>[18042.734309] Call Trace:
<4>[18042.734309]   
<4>[18042.734309]  [] tcp_validate_incoming+0x135/0x2c0
<4>[18042.734309]  [] ? _raw_spin_unlock_bh+0x12/0x20
<4>[18042.734309]  [] tcp_rcv_state_process+0x47/0xba0
<4>[18042.734309]  [] tcp_child_process+0x45/0xf0
<4>[18042.734309]  [] tcp_v4_do_rcv+0x1b0/0x290
<4>[18042.734309]  [] ? security_sock_rcv_skb+0x11/0x20
<4>[18042.734309]  [] ? sk_filter+0x1f/0xb0
<4>[18042.734309]  [] tcp_v4_rcv+0x738/0x810
<4>[18042.734309]  [] ip_local_deliver_finish+0xb9/0x230
<4>[18042.734309]  [] ip_local_deliver+0x80/0x90
<4>[18042.734309]  [] ip_rcv_finish+0x69/0x310
<4>[18042.734309]  [] ip_rcv+0x248/0x320
<4>[18042.734309]  [] __netif_receive_skb+0x372/0x580
<4>[18042.734309]  [] ? check_preempt_wakeup+0x158/0x250
<4>[18042.734309]  [] netif_receive_skb+0x28/0x90
<4>[18042.734309]  [] ? __wake_up+0x4e/0x70
<4>[18042.734309]  [] napi_gro_complete+0xcc/0x100
<4>[18042.734309]  [] napi_complete+0x2f/0x80
<4>[18042.734309]  [] napi_rx_handler+0x2f/0x80 [cxgb4]
<4>[18042.734309]  [] net_rx_action+0xb7/0x1a0
<4>[18042.734309]  [] ? do_raw_spin_lock+0x61/0x110
<4>[18042.734309]  [] __do_softirq+0xb5/0x1c0
<4>[18042.734309]  [] ? _raw_spin_lock+0x9/0x10
<4>[18042.734309]  [] call_softirq+0x1c/0x30
<4>[18042.734309]  [] do_softirq+0x6d/0xa0
<4>[18042.734309]  [] irq_exit+0xa5/0xb0
<4>[18042.734309]  [] do_IRQ+0x5e/0xd0
<4>[18042.734309]  [] common_interrupt+0x6a/0x6a

Is it like the problem which fixed by commit 
709e8697af1c86772c1a6fccda6d4b0e2e226547
(tcp: clear xmit timers in tcp_v4_syn_recv_sock())?

I think the divide error happen at:
tcp_send_dupack
-> tcp_enter_quickack_mode
-> tcp_incr_quickack

There is code that: 
 unsigned quickacks = tcp_sk(sk)->rcv_wnd / (2 * icsk->icsk_ack.rcv_mss);
so the icsk_ack.rcv_mss is 0?

But I am not sure, is it a Bug in the kernel? Or maybe somewhere I do wrong.

Can anybody help me to check is it a Bug or other problems, and how can I to 
resolve it.

Regards,
Wang

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Problem: A divide error 0000 occured when rcv_mss is 0

2014-10-22 Thread Wang Weidong 
Hi everyone,

my kernel is based on linux-stable-3.4.87. And when I do some testing,
I got this Bug:

4[18042.394823] divide error:  [#1]
4[18042.395178] SMP 
4[18042.734309] CPU 2 

...

4[18042.734309] RIP: 0010:[81385e44]  [81385e44] 
tcp_send_dupack+0x54/0xe0
4[18042.734309] RSP: 0018:8801c1845af0  EFLAGS: 00010246
4[18042.734309] RAX: 000f4240 RBX: 8801604fad00 RCX: 

4[18042.734309] RDX:  RSI: 880121cd5400 RDI: 
8801604fad00
4[18042.734309] RBP: 8801c1845b00 R08: 355e0308 R09: 
08015603
4[18042.734309] R10: 000f R11: 88016095e1cc R12: 
880121cd5400
4[18042.734309] R13:  R14: 88014f5d1c62 R15: 
88014f5d1c62
4[18042.734309] FS:  7f611dc6d700() GS:8801c184() 
knlGS:
4[18042.734309] CS:  0010 DS:  ES:  CR0: 8005003b
4[18042.734309] CR2: ff600400 CR3: 00014c83e000 CR4: 
001407e0
4[18042.734309] DR0:  DR1:  DR2: 

4[18042.734309] DR3:  DR6: 0ff0 DR7: 
0400
4[18042.734309] Process CSD_1 (pid: 28654, threadinfo 88019fb92000, task 
880162555c80)
4[18042.734309] Stack:
4[18042.734309]  2135 8801604fad00 8801c1845b40 
813886b5
4[18042.734309]  8801c1845b20 81441aa2 8801604fad00 
880121cd5400
4[18042.734309]  88014f5d1c62 88016095e180 8801c1845b90 
8138d0b7
4[18042.734309]  88014153e0d0 0001 0002 
8801604fad00
4[18042.734309]  88016095e180 0003 88016095e180 
88014f5d1c62
4[18042.734309]  8801c1845bc0 81397255 880121cd5400 
88016095e180
4[18042.734309]  8801604fad00 88014f5d1c62 8801c1845c10 
81395a70
4[18042.734309]  8801000f 811bf0e1 8801c1845c10 
81356d2f
4[18042.734309]  880121cd5400 81856680 88016095e180 
88016095e1d0
4[18042.734309]  8801c1845c80 81396fc8 8801000f 
880163d5e000
4[18042.734309]  8801c1845cb0 000f 81856680 
0a72a8c00801
4[18042.734309]  81884600 880121cd5400 8164cc80 
0006
4[18042.734309]  81856680 81883920 8801c1845cb0 
813746e9
4[18042.734309]  880121cd5400 88014f5d1c4e 0008 
880163d5e000
4[18042.734309]  8801c1845ce0 81374a20 88018000 
0008
4[18042.734309]  880163d5e000 880121cd5400
4[18042.734309] Call Trace:
4[18042.734309]  IRQ 
4[18042.734309]  [813886b5] tcp_validate_incoming+0x135/0x2c0
4[18042.734309]  [81441aa2] ? _raw_spin_unlock_bh+0x12/0x20
4[18042.734309]  [8138d0b7] tcp_rcv_state_process+0x47/0xba0
4[18042.734309]  [81397255] tcp_child_process+0x45/0xf0
4[18042.734309]  [81395a70] tcp_v4_do_rcv+0x1b0/0x290
4[18042.734309]  [811bf0e1] ? security_sock_rcv_skb+0x11/0x20
4[18042.734309]  [81356d2f] ? sk_filter+0x1f/0xb0
4[18042.734309]  [81396fc8] tcp_v4_rcv+0x738/0x810
4[18042.734309]  [813746e9] ip_local_deliver_finish+0xb9/0x230
4[18042.734309]  [81374a20] ip_local_deliver+0x80/0x90
4[18042.734309]  [81374389] ip_rcv_finish+0x69/0x310
4[18042.734309]  [81374c78] ip_rcv+0x248/0x320
4[18042.734309]  [81344dd2] __netif_receive_skb+0x372/0x580
4[18042.734309]  [8106f0d8] ? check_preempt_wakeup+0x158/0x250
4[18042.734309]  [81345198] netif_receive_skb+0x28/0x90
4[18042.734309]  [81064c4e] ? __wake_up+0x4e/0x70
4[18042.734309]  [813453dc] napi_gro_complete+0xcc/0x100
4[18042.734309]  [8134584f] napi_complete+0x2f/0x80
4[18042.734309]  [a1575baf] napi_rx_handler+0x2f/0x80 [cxgb4]
4[18042.734309]  [81345957] net_rx_action+0xb7/0x1a0
4[18042.734309]  [812259b1] ? do_raw_spin_lock+0x61/0x110
4[18042.734309]  [8103e385] __do_softirq+0xb5/0x1c0
4[18042.734309]  [81441b59] ? _raw_spin_lock+0x9/0x10
4[18042.734309]  [8144a99c] call_softirq+0x1c/0x30
4[18042.734309]  [810040fd] do_softirq+0x6d/0xa0
4[18042.734309]  [8103e725] irq_exit+0xa5/0xb0
4[18042.734309]  [81003cee] do_IRQ+0x5e/0xd0
4[18042.734309]  [81441d6a] common_interrupt+0x6a/0x6a

Is it like the problem which fixed by commit 
709e8697af1c86772c1a6fccda6d4b0e2e226547
(tcp: clear xmit timers in tcp_v4_syn_recv_sock())?

I think the divide error happen at:
tcp_send_dupack
- tcp_enter_quickack_mode
- tcp_incr_quickack

There is code that: 
 unsigned quickacks = tcp_sk(sk)-rcv_wnd / (2 * icsk-icsk_ack.rcv_mss);
so the icsk_ack.rcv_mss is 0?

But I am not sure, is it a Bug in the kernel? Or maybe somewhere I do wrong.

Can anybody help me to check is it a Bug or other problems, and how can I to 
resolve it.

Regards,

Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states

2014-09-30 Thread Wang Weidong 
On 2014/9/28 4:01, Rafael J. Wysocki wrote:
> On Saturday, September 27, 2014 01:32:59 PM Wang Weidong wrote:
>> 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.
> 
> That would only be OK if it is guaranteed that the set of available
> states hasn't changed, which I'm not sure is the case.
> 
> Rafael
> 

Yep, ACPI maybe will dynamic to report the states to the OS . So I should 
consider it again.

Regards,
Wang
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states

2014-09-30 Thread Wang Weidong 
On 2014/9/28 4:01, Rafael J. Wysocki wrote:
 On Saturday, September 27, 2014 01:32:59 PM Wang Weidong wrote:
 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.
 
 That would only be OK if it is guaranteed that the set of available
 states hasn't changed, which I'm not sure is the case.
 
 Rafael
 

Yep, ACPI maybe will dynamic to report the states to the OS . So I should 
consider it again.

Regards,
Wang
 
 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states

2014-09-26 Thread Wang Weidong 
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 
>> ---
>>  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) {
>>  /*
>>
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states

2014-09-26 Thread Wang Weidong 
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 wangweido...@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) {
  /*

 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states

2014-08-20 Thread Wang Weidong 
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.

Signed-off-by: Wang Weidong 
---
 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) {
/*
-- 
1.7.12


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states

2014-08-20 Thread Wang Weidong 
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.

Signed-off-by: Wang Weidong wangweido...@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) {
/*
-- 
1.7.12


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] cpufreq: get the cur_freq from acpi_processor_performance

2014-08-01 Thread Wang Weidong 
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.

Signed-off-by: Wang Weidong 
---
 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..2b934cb 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) {
/*
-- 
1.7.12


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] cpufreq: get the cur_freq from acpi_processor_performance

2014-08-01 Thread Wang Weidong 
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.

Signed-off-by: Wang Weidong wangweido...@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..2b934cb 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) {
/*
-- 
1.7.12


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Thumb-2: Fix out-of-range offset for Thumb-2 in, proc-macros.S

2014-06-16 Thread Wang Weidong 
On 2014/6/16 21:49, Will Deacon wrote:
> On Tue, Jun 10, 2014 at 08:00:01AM +0100, Wang Weidong wrote:
>> The STR Instruction Encoding T4 points that the  is in the
>> range 0-255.So split the instruction into two for Thumb-2. Just
>> like commit 874d5d3ccc("ARM: 6623/1: Thumb-2: Fix out-of-range
>> offset for Thumb-2 in proc-v7.S").
>>
>> Signed-off-by: Wang Weidong 
>> ---
>>  arch/arm/mm/proc-macros.S | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
>> index ee1d805..63f710c 100644
>> --- a/arch/arm/mm/proc-macros.S
>> +++ b/arch/arm/mm/proc-macros.S
>> @@ -252,7 +252,9 @@
>>  tst r3, #L_PTE_PRESENT | L_PTE_YOUNG@ present and young?
>>  movne   r2, #0  @ no -> fault
>>  
>> -str r2, [r0, #2048]!@ hardware version
>> + ARM(   str r2, [r0, #2048]!) @ hardware version
>> + THUMB( add r0, r0, #2048   )
>> + THUMB( str r2, [r0])
>>  mov ip, #0
>>  mcr p15, 0, r0, c7, c10, 1  @ clean L1 D line
>>  mcr p15, 0, ip, c7, c10, 4  @ data write barrier
> 
> AFAICT this is in xscale_set_pte_ext_epilogue which should only be built as
> ARM. Are you seeing a real issue here?
> 
> Will
> 

Hi will,

I don't see any issue here. I just review the codes while I learn thumb-2.
It does only build as ARM, so ignore it.

Regards
Wang

> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Thumb-2: Fix out-of-range offset for Thumb-2 in, proc-macros.S

2014-06-16 Thread Wang Weidong 
On 2014/6/16 21:49, Will Deacon wrote:
 On Tue, Jun 10, 2014 at 08:00:01AM +0100, Wang Weidong wrote:
 The STR Instruction Encoding T4 points that the imm is in the
 range 0-255.So split the instruction into two for Thumb-2. Just
 like commit 874d5d3ccc(ARM: 6623/1: Thumb-2: Fix out-of-range
 offset for Thumb-2 in proc-v7.S).

 Signed-off-by: Wang Weidong wangweido...@huawei.com
 ---
  arch/arm/mm/proc-macros.S | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
 index ee1d805..63f710c 100644
 --- a/arch/arm/mm/proc-macros.S
 +++ b/arch/arm/mm/proc-macros.S
 @@ -252,7 +252,9 @@
  tst r3, #L_PTE_PRESENT | L_PTE_YOUNG@ present and young?
  movne   r2, #0  @ no - fault
  
 -str r2, [r0, #2048]!@ hardware version
 + ARM(   str r2, [r0, #2048]!) @ hardware version
 + THUMB( add r0, r0, #2048   )
 + THUMB( str r2, [r0])
  mov ip, #0
  mcr p15, 0, r0, c7, c10, 1  @ clean L1 D line
  mcr p15, 0, ip, c7, c10, 4  @ data write barrier
 
 AFAICT this is in xscale_set_pte_ext_epilogue which should only be built as
 ARM. Are you seeing a real issue here?
 
 Will
 

Hi will,

I don't see any issue here. I just review the codes while I learn thumb-2.
It does only build as ARM, so ignore it.

Regards
Wang

 .
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: Thumb-2: Fix out-of-range offset for Thumb-2 in, proc-macros.S

2014-06-10 Thread Wang Weidong 
The STR Instruction Encoding T4 points that the  is in the
range 0-255.So split the instruction into two for Thumb-2. Just
like commit 874d5d3ccc("ARM: 6623/1: Thumb-2: Fix out-of-range
offset for Thumb-2 in proc-v7.S").

Signed-off-by: Wang Weidong 
---
 arch/arm/mm/proc-macros.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index ee1d805..63f710c 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -252,7 +252,9 @@
tst r3, #L_PTE_PRESENT | L_PTE_YOUNG@ present and young?
movne   r2, #0  @ no -> fault
 
-   str r2, [r0, #2048]!@ hardware version
+ ARM(  str r2, [r0, #2048]!) @ hardware version
+ THUMB( addr0, r0, #2048   )
+ THUMB( strr2, [r0])
mov ip, #0
mcr p15, 0, r0, c7, c10, 1  @ clean L1 D line
mcr p15, 0, ip, c7, c10, 4  @ data write barrier
-- 
1.7.12


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: Thumb-2: Fix out-of-range offset for Thumb-2 in, proc-macros.S

2014-06-10 Thread Wang Weidong 
The STR Instruction Encoding T4 points that the imm is in the
range 0-255.So split the instruction into two for Thumb-2. Just
like commit 874d5d3ccc(ARM: 6623/1: Thumb-2: Fix out-of-range
offset for Thumb-2 in proc-v7.S).

Signed-off-by: Wang Weidong wangweido...@huawei.com
---
 arch/arm/mm/proc-macros.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index ee1d805..63f710c 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -252,7 +252,9 @@
tst r3, #L_PTE_PRESENT | L_PTE_YOUNG@ present and young?
movne   r2, #0  @ no - fault
 
-   str r2, [r0, #2048]!@ hardware version
+ ARM(  str r2, [r0, #2048]!) @ hardware version
+ THUMB( addr0, r0, #2048   )
+ THUMB( strr2, [r0])
mov ip, #0
mcr p15, 0, r0, c7, c10, 1  @ clean L1 D line
mcr p15, 0, ip, c7, c10, 4  @ data write barrier
-- 
1.7.12


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/