Go to main content

Writing Device Drivers for Oracle® Solaris 11.3

Exit Print View

Updated: March 2019

Power Management Framework

    The Oracle Solaris Power Management framework depends on device drivers to implement device-specific power management functions. The framework is implemented in two parts:

  • Device power management – Automatically turns off unused devices to reduce power consumption

  • System power management – Automatically turns off the computer when the entire system is idle

Device Power Management

The framework enables devices to reduce their energy consumption after a specified idle time interval. As part of power management, system software checks for idle devices. The Power Management framework exports interfaces that enable communication between the system software and the device driver.

    The Oracle Solaris Power Management framework provides the following features for device power management:

  • A device-independent model for power-manageable devices.

  • dtpower(1M), a tool for configuring workstation power management.

  • A set of DDI interfaces for notifying the framework about power management compatibility and idleness state.

System Power Management

System power management involves saving the state of the system prior to powering the system down. Thus, the system can be returned to the same state immediately when the system is turned back on.

    To shut down an entire system with return to the state prior to the shutdown, take the following steps:

  • Stop kernel threads and user processes. Restart these threads and processes later.

  • Save the hardware state of all devices on the system to disk. Restore the state later.

SPARC only - System power management is currently implemented only on some SPARC systems supported by the Oracle Solaris OS.

The System Power Management framework in the Oracle Solaris OS provides the following features for system power management:

  • A platform-independent model of system idleness.

  • A set of interfaces for the device driver to override the method for determining which drivers have hardware state.

  • A set of interfaces to enable the framework to call into the driver to save and restore the device state.

  • A mechanism for notifying processes that a resume operation has occurred.