Re: CFR: Generalized power-management interface
In message [EMAIL PROTECTED], Mitsuru IWASAKI さんいわく : Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz What about treating it as a part of ioctl in existing device, then make symbolic link to a generalzed name,instead of consuming new major number? Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz What about treating it as a part of ioctl in existing device, then make symbolic link to a generalzed name,instead of consuming new major number? Does `existing device' mean APM or ACPI? We don't know which power management system is enabled on the actual system, so it's impossible. We need one mandatory device for PM to be generalized. I think the opposite way is more reasonable. Or if your concern is shortage of major number, we could expand it in proper way. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
In message [EMAIL PROTECTED], Mitsuru IWASAKI さんいわく : I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz What about treating it as a part of ioctl in existing device, then make symbolic link to a generalzed name,instead of consuming new major number? Does `existing device' mean APM or ACPI? Yes . We don't know which power management system is enabled on the actual system, so it's impossible. We need one mandatory device for PM to be generalized. I think the opposite way is more reasonable. Why? Is it bad to check whether the device is available or not in rc? Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, If we're going to talk about 'health' for a machine and it's components, it should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). Yes, but my understanding on SES/SAF-TE is very poor unfortunately :-) I think number of hackers who can cover all areas with enough knowledge and experience is quite limited, so I prefer dividing it into sub-areas sharing upper level framework to make things simple. Any volunteers for the design? something like; health + power + apm | | | + acpi | + thermal --+ acpi | | : : Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
We don't know which power management system is enabled on the actual system, so it's impossible. We need one mandatory device for PM to be generalized. I think the opposite way is more reasonable. Why? Is it bad to check whether the device is available or not in rc? Ah, you mean we support the same ioctl interface directly in both apm and acpi for power management without passthru requests via generalized device, right? If ioctl is only the matter, I thinkg yes. But having own device file is still advantages when we start considering other cdevsw stuff such as open/close/read/write/poll/etc. I think the way you suggested may prevent generalized device interface improving and make existing-code to be more complicated. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
On Sun, 14 Jan 2001, Mitsuru IWASAKI wrote: Hi, If we're going to talk about 'health' for a machine and it's components, it should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). Yes, but my understanding on SES/SAF-TE is very poor unfortunately :-) I think number of hackers who can cover all areas with enough knowledge and experience is quite limited, so I prefer dividing it into sub-areas sharing upper level framework to make things simple. Any volunteers for the design? something like; SAF-TE is nearly a proper subset of SES, and SES covers lots of things (not just environmental) health + power + apm | | | + acpi | | | + SES/SAF-TE | + thermal --+ acpi | | | + SES/SAF-TE | | + object* --+ SES/SAF-TE : : * An 'object' can be marked as having a fault condition An object might be a disk drive tray To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz Note that ioctl number for power device have been changed, so rebuilding your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. Added API is; u_intpower_get_pm_type(void); I'll get device major number for /dev/power and commit them within a few days if no objection. Thanks I've created new common framework on generalized power-management interface for userland utilities. http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz This provides some PM APIs to APM applications, such as wmapm, so that these applications can be ported smoothly to use ACPI (power management portion). Currently following APIs are implemented; intpower_get_syspm_info(struct power_syspm_info *); intpower_get_batt_info(u_int, struct power_batt_info *); intpower_standby(void); intpower_suspend(void); intpower_hibernate(void); And PM event notification mechanism is suggested to be implemented so far. Sample application is included in usr.sbin/power/ which is very similar to apm(8) but supports ACPI as well. usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control Method Battery), can be used to verify that generalized power-management interface is working correctly. Note that many ACPI BIOS give us unknown battery remaining time when ac-line is plugged in. MIB 'hw.battery.full_charge_time' can be used to specify the full charged remaining time of batteries in minutes, like sysctl -w hw.battery.full_charge_time=60,60 for multiple number of batteries, or sysctl -w hw.battery.full_charge_time=120 for a battery installed. To test them, /dev/power is required as a device control file. % ls -l /dev/power crw-r--r-- 1 root wheel 210, 0 12/19 04:51 /dev/power I'll commit them at sometime early in coming century. Any comments would be appreciated. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
On 12-Jan-01 Mitsuru IWASAKI wrote: Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz Note that ioctl number for power device have been changed, so rebuilding your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. Added API is; u_intpower_get_pm_type(void); I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Thanks -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
On 12-Jan-01 Mitsuru IWASAKI wrote: Hi, I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? It was just an idea to think about is all. :) However you do it will probably be fine. I'm not really working on this code enough to make too many suggestions right now. :) battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info and find out where it hangs when I don't disable the SIO_ controller. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
If we're going to talk about 'health' for a machine and it's components, it should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). On 12-Jan-01 Mitsuru IWASAKI wrote: Hi, I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? It was just an idea to think about is all. :) However you do it will probably be fine. I'm not really working on this code enough to make too many suggestions right now. :) battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info and find out where it hangs when I don't disable the SIO_ controller. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CFR: Generalized power-management interface
Hi, I've created new common framework on generalized power-management interface for userland utilities. http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz This provides some PM APIs to APM applications, such as wmapm, so that these applications can be ported smoothly to use ACPI (power management portion). Currently following APIs are implemented; int power_get_syspm_info(struct power_syspm_info *); int power_get_batt_info(u_int, struct power_batt_info *); int power_standby(void); int power_suspend(void); int power_hibernate(void); And PM event notification mechanism is suggested to be implemented so far. Sample application is included in usr.sbin/power/ which is very similar to apm(8) but supports ACPI as well. usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control Method Battery), can be used to verify that generalized power-management interface is working correctly. Note that many ACPI BIOS give us unknown battery remaining time when ac-line is plugged in. MIB 'hw.battery.full_charge_time' can be used to specify the full charged remaining time of batteries in minutes, like sysctl -w hw.battery.full_charge_time=60,60 for multiple number of batteries, or sysctl -w hw.battery.full_charge_time=120 for a battery installed. To test them, /dev/power is required as a device control file. % ls -l /dev/power crw-r--r-- 1 root wheel 210, 0 12/19 04:51 /dev/power I'll commit them at sometime early in coming century. Any comments would be appreciated. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
