* [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
@ 2014-08-21 5:55 ` Wang Weidong
0 siblings, 0 replies; 9+ messages in thread
From: Wang Weidong @ 2014-08-21 5:55 UTC (permalink / raw)
To: rjw, viresh.kumar
Cc: linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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 <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) {
/*
--
1.7.12
^ permalink raw reply related [flat|nested] 9+ messages in thread* [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
@ 2014-08-21 5:55 ` Wang Weidong
0 siblings, 0 replies; 9+ messages in thread
From: Wang Weidong @ 2014-08-21 5:55 UTC (permalink / raw)
To: rjw, viresh.kumar
Cc: linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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 <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) {
/*
--
1.7.12
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
2014-08-21 5:55 ` Wang Weidong
(?)
@ 2014-08-25 13:41 ` Viresh Kumar
-1 siblings, 0 replies; 9+ messages in thread
From: Viresh Kumar @ 2014-08-25 13:41 UTC (permalink / raw)
To: Wang Weidong
Cc: Rafael J. Wysocki, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org >> linux-kernel@vger.kernel.org
On 21 August 2014 11:25, Wang Weidong <wangweidong1@huawei.com> 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.
>
> 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) {
> /*
The problem looks real but I am not very well aware of this driver and
so it would
be more appropriate if Rafael replies/Applies..
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
2014-08-21 5:55 ` Wang Weidong
(?)
(?)
@ 2014-09-26 23:21 ` Rafael J. Wysocki
2014-09-27 5:32 ` Wang Weidong
-1 siblings, 1 reply; 9+ messages in thread
From: Rafael J. Wysocki @ 2014-09-26 23:21 UTC (permalink / raw)
To: Wang Weidong
Cc: viresh.kumar, linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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?
> 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) {
> /*
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
2014-09-26 23:21 ` Rafael J. Wysocki
@ 2014-09-27 5:32 ` Wang Weidong
0 siblings, 0 replies; 9+ messages in thread
From: Wang Weidong @ 2014-09-27 5:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: viresh.kumar, linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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) {
>> /*
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
@ 2014-09-27 5:32 ` Wang Weidong
0 siblings, 0 replies; 9+ messages in thread
From: Wang Weidong @ 2014-09-27 5:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: viresh.kumar, linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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) {
>> /*
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
2014-09-27 5:32 ` Wang Weidong
(?)
@ 2014-09-27 20:01 ` Rafael J. Wysocki
2014-09-30 7:09 ` Wang Weidong
-1 siblings, 1 reply; 9+ messages in thread
From: Rafael J. Wysocki @ 2014-09-27 20:01 UTC (permalink / raw)
To: Wang Weidong
Cc: viresh.kumar, linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
2014-09-27 20:01 ` Rafael J. Wysocki
@ 2014-09-30 7:09 ` Wang Weidong
0 siblings, 0 replies; 9+ messages in thread
From: Wang Weidong @ 2014-09-30 7:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: viresh.kumar, linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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
>
> .
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RESEND PATCH] acpi-cpufreq: get the cur_freq from acpi_processor_performance states
@ 2014-09-30 7:09 ` Wang Weidong
0 siblings, 0 replies; 9+ messages in thread
From: Wang Weidong @ 2014-09-30 7:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: viresh.kumar, linux-pm,
linux-kernel@vger.kernel.org >> "linux-kernel@vger.kernel.org"
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
>
> .
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-09-30 7:09 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
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.