powerd doesn't decrease CPU frequency in some cases

[Ian Smith]

On Mon, 24 Dec 2007, Rui Paulo wrote:
 > At Mon, 24 Dec 2007 23:16:54 +0200,
 > Aragon Gouveia wrote:
 > > 
 > > Hi,
 > > 
 > > | By Rui Paulo <rpaulo at fnop.net>
 > > |                                          [ 2007-12-24 14:43 +0200 ]
 > > > Isn't it better to teach est(4) to ignore values that differ in, say,  
 > > > +/- 5Mhz ?
 > > 
 > > I agree my patch isn't ideal.  I was thinking about it today and it might
 > > be useful to implement something that ignores frequencies whose power
 > > ratings don't differ by more than X mW.  In my case, both 2201 and 2200 are
 > > rated to draw 35000 mW.  The question is, in these cases which one of the
 > > two should be ignored?  Can't ignore both...
 > 
 > I think you can ignore one of them, which one doesn't really matter
 > because the power levels are the same. I suspect that, in these cases,
 > the 2001 comes after 2000 in the EST table, so if we ignore a value
 > already present, 2000 will remain and 2001 will be ignored.

I'm starting to wonder if this 2000/2001 thing isn't some sort of signal
to a Certain OS to do Something Proprietary.  As it makes no engineering
sense, best we can do for powerd without Inside Knowledge is what both
these patches offer, eliminating/ignoring frequencies that won't set.

It seems it does matter which is chosen; Andrey demonstrated in his case
that setting 2000 gave 2001 anyway, so the one that reads back wrong
when set is the one to ignore.  It'd be better to know _why_, though.

 > > Sorry Andrey, I missed your patch.  Was a bit overly excited when I saw
 > > someone else finally experiencing the same problem as me after receiving
 > > zero response a month ago when I posted about it. :)
 > > 
 > > Something I asked in my post a month ago was where does
 > > dev.cpu.X.freq_levels get its data?  I was thinking it might be something
 > > that can be addressed with a patched ACPI DSDT?
 > 
 > dev.cpu.0.freq_levels is the combiation of several power/speed
 > throttling sources, namely, est(4), acpi_throttle(4), etc. The API
 > that deals with this is cpufreq(8).

s/8/4/

Trouble is, there exists no est(4), acpi_throttle(4) nor acpi_perf(4),
checked again after seeing your message, up to 8-current.  Trying to
work out interdependencies and interactions between the various modules
and drivers is, as far as I can tell, a matter of studying the code,
which I've done a bit at times for interest, but certainly not deeply
enough to try documenting, nor even making a decent dependency diagram.

cpufreq(4) is about as good as it gets currently, and I gather cpufreq
isn't dependent on ACPI as such.  I can't find manuals for ANY of these:

SUPPORTED DRIVERS
     The following device drivers offer absolute frequency control via the
     cpufreq interface.  Usually, only one of these can be active at a time.

     acpi_perf  ACPI CPU performance states
     est        Intel Enhanced SpeedStep
     ichss      Intel SpeedStep for ICH
     powernow   AMD PowerNow! for K7 and K8
     smist      Intel SMI-based SpeedStep for PIIX4

     The following device drivers offer relative frequency control and have an
     additive effect:

     acpi_throttle  ACPI CPU throttling
     p4tcc          Pentium 4 Thermal Control Circuitry

Can anyone point to any out-of-band documentation for any of this?

cheers, Ian