| Message ID | 20090725004328.20709.57712.stgit@elm3a70.beaverton.ibm.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
> @@ -365,6 +373,16 @@ power[1-*]_average_lowest Historical average minimum power use > Unit: microWatt > RO > > +power[1-*]_average_max A notification is sent when power use > + rises above this value. > + Unit: microWatt > + RW > + How is the notification sent? > +power[1-*]_average_min A notification is sent when power use > + sinks below this value. > + Unit: microWatt > + RW And what is this good for? Will it wake from sleep? Will it wake from C3? ...seems like good way to prevent deep sleep states. > +power[1-*]_cap If power use rises above this limit, the > + system should take action to reduce > power use. System as in 'hw'? Or who? And how? Pavel
On Fri, Aug 07, 2009 at 08:09:06PM +0200, Pavel Machek wrote: > > > @@ -365,6 +373,16 @@ power[1-*]_average_lowest Historical average minimum power use > > Unit: microWatt > > RO > > > > +power[1-*]_average_max A notification is sent when power use > > + rises above this value. > > + Unit: microWatt > > + RW > > + > > How is the notification sent? ACPI Notify is sent to the kernel, which passes it to the ACPI netlink socket. > > +power[1-*]_average_min A notification is sent when power use > > + sinks below this value. > > + Unit: microWatt > > + RW > > And what is this good for? Will it wake from sleep? Will it wake from > C3? All it really does is generates an ACPI Notify event, which is a hint to the OS that it could re-read the power meter use. > > ...seems like good way to prevent deep sleep states. > > > +power[1-*]_cap If power use rises above this limit, the > > + system should take action to reduce > > power use. > > System as in 'hw'? Or who? And how? The ACPI spec is silent on this matter. It's not clear if the OS is supposed to monitor and take action on its own when power > cap, or if the hardware/BIOS will take action, or possibly both...? --D -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat 2009-08-08 10:40:20, Darrick J. Wong wrote: > On Fri, Aug 07, 2009 at 08:09:06PM +0200, Pavel Machek wrote: > > > > > @@ -365,6 +373,16 @@ power[1-*]_average_lowest Historical average minimum power use > > > Unit: microWatt > > > RO > > > > > > +power[1-*]_average_max A notification is sent when power use > > > + rises above this value. > > > + Unit: microWatt > > > + RW > > > + > > > > How is the notification sent? > > ACPI Notify is sent to the kernel, which passes it to the ACPI > netlink socket. Uhuh. This is hwmon documentation AFAICT; so a) it should be documented here, and b) interface should be generic so that it works without ACPI, too. > > > +power[1-*]_average_min A notification is sent when power use > > > + sinks below this value. > > > + Unit: microWatt > > > + RW > > > > And what is this good for? Will it wake from sleep? Will it wake from > > C3? > > All it really does is generates an ACPI Notify event, which is a hint to the OS > that it could re-read the power meter use. So it is one-shot? Document that. > > ...seems like good way to prevent deep sleep states. > > > > > +power[1-*]_cap If power use rises above this limit, the > > > + system should take action to reduce > > > power use. > > > > System as in 'hw'? Or who? And how? > > The ACPI spec is silent on this matter. It's not clear if the OS is supposed > to monitor and take action on its own when power > cap, or if the hardware/BIOS > will take action, or possibly both...? Having user<->kernel interface that is well... uh... undocumented makes little sense. Pavel
On Sat, Aug 08, 2009 at 11:48:30PM +0200, Pavel Machek wrote: > > Uhuh. This is hwmon documentation AFAICT; so a) it should be > documented here, and b) interface should be generic so that it works > without ACPI, too. Perhaps it is time to set up a netlink interface for all the hwmon drivers? From what I can tell, some of the chips can send interrupts when alarms go off, though I don't see much of an effort by the drivers to catch those interrupts. For sure there's no netlink socket that one can read for that sort of thing; a far as I can tell, client programs are expected to bang on sysfs periodicially to figure out when things have gone bad. <shrug> If there's sufficient interest in building a netlink-like notification system to replace (or augment) polling, I'll put something together. > > All it really does is generates an ACPI Notify event, which is a hint to the OS > > that it could re-read the power meter use. > > So it is one-shot? Document that. <nod> > > The ACPI spec is silent on this matter. It's not clear if the OS is supposed > > to monitor and take action on its own when power > cap, or if the hardware/BIOS > > will take action, or possibly both...? > > Having user<->kernel interface that is well... uh... undocumented > makes little sense. So it goes with ACPI. Given that things like Node Manager and Active Energy Manager claim to be able to control power use, I would guess that it is generally likely that a power monitoring system would take action on its own to cut power use, and not necessarily bothering to tell the OS exactly what it's doing. --D -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon 2009-08-10 14:12:11, Darrick J. Wong wrote: > On Sat, Aug 08, 2009 at 11:48:30PM +0200, Pavel Machek wrote: > > > > Uhuh. This is hwmon documentation AFAICT; so a) it should be > > documented here, and b) interface should be generic so that it works > > without ACPI, too. > > Perhaps it is time to set up a netlink interface for all the hwmon drivers? > >From what I can tell, some of the chips can send interrupts when alarms go off, > though I don't see much of an effort by the drivers to catch those interrupts. > For sure there's no netlink socket that one can read for that sort of thing; a > far as I can tell, client programs are expected to bang on sysfs periodicially > to figure out when things have gone bad. Is netlink right interface for that? Perhaps /sys files should be pollable? > > > The ACPI spec is silent on this matter. It's not clear if the OS is supposed > > > to monitor and take action on its own when power > cap, or if the hardware/BIOS > > > will take action, or possibly both...? > > > > Having user<->kernel interface that is well... uh... undocumented > > makes little sense. > > So it goes with ACPI. Given that things like Node Manager and Active Energy > Manager claim to be able to control power use, I would guess that it is > generally likely that a power monitoring system would take action on its own to > cut power use, and not necessarily bothering to tell the OS exactly what it's > doing. I guess this needs to be clarified/documented properly because it should go anywhere near mainline. Pavel
On Wed, Aug 12, 2009 at 01:56:54PM +0200, Pavel Machek wrote: > Is netlink right interface for that? Perhaps /sys files should be > pollable? Since the ACPI meter receives ACPI events, it seems logical to me that these events should be passed through to ACPI clients. It also seems logical that hwmon clients shouldn't have to know about ACPI netlink sockets either, so I'll combine them both and see what popular consensus thinks of that. :) Therefore, I updated the patch to make the appropriate sysfs files pollable, and the hwmon sysfs documentation to state that they can be polled. > > So it goes with ACPI. Given that things like Node Manager and Active Energy > > Manager claim to be able to control power use, I would guess that it is > > generally likely that a power monitoring system would take action on its own to > > cut power use, and not necessarily bothering to tell the OS exactly what it's > > doing. > > I guess this needs to be clarified/documented properly because it > should go anywhere near mainline. Ok, I'll clarify the documentation to say that those two scenarios are possible, and to contact the machine vendor for details. --D -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index dcbd502..e196701 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -357,6 +357,14 @@ power[1-*]_average_interval Power use averaging interval Unit: milliseconds RW +power[1-*]_average_interval_max Maximum power use averaging interval + Unit: milliseconds + RO + +power[1-*]_average_interval_min Minimum power use averaging interval + Unit: milliseconds + RO + power[1-*]_average_highest Historical average maximum power use Unit: microWatt RO @@ -365,6 +373,16 @@ power[1-*]_average_lowest Historical average minimum power use Unit: microWatt RO +power[1-*]_average_max A notification is sent when power use + rises above this value. + Unit: microWatt + RW + +power[1-*]_average_min A notification is sent when power use + sinks below this value. + Unit: microWatt + RW + power[1-*]_input Instantaneous power use Unit: microWatt RO @@ -381,6 +399,32 @@ power[1-*]_reset_history Reset input_highest, input_lowest, average_highest and average_lowest. WO +power[1-*]_accuracy Accuracy of the power meter. + Unit: Percent + RO + +power[1-*]_alarm 1 if the system is drawing more power than the + cap allows; 0 otherwise. + RO + +power[1-*]_cap If power use rises above this limit, the + system should take action to reduce power use. + Unit: microWatt + RW + +power[1-*]_cap_hyst Margin of hysteresis built around capping and + notification. + Unit: microWatt + RW + +power[1-*]_cap_max Maximum cap that can be set. + Unit: microWatt + RO + +power[1-*]_cap_min Minimum cap that can be set. + Unit: microWatt + RO + ********** * Energy * **********
Augment the documentation of the hwmon sysfs API to accomodate ACPI power meters. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> --- Documentation/hwmon/sysfs-interface | 44 +++++++++++++++++++++++++++++++++++ 1 files changed, 44 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html