Lines Matching refs:the
15 * Changing the default idle-delay time
19 * Other parts of the driver interface
31 Power Management (PM) is the practice of saving energy by suspending
35 "resumed" (returned to a functional full-power state) when the kernel
38 suspended; an example would be reducing the CPU's clock rate. This
41 When the parts being suspended include the CPU and most of the rest of
42 the system, we speak of it as a "system suspend". When a particular
43 device is turned off while the system as a whole remains running, we
46 dynamic PM is implemented in the USB subsystem, although system PM is
50 System PM support is present only if the kernel was built with CONFIG_SUSPEND
52 the kernel was built with CONFIG_PM enabled.
54 [Historically, dynamic PM support for USB was present only if the
56 CONFIG_PM_RUNTIME). Starting with the 3.10 kernel release, dynamic PM support
57 for USB was present whenever the kernel was built with CONFIG_PM_RUNTIME
65 the computer tells it to. Likewise, if the entire computer has been
66 suspended, it generally doesn't resume until the user tells it to, say
67 by pressing a power button or opening the cover.
69 However some devices have the capability of resuming by themselves, or
70 asking the kernel to resume them, or even telling the entire computer
82 A device is idle whenever the kernel thinks it's not busy doing
84 exact definition depends on the device's driver; drivers are allowed
87 unless all the devices plugged into that hub are already suspended.)
98 Dynamic suspends occur when the kernel decides to suspend an idle
101 of time, the so-called idle-delay time.
103 Of course, nothing the kernel does on its own initiative should
104 prevent the computer or its devices from working properly. If a
105 device has been autosuspended and a program tries to use it, the
106 kernel will automatically resume the device (autoresume). For the
108 enabled, if the device supports remote wakeup.
111 autosuspend. In fact, at the time of this writing (Linux 2.6.23) the
112 only drivers which do support it are the hub driver, kaweth, asix,
114 non-supporting driver is bound to a device, the device won't be
115 autosuspended. In effect, the kernel pretends the device is never
120 agent outside the USB stack: system suspend/resume (triggered by
122 remote wakeup (triggered by the device). Internal events are those
123 triggered within the USB stack: autosuspend and autoresume. Note that
131 The user interface for controlling dynamic PM is located in the power/
133 /sys/bus/usb/devices/.../power/ where "..." is the device's ID. The
136 file was deprecated as of the 2.6.35 kernel and replaced by the
137 "control" file. In 2.6.38 the "autosuspend" file will be deprecated
138 and replaced by the "autosuspend_delay_ms" file. The only difference
139 is that the newer file expresses the delay in milliseconds whereas the
145 This file is empty if the device does not support
146 remote wakeup. Otherwise the file contains either the
147 word "enabled" or the word "disabled", and you can
148 write those words to the file. The setting determines
149 whether or not remote wakeup will be enabled when the
150 device is next suspended. (If the setting is changed
151 while the device is suspended, the change won't take
152 effect until the following suspend.)
157 You can write those words to the file to change the
160 "on" means that the device should be resumed and
164 "auto" is the normal state in which the kernel is
165 allowed to autosuspend and autoresume the device.
168 "suspend", meaning that the device should remain
174 This file contains an integer value, which is the
175 number of milliseconds the device should remain idle
176 before the kernel will autosuspend it (the idle-delay
178 as soon as the device becomes idle, and negative
180 number to the file to change the autosuspend
184 power/control do essentially the same thing -- they both prevent the
185 device from being autosuspended. Yes, this is a redundancy in the
188 (In 2.6.21 writing "0" to power/autosuspend would prevent the device
189 from being autosuspended; the behavior was changed in 2.6.22. The
190 power/autosuspend attribute did not exist prior to 2.6.21, and the
196 Changing the default idle-delay time
200 a module parameter in usbcore. You can specify the value when usbcore
211 Some distributions load the usbcore module very early during the boot
213 image. To alter the parameter value you would have to rebuild that
216 If usbcore is compiled into the kernel rather than built as a loadable
221 to the kernel's boot command line.
223 Finally, the parameter value can be changed while the system is
232 Setting the initial default idle-delay to -1 will prevent any
233 autosuspend of any USB device. This has the benefit of allowing you
241 management. Nevertheless, the sad fact is that many devices do not
243 try to resume them they disconnect themselves from the USB bus or
246 the same deficiency.
248 For this reason, by default the kernel disables autosuspend (the
253 (In 2.6.21 and 2.6.22 this wasn't the case. Autosuspend was enabled
257 This means that non-hub devices won't be autosuspended unless the user
259 any widespread programs which will do this; we hope that in the near
261 responsibility. In the meantime you can always carry out the
263 also change the idle-delay time; 2 seconds is not the best choice for
267 it can enable autosuspend all by itself. For example, the video
273 autosuspend there are still problems. For example, the usbhid driver,
276 causing the keyboard to do a remote wakeup all right, will nonetheless
283 device by suspending it at the wrong time. (Highly unlikely, but
291 are pretty modest; the driver need only define
297 methods in its usb_driver structure, and the reset_resume method is
300 The suspend method is called to warn the driver that the
301 device is going to be suspended. If the driver returns a
302 negative error code, the suspend will be aborted. Normally
303 the driver will return 0, in which case it must cancel all
306 The resume method is called to tell the driver that the
307 device has been resumed and the driver can return to normal
310 The reset_resume method is called to tell the driver that
311 the device has been resumed and it also has been reset.
313 since the device has probably lost most or all of its state
314 (although the interfaces will be in the same altsettings as
315 before the suspend).
317 If the device is disconnected or powered down while it is suspended,
318 the disconnect method will be called instead of the resume or
321 current to the USB host controllers during hibernation. (It's
322 possible to work around the hibernation-forces-disconnect problem by
323 using the USB Persist facility.)
325 The reset_resume method is used by the USB Persist facility (see
328 device is reset during a resume and the driver does not have a
329 reset_resume method, the driver won't receive any notification about
330 the resume. Later kernels will call the driver's disconnect method;
334 methods get called when the interfaces are suspended or resumed. In
336 force the drivers for those interface to stop all activity) without
337 suspending the other interfaces. The USB core doesn't allow this; all
338 interfaces are suspended when the device itself is suspended and all
339 interfaces are resumed when the device is resumed. It isn't possible
341 closest you can come is to unbind the interfaces' drivers.
348 three of the methods listed above. In addition, a driver indicates
349 that it supports autosuspend by setting the .supports_autosuspend flag
350 in its usb_driver structure. It is then responsible for informing the
361 The functions work by maintaining a usage counter in the
362 usb_interface's embedded device structure. When the counter is > 0
363 then the interface is deemed to be busy, and the kernel will not
364 autosuspend the interface's device. When the usage counter is = 0
365 then the interface is considered to be idle, and the kernel may
366 autosuspend the device.
368 Drivers need not be concerned about balancing changes to the usage
369 counter; the USB core will undo any remaining "get"s when a driver
371 any of the usb_autopm_* functions after their disconnect() routine has
374 Drivers using the async routines are responsible for their own
377 usb_autopm_get_interface() increments the usage counter and
378 does an autoresume if the device is suspended. If the
379 autoresume fails, the counter is decremented back.
381 usb_autopm_put_interface() decrements the usage counter and
382 attempts an autosuspend if the new value is = 0.
385 usb_autopm_put_interface_async() do almost the same things as
387 use a workqueue to do the resume or suspend part of their
389 such as an URB's completion handler, but when they return the
390 device will generally not yet be in the desired state.
394 decrement the usage counter; they do not attempt to carry out
404 reason or another. For example, the power/control attribute might be
405 set to "on", or another interface in the same device might not be
406 idle. This is perfectly normal. If the reason for failure was that
407 the device hasn't been idle for long enough, a timer is scheduled to
408 carry out the operation automatically when the autosuspend idle-delay
412 the device is no longer present or operating properly. Unlike
416 Other parts of the driver interface
423 in their probe() routine, if they know that the device is capable of
425 writing "auto" to the device's power/control attribute. Likewise,
430 This is exactly the same as writing "on" to the power/control attribute.
434 autosuspending a keyboard if the user can't cause the keyboard to do a
435 remote wakeup by typing on it. If the driver sets
436 intf->needs_remote_wakeup to 1, the kernel won't autosuspend the
437 device if remote wakeup isn't available. (If the device is already
438 autosuspended, though, setting this flag won't cause the kernel to
440 method, at which time the device is guaranteed not to be
445 usb_autopm_put_interface_async() when the output queue drains. When
450 in the event handler. This tells the PM core that the device was just
451 busy and therefore the next autosuspend idle-delay expiration should
452 be pushed back. Many of the usb_autopm_* routines also make this call,
456 driver may call the usb_autopm_get_interface_async() routine at a time
457 when the core has just finished deciding the device has been idle for
458 long enough but not yet gotten around to calling the driver's suspend
460 the I/O request routine and the URB completion handler; it should
461 cause autosuspends to fail with -EBUSY if the driver needs to use the
466 the PMSG_IS_AUTO() macro to the message argument to the suspend
475 autoresume -- the device semaphore (udev->dev.sem) will be held when a
478 disconnect, pre_reset, and post_reset; the USB core guarantees that
482 critical section, the best way is to lock the device and call
483 usb_autopm_get_interface() (and do the reverse at the end of the
484 critical section). Holding the device semaphore will block all
485 external PM calls, and the usb_autopm_get_interface() will prevent any
497 possible, the device should remain suspended following the system
499 the kernel's behavior in this regard has changed. As of 2.6.37 the
507 the system is suspending. The remote wakeup may succeed, which would
508 cause the system suspend to abort. If the remote wakeup doesn't
509 succeed, it may still remain active and thus cause the system to
510 resume as soon as the system suspend is complete. Or the remote
512 and on the hardware and firmware design.
520 enabling hardware LPM, the host can automatically put the device into
524 The user interface for controlling hardware LPM is located in the
526 /sys/bus/usb/devices/.../power/ where "..." is the device's ID. The
532 xHCI host root hub which support software LPM, the
533 host will run a software LPM test for it; if the device
534 enters L1 state and resume successfully and the host
536 driver will enable hardware LPM for the device. You
537 can write y/Y/1 or n/N/0 to the file to enable/disable
545 and U2 exit latencies have been set in the BOS
546 descriptor; if the check is is passed and the host
548 enabled for the device and these files will be created.
551 is enabled for the device.
557 controlled link power management, the USB subsystem also has the
560 In the case of a root or platform-internal hub the host controller
562 method calls to set the port power state. For more background see the
566 logically off, and may trigger the actual loss of VBUS to the port [3].
567 VBUS may be maintained in the case where a hub gangs multiple ports into
568 a shared power well causing power to remain until all ports in the gang
574 WARNING: turning off a port may result in the inability to hot add a device.
577 As far as the effect on the device itself it is similar to what a device
578 goes through during system suspend, i.e. the power session is lost. Any
580 similarly affected by a port power cycle event. For this reason the
581 implementation shares the same device recovery path (and honors the same
582 quirks) as the system resume path for the hub.
587 * wakeup note: if a device is configured to send wakeup events the port
595 The port power control mechanism uses the PM runtime system. Poweroff is
596 requested by clearing the power/pm_qos_no_power_off flag of the port device
597 (defaults to 1). If the port is disconnected it will immediately receive a
598 ClearPortFeature(PORT_POWER) request. Otherwise, it will honor the pm runtime
599 rules and require the attached child device and all descendants to be suspended.
600 This mechanism is dependent on the hub advertising port power switching in its
604 need to unbind the interface drivers before the usb_device will suspend. An
606 to unbind interface drivers, not the driver of the parent usb device. Also,
607 leave hub interface drivers bound. If the driver for the usb device (not
608 interface) is unbound the kernel is no longer able to resume the device. If a
610 attached child-devices will disconnect. A good rule of thumb is that if the
614 Example of the relevant files for port power control. Note, in this example
640 peer ports are simply the hi-speed and superspeed interface pins that
641 are combined into a single usb3 connector. Peer ports share the same
645 connection and attempt to connect to the hi-speed pins. The
650 that the setting pm_qos_no_power_off to zero on a superspeed port may not cause
651 the port to power-off until its highspeed peer has gone to its runtime suspend
652 state. Userspace must take care to order the suspensions if it wants to
659 power session is lost the device may have been removed, or need reset.
660 Resuming the child device when the parent port regains power resolves those
661 states and clamps the maximum port power cycle frequency at the rate the child
666 This writable flag controls the state of an idle port.
667 Once all children and descendants have suspended the
670 '1' the port will remain active/powered regardless of
671 the stats of descendants. Defaults to 1.
674 This file reflects whether the port is 'active' (power is on)
679 An advisory read-only flag to userspace indicating the
680 location and connection type of the port. It returns
686 port on the platform. Typically userspace would choose
697 for the device to be connected prior to the port
698 powering off, or to activate the port prior to enabling
712 NOTE1: since we are relying on the BIOS to get this ACPI
713 information correct, the USB port descriptions may be
721 applied before the port is allowed to poweroff.
724 Must be 'auto', and the port will not
726 reflects the 'suspended' state. Default
731 kernel can persist the device's configuration across a
738 this time the only mechanism to clear the usb-internal
746 echo auto > power/control # this is the default value
748 echo 1 > <child>/power/persist # this is the default value
760 Given confidence in the platform firmware's description of the ports
764 connection switch for the port.
768 some external factor indicates the user has stopped interacting with the
770 ports when the screen blanks, and re-power them when the screen becomes
772 the user pushes the power button.