Writing Device Drivers

Changes to Power Management Interfaces

Prior to the Solaris 8 release, power management of devices was not automatic. Developers had 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 standard power.

Power assumed an implied dependency of all other components on component 0. When component 0 changed to level 0, a call was made into the driver's detach(9E) with the DDI_PM_SUSPEND command to save the hardware state. When component 0 changed from level 0, a call was made to the attach(9E) routine with the command DDI_PM_RESUME to restore hardware state.

The following interfaces and commands are obsolete, although they are still supported for binary purposes:

Since the Solaris 8 release, devices that export the pm-components property automatically use power management 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 enable the power management framework to deal with emerging device technology. Power management now results in greater power savings. The framework can detect automatically which devices can save power. The framework can use intermediate power states of the devices. A system can now meet energy consumption goals without powering down the entire system and without any functions.

Table 12–1 Power Management Interfaces

Removed Interfaces 

Equivalent Interfaces 

pm_create_components(9F)

pm-components(9P)

pm_set_normal_power(9F)

pm-components(9P)

pm_destroy_components(9F)

None 

pm_get_normal_power(9F)

None 

ddi_dev_is_needed(9F)

pm_raise_power(9F)

None 

pm_lower_power(9F)

None 

pm_power_has_changed(9F)

DDI_PM_SUSPEND 

None 

DDI_PM_RESUME 

None