passive cooling and cpufreq

[Hajimu UMEMOTO]

Hi,

>>>>> On Wed, 06 Jul 2005 17:59:19 -0700
>>>>> Nate Lawson <nate at root.org> said:

nate> I have moved this email to acpi@ for general discussion.

Okay, thanks.

nate> There is a much simpler way to access cpufreq(4) from the kernel that 
nate> shouldn't require modifications.  It exports newbus methods for 
nate> controling the frequency.  This kind of code should work:

nate> That is all, simple eh?  :)  The cpufreq kernel interface wraps access 
nate> to all cpufreq hardware drivers (acpi_perf, est, p4tcc, acpi_throttle, 
nate> etc.)  You only need to call methods on cpufreq0 and it will handle 
nate> getting the desired frequency for you.  See "man 4 cpufreq" for details.

Oh, it's cool.  I didn't know how to obtain cpufreq_dc from outside of
kern_cpu.c.  So, I added some functions into kern_cpu.c in my previous
patch.
However, it seems cpufreq_curr_sysctl() set frequency to all CPUs with
some comment.  Is it enough to set frequency to only one CPU?

nate> acpi_perf has two modes, one that supplies info only.  If your BIOS only 
nate> supports that mode, usually another driver like est will handle the 
nate> actual hardware.  Since cpufreq is smart and probes all possible cpu 
nate> frequency control devices, parsing _PSL is not necessary.  cpufreq(4) 
nate> can actually use more devices than are present in _PSL.  If needed in 
nate> the future, acpi_perf can be linked with _PSL so that dependencies are 
nate> known.

Thank you for clarification.

nate> There should be no conflict with userland.  The above priority value 
nate> (CPUFREQ_PRIO_KERN) specifies that this call overrides settings made 
nate> previously (ie. via sysctl.)  However, cpufreq(4) saves the old setting 
nate> so that once the cooling condition passes, CPUFREQ_SET(dev, NULL, 
nate> CPUFREQ_PRIO_KERN) can be used to restore it.

It's cool.  But, I think it is insufficient.  In passive cooling
state, it appears that there is some room to raise frequency from
powerd(8).  So, powerd(8) tries to raise frequency continuously.  I
think it is not desired behavior.  This is a reason why I modified
cpufreq_curr_sysctl() in my previous patch to return faked value in
passive cooling state.

I made my new patch:

	http://www.imasy.or.jp/~ume/FreeBSD/passive-cooling-20050707.diff

It doesn't modify kern_cpu.c.  Instead, I added some code into
powerd(8) to don't try to update frequency when
hw.acpi.thermal.tz0.passive_active is on.  And, I needed to ignore
EPERM when updating dev.cpu.0.freq.

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume at mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/