FSB scaling for ASUS EeePC 1000H

FSB scaling for ASUS EeePC 1000H

[Francesco Lattanzio]

[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]

The following patch (against the current "linux-acpi-2.6" source tree) 
adds the capability of the ASUS EeePC 1000H (and maybe other models as 
well) to scale the FSB frequency and core voltage. Do not confuse this 
with cpufreq (SpeedStep and other similar mechanisms): cpufreq changes 
the internal CPU clock multiplier (and eventually the core voltage too) 
leaving the FSB frequency untouched.

A new file, "cpuclk_cfg", is added under "/sys/devices/platform/eeepc" 
through which is possible to select one of the available predefined CPU 
clock configuration (FSB frequency and core voltage).

Reading from cpuclk_cfg returns two numbers: the first is the number of 
available "CPU clock configurations", the second is a non-negative 
number less than the first representing the current configuration. If 
the function is not supported (through ACPI) the string "<unsupported>" 
is returned instead.

Writing a number to cpuclk_cfg allows to change the current CPU clock 
configuration.

On the Eee PC 1000H there are three available clock configuration:

        0 -> Super Performance Mode
        1 -> High Performance Mode
        2 -> Power Saving Mode

The selected configuration is saved into the NVRAM and restored after a 
reboot. This fact allowed me to use use /proc/cpuinfo to measure the CPU 
clock (while keeping SpeedStep disabled, i.e. at its maximum multiplier 
value):

        0 -> cpu MHz: 1709.760 / bogomips: 3420.00
        1 -> cpu MHz: 1595.736 / bogomips: 3192.45
        2 -> cpu MHz: 1254.026 / bogomips: 2509.55

The attached file is a dump of the DSDT taken from my EeePC 1000H I used 
as a reference to write the patch.
Here is the patch:

diff --git a/drivers/platform/x86/eeepc-laptop.c 
b/drivers/platform/x86/eeepc-laptop.c
index 786ed86..d079d51 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -382,10 +382,40 @@ EEEPC_CREATE_DEVICE_ATTR(camera, CM_ASL_CAMERA);
 EEEPC_CREATE_DEVICE_ATTR(cardr, CM_ASL_CARDREADER);
 EEEPC_CREATE_DEVICE_ATTR(disp, CM_ASL_DISPLAYSWITCH);
 
+
+static ssize_t show_ckfg(struct device *dev,
+                        struct device_attribute *attr,
+                        char *buf)
+{
+       int n_of_cfgs,current_cfg;
+       current_cfg=get_acpi(CM_ASL_CPUFV);
+       if (current_cfg<0)
+               return sprintf(buf, "%s\n", "<unsupported>");
+       n_of_cfgs=(current_cfg>>8)&0xff;
+       current_cfg&=0xff;
+       return sprintf(buf, "%d %d\n", n_of_cfgs, current_cfg);
+}
+
+static ssize_t store_ckfg(struct device *dev,
+                         struct device_attribute *attr,
+                         const char *buf, size_t count)
+{
+       return store_sys_acpi(CM_ASL_CPUFV, buf, count);
+}
+
+static struct device_attribute dev_attr_ckfg = {
+       .attr = {
+               .name = "cpuclk_cfg",
+               .mode = 0644 },
+       .show   = show_ckfg,
+       .store  = store_ckfg
+};
+
 static struct attribute *platform_attributes[] = {
        &dev_attr_camera.attr,
        &dev_attr_cardr.attr,
        &dev_attr_disp.attr,
+       &dev_attr_ckfg.attr,
        NULL
 };


-- 
Francesco Lattanzio <franz.lattanzio@gmail.com>


[-- Attachment #2: eeepc_1000h_dsdt.dsl.gz --]
[-- Type: application/gzip, Size: 16805 bytes --]

Re: FSB scaling for ASUS EeePC 1000H

[Matthew Garrett]

On Sun, Mar 15, 2009 at 04:01:23PM +0100, Francesco Lattanzio wrote:
> The following patch (against the current "linux-acpi-2.6" source tree) 
> adds the capability of the ASUS EeePC 1000H (and maybe other models as 
> well) to scale the FSB frequency and core voltage. Do not confuse this 
> with cpufreq (SpeedStep and other similar mechanisms): cpufreq changes 
> the internal CPU clock multiplier (and eventually the core voltage too) 
> leaving the FSB frequency untouched.

No, there's no requirement that cpufreq be limited to clock-multiplier 
based methods. It's the right interfae to use for CPU speed control.

(snip patch)

Is this different to the cpufreq driver suggested at 
http://lkml.org/lkml/2008/11/23/115 , other than the latter having 
hardcoded speed values?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: FSB scaling for ASUS EeePC 1000H

[Francesco Lattanzio]

Matthew Garrett ha scritto:
> On Sun, Mar 15, 2009 at 04:01:23PM +0100, Francesco Lattanzio wrote:
>   
>> The following patch (against the current "linux-acpi-2.6" source tree) 
>> adds the capability of the ASUS EeePC 1000H (and maybe other models as 
>> well) to scale the FSB frequency and core voltage. Do not confuse this 
>> with cpufreq (SpeedStep and other similar mechanisms): cpufreq changes 
>> the internal CPU clock multiplier (and eventually the core voltage too) 
>> leaving the FSB frequency untouched.
>>     
>
> No, there's no requirement that cpufreq be limited to clock-multiplier 
> based methods. It's the right interfae to use for CPU speed control.
>
> (snip patch)
>
> Is this different to the cpufreq driver suggested at 
> http://lkml.org/lkml/2008/11/23/115 , other than the latter having 
> hardcoded speed values?
>
>   
It is exactly the same thing, done differently. Now I ask you, should we 
put this feature inside some eeepc-specific cpufreq module, or inside 
the eeepc-laptop module? Keep in mind that the 1000H model allows me to 
combine the effects of both the cpufreq (through Atom SpeedStep feature) 
and these ACPI methods.

-- 
Francesco Lattanzio <franz.lattanzio@gmail.com>

Re: FSB scaling for ASUS EeePC 1000H

[Matthew Garrett]

On Tue, Mar 17, 2009 at 09:26:06AM +0100, Francesco Lattanzio wrote:

> It is exactly the same thing, done differently. Now I ask you, should we 
> put this feature inside some eeepc-specific cpufreq module, or inside 
> the eeepc-laptop module? Keep in mind that the 1000H model allows me to 
> combine the effects of both the cpufreq (through Atom SpeedStep feature) 
> and these ACPI methods.

Putting it in eeepc-laptop is probably easier. I'd recommend doing it 
with cpufreq, but making sure that the transition latency is large 
enough that ondemand won't try to mess with it. There's actually an 
interesting question of what to do with making sure performance doesn't 
bind and push you to a speed you don't want by default. I'll talk to 
Dave about that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org