From owner-freebsd-acpi@FreeBSD.ORG  Tue Aug 16 05:43:18 2005
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
X-Original-To: acpi@freebsd.org
Delivered-To: freebsd-acpi@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B753216A41F
	for <acpi@freebsd.org>; Tue, 16 Aug 2005 05:43:18 +0000 (GMT)
	(envelope-from ume@mahoroba.org)
Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 369B943D45
	for <acpi@freebsd.org>; Tue, 16 Aug 2005 05:43:17 +0000 (GMT)
	(envelope-from ume@mahoroba.org)
Received: from kasuga.mahoroba.org
	(IDENT:u+3n7+2RVXGO8Fc0UwC9cFExqZO/MWZnRHNLkpBeicnkpg8mbNY/D1hvtYh2TAEr@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521])
	(user=ume mech=CRAM-MD5 bits=0)
	by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id
	j7G5h98T033727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 16 Aug 2005 14:43:11 +0900 (JST)
	(envelope-from ume@mahoroba.org)
Date: Tue, 16 Aug 2005 14:42:00 +0900
Message-ID: <yge8xz28ml3.wl%ume@mahoroba.org>
From: Hajimu UMEMOTO <ume@freebsd.org>
To: Nate Lawson <nate@root.org>
In-Reply-To: <43013C90.7040901@root.org>
References: <20050814023842.C0D845D07@ptavv.es.net>
	<ygezmrk2van.wl%ume@mahoroba.org> <ygeoe7zacqg.wl%ume@mahoroba.org>
	<4300C5DF.40409@root.org> <ygek6in5e4t.wl%ume@mahoroba.org>
	<ygeacjj81bw.wl%ume@mahoroba.org> <43013C90.7040901@root.org>
User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka)
	FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50
	(i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI)
X-Operating-System: FreeBSD 6.0-BETA2
X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc
X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5  BF5F 04E9 F086 BF90 71FE
Organization: Internet Mutual Aid Society, YOKOHAMA
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by
	milter-greylist-2.0 (ameno.mahoroba.org
	[IPv6:3ffe:501:185b:8010::1]);
	Tue, 16 Aug 2005 14:43:13 +0900 (JST)
X-Virus-Scanned: by amavisd-new
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.0.4
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org
Cc: acpi@freebsd.org
Subject: Re: Annoyances with passive thermal code (acpi_thermal)
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
	<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
	<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2005 05:43:18 -0000

Hi,

>>>>> On Mon, 15 Aug 2005 18:08:32 -0700
>>>>> Nate Lawson <nate@root.org> said:

nate> The original intention was that we would save a stack of values and that 
nate> a CPUFREQ_SET(NULL, prio) would restore the last setting for the 
nate> priority before "prio".

nate> Example:
nate> freq = 1000 Mhz
nate> CPUFREQ_SET(1200, PRIO_USER)  -- saves 1000 Mhz @PRIO_LOWEST
nate> freq = 1200
nate> CPUFREQ_SET(1800, PRIO_LOWEST) -- EPERM since prio too low
nate> freq = 1200
nate> CPUFREQ_SET(1700, PRIO_KERN)  -- saves 1200 Mhz @PRIO_USER
nate> freq = 1700
nate> CPUFREQ_SET(1900, PRIO_KERN)  -- no saves since prio same as before
nate> freq = 1900
nate> CPUFREQ_SET(NULL, PRIO_KERN)  -- restores 1200 Mhz @PRIO_USER
nate> freq = 1200
nate> CPUFREQ_SET(NULL, PRIO_USER)  -- restores 1000 Mhz @PRIO_LOWEST
nate> freq = 1000

nate> Implementing this as a simple array would make sense.  Would you be 
nate> willing to do this?  If not, your patch should be fine for now.

No, I need to save a cpu level only when raising prio to PRIO_KERN
from lower prio.  But, I realized that my privious patch was
insufficient.  If dev.cpu.0.freq was not set by sysctl(8), cpu level
was never saved.

Index: sys/kern/kern_cpu.c
diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c
--- sys/kern/kern_cpu.c.orig	Mon Apr 11 04:11:23 2005
+++ sys/kern/kern_cpu.c	Tue Aug 16 14:22:10 2005
@@ -336,7 +336,7 @@ cf_set_method(device_t dev, const struct
 	 */
 	if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN &&
 	    sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN &&
-	    priority > sc->curr_priority) {
+	    priority > CPUFREQ_PRIO_USER && priority > sc->curr_priority) {
 		CF_DEBUG("saving level, freq %d prio %d\n",
 		    sc->curr_level.total_set.freq, sc->curr_priority);
 		sc->saved_level = sc->curr_level;

In anyway, we should make this as stack some day.

Sincerely,

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