From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 16 01:08:40 2005 Return-Path: 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 6871F16A41F; Tue, 16 Aug 2005 01:08:40 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB4E543D6B; Tue, 16 Aug 2005 01:08:35 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7G18bo5018694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Aug 2005 18:08:37 -0700 Message-ID: <43013C90.7040901@root.org> Date: Mon, 15 Aug 2005 18:08:32 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2005 01:08:40 -0000 Hajimu UMEMOTO wrote: > I found the cause. The saved_level is not stackable. So, an initial > cpu level was saved, then a cpu level at CPUFREQ_PRIO_USER was not > saved. Here is a patch to solve this problem: > > 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 03:31:55 2005 > @@ -336,6 +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 && > + sc->curr_priority > CPUFREQ_PRIO_LOWEST && > priority > sc->curr_priority) { > CF_DEBUG("saving level, freq %d prio %d\n", > sc->curr_level.total_set.freq, sc->curr_priority); > > I think it is enough to solve CPUFREQ_PRIO_USER v.s. CPUFREQ_PRIO_KERN > issue. However, it may better to have saved_level at each priority, > IMHO. The original intention was that we would save a stack of values and that a CPUFREQ_SET(NULL, prio) would restore the last setting for the priority before "prio". Example: freq = 1000 Mhz CPUFREQ_SET(1200, PRIO_USER) -- saves 1000 Mhz @PRIO_LOWEST freq = 1200 CPUFREQ_SET(1800, PRIO_LOWEST) -- EPERM since prio too low freq = 1200 CPUFREQ_SET(1700, PRIO_KERN) -- saves 1200 Mhz @PRIO_USER freq = 1700 CPUFREQ_SET(1900, PRIO_KERN) -- no saves since prio same as before freq = 1900 CPUFREQ_SET(NULL, PRIO_KERN) -- restores 1200 Mhz @PRIO_USER freq = 1200 CPUFREQ_SET(NULL, PRIO_USER) -- restores 1000 Mhz @PRIO_LOWEST freq = 1000 Implementing this as a simple array would make sense. Would you be willing to do this? If not, your patch should be fine for now. -- Nate