Hello,
Below is a one line patch to possibly fix this bug:
http://bugs.gentoo.org/show_bug.cgi?id=178585
http://bugzilla.kernel.org/show_bug.cgi?id=8075
If the kernel is configured with:
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_ACPI_CPUFREQ=m
Which is currently an allowed configuration, the powernow-k8 driver on
an SMP system will fail with a warning like:
powernow-k8: Found 4 Dual Core AMD Opteron(tm) Processor 285 processors (version 2.00.00)
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
Which mimics that failure you get when powernow/cool'n'quiet is disabled
in the BIOS. I don't know if this config combination is valid on a
uniprocessor system so this dependency may need to be enforced only if
SMP in enabled. The other powernow-* drivers likely have the same
requirements as -k8 but I am unable to test them.
Signed-off-by: Joshua Hoblitt <[email protected]>
--
Kconfig | 1 +
1 file changed, 1 insertion(+)
--- linux-2.6.21.1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-04-27 11:49:26.000000000 -1000
+++ linux-2.6.21.1/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-05-15 14:48:50.000000000 -1000
@@ -82,6 +82,7 @@ config X86_POWERNOW_K8
tristate "AMD Opteron/Athlon64 PowerNow!"
select CPU_FREQ_TABLE
depends on EXPERIMENTAL
+ depends on X86_ACPI_CPUFREQ
help
This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 processors.
[Copying maintainer.]
Joshua Hoblitt wrote:
> Hello,
>
> Below is a one line patch to possibly fix this bug:
>
> http://bugs.gentoo.org/show_bug.cgi?id=178585
> http://bugzilla.kernel.org/show_bug.cgi?id=8075
>
> If the kernel is configured with:
>
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_X86_ACPI_CPUFREQ=m
>
> Which is currently an allowed configuration, the powernow-k8 driver on
> an SMP system will fail with a warning like:
>
> powernow-k8: Found 4 Dual Core AMD Opteron(tm) Processor 285 processors (version 2.00.00)
> powernow-k8: MP systems not supported by PSB BIOS structure
> powernow-k8: MP systems not supported by PSB BIOS structure
> powernow-k8: MP systems not supported by PSB BIOS structure
> powernow-k8: MP systems not supported by PSB BIOS structure
>
> Which mimics that failure you get when powernow/cool'n'quiet is disabled
> in the BIOS. I don't know if this config combination is valid on a
> uniprocessor system so this dependency may need to be enforced only if
> SMP in enabled. The other powernow-* drivers likely have the same
> requirements as -k8 but I am unable to test them.
>
> Signed-off-by: Joshua Hoblitt <[email protected]>
> --
> Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-2.6.21.1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-04-27 11:49:26.000000000 -1000
> +++ linux-2.6.21.1/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-05-15 14:48:50.000000000 -1000
> @@ -82,6 +82,7 @@ config X86_POWERNOW_K8
> tristate "AMD Opteron/Athlon64 PowerNow!"
> select CPU_FREQ_TABLE
> depends on EXPERIMENTAL
> + depends on X86_ACPI_CPUFREQ
> help
> This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 processors.
>
>
<dropping trivial@ from cc: as this definitly isn't>
On Tue, May 15, 2007 at 03:17:11PM -1000, Joshua Hoblitt wrote:
> --- linux-2.6.21.1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-04-27 11:49:26.000000000 -1000
> +++ linux-2.6.21.1/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-05-15 14:48:50.000000000 -1000
> @@ -82,6 +82,7 @@ config X86_POWERNOW_K8
> tristate "AMD Opteron/Athlon64 PowerNow!"
> select CPU_FREQ_TABLE
> depends on EXPERIMENTAL
> + depends on X86_ACPI_CPUFREQ
> help
> This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 processors.
This is completely the wrong thing to do.
There's no dependancy between these two modules, as they are two independant
cpufreq drivers. I think you may be confused with X86_POWERNOW_K8_ACPI
(Which should get set if you have ACPI_PROCESSOR enabled)
Dave
--
http://www.codemonkey.org.uk
Am Mittwoch 16 Mai 2007 schrieb Joshua Hoblitt:
> Hello,
>
> Below is a one line patch to possibly fix this bug:
>
> http://bugs.gentoo.org/show_bug.cgi?id=178585
> http://bugzilla.kernel.org/show_bug.cgi?id=8075
>
> If the kernel is configured with:
>
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_X86_ACPI_CPUFREQ=m
>
> Which is currently an allowed configuration, the powernow-k8 driver on
> an SMP system will fail with a warning like:
NAK. I have an Athlon X2 and it works for me w/o the P states driver compiled
in.
YOu probably should ask the vendor to fix the bios or simply compile in the p
states driver additionally w/o forcing the user to do it.
Maybe you want to give a hint in the p states driver help text?
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
On 16/05/07, Prakash Punnoor <[email protected]> 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:
"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."
Cheers,
Duane.
--
"I never could learn to drink that blood and call it wine" - Bob Dylan
Duane Griffin wrote:
> On 16/05/07, Prakash Punnoor <[email protected]> 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:
Please hold off this patch until we've gained a more complete
understanding of the issues and workarounds (which will probably lead to
us writing a better patch anyway)
Daniel
On Wed, May 16, 2007 at 08:53:13PM +0100, Duane Griffin wrote:
> On 16/05/07, Prakash Punnoor <[email protected]> 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
On Wed, May 16, 2007 at 04:04:40PM -0400, Daniel Drake wrote:
> Duane Griffin wrote:
> >On 16/05/07, Prakash Punnoor <[email protected]> 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:
>
> Please hold off this patch until we've gained a more complete
> understanding of the issues and workarounds (which will probably lead to
> us writing a better patch anyway)
I agree - the issue is more complicated that I had thought. I received
an off list message saying that this dependency isn't required on a
single-socket Athlon X2 system. So it sounds like isn't an SMP setup
issue as much as it is a multi-socket or perhaps just an issue with my
vendor (Tyan).
-J
--
Joshua Hoblitt wrote:
> On Wed, May 16, 2007 at 04:04:40PM -0400, Daniel Drake wrote:
>
>> Duane Griffin wrote:
>>
>>> On 16/05/07, Prakash Punnoor <[email protected]> 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:
>>>
>> Please hold off this patch until we've gained a more complete
>> understanding of the issues and workarounds (which will probably lead to
>> us writing a better patch anyway)
>>
>
> I agree - the issue is more complicated that I had thought. I received
> an off list message saying that this dependency isn't required on a
> single-socket Athlon X2 system. So it sounds like isn't an SMP setup
> issue as much as it is a multi-socket or perhaps just an issue with my
> vendor (Tyan).
>
> -J
>
> --
>
Like i mentioned off list, the problem here is that cpu freq modules
dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do. Even the
help text of CONFIG_ACPI_PROCESSOR says this. I'm unsure as to why the
drivers that do, dont make the dependency known to Kconfig, since
obviously the writer of acpi_processor knew the dependency existed.
Simple fix would be to just include the depends line for
CONFIG_ACPI_PROCESSOR for the powernow driver, and any others people
wonna test. I suspect most people just compile in the acpi_processor
driver, never seeing this problem occur.
Ed Sweetman wrote:
> Like i mentioned off list, the problem here is that cpu freq modules
> dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do.
Not really. Firstly, some of the cpufreq modules *do* depend on
CONFIG_ACPI_PROCESSOR. Secondly, the ones that don't have an existing
dependency do not actually depend on ACPI_PROCESSOR in some/most
configurations.
I'll send in a patch to fix the real problem soon.
Daniel
Daniel Drake wrote:
> Ed Sweetman wrote:
>> Like i mentioned off list, the problem here is that cpu freq modules
>> dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do.
>
> Not really. Firstly, some of the cpufreq modules *do* depend on
> CONFIG_ACPI_PROCESSOR. Secondly, the ones that don't have an existing
> dependency do not actually depend on ACPI_PROCESSOR in some/most
> configurations.
>
> I'll send in a patch to fix the real problem soon.
>
> Daniel
The way i patched it was to just include a "select ACPI_PROCESSOR" in
the X86_POWERNOW_K8 Kconfig entry.
Since the "driver" that the user sees in the Kconfig is X86_POWERNOW_K8
is actually not a driver at all, our actual driver behaves differently
since the "pseudo" driver only depends is CPUFREQ. This is misleading,
as the actual driver beneath it, depends on ACPI_PROCESSOR too. Now the
driver beneath it responds as you'd think. It disables itself when it's
depends lines are invalid. Which is good. But the menu entry that we
see is for X86_POWERNOW_K8, and that isn't disabled or anything when
those depends lines of the driver it actually represents fails.
This is easily fixed with the select line in the "pseudo" driver
...which i find a little more appropriate than a depends line.
As for actual module dependency issues, i haven't bothered looking into
that. As far as the Kconfig shows it shouldn't be allowed to have
ACPI_PROCESSOR as a module at all. So maybe that's intended.
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:
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
--
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 <[email protected]> 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
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 <[email protected]> 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
>>
the previous post i keep referring you to has a patch that was mangled
...here is the non-mangled version
--- ./linux-backup/arch/x86_64/kernel/cpufreq/Kconfig 2007-02-04
13:44:54.000000000 -0500
+++ ./linux-2.6.21-rc5-mm2/arch/x86_64/kernel/cpufreq/Kconfig
2007-05-17 18:13:07.000000000 -0400
@@ -10,20 +10,27 @@
comment "CPUFreq processor drivers"
-config X86_POWERNOW_K8
+config X86_POWERNOW_K8
tristate "AMD Opteron/Athlon64 PowerNow!"
select CPU_FREQ_TABLE
help
This adds the CPUFreq driver for mobile AMD Opteron/Athlon64
processors.
+ An acpi interface is available if acpi support has been selected.
+ This is required for multi-socket and other systems but not
necessarily required for UP single socket systems.
For details, take a look at <file:Documentation/cpu-freq/>.
If in doubt, say N.
config X86_POWERNOW_K8_ACPI
- bool
- depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
- depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
+ bool "ACPI Support"
+ select ACPI_PROCESSOR
+ depends on X86_POWERNOW_K8
+ help
+ This provides access to the acpi tables for full p-state
functionality. This driver is also required
+ for cpufreq to work with multi-socket and other smp systems.
+
+ It is safe to say Y here.
default y
config X86_SPEEDSTEP_CENTRINO
On Fri, May 18, 2007 at 12:09:38AM -0400, Ed Sweetman wrote:
> the previous post i keep referring you to has a patch that was mangled
> ...here is the non-mangled version
>
> --- ./linux-backup/arch/x86_64/kernel/cpufreq/Kconfig 2007-02-04
> 13:44:54.000000000 -0500
> +++ ./linux-2.6.21-rc5-mm2/arch/x86_64/kernel/cpufreq/Kconfig
> 2007-05-17 18:13:07.000000000 -0400
> @@ -10,20 +10,27 @@
>
> comment "CPUFreq processor drivers"
>
> -config X86_POWERNOW_K8
> +config X86_POWERNOW_K8
> tristate "AMD Opteron/Athlon64 PowerNow!"
still has unnecessary whitespace changes
> select CPU_FREQ_TABLE
> help
> This adds the CPUFreq driver for mobile AMD Opteron/Athlon64
> processors.
> + An acpi interface is available if acpi support has been selected.
> + This is required for multi-socket and other systems but not
> necessarily required for UP single socket systems.
and still wordwrapped.
(also capitalise ACPI)
Dave
--
http://www.codemonkey.org.uk
On Fri, May 18, 2007 at 12:01:08PM -0400, Dave Jones wrote:
> On Fri, May 18, 2007 at 12:09:38AM -0400, Ed Sweetman wrote:
[snip]
> still has unnecessary whitespace changes
[snip]
> and still wordwrapped.
> (also capitalise ACPI)
I haven't seen any more e-mail traffic on this topic so I'm assuming
that the ball has been dropped. Please excuse me if an acceptable patch
has been submitted that I wasn't CC'd on.
Here is cleaned up version of Ed's patch that I believe addresses Dave's
stylistic concerns applies the relevant changes to both x86 & x86_64.
Signed-off-by: Joshua Hoblitt <[email protected]>
--
i386/kernel/cpu/cpufreq/Kconfig | 13 ++++++++++---
x86_64/kernel/cpufreq/Kconfig | 13 ++++++++++---
2 files changed, 20 insertions(+), 6 deletions(-)
diff -Nurp linux-2.6.22-rc1-mm1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig linux-2.6.22-rc1-mm1/arch/i386/kernel/cpu/cpufreq/Kconfig
--- linux-2.6.22-rc1-mm1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-04-27 11:49:26.000000000 -1000
+++ linux-2.6.22-rc1-mm1/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-05-21 16:20:47.000000000 -1000
@@ -90,10 +90,17 @@ config X86_POWERNOW_K8
If in doubt, say N.
config X86_POWERNOW_K8_ACPI
- bool
- depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
- depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
+ bool "ACPI Support"
+ select ACPI_PROCESSOR
+ depends on X86_POWERNOW_K8
default y
+ help
+ This provides access to the K8s Processor Performance States via ACPI.
+ This driver is probably required for CPUFreq to work with multi-socket and
+ SMP systems. It is not required on at least some single-socket yet
+ multi-core systems, even if SMP is enabled.
+
+ It is safe to say Y here.
config X86_GX_SUSPMOD
tristate "Cyrix MediaGX/NatSemi Geode Suspend Modulation"
diff -Nurp linux-2.6.22-rc1-mm1.orig/arch/x86_64/kernel/cpufreq/Kconfig linux-2.6.22-rc1-mm1/arch/x86_64/kernel/cpufreq/Kconfig
--- linux-2.6.22-rc1-mm1.orig/arch/x86_64/kernel/cpufreq/Kconfig 2007-05-21 16:11:16.000000000 -1000
+++ linux-2.6.22-rc1-mm1/arch/x86_64/kernel/cpufreq/Kconfig 2007-05-21 16:29:11.000000000 -1000
@@ -24,10 +24,17 @@ config X86_POWERNOW_K8
If in doubt, say N.
config X86_POWERNOW_K8_ACPI
- bool
- depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
- depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
+ bool "ACPI Support"
+ select ACPI_PROCESSOR
+ depends on X86_POWERNOW_K8
default y
+ help
+ This provides access to the K8s Processor Performance States via ACPI.
+ This driver is probably required for CPUFreq to work with multi-socket and
+ SMP systems. It is not required on at least some single-socket yet
+ multi-core systems, even if SMP is enabled.
+
+ It is safe to say Y here.
config X86_SPEEDSTEP_CENTRINO
tristate "Intel Enhanced SpeedStep (deprecated)"
On Mon, May 21, 2007 at 04:47:43PM -1000, Joshua Hoblitt wrote:
apologies for the delay in getting back to this.
> Here is cleaned up version of Ed's patch that I believe addresses Dave's
> stylistic concerns applies the relevant changes to both x86 & x86_64.
The x86-64 version is a symlink to the i386 file, so is unnecessary.
(That trap catches people out regularly).
> Signed-off-by: Joshua Hoblitt <[email protected]>
The patch content looks ok to me, Daniel, ack?
> diff -Nurp linux-2.6.22-rc1-mm1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig l=
> inux-2.6.22-rc1-mm1/arch/i386/kernel/cpu/cpufreq/Kconfig
> --- linux-2.6.22-rc1-mm1.orig/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-04-=
> 27 11:49:26.000000000 -1000
> +++ linux-2.6.22-rc1-mm1/arch/i386/kernel/cpu/cpufreq/Kconfig 2007-05-21 16=
> :20:47.000000000 -1000
> @@ -90,10 +90,17 @@ config X86_POWERNOW_K8
> If in doubt, say N.
> =20
> config X86_POWERNOW_K8_ACPI
> - bool
> - depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
> - depends on !(X86_POWERNOW_K8 =3D y && ACPI_PROCESSOR =3D m)
> + bool "ACPI Support"
MIME damage prevents this from applying.
Dave
--
http://www.codemonkey.org.uk
Dave Jones wrote:
> The patch content looks ok to me, Daniel, ack?
Works for me, thanks.
Daniel