powernow-k7. Recalibrate cpu_khz
cover powernow-k7. Recalibrate cpu_khz
Hi,
Here come two patches in order to fix some issues with powernow-k7.
The main trouble is that we can't rely on cpu_khz when that one is computed at boot time. AMD will require that the CPU will be at max frequencies, but some BIOS do not respect this. More, the BIOS is only required to change the frequency of the processor, but only at POST time. Some BIOS also do not follow this rule, so that even if the processor is at full speed at POST, it may decide (probably after switching to ACPI or APM mode?) to switch to another frequency.
The only workaround for this two kind of bugs I see is to recalibrate cpu_khz, but this require discussions with other people, I guess. The second patch will be the powernow-k7 portion.
Cheers,
Signature · 4 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
RFC PATCH 1/2 powernow-k7. Recalibrate cpu_khz (common code)
Some cpufreq drivers (at that time, only powernow-k7) need to recalibrate the cpu_khz at runtime.
arch/i386/kernel/timers/common.c | 15 +++++++++++++-- include/asm-i386/timer.h | 1 + 2 files changed, 14 insertions(+), 2 deletions(-)
arch/i386/kernel/timers/common.c +13 -2
@@ -6,6 +6,7 @@#include <linux/timex.h> #include <linux/errno.h> #include <linux/jiffies.h> +#include <linux/module.h> #include <asm/io.h> #include <asm/timer.h>
@@ -24,7 +25,7 @@#define CALIBRATE_TIME (5 * 1000020/HZ) -unsigned long __init calibrate_tsc (void ) +unsigned long calibrate_tsc (void ) {mach_prepare_counter ();
@@ -139,7 +140,7 @@#endif /* calculate cpu_khz */ -void __init init_cpu_khz (void ) +void init_cpu_khz (void ) {if (cpu_has_tsc) {unsigned long tsc_quotient =calibrate_tsc ();
@@ -158,3 +159,13 @@ } } } + +int recalibrate_cpu_khz (void ) +{ +if (cpu_has_tsc) { +init_cpu_khz (); +return 0 ; + }else +return -ENODEV ; +} +EXPORT_SYMBOL (recalibrate_cpu_khz);
include/asm-i386/timer.h +1 -0
@@ -53,6 +53,7 @@extern unsigned long calibrate_tsc (void );extern void init_cpu_khz (void ); +extern int recalibrate_cpu_khz (void );#ifdef CONFIG_HPET_TIMER extern struct init_timer_opts timer_hpet_init;extern unsigned long calibrate_tsc_hpet (unsigned long *tsc_hpet_quotient_ptr);
Signature · 4 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
RFC PATCH 2/2 powernow-k7. Recalibrate cpu_khz.
In reply to Bruno DucrotWe have to recalibrate cpu_khz in order to use the current FID instead the max FID since some BIOS do not put the processor at maximum frequency at POST. Also, some BIOS will change the processor frequency at our back after cpu_khz was calibrate. Finally, this will fix a long standing bug when we do something like this:
# rmmod powernow-k7 # modprobe powernow-k7
arch/i386/kernel/cpu/cpufreq/powernow-k7.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-)
arch/i386/kernel/cpu/cpufreq/powernow-k7.c +7 -2
@@ -23,6 +23,7 @@#include <linux/dmi.h> #include <asm/msr.h> +#include <asm/timer.h> #include <asm/timex.h> #include <asm/io.h> #include <asm/system.h>
@@ -586,8 +587,12 @@ static int __init powernow_cpu_init (strrdmsrl (MSR_K7_FID_VID_STATUS , fidvidstatus.val); -/* A K7 with powernow technology is set to max frequency by BIOS */ - fsb = (10 * cpu_khz) / fid_codes[fidvidstatus.bits.MFID]; +/* We have to recalibrate cpu_khz unfortunately */ + result =recalibrate_cpu_khz (); +if (result) +return result; + + fsb = (10 * cpu_khz) / fid_codes[fidvidstatus.bits.CFID];if (!fsb) { printk(KERN_WARNING PFX "can not determine bus frequency\n");return -EINVAL ;
Signature · 4 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 12 lines · Bruno Ducrot
Hi,
Here come two patches in order to fix some issues with powernow-k7.
The main trouble is that we can't rely on
cpu_khzwhen that one is computed at boot time. AMD will require that the CPU will be at max frequencies, but some BIOS do not respect this. More, the BIOS is only required to change the frequency of the processor, but only at POST time. Some BIOS also do not follow this rule, so that even if the processor is at full speed at POST, it may decide (probably after switching to ACPI or APM mode?) to switch to another frequency.
Quoted 3 lines
The only workaround for this two kind of bugs I see is to recalibrate
cpu_khz, but this require discussions with other people, I guess. The second patch will be the powernow-k7 portion.
Very interesting approach -- and something which might be useful for the ACPI cpufreq driver as well: by doing the cpu_khz re-calculation we can check whether the speed changed --> finally a ->get() function [and one which clearly shows that it may only be accessible to root] can be implemented for this driver... Also, on "lost ticks" we might fall back to try a cpu_khz re-calculation first...
However, I'd like to have John Stultz input on this -- especially as he maintains the timing subsystem. And one problem I see is that we'd need to update "loops_per_jiffy" accordingly...
Thanks,
Dominik
_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq
Quoted 17 lines · Dominik Brodowski
Quoted 12 lines · Bruno Ducrot
Hi,
Here come two patches in order to fix some issues with powernow-k7.
The main trouble is that we can't rely on
cpu_khzwhen that one is computed at boot time. AMD will require that the CPU will be at max frequencies, but some BIOS do not respect this. More, the BIOS is only required to change the frequency of the processor, but only at POST time. Some BIOS also do not follow this rule, so that even if the processor is at full speed at POST, it may decide (probably after switching to ACPI or APM mode?) to switch to another frequency.Quoted 3 lines
The only workaround for this two kind of bugs I see is to recalibrate
cpu_khz, but this require discussions with other people, I guess. The second patch will be the powernow-k7 portion.
Quoted 6 lines
Very interesting approach -- and something which might be useful for the ACPI cpufreq driver as well: by doing the
cpu_khzre-calculation we can check whether the speed changed --> finally a ->get() function [and one which clearly shows that it may only be accessible to root] can be implemented for this driver... Also, on "lost ticks" we might fall back to try acpu_khzre-calculation first...
Well, there may be some issues though since some processors do have well known broken TSC support. And the p4-clockmod driver can't recalibrate cpu_khz just because TSC frequency do not change.
Quoted 1 line
However, I'd like to have John Stultz input on this
I will ask him.
Quoted 3 lines
-- especially as he
maintains the timing subsystem. And one problem I see is that we'd need to update "loops_per_jiffy" accordingly...
I forgot indeed loops_per_jiffy. I feel sometimes stupid.
Cheers,
Signature · 4 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Quoted 10 lines · Bruno Ducrot
Quoted 6 lines
Very interesting approach -- and something which might be useful for the ACPI cpufreq driver as well: by doing the
cpu_khzre-calculation we can check whether the speed changed --> finally a ->get() function [and one which clearly shows that it may only be accessible to root] can be implemented for this driver... Also, on "lost ticks" we might fall back to try acpu_khzre-calculation first...Well, there may be some issues though since some processors do have well known broken TSC support. And the p4-clockmod driver can't recalibrate
cpu_khzjust because TSC frequency do not change.
However, if the TSC is fixed we also don't see "lost ticks" :-)
Quoted 3 lines
Quoted 1 line
However, I'd like to have John Stultz input on this
I will ask him.
Excellent.
Quoted 5 lines
Quoted 3 lines
-- especially as he
maintains the timing subsystem. And one problem I see is that we'd need to update "loops_per_jiffy" accordingly...I forgot indeed
loops_per_jiffy. I feel sometimes stupid.
Then let me tell you that you're definitely _not_ stupid.
Thanks,
Dominik