From nobody@FreeBSD.org  Tue Feb 23 14:36:19 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A840A106568B
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 23 Feb 2010 14:36:19 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 96E388FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 23 Feb 2010 14:36:19 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o1NEaJs7079222
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 23 Feb 2010 14:36:19 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o1NEaJDt079221;
	Tue, 23 Feb 2010 14:36:19 GMT
	(envelope-from nobody)
Message-Id: <201002231436.o1NEaJDt079221@www.freebsd.org>
Date: Tue, 23 Feb 2010 14:36:19 GMT
From: Boris Kochergin <spawk@acm.poly.edu>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [PATCH] Add debug.cpufreq.highest to cpufreq
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         144232
>Category:       kern
>Synopsis:       [cpufreq] [patch] Add debug.cpufreq.highest to cpufreq
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-acpi
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 23 14:40:00 UTC 2010
>Closed-Date:    Fri Mar 26 21:03:58 MET 2010
>Last-Modified:  Fri Mar 26 21:03:58 MET 2010
>Originator:     Boris Kochergin
>Release:        8.0-RELEASE-p2
>Organization:
Polytechnic Institute of NYU
>Environment:
FreeBSD peer 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #2: Mon Feb 22 23:18:53 EST 2010     root@peer:/usr/obj/usr/src/sys/PEER  i386
>Description:
I request that support for the debug.cpufreq.highest sysctl, which places an upper bound on the frequencies returned to users, be added to cpufreq. I am currently using it in conjunction with the dev.acpi_ibm.0.fan_level sysctl from the acpi_ibm module set to 0 to keep a laptop both cool and quiet while it has a broken fan. Others have also found uses for the functionality (http://forums.freebsd.org/showthread.php?t=172).
>How-To-Repeat:

>Fix:


Patch attached with submission follows:

--- sys/kern/kern_cpu.c.orig    2010-02-22 22:40:37.000000000 -0500
+++ sys/kern/kern_cpu.c 2010-02-22 23:11:03.000000000 -0500
@@ -131,12 +131,16 @@
 DRIVER_MODULE(cpufreq, cpu, cpufreq_driver, cpufreq_dc, 0, 0);
 
 static int             cf_lowest_freq;
+static int             cf_highest_freq;
 static int             cf_verbose;
 TUNABLE_INT("debug.cpufreq.lowest", &cf_lowest_freq);
+TUNABLE_INT("debug.cpufreq.highest", &cf_highest_freq);
 TUNABLE_INT("debug.cpufreq.verbose", &cf_verbose);
 SYSCTL_NODE(_debug, OID_AUTO, cpufreq, CTLFLAG_RD, NULL, "cpufreq debugging");
 SYSCTL_INT(_debug_cpufreq, OID_AUTO, lowest, CTLFLAG_RW, &cf_lowest_freq, 1,
     "Don't provide levels below this frequency.");
+SYSCTL_INT(_debug_cpufreq, OID_AUTO, highest, CTLFLAG_RW, &cf_highest_freq, 1,
+    "Don't provide levels above this frequency.");
 SYSCTL_INT(_debug_cpufreq, OID_AUTO, verbose, CTLFLAG_RW, &cf_verbose, 1,
     "Print verbose debugging messages");
 
@@ -306,6 +310,14 @@
                goto out;
        }
 
+       /* Reject levels that are above our specified threshold. */
+       if (cf_highest_freq > 0 && level->total_set.freq > cf_highest_freq) {
+               CF_DEBUG("rejecting freq %d, greater than %d limit\n",
+                   level->total_set.freq, cf_highest_freq);
+               error = EINVAL;
+               goto out;
+       }
+
        /* If already at this level, just return. */
        if (CPUFREQ_CMP(sc->curr_level.total_set.freq, level->total_set.freq)) {
                CF_DEBUG("skipping freq %d, same as current level %d\n",
@@ -633,8 +645,13 @@
                        continue;
                }
 
-               /* Skip levels that have a frequency that is too low. */
-               if (lev->total_set.freq < cf_lowest_freq) {
+               /*
+                * Skip levels that have a frequency that is too low or too
+                * high.
+                */
+               if (lev->total_set.freq < cf_lowest_freq ||
+                   (cf_highest_freq > 0 &&
+                    lev->total_set.freq > cf_highest_freq)) {
                        sc->all_count--;
                        continue;
                }

--- share/man/man4/cpufreq.4.orig       2010-02-23 09:24:45.000000000 -0500
+++ share/man/man4/cpufreq.4    2010-02-23 09:25:59.000000000 -0500
@@ -98,6 +98,11 @@
 This setting is also accessible via a tunable with the same name.
 This can be used to disable very low levels that may be unusable on
 some systems.
+.It Va debug.cpufreq.highest
+Highest CPU frequency in MHz to offer to users.
+This setting is also accessible via a tunable with the same name.
+This can be used to disable very high levels that may be unusable on
+some systems.
 .It Va debug.cpufreq.verbose
 Print verbose messages.
 This setting is also accessible via a tunable with the same name.


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi 
Responsible-Changed-By: brucec 
Responsible-Changed-When: Thu Mar 25 08:29:06 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144232 

From: Dan Lukes <dan@obluda.cz>
To: bug-followup@FreeBSD.org, spawk@acm.poly.edu
Cc:  
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to cpufreq
Date: Thu, 25 Mar 2010 11:04:15 +0100

 It sound like improper place for implementation of such logic.
 
 Cpufreq is hardware driver - it allow others to control CPU speeds. It 
 do no own decisions nor should do (imho). When it should not do 
 decisions, then it's not appropriate place to store variables that exist 
 for the purpose of such decision process only.
 
 cpufreq consumers (like powerd or acpi_thermal) are there for decision 
 making so such logic and configuration variables should be there.
 
 The debug.cpufreq.lowest is here because some reported levels are not 
 usable in the real, not because someone decided he don't want to use it.
 
 You may be interested that requested feature is implemented as part of 
 acpi_thermal. From man acpi_thermal:
 
 hw.acpi.thermal.tz%d.passive_cooling
      If set to 1, passive cooling is enabled.  It does cooling without
      fans using cpufreq(4) as the mechanism for controlling CPU speed.
      Default is enabled for tz0 where it is available.
 
 It require support from ACPI on your notebook which may or may not be 
 present. If such support is not present, so acpi_thermal can't help you, 
 then another "frequency decision" utility - e.g. - powerd - is 
 candidate-place to implement requested logic. No logic should belong to 
 cpufreq device driver itself, so no tunables for them there.
 
 I noticed the argument "maximum on AC is another than maximum on 
 battery", but power state is available to powerd, so the logic we are 
 speaking about can count the power state as well. The only question is - 
 how to tell to powerd what we want from it exactly.
 
 						Dan

From: Nate Lawson <nate@root.org>
To: Dan Lukes <dan@obluda.cz>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to 
 cpufreq
Date: Thu, 25 Mar 2010 09:06:04 -0700

 Dan Lukes wrote:
  >  It sound like improper place for implementation of such logic.
 >  
 >  Cpufreq is hardware driver - it allow others to control CPU speeds. It 
 >  do no own decisions nor should do (imho). When it should not do 
 >  decisions, then it's not appropriate place to store variables that exist 
 >  for the purpose of such decision process only.
 >  
 >  cpufreq consumers (like powerd or acpi_thermal) are there for decision 
 >  making so such logic and configuration variables should be there.
 >  
 >  The debug.cpufreq.lowest is here because some reported levels are not 
 >  usable in the real, not because someone decided he don't want to use it.
 
 Exactly right. The "lowest" sysctl was there to prevent use of modes
 that users said froze their laptop. It is not for scheduling/general
 policy decisions. There is no reason for "highest" as this is a
 scheduling decision. Such logic should be in powerd and such control
 programs.
 
 -- 
 Nate
 

From: Nate Lawson <nate@root.org>
To: Boris Kochergin <spawk@acm.poly.edu>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to 
  cpufreq
Date: Thu, 25 Mar 2010 11:08:52 -0700

 Boris Kochergin wrote:
 > 
 > OK. I also have code to implement -m and -M (minimum and maximum
 > frequency, respectively) options in powerd:
 > 
 > http://acm.poly.edu/~spawk/powerd/
 > 
 > It's for 7.0-RELEASE, so I will see if it needs to be brought up to date
 > and will file a PR.
 
 Seems reasonable. Needs a little whitespace cleanup.
 
 -- 
 Nate
 

From: Boris Kochergin <spawk@acm.poly.edu>
To: bug-followup@FreeBSD.org
Cc: Nate Lawson <nate@root.org>
Subject: Re: kern/144232: [cpufreq] [patch] Add debug.cpufreq.highest to 
  cpufreq
Date: Fri, 26 Mar 2010 13:02:33 -0400

 This PR can be closed. A new one with modernized patches to add support 
 for this in powerd is at bin/145063.
 
 -Boris
State-Changed-From-To: open->closed 
State-Changed-By: joerg 
State-Changed-When: Fri Mar 26 21:03:30 MET 2010 
State-Changed-Why:  
Closed upon Boris' request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144232 
>Unformatted:
