Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

[Corentin Chary]

>> Could it happen that upcoming machines provide this interface (the two ACPI
>> functions) and also can do real CPU frequency/volt switching, e.g. via
>> acpi-cpufreq?
>
> Probably this interface is a solution specific to machines based on the
> celeron M: I don't even know if other 'old' models provide the same
> interface.

Hi,
We I just received another patch for that (adding a cpufv file in
sysfs) and I don't really know what to do.

As Grigori Goronzy said, using cpufreq in not a good idea:

> 1) dynamic governors like "ondemand" or "conservative" are not suitable
> for SHE. It's possible to avoid usage of these by specifying a long
> (e.g. UINT_MAX) transition latency. However, the fallback governor is
> "performance" which isn't a good idea either, because it'll use the
> overclock setting always. For SHE, the default should be the "normal",
> non-overclocked frequency.
>
> 2) The SHE ACPI interface doesn't expose the clock frequencies. I'm
> using 750 / 1000 / 1500 KHz at the moment, but that's hacky. cpufreq
> does not support performance points with names, such as "powersave",
> "normal", "performance", etc.
>
> 3) It looks like it is impossible to use more than one cpufreq driver
> per CPU. This effectively means you can either use the regular ACPI
> frequency scaling, which switches between multipliers, or SHE. That's
> unacceptable. SHE is not intended to replace the regular frequency
> scaling, but to complement it.

But adding another specific file for eeepc seems ugly too.
Does someone have a great idea to solve that ?

Thanks
-- 
Corentin Chary
http://xf.iksaif.net

Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

[Matthew Garrett]

On Sun, Apr 05, 2009 at 09:43:40AM +0200, Corentin Chary wrote:
> >> Could it happen that upcoming machines provide this interface (the two ACPI
> >> functions) and also can do real CPU frequency/volt switching, e.g. via
> >> acpi-cpufreq?
> >
> > Probably this interface is a solution specific to machines based on the
> > celeron M: I don't even know if other 'old' models provide the same
> > interface.
> 
> Hi,
> We I just received another patch for that (adding a cpufv file in
> sysfs) and I don't really know what to do.
> 
> As Grigori Goronzy said, using cpufreq in not a good idea:

I'm not sure I agree. It's clear that ondemand and conservative aren't 
sensible choices with the driver, but beyond that...

> > 3) It looks like it is impossible to use more than one cpufreq driver
> > per CPU. This effectively means you can either use the regular ACPI
> > frequency scaling, which switches between multipliers, or SHE. That's
> > unacceptable. SHE is not intended to replace the regular frequency
> > scaling, but to complement it.

I don't think there's a terribly good reason to use the SHE methods if 
the CPU supports speedstep. 945 will automatically drop the frontside 
bus in the deepest P states. I'd be surprised if it gave any real world 
benefits on the atom based systems.

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

Re: [Acpi4asus-user] [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

[Grigori Goronzy]

Matthew Garrett wrote:
> I don't think there's a terribly good reason to use the SHE methods if 
> the CPU supports speedstep. 945 will automatically drop the frontside 
> bus in the deepest P states. I'd be surprised if it gave any real world 
> benefits on the atom based systems.
> 

It does make quite a difference, especially because the chipset and CPU
are undervolted in the "powersave" preset. Also, SHE offers a slight
overclock (with the "performance" preset) which cannot be achieved with
mere multiplier switching. This is all guaranteed to be safe by Asus.

On my Eee PC 901, the idle power consumption drops from about 7W to 5.8W
when switching from "normal" to "powersave". That's about 15%. Under
load the benefit seems to be even greater.

I'm the author of a program called eee-control, which currently uses
another method to change FSB and voltage. It directly communicates with
the PLL controller over SMBus and with the embedded controller through
some I/O ports. This method works, but is not very safe and very
hardware specific. The ACPI interface of Asus' SHE abstracts all the
hardware differences away and thus would be preferred.
Anyway, my point is: my experience and reports by users show that the
difference is *huge*.

Regards,
Grigori