Date: Wed, 06 Jul 2011 17:23:23 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Vitaly Magerya <vmagerya@gmail.com> Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook Message-ID: <4E146FDB.2020602@FreeBSD.org> In-Reply-To: <CAL409KyX0jDd9U=7GExvyPR1cDxPwsMHm2b%2B1Tvmijhpg0iWDQ@mail.gmail.com> References: <BANLkTim%2B1UwquMJ32WP8wZBGkYxPv78MLA@mail.gmail.com> <4E05EB91.9090509@FreeBSD.org> <BANLkTi=dyNx=TjyEqYMhSkRtddjVA4nAtw@mail.gmail.com> <4E0862A0.7060405@FreeBSD.org> <BANLkTikmVUtLyANBSqYb%2BL-xkwQ4Zo51Eg@mail.gmail.com> <4E09BADF.7050702@FreeBSD.org> <BANLkTin_%2BZH%2Bo7rdR9ijHMtrXcSdH9ZSdQ@mail.gmail.com> <4E0A41C8.3000904@FreeBSD.org> <BANLkTikwgy%2BKuA5E5zXQKGT-eyV35YAVag@mail.gmail.com> <4E0CE158.6030804@FreeBSD.org> <BANLkTinRY-h%2BkpXtwWJ_L86qVRdoynFSdg@mail.gmail.com> <4E0DB58F.4070906@FreeBSD.org> <CAL409Kw=rUnm9D56KvYiFWiU-bp59KqKnPcUXL38rZsW_Qh8AQ@mail.gmail.com> <4E130154.9080809@FreeBSD.org> <CAL409KyX0jDd9U=7GExvyPR1cDxPwsMHm2b%2B1Tvmijhpg0iWDQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 06/07/2011 00:49 Vitaly Magerya said the following: > Andriy Gapon <avg@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E146FDB.2020602>