From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 6 14:23:27 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 992D0106566B for ; Wed, 6 Jul 2011 14:23:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BB1FA8FC13 for ; Wed, 6 Jul 2011 14:23:26 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00845; Wed, 06 Jul 2011 17:23:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E146FDB.2020602@FreeBSD.org> Date: Wed, 06 Jul 2011 17:23:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Vitaly Magerya 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> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 14:23:27 -0000 on 06/07/2011 00:49 Vitaly Magerya said the following: > Andriy Gapon wrote: >> Possible courses of action: >> >> 1. Do nothing and leave you with your workaround. >> >> 2. Provide intel_idle-like driver for FreeBSD. I don't like this approach for >> reasons I've stated before. >> >> 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! :) > Here's what I tried (trivial diff, sending inline): > > --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 > +++ acpi_cpu.c 2011-07-05 21:44:56.000000000 +0000 > @@ -988,12 +988,13 @@ > { > struct acpi_cpu_softc *sc = (struct acpi_cpu_softc *)context; > struct acpi_cpu_softc *isc; > - int i; > + int prev_cx_count, i; > > if (notify != ACPI_NOTIFY_CX_STATES) > return; > > /* Update the list of Cx states. */ > + prev_cx_count = sc->cpu_cx_count; > acpi_cpu_cx_cst(sc); > acpi_cpu_cx_list(sc); > > @@ -1008,6 +1009,8 @@ > if (sc->cpu_cx_lowest < cpu_cx_lowest) > acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); > ACPI_SERIAL_END(cpu); > + if (prev_cx_count != sc->cpu_cx_count) > + acpi_UserNotify("CPU_CX", h, sc->cpu_cx_count); > } > > static int > --- devd.conf.orig 2011-07-05 20:19:30.000000000 +0000 > +++ devd.conf 2011-07-05 20:30:08.000000000 +0000 > @@ -209,6 +209,13 @@ > action "/etc/rc.d/power_profile $notify"; > }; > > +# Update power profile when available CPU Cx states are updated. > +notify 10 { > + match "system" "ACPI"; > + match "subsystem" "CPU_CX"; > + action "/etc/rc.d/power_profile 0x0`sysctl -n hw.acpi.acline`"; > +}; > + > # Notify all users before beginning emergency shutdown when we get > # a _CRT or _HOT thermal event and we're going to power down the system > # very soon. > > 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. 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. Otherwise I really like this, thank you. -- Andriy Gapon