Power Management Flow of Control

Figure 9-1 illustrates the flow of control in the power management framework.

When a component's activity is complete, a driver can call pm_idle_component(9F) to mark the component as idle. When the component has been idle for its threshold time, the framework may lower the power of the component to its next lower level. The framework does this by calling the power(9E) function to set the power level of the component to its next lower supported power level (if any). The driver's power(9E) function should reject any attempt to lower the power level of a component when it is busy. The driver's power(9E) function should also save any state that will be lost as a result of the transition to the lower power level before making that transition.

When the component is needed again at a higher power level, the driver calls pm_busy_component(9F) to keep the framework from lowering the power still further, and then calls pm_raise_power(9F) on the component. The framework then calls power(9E) to raise the power of the component (before the call to pm_raise_power(9F) returns). The driver's power(9E) code must restore any state that was lost in the lower level but is needed in the higher level after making the power transition.

When a driver is detaching, it should call pm_lower_power(9F) for each component to lower its power to its lowest level. The framework may then call into the driver's power(9E) routine (before the call to pm_lower_power(9F) returns) to lower the power of the component.

Figure 9-1 Power Management Conceptual State Diagram

Changes to Power Management Interfaces

Previous to the Solaris 8 release, power management of devices was not automatic. It was necessary to add an entry to /etc/power.conf for each device that was to be power managed.

The framework assumed that all devices supported only two power levels: 0 and full ("normal") power.

There was an implied dependency of all other components on component 0. Whenever component 0 changed to or from level 0, a call was made into the driver's detach(9E) or attach(9E) routine with commands DDI_PM_SUSPEND and DDI_PM_RESUME respectively to save and restore hardware state.

The old interfaces (including ddi_dev_is_needed(9F), pm_create_components(9F), pm_destroy_components(9F), pm_get_normal_power(9F), pm_set_normal_power(9F), DDI_PM_SUSPEND and DDI_PM_RESUME) are still supported for binary compatibility, but are obsolete.

As of the Solaris 8 release, devices which export the pm-components property are automatically power managed (if autopm is enabled).

The framework now knows from the pm-components property which power levels are supported by each device.

The framework makes no assumptions about dependencies among the different components of a device. The device driver is responsible for saving and restoring hardware state as needed when changing power levels.

These changes allow the power management framework to deal with emerging device technology, and result in greater power savings (since the framework can detect automatically which devices can save power, and can use intermediate power states of the devices), and allows the system to meet energy consumption goals without the entire system being powered down or functionality being lost.

Table 9-1 Power Management Interfaces

Old Interfaces	Solaris 8 Interfaces
pm_create_components(9E)	pm-conponents(9)
pm_set_normal_power(9F)	pm-components(9)
pm_destroy_components(9F)
pm_get_normal_power(9E)
ddi_dev_is_needed(9F)	pm_raise_power(9F)
	pm_lower_power(9F
	pm_power_has_changed(9F)
DDI_PM_SUSPEND
DDI_PM_RESUME