| Message ID | 20130118190659.GB16757@srcf.ucam.org (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Fri, Jan 18, 2013 at 07:06:59PM +0000, Matthew Garrett wrote: > On Fri, Jan 18, 2013 at 08:00:21PM +0100, Borislav Petkov wrote: > > > ################################################################################## > > # x86 drivers. > > # Link order matters. K8 is preferred to ACPI because of firmware bugs in early > > # K8 systems. > > ... > > > > Great. :( > > The only case I can see this hitting would be if the platform is using > system IO rather than fixed hardware functionality. Easiest thing to do > there would be something like this: > > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c > index 0d048f6..8b466d5 100644 > --- a/drivers/cpufreq/acpi-cpufreq.c > +++ b/drivers/cpufreq/acpi-cpufreq.c > @@ -762,6 +762,11 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy) > > switch (perf->control_register.space_id) { > case ACPI_ADR_SPACE_SYSTEM_IO: > + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) { > + pr_debug("Old AMD systems must use native drivers\n"); > + result = -ENODEV; > + goto err_unreg; > + } > pr_debug("SYSTEM IO addr space\n"); > data->cpu_feature = SYSTEM_IO_CAPABLE; > break; Ok, how much can we rely on ACPI to have this ACPI_ADR_SPACE_SYSTEM_IO properly set on K8? Because the thing is, we want to use acpi-cpufreq on F10h onwards and leave powernow-k8 to K8s. So we're purely relying on ->control_register.space_id being ACPI_ADR_SPACE_SYSTEM_IO on *all* K8s. And with the history BIOS has, I don't trust it a single bit. Other than that, this could work... Thanks.
On Fri, Jan 18, 2013 at 08:36:56PM +0100, Borislav Petkov wrote: > Ok, how much can we rely on ACPI to have this ACPI_ADR_SPACE_SYSTEM_IO > properly set on K8? Because the thing is, we want to use acpi-cpufreq on > F10h onwards and leave powernow-k8 to K8s. SYSTEM_IO only supports single processors and was superceded in ACPI 2.0. Are there any single-core F10h?
On Fri, Jan 18, 2013 at 07:38:34PM +0000, Matthew Garrett wrote: > On Fri, Jan 18, 2013 at 08:36:56PM +0100, Borislav Petkov wrote: > > > Ok, how much can we rely on ACPI to have this ACPI_ADR_SPACE_SYSTEM_IO > > properly set on K8? Because the thing is, we want to use acpi-cpufreq on > > F10h onwards and leave powernow-k8 to K8s. > > SYSTEM_IO only supports single processors and was superceded in ACPI > 2.0. Are there any single-core F10h? Hmm, maybe some downcored creations, who knows? But actually, that doesn't matter: we want to exit early from acpi-cpufreq loading on K8 only so the check should simply be: if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD && boot_cpu_data.x86 == 0xf) { pr_debug(...) ... } Yeah, I think that should work. I'll add your patch to the others and make a patchset to give it a run. If it looks good, we'll queue it for 3.9 so that it can see more testing. Thanks.
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 0d048f6..8b466d5 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -762,6 +762,11 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy) switch (perf->control_register.space_id) { case ACPI_ADR_SPACE_SYSTEM_IO: + if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) { + pr_debug("Old AMD systems must use native drivers\n"); + result = -ENODEV; + goto err_unreg; + } pr_debug("SYSTEM IO addr space\n"); data->cpu_feature = SYSTEM_IO_CAPABLE; break;