Date: Thu, 07 Jul 2005 18:45:56 +0900 From: Hajimu UMEMOTO <ume@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: acpi@FreeBSD.org, takawata@FreeBSD.org Subject: Re: passive cooling and cpufreq Message-ID: <yge4qb7t0dn.wl%ume@mahoroba.org> In-Reply-To: <42CC7E67.50401@root.org> References: <42CB0369.1000701@root.org> <yger7ebsv9r.wl%ume@mahoroba.org> <42CC7E67.50401@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, >>>>> On Wed, 06 Jul 2005 17:59:19 -0700 >>>>> Nate Lawson <nate@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@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?yge4qb7t0dn.wl%ume>