| Message ID | 49BD1843.7050502@gmail.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
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 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.
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.
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 };
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: