1pm-components(9P) Kernel Properties for Drivers pm-components(9P)
2
6 pm-components - Power Management device property
7
9 A device is power manageable if the power consumption of the device can
10 be reduced when it is idle. In general, a power manageable device con‐
11 sists of a number of power manageable hardware units called components.
12 Each component is separately controllable and has its own set of power
13 parameters.
14 An example of a one-component power manageable device is a disk whose
17 spindle motor can be stopped to save power when the disk is idle. An
18 example of a two-component power manageable device is a frame buffer
19 card with a connected monitor. The frame buffer electronics (with power
20 that can be reduced when not in use) comprises the first component. The
21 second component is the monitor, which can enter in a lower power mode
22 when not in use. The combination of frame buffer electronics and moni‐
23 tor is considered as one device by the system.
24 In the Power Management framework, all components are considered equal
27 and completely independent of each other. If this is not true for a
28 particular device, the device driver must ensure that undesirable state
29 combinations do not occur. Each component is created in the idle state.
30 The pm-components property describes the Power Management model of a
33 device driver to the Power Management framework. It lists each power
34 manageable component by name and lists the power level supported by
35 each component by numerical value and name. Its syntax and interpreta‐
36 tion is described below.
37 This property is only interpreted by the system immediately after the
40 device has successfully attached, or upon the first call into Power
41 Management framework, whichever comes first. Changes in the property
42 made by the driver after the property has been interpreted will not be
43 recognized.
44 pm-components is a string array property. The existence of the pm-com‐
47 ponents property indicates that a device implements power manageable
48 components and describes the Power Management model implemented by the
49 device driver. The existence of pm-components also indicates to the
50 framework that device is ready for Power Management if automatic device
51 Power Management is enabled. See power.conf(4).
52 The pm-component property syntax is:
55 pm-components="NAME=component name","numeric power level=power level name", "numeric power level=power level name" [, "numeric power level=power level name" ...] [, "NAME=component name", "numeric power level=power level name", "numeric power level=power level name" [, "numeric power level=power level name"...]...];
57 The start of each new component is represented by a string consisting
61 of NAME= followed by the name of the component. This should be a short
62 name that a user would recognize, such as "Monitor" or "Spindle Motor."
63 The succeeding elements in the string array must be strings consisting
64 of the numeric value (can be decimal or 0x <hexadecimal number>) of a
65 power level the component supports, followed by an equal sign followed
66 by a short descriptive name for that power level. Again, the names
67 should be descriptive, such as "On," "Off," "Suspend", "Standby," etc.
68 The next component continues the array in the same manner, with a
69 string that starts out NAME=, specifying the beginning of a new compo‐
70 nent (and its name), followed by specifications of the power levels the
71 component supports.
72 The components must be listed in increasing order according to the com‐
75 ponent number as interpreted by the driver's power(9E) routine. (Compo‐
76 nents are numbered sequentially from 0). The power levels must be
77 listed in increasing order of power consumption. Each component must
78 support at least two power levels, or there is no possibility of power
79 level transitions. If a power level value of 0 is used, it must be the
80 first one listed for that component. A power level value of 0 has a
81 special meaning (off) to the Power Management framework.
82
84 An example of a pm-components entry from the .conf file of a driver
85 which implements a single power managed component consisting of a disk
86 spindle motor is shown below. This is component 0 and it supports 2
87 power level, which represent spindle stopped or full speed.
88 pm-components="NAME=Spindle Motor", "0=Stopped", "1=Full Speed";
90 ...
91 Below is an example of how the above entry would be implemented in the
96 attach(9E) function of the driver.
97 static char *pmcomps[] = {
99 "NAME=Spindle Motor",
100 "0=Stopped",
101 "1=Full Speed"
102 };
103 ...
105 xxattach(dev_info_t *dip, ddi_attach_cmd_t cmd)
107 {
108 ...
109 if (ddi_prop_update_string_array(DDI_DEV_T_NONE, dip, "pm-components",
110 &pmcomp[0], sizeof (pmcomps) / sizeof (char *)) !=DDI_PROP_SUCCESS)
111 goto failed;
112 }
113 Below is an example for a frame buffer which implements two components.
118 Component 0 is the frame buffer electronics which supports four differ‐
119 ent power levels. Component 1 represents the state of Power Management
120 of the attached monitor.
121 pm-components="NAME=Frame Buffer", "0=Off"
123 "1=Suspend", "2=Standby", "3=On",
124 "NAME=Monitor", "0=Off", "1=Suspend", "2=Standby,"
125 "3=On;
126
130 See attributes(5) for descriptions of the following attributes:
131 ┌─────────────────────────────┬─────────────────────────────┐
136 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
137 ├─────────────────────────────┼─────────────────────────────┤
138 │Interface stability │Committed │
139 └─────────────────────────────┴─────────────────────────────┘
140
142 power.conf(4), pm(7D), attach(9E), detach(9E),
143 ddi_prop_update_string_array(9F) pm_busy_component(9F), pm_idle_compo‐
144 nent(9F)
145 Writing Device Drivers
148SunOS 5.11 6 Jan 2004 pm-components(9P)