From: Ed Sweetman <safemode2@comcast.net>
To: Dave Jones <davej@redhat.com>
Cc: Len Brown <lenb@kernel.org>, Daniel Drake <dsd@gentoo.org>,
duaneg@dghda.com, prakash@punnoor.de, jhoblitt@ifa.hawaii.edu,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powernow-k8: depend on acpi-processor for SMP systems
Date: Thu, 17 May 2007 17:40:31 -0400 [thread overview]
Message-ID: <464CCBCF.3010001@comcast.net> (raw)
In-Reply-To: <464CC920.6030409@comcast.net>
[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]
Ed Sweetman wrote:
> Dave Jones wrote:
>> On Thu, May 17, 2007 at 02:13:42PM -0400, Len Brown wrote:
>>
>> > > Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig
>> > > ===================================================================
>> > > --- linux.orig/arch/i386/kernel/cpu/cpufreq/Kconfig
>> > > +++ linux/arch/i386/kernel/cpu/cpufreq/Kconfig
>> > > @@ -81,6 +81,7 @@ config X86_POWERNOW_K7_ACPI
>> > > config X86_POWERNOW_K8
>> > > tristate "AMD Opteron/Athlon64 PowerNow!"
>> > > select CPU_FREQ_TABLE
>> > > + select ACPI_PROCESSOR if SMP
>> > > depends on EXPERIMENTAL
>> > > help
>> > > This adds the CPUFreq driver for mobile AMD
>> Opteron/Athlon64 processors.
>> > > Unfortunately this patch will not actually enable
>> ACPI_PROCESSOR in
>> > the SMP=y ACPI=n case. "select" doesn't work for targets that
>> > have dependencies.
>>
>> I don't think we can fix this perfectly tbh, but the above at
>> least gets us close for the majority of users.
>>
>> Are there many x86-64 users that don't enable acpi ?
>>
>> Dave
>>
>>
> I've just always compiled acpi_processor in, it's only logical that if
> you are using a power management feature, that you compile in the
> power management interface, and if your stuff deals directly with the
> cpu, you may want to compile the acpi_processor driver in. The only
> reason I knew to do that though, was because i go through each
> option. Someone else looking to just enable cpufreq, would skip the
> sub-drivers of ACPI, and never know better. We dont suggest anywhere
> in the cpufreq driver, we dont mention restrictions or limits of the
> driver without acpi, and we certainly dont select it or make it
> dependent (except silently and invisibly to the user).
> Every other cpufreq driver demands acpi. In windows you have to have
> acpi, the p states are called acpi p states everywhere. The problem
> here is that the author to the powernow_k8 driver found a way to get
> some cpufreq functionality without acpi.
> So to make everyone happy, maybe we should have the silently
> selected/deselected driver exposed to the user, as a sub-driver.
> -> Powernow K8 / athlon64 cpufreq driver y/m/n
> -------> ACPI support y/m/n
>
Here's a patch
[-- Attachment #2: powernow.patch --]
[-- Type: text/x-patch, Size: 682 bytes --]
--- ./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 17:37:24.000000000 -0400
@@ -10,7 +10,7 @@
comment "CPUFreq processor drivers"
-config X86_POWERNOW_K8
+config X86_POWERNOW_K8
tristate "AMD Opteron/Athlon64 PowerNow!"
select CPU_FREQ_TABLE
help
@@ -21,10 +21,10 @@
If in doubt, say N.
config X86_POWERNOW_K8_ACPI
- bool
+ tristate "ACPI support"
depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
- default y
+
config X86_SPEEDSTEP_CENTRINO
tristate "Intel Enhanced SpeedStep (deprecated)"
next prev parent reply other threads:[~2007-05-17 21:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-16 23:50 [PATCH] powernow-k8: depend on acpi-processor for SMP systems Daniel Drake
2007-05-17 0:03 ` Dave Jones
2007-05-17 0:26 ` Joshua Hoblitt
2007-05-17 0:37 ` Dave Jones
2007-05-17 0:54 ` Daniel Drake
2007-05-17 1:03 ` Ed Sweetman
2007-05-17 9:02 ` Pavel Machek
2007-05-17 10:24 ` Ed Sweetman
2007-06-04 10:52 ` Pavel Machek
2007-05-17 18:13 ` Len Brown
2007-05-17 18:23 ` Dave Jones
2007-05-17 21:29 ` Ed Sweetman
2007-05-17 21:40 ` Ed Sweetman [this message]
2007-05-17 21:52 ` Dave Jones
2007-05-17 22:15 ` Ed Sweetman
2007-05-17 21:43 ` Dave Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=464CCBCF.3010001@comcast.net \
--to=safemode2@comcast.net \
--cc=davej@redhat.com \
--cc=dsd@gentoo.org \
--cc=duaneg@dghda.com \
--cc=jhoblitt@ifa.hawaii.edu \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=prakash@punnoor.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.