* [PATCH 2.6] powernow-k7 acpi support.
@ 2004-02-09 13:26 Bruno Ducrot
2004-02-09 15:05 ` Dominik Brodowski
0 siblings, 1 reply; 11+ messages in thread
From: Bruno Ducrot @ 2004-02-09 13:26 UTC (permalink / raw)
To: davej; +Cc: Dominik Brodowski, cpufreq
Hi Dave, Dominik, list,
Since now linux-2.6 bk tree do have necessary patches from Dominik for,
this is a possible version in order to get the powernow table from ACPI,
if the legacy method fail, or if the laptop is blacklisted. The following
patch do only include the static function powernow_acpi_init() that have
to be called in order to get the config stuff from acpi.
By now, there are different ways to use it. The present patch do not
include any of them.
1- Include the powernow_acpi_init() as the first call in
powernow_decode_bios(), so that ACPI is used first, then if it failed,
the legacy method is used,
or
2- Include the powernow_acpi_init() at powernow_decode_bios() just
before the 3 printk's stating to write that you should see
http://www.codemonkey.org.uk/projects/cpufreq/...
I guess 2- is 'better', but I would like to get some thought, though.
--- linux-2.6.2-rc3-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2004/02/03 19:05:44 1.4
+++ linux-2.6.2-rc3-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2004/02/04 16:03:28
@@ -27,6 +27,11 @@
#include <asm/io.h>
#include <asm/system.h>
+#ifdef CONFIG_ACPI_PROCESSOR
+#include <linux/acpi.h>
+#include <acpi/processor.h>
+#endif
+
#include "powernow-k7.h"
#define DEBUG
@@ -57,6 +62,17 @@
u8 numpstates;
};
+#ifdef CONFIG_ACPI_PROCESSOR
+union powernow_acpi_control_t {
+ struct {
+ unsigned long fid:5,
+ vid:5,
+ sgtc:20,
+ res1:2;
+ } bits;
+ unsigned long val;
+};
+#endif
/* divide by 1000 to get VID. */
static int mobile_vid_table[32] = {
@@ -309,6 +325,110 @@
return 0;
}
+#ifdef CONFIG_ACPI_PROCESSOR
+
+static int powernow_acpi_init(void)
+{
+ int i;
+ int retval = 0;
+ struct acpi_pct_register *r;
+ struct acpi_processor_performance p;
+
+ memset(&p, 0, sizeof (p));
+
+ if (powernow_table != NULL)
+ return -EINVAL;
+
+ printk("1\n");
+ if (acpi_processor_register_performance(&p, 0))
+ return -EIO;
+ printk("2\n");
+
+ r = &p.control_register;
+ if (r->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
+ retval = -ENODEV;
+ goto out;
+ }
+ r = &p.status_register;
+ if (r->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
+ retval = -ENODEV;
+ goto out;
+ }
+
+ number_scales = p.state_count;
+
+ if (number_scales < 2) {
+ retval = -ENODEV;
+ goto out;
+ }
+
+ powernow_table = kmalloc((number_scales + 1) * (sizeof(struct cpufreq_frequency_table)), GFP_KERNEL);
+ if (!powernow_table) {
+ retval = -ENOMEM;
+ goto out;
+ }
+
+ memset(powernow_table, 0, ((number_scales + 1) * sizeof(struct cpufreq_frequency_table)));
+
+ fsb = 100; /* XXX fix me */
+ latency = 10000; /* XXX don't trust bios writers.. */
+
+ for (i = 0; i < number_scales; i++) {
+ union powernow_acpi_control_t pc;
+ u8 fid, vid;
+ unsigned int speed;
+
+ pc.val = (unsigned long) p.states[i].control;
+ dprintk (KERN_INFO PFX "acpi: P%d: %d MHz, %d mW, %d uS, control %08x, status %08x, vid: %02x fid: %02x SGTC: %d\n",
+ i,
+ (u32) p.states[i].core_frequency,
+ (u32) p.states[i].power,
+ (u32) p.states[i].transition_latency,
+ (u32) p.states[i].control,
+ (u32) p.states[i].status,
+ pc.bits.vid,
+ pc.bits.fid,
+ pc.bits.sgtc);
+
+ vid = pc.bits.vid;
+ fid = pc.bits.fid;
+
+ powernow_table[i].frequency = fsb * fid_codes[fid] * 100;
+ powernow_table[i].index = fid; /* lower 8 bits */
+ powernow_table[i].index |= (vid << 8); /* upper 8 bits */
+
+ speed = fsb * (fid_codes[fid]/10);
+ if ((fid_codes[fid] % 10)==5) {
+ speed += fsb/2;
+ if (have_a0 == 1)
+ powernow_table[i].frequency = CPUFREQ_ENTRY_INVALID;
+ }
+
+ dprintk (KERN_INFO PFX " FID: 0x%x (%d.%dx [%dMHz])\t", fid,
+ fid_codes[fid] / 10, fid_codes[fid] % 10, speed);
+ dprintk ("VID: 0x%x (%d.%03dV)\n", vid, mobile_vid_table[vid]/1000,
+ mobile_vid_table[vid]%1000);
+
+ if (speed < minimum_speed)
+ minimum_speed = speed;
+ if (speed > maximum_speed)
+ maximum_speed = speed;
+ }
+ powernow_table[i].frequency = CPUFREQ_TABLE_END;
+ powernow_table[i].index = 0;
+
+ /*
+ * We don't need no more acpi.
+ * XXX is that true?
+ */
+
+out:
+ acpi_processor_unregister_performance(&p, 0);
+
+ return retval;
+}
+#endif
+
static int powernow_decode_bios (int maxfid, int startvid)
{
struct psb_s *psb;
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 13:26 [PATCH 2.6] powernow-k7 acpi support Bruno Ducrot
@ 2004-02-09 15:05 ` Dominik Brodowski
2004-02-09 15:20 ` Bruno Ducrot
2004-02-09 17:50 ` Bruno Ducrot
0 siblings, 2 replies; 11+ messages in thread
From: Dominik Brodowski @ 2004-02-09 15:05 UTC (permalink / raw)
To: Bruno Ducrot; +Cc: davej, cpufreq
[-- Attachment #1.1: Type: text/plain, Size: 1814 bytes --]
> 1- Include the powernow_acpi_init() as the first call in
> powernow_decode_bios(), so that ACPI is used first, then if it failed,
> the legacy method is used,
> or
> 2- Include the powernow_acpi_init() at powernow_decode_bios() just
> before the 3 printk's stating to write that you should see
> http://www.codemonkey.org.uk/projects/cpufreq/...
>
> I guess 2- is 'better', but I would like to get some thought, though.
Hm. That's difficult to decide, also for the speedstep-centrino case... I'd
like to hear some opinions from ACPI and AMD guys first before we decide...
> + printk("1\n");
> + if (acpi_processor_register_performance(&p, 0))
> + return -EIO;
> + printk("2\n");
> +
> + r = &p.control_register;
> + if (r->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
How about
if (p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
?
> + retval = -ENODEV;
> + goto out;
> + }
> + r = &p.status_register;
> + if (r->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
same here...
> + fsb = 100; /* XXX fix me */
Any idea on how to determine the FSB?
> + latency = 10000; /* XXX don't trust bios writers.. */
heh...
> + /*
> + * We don't need no more acpi.
> + * XXX is that true?
> + */
No, it's not true. If we use ACPI, we need to keep it registered until we
stop using it. Reasons:
- keep buggy drivers from interfering [e.g. other cpufreq drivers which
register with ACPI first and with cpufreq later, or avoid registering with
cpufreq because of being proprietary...]
- honor _PPC limits
- allow for ACPI interface (additions):
This includes the /proc/acpi/processor/./performance interface which
people still tend to use, and additions to
/sys/devices/system/cpu/cpu0/cpufreq/ still to be written.
Dominik
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 15:05 ` Dominik Brodowski
@ 2004-02-09 15:20 ` Bruno Ducrot
2004-02-09 17:37 ` Bruno Ducrot
2004-02-09 17:50 ` Bruno Ducrot
1 sibling, 1 reply; 11+ messages in thread
From: Bruno Ducrot @ 2004-02-09 15:20 UTC (permalink / raw)
To: davej, cpufreq; +Cc: Dominik Brodowski
On Mon, Feb 09, 2004 at 04:05:19PM +0100, Dominik Brodowski wrote:
> > 1- Include the powernow_acpi_init() as the first call in
> > powernow_decode_bios(), so that ACPI is used first, then if it failed,
> > the legacy method is used,
> > or
> > 2- Include the powernow_acpi_init() at powernow_decode_bios() just
> > before the 3 printk's stating to write that you should see
> > http://www.codemonkey.org.uk/projects/cpufreq/...
> >
> > I guess 2- is 'better', but I would like to get some thought, though.
>
> Hm. That's difficult to decide, also for the speedstep-centrino case... I'd
> like to hear some opinions from ACPI and AMD guys first before we decide...
Well, ACPI guys would say you to use ACPI for, but I prefer the legacy
method because otherwise I loose 3 power states ;)
>
> > + printk("1\n");
Sound like I forgot to remove that, sorry..
> > + if (acpi_processor_register_performance(&p, 0))
> > + return -EIO;
> > + printk("2\n");
> > +
> > + r = &p.control_register;
> > + if (r->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
>
> How about
> if (p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
because I use p.control_register at least 2 times, and when that happens
I prefer to introduce another variable, because it's more easier to read IMHO.
>
> > + retval = -ENODEV;
> > + goto out;
> > + }
> > + r = &p.status_register;
> > + if (r->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
>
> same here...
and that the second one ;)
>
> > + fsb = 100; /* XXX fix me */
>
> Any idea on how to determine the FSB?
Unfortunately no. I don't have all the AMD processor specification for
this.
>
> > + latency = 10000; /* XXX don't trust bios writers.. */
>
> heh...
OK, I'm perhaps a little bit rude here. I will rewrite that.
>
> > + /*
> > + * We don't need no more acpi.
> > + * XXX is that true?
> > + */
>
> No, it's not true. If we use ACPI, we need to keep it registered until we
> stop using it. Reasons:
> - keep buggy drivers from interfering [e.g. other cpufreq drivers which
> register with ACPI first and with cpufreq later, or avoid registering with
> cpufreq because of being proprietary...]
> - honor _PPC limits
> - allow for ACPI interface (additions):
> This includes the /proc/acpi/processor/./performance interface which
> people still tend to use, and additions to
> /sys/devices/system/cpu/cpu0/cpufreq/ still to be written.
>
Ok (actually, I don't think _PPC is supported on most K7 mobo, since it
return 0 in almost all DSDT, but well, I should consider though in order
to be fully ACPI compliant).
Thanks,
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 15:20 ` Bruno Ducrot
@ 2004-02-09 17:37 ` Bruno Ducrot
0 siblings, 0 replies; 11+ messages in thread
From: Bruno Ducrot @ 2004-02-09 17:37 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: davej, cpufreq
On Mon, Feb 09, 2004 at 04:20:52PM +0100, Bruno Ducrot wrote:
> > How about
> > if (p.control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
>
> because I use p.control_register at least 2 times, and when that happens
> I prefer to introduce another variable, because it's more easier to read IMHO.
Actually, what I wrotte is stupid in that case, and that obfuscate more.
I will do what you suggest.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 15:05 ` Dominik Brodowski
2004-02-09 15:20 ` Bruno Ducrot
@ 2004-02-09 17:50 ` Bruno Ducrot
2004-02-09 18:05 ` Dominik Brodowski
1 sibling, 1 reply; 11+ messages in thread
From: Bruno Ducrot @ 2004-02-09 17:50 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: davej, cpufreq
How about that one? By now, I'm a little puzzled with the fsb stuff,
though. A first idea may be to look into what say ACPI about the
frequency, and deduce the fsb from, but I don't like it.
--- powernow-k7.c 2004-02-09 18:48:22.000000000 +0100
+++ linux-2.6.3-bk-acpi/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2004-02-09 18:37:17.000000000 +0100
@@ -27,6 +27,11 @@
#include <asm/io.h>
#include <asm/system.h>
+#ifdef CONFIG_ACPI_PROCESSOR
+#include <linux/acpi.h>
+#include <acpi/processor.h>
+#endif
+
#include "powernow-k7.h"
#define DEBUG
@@ -57,6 +62,17 @@
u8 numpstates;
};
+#ifdef CONFIG_ACPI_PROCESSOR
+union powernow_acpi_control_t {
+ struct {
+ unsigned long fid:5,
+ vid:5,
+ sgtc:20,
+ res1:2;
+ } bits;
+ unsigned long val;
+};
+#endif
/* divide by 1000 to get VID. */
static int mobile_vid_table[32] = {
@@ -308,6 +325,132 @@
return 0;
}
+#ifdef CONFIG_ACPI_PROCESSOR
+
+struct acpi_processor_performance *acpi_processor_perf;
+
+static int powernow_acpi_init(void)
+{
+ int i;
+ int retval = 0;
+
+ if (acpi_processor_perf != NULL)
+ return -EINVAL;
+
+ if (powernow_table != NULL)
+ return -EINVAL;
+
+ acpi_processor_perf = kmalloc(sizeof(struct acpi_processor_performance),
+ GFP_KERNEL);
+
+ if (!acpi_processor_perf)
+ return -ENOMEM;
+
+ memset(acpi_processor_perf, 0, sizeof(struct acpi_processor_performance));
+
+ if (acpi_processor_register_performance(acpi_processor_perf, 0)) {
+ retval = -EIO;
+ goto err1;
+ }
+
+ if (acpi_processor_perf->control_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
+ retval = -ENODEV;
+ goto err2;
+ }
+
+ if (acpi_processor_perf->status_register.space_id != ACPI_ADR_SPACE_FIXED_HARDWARE) {
+ retval = -ENODEV;
+ goto err2;
+ }
+
+ number_scales = acpi_processor_perf->state_count;
+
+ if (number_scales < 2) {
+ retval = -ENODEV;
+ goto err2;
+ }
+
+ powernow_table = kmalloc((number_scales + 1) * (sizeof(struct cpufreq_frequency_table)), GFP_KERNEL);
+ if (!powernow_table) {
+ retval = -ENOMEM;
+ goto err2;
+ }
+
+ memset(powernow_table, 0, ((number_scales + 1) * sizeof(struct cpufreq_frequency_table)));
+
+ fsb = 100; /* XXX fix me */
+ latency = 0;
+
+ for (i = 0; i < number_scales; i++) {
+ u8 fid, vid;
+ union powernow_acpi_control_t pc;
+ unsigned int speed;
+
+ pc.val = (unsigned long) acpi_processor_perf->states[i].control;
+ dprintk (KERN_INFO PFX "acpi: P%d: %d MHz, %d mW, %d uS, control %08x, status %08x, vid: %02x fid: %02x SGTC: %d\n",
+ i,
+ (u32) acpi_processor_perf->states[i].core_frequency,
+ (u32) acpi_processor_perf->states[i].power,
+ (u32) acpi_processor_perf->states[i].transition_latency,
+ (u32) acpi_processor_perf->states[i].control,
+ (u32) acpi_processor_perf->states[i].status,
+ pc.bits.vid,
+ pc.bits.fid,
+ pc.bits.sgtc);
+
+ vid = pc.bits.vid;
+ fid = pc.bits.fid;
+
+ powernow_table[i].frequency = fsb * fid_codes[fid] * 100;
+ powernow_table[i].index = fid; /* lower 8 bits */
+ powernow_table[i].index |= (vid << 8); /* upper 8 bits */
+
+ speed = fsb * (fid_codes[fid]/10);
+ if ((fid_codes[fid] % 10)==5) {
+ speed += fsb/2;
+ if (have_a0 == 1)
+ powernow_table[i].frequency = CPUFREQ_ENTRY_INVALID;
+ }
+
+ dprintk (KERN_INFO PFX " FID: 0x%x (%d.%dx [%dMHz])\t", fid,
+ fid_codes[fid] / 10, fid_codes[fid] % 10, speed);
+ dprintk ("VID: 0x%x (%d.%03dV)\n", vid, mobile_vid_table[vid]/1000,
+ mobile_vid_table[vid]%1000);
+
+ if (latency < pc.bits.sgtc)
+ latency = pc.bits.sgtc;
+
+ if (speed < minimum_speed)
+ minimum_speed = speed;
+ if (speed > maximum_speed)
+ maximum_speed = speed;
+ }
+
+ /* Validate latency. The latency should be at least
+ * 10000 and must fit in a 20 bit register.
+ */
+ if ((latency & ((~((~0u) << 20)))) < 10000) {
+ printk(KERN_WARNING PFX "broken latency in ACPI table.\n");
+ printk(KERN_INFO PFX "ACPI set settling time to %d.%02d microseconds. "
+ "Should be at least 100. Correcting.\n",
+ latency/100,
+ latency%100);
+ latency = 10000;
+ }
+ powernow_table[i].frequency = CPUFREQ_TABLE_END;
+ powernow_table[i].index = 0;
+
+ return 0;
+
+err2:
+ acpi_processor_unregister_performance(acpi_processor_perf, 0);
+err1:
+ kfree(acpi_processor_perf);
+ acpi_processor_perf = NULL;
+ return retval;
+}
+#endif
+
static int powernow_decode_bios (int maxfid, int startvid)
{
struct psb_s *psb;
@@ -640,6 +804,10 @@
static void __exit powernow_exit (void)
{
+ if (acpi_processor_perf) {
+ acpi_processor_unregister_performance(acpi_processor_perf, 0);
+ kfree(acpi_processor_perf);
+ }
cpufreq_unregister_driver(&powernow_driver);
if (powernow_table)
kfree(powernow_table);
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 17:50 ` Bruno Ducrot
@ 2004-02-09 18:05 ` Dominik Brodowski
2004-02-09 18:29 ` Bruno Ducrot
2004-02-09 18:58 ` Bruno Ducrot
0 siblings, 2 replies; 11+ messages in thread
From: Dominik Brodowski @ 2004-02-09 18:05 UTC (permalink / raw)
To: Bruno Ducrot; +Cc: davej, cpufreq
[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]
On Mon, Feb 09, 2004 at 06:50:00PM +0100, Bruno Ducrot wrote:
>
> How about that one?
Looks much better, IMO.
> By now, I'm a little puzzled with the fsb stuff,
> though. A first idea may be to look into what say ACPI about the
> frequency, and deduce the fsb from, but I don't like it.
So you wouldn't like
fsb = (acpi_processor_perf->states[i].core_frequency * 10) / fid_codes[fid]
? Why?
Dominik
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 18:05 ` Dominik Brodowski
@ 2004-02-09 18:29 ` Bruno Ducrot
2004-02-09 18:58 ` Bruno Ducrot
1 sibling, 0 replies; 11+ messages in thread
From: Bruno Ducrot @ 2004-02-09 18:29 UTC (permalink / raw)
To: cpufreq; +Cc: davej, Bruno Ducrot
On Mon, Feb 09, 2004 at 07:05:53PM +0100, Dominik Brodowski wrote:
> On Mon, Feb 09, 2004 at 06:50:00PM +0100, Bruno Ducrot wrote:
> >
> > How about that one?
>
> Looks much better, IMO.
Thanks.
>
> > By now, I'm a little puzzled with the fsb stuff,
> > though. A first idea may be to look into what say ACPI about the
> > frequency, and deduce the fsb from, but I don't like it.
>
> So you wouldn't like
>
> fsb = (acpi_processor_perf->states[i].core_frequency * 10) / fid_codes[fid]
>
> ? Why?
Because I would much prefer a generic function get_amd_fsb(),
independant from bios.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 18:05 ` Dominik Brodowski
2004-02-09 18:29 ` Bruno Ducrot
@ 2004-02-09 18:58 ` Bruno Ducrot
2004-02-10 9:03 ` Dominik Brodowski
1 sibling, 1 reply; 11+ messages in thread
From: Bruno Ducrot @ 2004-02-09 18:58 UTC (permalink / raw)
To: Dominik Brodowski; +Cc: davej, cpufreq
On Mon, Feb 09, 2004 at 07:05:53PM +0100, Dominik Brodowski wrote:
> On Mon, Feb 09, 2004 at 06:50:00PM +0100, Bruno Ducrot wrote:
> >
> > How about that one?
>
> Looks much better, IMO.
>
> > By now, I'm a little puzzled with the fsb stuff,
> > though. A first idea may be to look into what say ACPI about the
> > frequency, and deduce the fsb from, but I don't like it.
>
> So you wouldn't like
>
> fsb = (acpi_processor_perf->states[i].core_frequency * 10) / fid_codes[fid]
>
Ok, you win. That one is ok ?
--- linux-2.6.3-bk-acpi/arch/i386/kernel/cpu/cpufreq/powernow-k7.c.orig 2004-02-09 19:39:41.000000000 +0100
+++ linux-2.6.3-bk-acpi/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2004-02-09 19:58:28.000000000 +0100
@@ -333,6 +333,7 @@
{
int i;
int retval = 0;
+ union powernow_acpi_control_t pc;
if (acpi_processor_perf != NULL)
return -EINVAL;
@@ -378,12 +379,22 @@
memset(powernow_table, 0, ((number_scales + 1) * sizeof(struct cpufreq_frequency_table)));
- fsb = 100; /* XXX fix me */
+ pc.val = (unsigned long) acpi_processor_perf->states[0].control;
+ fsb = (10 * (u32) acpi_processor_perf->states[0].core_frequency) / (fid_codes[pc.bits.fid]);
+ if (fsb > 133)
+ fsb = 133;
+ if (fsb < 100)
+ fsb = 100;
+
+ if (100 + 133 < 2*fsb)
+ fsb = 133;
+ else
+ fsb = 100;
+
latency = 0;
for (i = 0; i < number_scales; i++) {
u8 fid, vid;
- union powernow_acpi_control_t pc;
unsigned int speed;
pc.val = (unsigned long) acpi_processor_perf->states[i].control;
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-09 18:58 ` Bruno Ducrot
@ 2004-02-10 9:03 ` Dominik Brodowski
2004-02-10 18:08 ` Dave Jones
0 siblings, 1 reply; 11+ messages in thread
From: Dominik Brodowski @ 2004-02-10 9:03 UTC (permalink / raw)
To: Bruno Ducrot; +Cc: davej, cpufreq
[-- Attachment #1.1: Type: text/plain, Size: 245 bytes --]
On Mon, Feb 09, 2004 at 07:58:31PM +0100, Bruno Ducrot wrote:
> Ok, you win. That one is ok ?
Looks good as well. All we have to decide is where to call these functions,
though... and Davej has to decide whether he likes it, too :-)
Dominik
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-10 9:03 ` Dominik Brodowski
@ 2004-02-10 18:08 ` Dave Jones
2004-02-10 20:05 ` Bruno Ducrot
0 siblings, 1 reply; 11+ messages in thread
From: Dave Jones @ 2004-02-10 18:08 UTC (permalink / raw)
To: Bruno Ducrot, cpufreq
On Tue, Feb 10, 2004 at 10:03:20AM +0100, Dominik Brodowski wrote:
> On Mon, Feb 09, 2004 at 07:58:31PM +0100, Bruno Ducrot wrote:
> > Ok, you win. That one is ok ?
>
> Looks good as well. All we have to decide is where to call these functions,
> though... and Davej has to decide whether he likes it, too :-)
Looks good to me, though I'm missing the part where you wire this up
to the rest of the code. I see two possibilities.
- fallback to acpi when we detect bad PST's.
- module parameter to force usage of acpi (override PST)
Dave
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2.6] powernow-k7 acpi support.
2004-02-10 18:08 ` Dave Jones
@ 2004-02-10 20:05 ` Bruno Ducrot
0 siblings, 0 replies; 11+ messages in thread
From: Bruno Ducrot @ 2004-02-10 20:05 UTC (permalink / raw)
To: Dave Jones; +Cc: cpufreq
On Tue, Feb 10, 2004 at 06:08:12PM +0000, Dave Jones wrote:
> On Tue, Feb 10, 2004 at 10:03:20AM +0100, Dominik Brodowski wrote:
> > On Mon, Feb 09, 2004 at 07:58:31PM +0100, Bruno Ducrot wrote:
> > > Ok, you win. That one is ok ?
> >
> > Looks good as well. All we have to decide is where to call these functions,
> > though... and Davej has to decide whether he likes it, too :-)
>
> Looks good to me, though I'm missing the part where you wire this up
> to the rest of the code. I see two possibilities.
Well, that need to be decided at first. I'm acually testing it by
calling that function in powernow_decode_bios() with something like
that:
--- linux-2.6.3-bk-acpi/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2004/02/10 20:04:05 1.2
+++ linux-2.6.3-bk-acpi/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2004/02/10 20:05:12
@@ -426,6 +426,9 @@
unsigned int etuple;
unsigned int ret;
+ if (powernow_acpi_init() == 0)
+ return 0;
+
etuple = cpuid_eax(0x80000001);
etuple &= 0xf00;
etuple |= (c->x86_model<<4)|(c->x86_mask);
but I guess this is not what people want probably, especially if there
are good PST's.
> - fallback to acpi when we detect bad PST's.
That sound good.
> - module parameter to force usage of acpi (override PST)
Yes, or check if the laptop is blacklisted.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-02-10 20:05 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-09 13:26 [PATCH 2.6] powernow-k7 acpi support Bruno Ducrot
2004-02-09 15:05 ` Dominik Brodowski
2004-02-09 15:20 ` Bruno Ducrot
2004-02-09 17:37 ` Bruno Ducrot
2004-02-09 17:50 ` Bruno Ducrot
2004-02-09 18:05 ` Dominik Brodowski
2004-02-09 18:29 ` Bruno Ducrot
2004-02-09 18:58 ` Bruno Ducrot
2004-02-10 9:03 ` Dominik Brodowski
2004-02-10 18:08 ` Dave Jones
2004-02-10 20:05 ` Bruno Ducrot
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.