share/man/man9f/pm_raise_power.9f

   1 '\" te
   2 .\" Copyright (c) 2005, Sun Microsystems, Inc.  All Rights Reserved
   3 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
   4 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
   5 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
   6 .TH PM_RAISE_POWER 9F "Mar 22, 2005"
   7 .SH NAME
   8 pm_raise_power, pm_lower_power \- Raise or lower power of components
   9 .SH SYNOPSIS
  10 .LP
  11 .nf
  12 #include <sys/ddi.h>
  13 #include <sys/sunddi.h>
  14
  15 \fBint\fR \fBpm_raise_power\fR(\fBdev_info_t *\fR\fIdip,\fR int \fIcomponent\fR, int \fIlevel\fR);
  16 .fi
  17
  18 .LP
  19 .nf
  20 \fBint\fR \fBpm_lower_power\fR(\fBdev_info_t *\fR\fIdip,\fR int \fIcomponent\fR, int \fIlevel\fR);
  21 .fi
  22
  23 .SH INTERFACE LEVEL
  24 .sp
  25 .LP
  26 Solaris DDI specific (Solaris DDI)
  27 .SH PARAMETERS
  28 .SS "pm_raise_power"
  29 .sp
  30 .ne 2
  31 .na
  32 \fB\fIdip\fR\fR
  33 .ad
  34 .RS 13n
  35 Pointer to the device's \fBdev_info\fR structure
  36 .RE
  37
  38 .sp
  39 .ne 2
  40 .na
  41 \fB\fIcomponent\fR\fR
  42 .ad
  43 .RS 13n
  44 The number of the \fIcomponent\fR for which a power level change is desired
  45 .RE
  46
  47 .sp
  48 .ne 2
  49 .na
  50 \fB\fIlevel\fR\fR
  51 .ad
  52 .RS 13n
  53 The power level to which the indicated \fIcomponent\fR will be raised
  54 .RE
  55
  56 .SS "pm_lower_power"
  57 .sp
  58 .ne 2
  59 .na
  60 \fB\fIdip\fR\fR
  61 .ad
  62 .RS 13n
  63 Pointer to the device's \fBdev_info\fR structure
  64 .RE
  65
  66 .sp
  67 .ne 2
  68 .na
  69 \fB\fIcomponent\fR\fR
  70 .ad
  71 .RS 13n
  72 Number of the \fIcomponent\fR for which a power level change is desired
  73 .RE
  74
  75 .sp
  76 .ne 2
  77 .na
  78 \fB\fIlevel\fR\fR
  79 .ad
  80 .RS 13n
  81 Power level to which the indicated \fIcomponent\fR will be lowered
  82 .RE
  83
  84 .SH DESCRIPTION
  85 .sp
  86 .LP
  87 The \fBpm_raise_power\fR(9F) function requests the Power Management framework
  88 to raise the power level of \fIcomponent \fRof \fIdip\fR to at least \fIlevel.
  89 \fR
  90 .sp
  91 .LP
  92 The state of the device should be examined before each physical access. The
  93 \fBpm_raise_power\fR(9F) function should be called to set a \fIcomponent \fR to
  94 the required power level if the operation to be performed requires the
  95 \fIcomponent \fR to be at a power level higher than its current power level.
  96 .sp
  97 .LP
  98 When \fBpm_raise_power\fR(9F) returns with success, the \fIcomponent \fR is
  99 guaranteed to be at least at the requested power level. All devices that depend
 100 on this will be at their full power level. Since the actual device power level
 101 may be higher than requested by the driver, the driver should not make any
 102 assumption about the absolute power level on successful return from
 103 \fBpm_raise_power\fR(9F).
 104 .sp
 105 .LP
 106 The \fBpm_raise_power\fR(9F) function may cause re-entry of the driver
 107 \fBpower\fR(9E) to raise the power level. Deadlock may result if the driver
 108 locks are held across the call to \fBpm_raise_power\fR(9F).
 109 .sp
 110 .LP
 111 The \fBpm_lower_power\fR(9F) function requests the Power Management framework
 112 to lower the power level of \fIcomponent \fRof \fIdip\fR to at most
 113 \fIlevel\fR.
 114 .sp
 115 .LP
 116 Normally, transitions to lower power levels are initiated by the Power
 117 Management framework based on \fIcomponent\fR idleness. However, when
 118 detaching, the driver should also initiate reduced power levels by setting the
 119 power level of all device components to their lowest levels. The
 120 \fBpm_lower_power\fR(9F) function is intended for this use only, and will
 121 return \fBDDI_FAILURE\fR if the driver is not detaching at the time of the
 122 call.
 123 .sp
 124 .LP
 125 If automatic Power Management is disabled (see \fBdtpower\fR(8) and
 126 \fBpower.conf\fR(4)), \fBpm_lower_power\fR(9F) returns \fBDDI_SUCCESS\fR
 127 without changing the power level of the component. Otherwise, when
 128 \fBpm_lower_power\fR(9F) returns with success, the \fIcomponent \fR is
 129 guaranteed to be at most at the requested power level. Since the actual device
 130 power level may be lower than requested by the driver, the driver should not
 131 make any assumption about the absolute power level on successful return from
 132 \fBpm_lower_power\fR(9F).
 133 .sp
 134 .LP
 135 The \fBpm_lower_power\fR(9F) function may cause re-entry of the driver
 136 \fBpower\fR(9E) to lower the power level. Deadlock may result if the driver
 137 locks are held across the call to \fBpm_lower_power\fR(9F).
 138 .LP
 139 Note -
 140 .sp
 141 .RS 2
 142 If these functions are called as a result of entry into the driver's
 143 \fBattach\fR(9E), \fBdetach\fR(9E) or \fBpower\fR(9E) entry point, these
 144 functions must be called from the same thread which entered \fBattach\fR(9E),
 145 \fBdetach\fR(9E) or \fBpower\fR(9E).
 146 .RE
 147 .SH RETURN VALUES
 148 .sp
 149 .LP
 150 The \fBpm_raise_power\fR(9F) function returns:
 151 .sp
 152 .ne 2
 153 .na
 154 \fB\fBDDI_SUCCESS\fR\fR
 155 .ad
 156 .RS 15n
 157 \fIComponent\fR is now at the requested power level or higher.
 158 .RE
 159
 160 .sp
 161 .ne 2
 162 .na
 163 \fB\fBDDI_FAILURE\fR\fR
 164 .ad
 165 .RS 15n
 166 \fIComponent \fRor \fIlevel\fR is out of range, or the framework was unable to
 167 raise the power level of the component to the requested level.
 168 .RE
 169
 170 .sp
 171 .LP
 172 The \fBpm_lower_power\fR(9F) function returns:
 173 .sp
 174 .ne 2
 175 .na
 176 \fB\fBDDI_SUCCESS\fR\fR
 177 .ad
 178 .RS 15n
 179 \fI Component \fR is now at the requested power level or lower, or automatic
 180 Power Management is disabled.
 181 .RE
 182
 183 .sp
 184 .ne 2
 185 .na
 186 \fB\fBDDI_FAILURE\fR\fR
 187 .ad
 188 .RS 15n
 189 \fI Component \fR or \fIlevel\fR is out of range, or the framework was unable
 190 to lower the power level of the component to the requested level, or the device
 191 is not detaching.
 192 .RE
 193
 194 .SH EXAMPLES
 195 .sp
 196 .LP
 197 A hypothetical disk driver might include this code to handle
 198 \fBpm_raise_power\fR(9F):
 199 .sp
 200 .in +2
 201 .nf
 202 static int
 203 xxdisk_strategy(struct buf *bp)
 204 {
 205
 206  ...
 207
 208        /*
 209         * At this point we have determined that we need to raise the
 210         * power level of the device. Since we have to drop the
 211         * mutex, we need to take care of case where framework is
 212         * lowering power at the same time we are raising power.
 213         * We resolve this by marking the device busy and failing
 214         * lower power in power() entry point when device is busy.
 215         */
 216
 217         ASSERT(mutex_owned(xsp->lock));
 218         if (xsp->pm_busycnt < 1) {
 219        /*
 220                    * Component is not already marked busy
 221                    */
 222          if (pm_busy_component(xsp->dip,
 223                         XXDISK_COMPONENT) != DDI_SUCCESS) {
 224                                bioerror(bp,EIO);
 225                                biodone(bp);
 226                                return (0);
 227                            }
 228                            xsp->pm_busycnt++;
 229         }
 230         mutex_exit(xsp->lock);
 231         if (pm_raise_power(xsp->dip,
 232                   XXDISK_COMPONENT, XXPOWER_SPUN_UP) != DDI_SUCCESS) {
 233                           bioerror(bp,EIO);
 234                           biodone(bp);
 235                           return (0);
 236         }
 237               mutex_enter(xsp->lock);
 238
 239               ....
 240
 241 }
 242
 243
 244 xxdisk_power(dev_info *dip, int comp, int level)
 245 {
 246
 247 \&...
 248
 249        /*
 250         * We fail the power() entry point if the device is busy and
 251         * request is to lower the power level.
 252
 253 */
 254
 255         ASSERT(mutex_owned( xsp->lock));
 256         if (xsp->pm_busycnt >= 1) {
 257                        if (level < xsp->cur_level) {
 258                         mutex_exit( xsp->lock);
 259                         return (DDI_FAILURE);
 260                 }
 261         }
 262
 263 \&...
 264
 265 }
 266 .fi
 267 .in -2
 268
 269 .SH CONTEXT
 270 .sp
 271 .LP
 272 These functions can be called from user or kernel context.
 273 .SH ATTRIBUTES
 274 .sp
 275 .LP
 276 See \fBattributes\fR(5) for a description of the following attribute:
 277 .sp
 278
 279 .sp
 280 .TS
 281 box;
 282 c | c
 283 l | l .
 284 ATTRIBUTE TYPE  ATTRIBUTE VALUE
 285 _
 286 Interface stability     Committed
 287 .TE
 288
 289 .SH SEE ALSO
 290 .sp
 291 .LP
 292 \fBpower.conf\fR(4), \fBpm\fR(7D), \fBattach\fR(9E), \fBdetach\fR(9E),
 293 \fBpower\fR(9E), \fBpm_busy_component\fR(9F), \fBpm_idle_component\fR(9F),
 294 \fBpm\fR(9P), \fBpm-components\fR(9P)
 295 .sp
 296 .LP
 297 \fIWriting Device Drivers\fR