From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 6 19:20:25 2011 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 E3B6A1065672; Wed, 6 Jul 2011 19:20:24 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82AA48FC16; Wed, 6 Jul 2011 19:20:24 +0000 (UTC) Received: by vxg33 with SMTP id 33so244126vxg.13 for ; Wed, 06 Jul 2011 12:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iTHQVoLL7fhThrK5od9+5aEC8H21dXCSpiOIaLzYG+M=; b=o2a8v1R3fnuNm2euLp+Bkm58q3afaSEzXa2VGyG2hEE5lVvCPyi0wJm71vxUOJ4jJZ ttTpeVfBm3SiHUrBZE/3Do2+/ta83h+vqvS0BNhR8QXukbB+A/zHTzCOv3jmxWAdT+yR PNouY/281RYqMHcC1EhG61ly7lgY0Jd0wal9Y= MIME-Version: 1.0 Received: by 10.52.66.199 with SMTP id h7mr2119434vdt.119.1309980023584; Wed, 06 Jul 2011 12:20:23 -0700 (PDT) Received: by 10.52.108.226 with HTTP; Wed, 6 Jul 2011 12:20:22 -0700 (PDT) In-Reply-To: <4E146FDB.2020602@FreeBSD.org> References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> <4E146FDB.2020602@FreeBSD.org> Date: Wed, 6 Jul 2011 22:20:22 +0300 Message-ID: From: Vitaly Magerya To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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: Wed, 06 Jul 2011 19:20:25 -0000 Andriy Gapon wrote: >>> 3. Try to make FreeBSD smarter with respect to dynamically changing >>> C-states. I >>> think it would be useful if we received a devd notifications about >>> C-state >>> reconfiguration. Then we could execute /etc/rc.d/power_profile to >>> account for the >>> new configuration. >> >> This would be the most useful option. > > I agree! :) Actually, I have a simpler fix. We could allow setting hw.acpi.cx_lowest to any value, including states that are not currently present. Then, on updates to available Cx states, our ACPI code will automatically set dev.cpu.N.cx_lowest to the closest valid value without the need for a separate power_profile invocation. Here's the diff: --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 +++ acpi_cpu.c 2011-07-06 17:23:16.000000000 +0000 @@ -1194,7 +1194,7 @@ if (strlen(state) < 2 || toupper(state[0]) != 'C') return (EINVAL); val = (int) strtol(state + 1, NULL, 10) - 1; - if (val < 0 || val > cpu_cx_count - 1) + if (val < 0) return (EINVAL); cpu_cx_lowest = val; You can even simplify power_profile with this change: --- power_profile.orig 2011-07-06 18:39:27.000000000 +0000 +++ power_profile 2011-07-06 18:40:20.000000000 +0000 @@ -81,8 +81,7 @@ # Set the various sysctls based on the profile's values. node="hw.acpi.cpu.cx_lowest" highest_value="C1" -lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \ - awk '{ print "C" split($0, a) }' -) 2> /dev/null`" +lowest_value="C99" eval value=\$${profile}_cx_lowest sysctl_set >> Here's what I tried (trivial diff, sending inline): >> >> [...] >> >> This generally works, except that power_profile is executed multiple >> times (the event is generated once per core, and when it is triggered >> by plugging the power cord, ACPI ACAD is reported at the same time >> thus resulting in one more power_profile execution). > > At this time and for this purpose I would probably send the notification only if > global cx_lowest value changes as we do not do per-CPU power profiles. Yes, this makes sense. > Also, I think that cpu_cx_count is not the best parameter for notification. > For per-cpu events I would rather use CPU ID. For global events, it may makes > sense to use /subsystem/ value of "CPU" and then discriminate various types of CPU > events via /notify/. E.g. notify=0 could be used to indicate Cx changes. Maybe > we will have more ACPI CPU events in the future. Seems reasonable too, but this won't be necessary for my case if the above change will be implemented.