Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

sysmon_pswitch_unregister(9) [netbsd man page]

SYSMON_PSWITCH(9)					   BSD Kernel Developer's Manual					 SYSMON_PSWITCH(9)

sysmon_pswitch -- framework for power switches SYNOPSIS
#include <dev/sysmon/sysmonvar.h> int sysmon_pswitch_register(struct sysmon_pswitch *smpsw); void sysmon_pswitch_unregister(struct sysmon_pswitch *smpsw); void sysmon_pswitch_event(struct sysmon_pswitch *smpsw, int event); DESCRIPTION
The machine-independent sysmon_pswitch provides a framework for power management. The interface has been largely superceded by the pmf(9) framework, but sysmon_pswitch is still used to manage power switches as well as related mechanical adapters and buttons. These are encapsu- lated in the following structure: struct sysmon_pswitch { const char *smpsw_name; /* power switch name */ int smpsw_type; /* power switch type */ LIST_ENTRY(sysmon_pswitch) smpsw_list; }; Unsurprisingly, smpsw_name specifies the name of the power switch and smpsw_type defines the type of it. The following types are defined: PSWITCH_TYPE_POWER PSWITCH_TYPE_SLEEP PSWITCH_TYPE_LID PSWITCH_TYPE_RESET PSWITCH_TYPE_ACADAPTER PSWITCH_TYPE_HOTKEY If the type is PSWITCH_TYPE_HOTKEY, there are few predefined names that can be used for smpsw_name: PSWITCH_HK_DISPLAY_CYCLE display-cycle PSWITCH_HK_LOCK_SCREEN lock-screen PSWITCH_HK_BATTERY_INFO battery-info PSWITCH_HK_EJECT_BUTTON eject-button PSWITCH_HK_ZOOM_BUTTON zoom-button PSWITCH_HK_VENDOR_BUTTON vendor-button Once a power switch event has been proceeded, sysmon_pswitch will inform the user space powerd(8), which will possibly execute a script matching the type of the power switch. FUNCTIONS
After the sysmon_pswitch structure has been initialized, a new power switch device can be registered by using sysmon_pswitch_register(). The device can be detached from the framework by sysmon_pswitch_unregister(). The sysmon_pswitch_event() is used to signal a new power switch event. There are two possibilities for the value of event: PSWITCH_EVENT_PRESSED A button has been pressed, the lid has been closed, the AC adapter is off, etc. PSWITCH_EVENT_RELEASED A button has been released, the lid is open, the AC adapter is on, etc. The corresponding events in powerd(8) are pressed and released. SEE ALSO
powerd(8), pmf(9), sysmon_envsys(9), sysmon_taskq(9) AUTHORS
Jason R. Thorpe <> BSD
January 26, 2010 BSD

Check Out this Related Man Page

pm_power_has_changed(9F)				   Kernel Functions for Drivers 				  pm_power_has_changed(9F)

pm_power_has_changed - Notify Power Management framework of autonomous power level change SYNOPSIS
#include <sys/ddi.h> #include <sys/sunddi.h> int pm_power_has_changed(dev_info_t *dip, int component, int level); INTERFACE LEVEL
Solaris DDI specific (Solaris DDI) PARAMETERS
dip Pointer to the device dev_info structure component Number of the component that has changed power level level Power level to which the indicated component has changed DESCRIPTION
The pm_power_has_changed(9) function notifies the Power Management framework that the power level of component of dip has changed to level. Normally power level changes are initiated by the Power Management framework due to device idleness, or through a request to the framework from the driver via pm_raise_power(9F) or pm_lower_power(9F), but some devices may change power levels on their own. For the framework to track the power level of the device under these circumstances, the framework must be notified of autonomous power level changes by a call to pm_power_has_changed(). Because of the asynchronous nature of these events, the Power Management framework might have called power(9E) between the device's autono- mous power level change and the driver calling pm_power_has_changed(), or the framework may be in the process of changing the power level when pm_power_has_changed() is called. To handle these situations correctly, the driver should verify that the device is indeed at the level or set the device to the level if it doesn't support inquirying of power levels, before calling pm_power_has_changed(). In addition, the driver should prevent a power(9E) entry point from running in parallel with pm_power_has_changed(). Note - If this function is called as a result of entry into the driver's attach(9E), detach(9E) or power(9E) entry point, this function must be called from the same thread which entered attach(9E), detach(9E) or power(9E). RETURN VALUES
The pm_power_has_changed() function returns: DDI_SUCCESS The power level of component was successfully updated to level. DDI_FAILURE Invalid component component or power level level. CONTEXT
This function can be called from user or kernel context. This function can also be called from interrupt context, providing that it is not the first Power Management function called by the driver. EXAMPLES
A hypothetical driver might include this code to handle pm_power_has_changed(9): static int xxusb_intr(struct buf *bp) { ... /* * At this point the device has informed us that it has * changed power level on its own. Inform this to framework. * We need to take care of the case when framework has * already called power() entry point and changed power level * before we were able to inform framework of this change. * Handle this by comparing the informed power level with * the actual power level and only doing the call if they * are same. In addition, make sure that power() doesn't get * run in parallel with this code by holding the mutex. */ ASSERT(mutex_owned(&xsp->lock)); if (level_informed == *(xsp->level_reg_addr)) { if (pm_power_has_changed(xsp->dip, XXUSB_COMPONENT, level_informed) != DDI_SUCCESS) { mutex_exit( &xsp->lock); return(DDI_INTR_UNCLAIMED); } } .... } xxdisk_power(dev_info *dip, int comp, int level) { mutex_enter( xsp->lock); ... ... } ATTRIBUTES
See attributes(5) for a description of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Stability level |Evolving | +-----------------------------+-----------------------------+ SEE ALSO
power.conf(4), pm(7D), attach(9E), detach(9E), power(9E), pm_busy_component(9F), pm_idle_component(9F), pm_raise_power(9F), pm_lower_power(9F), pm(9P), pm-components(9P) Writing Device Drivers SunOS 5.10 22 July 2004 pm_power_has_changed(9F)
Man Page