Re: [PATCH] Kconfig powernow-k8 driver should depend on ACPI P-Statesdriver
From: Ed Sweetman
Date: Fri May 18 2007 - 00:08:22 EST
Joshua Hoblitt wrote:
I think it's pretty clear that Dave and Daniel were both correct and
that ACPI_PROCESSOR is the correct dependency for multi-socket systems.
However, it's worth noting that this dependency seems to be unrelated to
SMP support. Ed Sweetman has reported that his single-socket but
multi-core system doesn't require ACPI_PROCESSOR for powernow support.
I just tried booting 2.6.21 w/o SMP support and w/o ACPI_PROCESSOR on
one of my multi-socket/multi-core systems. Sure enough, powernow
won't work without ACPI_PROCESSOR:
I said before and originally, in response to the original post by you,
that i didn't need acpi p-states driver, which is what this thread was
suggesting. We later determined that the thread title was misleading,
this thread should be titled "Kconfig powernow-k8 driver should depend
on ACPI_PROCESSOR driver"
I've always compiled acpi_processor in the kernel, i use acpi, i have a
processor, it seemed to fit.
powernow-k8: Found 1 Dual-Core AMD Opteron(tm) Processor 2220 processors (version 2.00.00)
powernow-k8: BIOS error - no PSB or ACPI _PSS objects
I suppose this means that the BIOS does something different to enable
SMP on a multi-core single socket and multi-socket systems. Anyways, I
believe the question that needs to be answered is: is it reasonable for
X86_POWERNOW_K8 to select ACPI_PROCESSOR if SMP is set? I'm not sure we
can do anything more intelligent unless Kconfig had more knowledge of
how the hardware other than just SMP/!SMP.
-J
My patch does the most intelligent thing thus far, it lets the user
decide. If the user is smart enough to enable cpufreq's powernow-k8
driver, then the user is smart enough to decide if he wants/needs to use
the acpi support of that driver. I'm just exposing the driver that is
causing all of this confusion to the user, since this is the driver that
gets enabled/disabled behind the scenes depending on acpi_processor
being selected. Now it's not automatically handled, the user can enable
acpi support or disable it (in the powernow driver), even if
acpi_processor is compiled in.
you should be able to use the acpi support of Powernow-k8 even in UP
situations, so only enabling it for SMP is wrong. Enabling it whenever
you have acpi compiled in and acpi_processor compiled in is wrong,
because the user may be using a UP system and not want to lookup the
acpi tables for powernow for some ungodly reason. Just allowing the
user to handle it works best. See my previous post for the patch.
--
On Wed, May 16, 2007 at 04:48:07PM -0400, Dave Jones wrote:
On Wed, May 16, 2007 at 08:53:13PM +0100, Duane Griffin wrote:
> On 16/05/07, Prakash Punnoor <prakash@xxxxxxxxxx> wrote:
> > Maybe you want to give a hint in the p states driver help text?
>
> I think a hint is the right thing to do, but in the PowerNow! driver
> rather than the p states one. How about adding something like this to
> the X86_POWERNOW_K8 (and X86_POWERNOW_K7?) help text:
The mobile K7s which had powernow support weren't SMP capable, so they're
irrelevant.
> "ACPI support is required for non-UP systems and requires ACPI_PROCESSOR
> to be selected. If ACPI_PROCESSOR is compiled as a module then this
> option must be too in order for ACPI support to be available."
X86_POWERNOW_K8_ACPI is already 'default y'. I think the problem lies in
that people aren't enabling its dependancy, ACPI_PROCESSOR.
We want something along the lines of..
config X86_POWERNOW_K8_ACPI
bool
if SMP & X86_POWERNOW_K8_ACPI
select ACPI_PROCESSOR
kconfig language quirks aside..
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/