Annoyances with passive thermal code (acpi_thermal)

Nate Lawson nate at root.org
Tue Aug 16 01:08:40 GMT 2005


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


More information about the freebsd-acpi mailing list