RE: [PATCH 6/8] acpi-cpufreq: use cpu_core_map on multicore processors

RE: [PATCH 6/8] acpi-cpufreq: use cpu_core_map on multicore processors

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: cpufreq-bounces@lists.linux.org.uk 
>[mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>Alexey Starikovskiy
>Sent: Monday, July 31, 2006 11:54 AM
>To: Brown, Len; Dave Jones
>Cc: cpufreq@lists.linux.org.uk
>Subject: [PATCH 6/8] acpi-cpufreq: use cpu_core_map on 
>multicore processors
>
> acpi-cpufreq.c |   11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
>on some new systems "shared_cpu_map" from ACPI is wrong, so   
>"cpu_core_map" structure is used to define right "policy->cpus" group.
>
>Signed-off: Denis Sadykov <denis.m.sadykov@intel.com>
>Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi at intel.com>
>Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy at intel.com>
>
>Index: linux-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>===================================================================
>--- 
>linux-2.6.17.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	
>2006-07-17 17:09:27.000000000 +0000
>+++ linux-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	
>2006-07-17 17:11:07.000000000 +0000
>@@ -542,7 +542,16 @@
> 		}
> 	}
> 
>-	policy->cpus = data->acpi_data->shared_cpu_map;
>+/*	policy->cpus = data->acpi_data->shared_cpu_map; */
>+/* NOTE TODO:
>+	Actually we must use "shared_cpu_map" from acpi data to 
>define policy->cpus,
>+	but on some new systems "shared_cpu_map" is wrong. So 
>we use "cpu_core_map"
>+	sructure temporarily. Should be return back. */
>+#ifdef CONFIG_SMP
>+	policy->cpus = cpu_core_map[cpu];
>+#else
>+	policy->cpus = cpumask_of_cpu(cpu);
>+#endif /* CONFIG_SMP */
> 	for_each_cpu_mask(i, policy->cpus) {
> 		drv_data[i] = data;
> 	}
>

I don't think this should be done universally. We should try to limit it
to only for the platforms that has this issue, using OEMID or some such
thing. In any case, this patch should not be part of this patch set.
Should be a standalone bugfix-workaround patch with more details about
the bug.

Thanks,
Venki

Re: [PATCH 6/8] acpi-cpufreq: use cpu_core_map on multicore processors

[Alexey Starikovskiy]

Pallipadi, Venkatesh wrote:
>  
> 
>> -----Original Message-----
>> From: cpufreq-bounces@lists.linux.org.uk 
>> [mailto:cpufreq-bounces@lists.linux.org.uk] On Behalf Of 
>> Alexey Starikovskiy
>> Sent: Monday, July 31, 2006 11:54 AM
>> To: Brown, Len; Dave Jones
>> Cc: cpufreq@lists.linux.org.uk
>> Subject: [PATCH 6/8] acpi-cpufreq: use cpu_core_map on 
>> multicore processors
>>
>> acpi-cpufreq.c |   11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> on some new systems "shared_cpu_map" from ACPI is wrong, so   
>> "cpu_core_map" structure is used to define right "policy->cpus" group.
>>
>> Signed-off: Denis Sadykov <denis.m.sadykov@intel.com>
>> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi at intel.com>
>> Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy at intel.com>
>>
>> Index: linux-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
>> ===================================================================
>> --- 
>> linux-2.6.17.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	
>> 2006-07-17 17:09:27.000000000 +0000
>> +++ linux-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	
>> 2006-07-17 17:11:07.000000000 +0000
>> @@ -542,7 +542,16 @@
>> 		}
>> 	}
>>
>> -	policy->cpus = data->acpi_data->shared_cpu_map;
>> +/*	policy->cpus = data->acpi_data->shared_cpu_map; */
>> +/* NOTE TODO:
>> +	Actually we must use "shared_cpu_map" from acpi data to 
>> define policy->cpus,
>> +	but on some new systems "shared_cpu_map" is wrong. So 
>> we use "cpu_core_map"
>> +	sructure temporarily. Should be return back. */
>> +#ifdef CONFIG_SMP
>> +	policy->cpus = cpu_core_map[cpu];
>> +#else
>> +	policy->cpus = cpumask_of_cpu(cpu);
>> +#endif /* CONFIG_SMP */
>> 	for_each_cpu_mask(i, policy->cpus) {
>> 		drv_data[i] = data;
>> 	}
>>
> 
> I don't think this should be done universally. We should try to limit it
> to only for the platforms that has this issue, using OEMID or some such
> thing. In any case, this patch should not be part of this patch set.
> Should be a standalone bugfix-workaround patch with more details about
> the bug.
> 
> Thanks,
> Venki
May be it belongs to processor_perflib, place there we check for _PSD?

[PATCH 6/8] acpi-cpufreq: use cpu_core_map on multicore processors

[Alexey Starikovskiy]

 acpi-cpufreq.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

on some new systems “shared_cpu_map” from ACPI is wrong, so   “cpu_core_map” structure is used to define right “policy->cpus” group.

Signed-off: Denis Sadykov <denis.m.sadykov@intel.com>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi at intel.com>
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy at intel.com>

Index: linux-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===================================================================
--- linux-2.6.17.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	2006-07-17 17:09:27.000000000 +0000
+++ linux-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c	2006-07-17 17:11:07.000000000 +0000
@@ -542,7 +542,16 @@
 		}
 	}
 
-	policy->cpus = data->acpi_data->shared_cpu_map;
+/*	policy->cpus = data->acpi_data->shared_cpu_map; */
+/* NOTE TODO:
+	Actually we must use "shared_cpu_map" from acpi data to define policy->cpus,
+	but on some new systems "shared_cpu_map" is wrong. So we use "cpu_core_map"
+	sructure temporarily. Should be return back. */
+#ifdef CONFIG_SMP
+	policy->cpus = cpu_core_map[cpu];
+#else
+	policy->cpus = cpumask_of_cpu(cpu);
+#endif /* CONFIG_SMP */
 	for_each_cpu_mask(i, policy->cpus) {
 		drv_data[i] = data;
 	}