From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 25 15:55:31 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21C7016A417 for ; Tue, 25 Dec 2007 15:55:31 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id A038D13C46B for ; Tue, 25 Dec 2007 15:55:30 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1733064uge.37 for ; Tue, 25 Dec 2007 07:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; bh=7qp153qZ40OQMM8Vp8au7xYoP3Du9v8ck7irnFhcZY4=; b=oTursR/BzwYa0xh9+jDDfWdxeGOzCGY9KeDBXkwApRQIY1EW5Jv9JeQr5NR+oDZkJdkRepGTY4HN3VUslDq6PGo8v6AfLsyOyVRRWComYsZkteyrCv/T50EvQofrxuA1QYeZ2KtzhqpyrKLIWOIzcplD/A7ZTPERXiymW38dw/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; b=EkKHY8KgGbaJ2/2e25n0MeRZ7B56qAlV9Rl6koUBbpnVhhc1blnZ0uvYtQ+uZ0jub7ShdZFBHj+lHSxJLeIeaN03/4kLDw24o0YjJVXPx6U9m5WeglWZrTLErunV5kCBBrm+CMuh89eJ4LbbAq0msyHTO06741GfCPqekKh1me0= Received: by 10.67.196.4 with SMTP id y4mr4896982ugp.39.1198598129388; Tue, 25 Dec 2007 07:55:29 -0800 (PST) Received: from epsilon.local.gmail.com ( [83.144.140.64]) by mx.google.com with ESMTPS id y34sm8752743iky.6.2007.12.25.07.55.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Dec 2007 07:55:28 -0800 (PST) Date: Tue, 25 Dec 2007 15:54:54 +0000 Message-ID: <86ejdaepm9.wl%rpaulo@fnop.net> From: Rui Paulo To: Ian Smith In-Reply-To: References: <863atrfyhh.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: Rui Cc: freebsd-acpi@freebsd.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 15:55:31 -0000 At Tue, 25 Dec 2007 17:16:58 +1100 (EST), Ian Smith wrote: > > On Mon, 24 Dec 2007, Rui Paulo wrote: > > At Mon, 24 Dec 2007 23:16:54 +0200, > > Aragon Gouveia wrote: > > > > > > Hi, > > > > > > | By Rui Paulo > > > | [ 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. Well, the fact that "setting 2000 gave 2001 anyway" is most likely regarding to how est is programmed, I think. > > > 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? There are no man pages for them, I failed to check the man pages properly. Regards. -- Rui Paulo