Lines Matching +full:no +full:- +full:reset +full:- +full:during +full:- +full:suspend
1 .. _usb-power-management:
7 :Date: Last-updated: February 2014
11 ---------
17 * Changing the default idle-delay time
31 -------------------------
35 component is ``suspended`` it is in a nonfunctional low-power state; it
37 ``resumed`` (returned to a functional full-power state) when the kernel
44 the system, we speak of it as a "system suspend". When a particular
46 call it a "dynamic suspend" (also known as a "runtime suspend" or
47 "selective suspend"). This document concentrates mostly on how
67 ----------------------
85 --------------------------
90 to declare that a device isn't idle even when there's no actual
96 If a USB device has no driver, its usbfs file isn't open, and it isn't
101 -------------------
103 Dynamic suspends occur when the kernel decides to suspend an idle
106 of time, the so-called idle-delay time.
118 usblp, usblcd, and usb-skeleton (which doesn't count). If a
119 non-supporting driver is bound to a device, the device won't be
125 agent outside the USB stack: system suspend/resume (triggered by
129 all dynamic suspend events are internal; external agents are not
134 ---------------------------------
157 effect until the following suspend.)
165 - ``on`` means that the device should be resumed and
169 - ``auto`` is the normal state in which the kernel is
173 ``suspend``, meaning that the device should remain
175 setting is no longer supported.)
181 before the kernel will autosuspend it (the idle-delay
186 idle-delay time.
188 Writing ``-1`` to ``power/autosuspend_delay_ms`` and writing ``on`` to
189 ``power/control`` do essentially the same thing -- they both prevent the
201 Changing the default idle-delay time
202 ------------------------------------
204 The default autosuspend idle-delay time (in seconds) is controlled by
216 Some distributions load the usbcore module very early during the boot
233 then each new USB device will have its autosuspend idle-delay
234 initialized to 5. (The idle-delay values for already existing devices
237 Setting the initial default idle-delay to -1 will prevent any
243 --------
247 support it very well. You can suspend them all right, but when you
255 than hubs. Hubs, at least, appear to be reasonably well-behaved in
262 This means that non-hub devices won't be autosuspended unless the user
268 also change the idle-delay time; 2 seconds is not the best choice for
271 If a driver knows that its device has proper suspend/resume support,
283 of them will issue a remote-wakeup request in response to button
293 -----------------------------------------
298 .suspend
305 - The ``suspend`` method is called to warn the driver that the
307 negative error code, the suspend will be aborted. Normally
311 - The ``resume`` method is called to tell the driver that the
315 - The ``reset_resume`` method is called to tell the driver that
316 the device has been resumed and it also has been reset.
320 before the suspend).
325 waking up from hibernation, as many systems do not maintain suspend
326 current to the USB host controllers during hibernation. (It's
327 possible to work around the hibernation-forces-disconnect problem by
331 :ref:`usb-persist`) and it can also be used under certain
333 device is reset during a resume and the driver does not have a
338 USB drivers are bound to interfaces, so their ``suspend`` and ``resume``
340 principle one might want to suspend some interfaces on a device (i.e.,
345 to suspend or resume some but not all of a device's interfaces. The
350 ---------------------------------------------------
376 runtime suspend should the interface be bound to a driver again. On
379 has returned -- say from within a work-queue routine -- provided they
395 their non-async counterparts. The big difference is that they
396 use a workqueue to do the resume or suspend part of their
417 carry out the operation automatically when the autosuspend idle-delay
421 the device is no longer present or operating properly. Unlike
422 autosuspend, there's no idle-delay for an autoresume.
426 -----------------------------------
442 during autosuspend. For example, there's not much point
445 ``intf->needs_remote_wakeup`` to 1, the kernel won't autosuspend the
460 busy and therefore the next autosuspend idle-delay expiration should
462 so drivers need to worry only when interrupt-driven input arrives.
467 long enough but not yet gotten around to calling the driver's ``suspend``
468 method. The ``suspend`` method must be responsible for synchronizing with
470 cause autosuspends to fail with -EBUSY if the driver needs to use the
473 External suspend calls should never be allowed to fail in this way,
475 the :c:func:`PMSG_IS_AUTO` macro to the message argument to the ``suspend``
481 ----------------
483 For external events -- but not necessarily for autosuspend or
484 autoresume -- the device semaphore (udev->dev.sem) will be held when a
485 ``suspend`` or ``resume`` method is called. This implies that external
486 suspend/resume events are mutually exclusive with calls to ``probe``,
490 If a driver wants to block all suspend/resume calls during some
499 --------------------------------------------
504 Firstly, a device may already be autosuspended when a system suspend
509 policy is to resume all devices during a system resume and let them
512 Secondly, a dynamic power-management event may occur as a system
513 suspend is underway. The window for this is short, since system
515 For example, a suspended device may send a remote-wakeup signal while
517 cause the system suspend to abort. If the remote wakeup doesn't
519 resume as soon as the system suspend is complete. Or the remote
525 ---------------------
552 When a USB 3.0 lpm-capable device is plugged in to a
563 ----------------------
569 In the case of a root or platform-internal hub the host controller
589 goes through during system suspend, i.e. the power session is lost. Any
590 USB device or driver that misbehaves with system suspend will be
597 http://dl.dropbox.com/u/96820575/sarah-sharp-lpt-port-power-off2-mini.pdf
601 http://linuxplumbers.ubicast.tv/videos/usb-port-power-off-kerneluserspace-api/
613 -------------------------------------
626 suspend. An unbound interface device is suspended by default. When unbinding,
629 device (not interface) is unbound the kernel is no longer able to resume the
631 lost and all attached child-devices will disconnect. A good rule of thumb is
639 prefix=/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1
645 $prefix/3-1:1.0/3-1-port1/device
647 $prefix/3-1:1.0/3-1-port1/power/pm_qos_no_power_off
648 $prefix/3-1:1.0/3-1-port1/device/power/control
649 $prefix/3-1:1.0/3-1-port1/device/3-1.1:<intf0>/driver/unbind
650 $prefix/3-1:1.0/3-1-port1/device/3-1.1:<intf1>/driver/unbind
652 $prefix/3-1:1.0/3-1-port1/device/3-1.1:<intfN>/driver/unbind
656 hi-speed peer::
658 $prefix/3-1:1.0/3-1-port1/peer -> ../../../../usb2/2-1/2-1:1.0/2-1-port1
659 ../../../../usb2/2-1/2-1:1.0/2-1-port1/peer -> ../../../../usb3/3-1/3-1:1.0/3-1-port1
662 peer ports are simply the hi-speed and superspeed interface pins that
667 connection and attempt to connect to the hi-speed pins. The
670 1. Port suspend is sequenced to guarantee that hi-speed ports are powered-off
671 before their superspeed peer is permitted to power-off. The implication is
673 not cause the port to power-off until its highspeed peer has gone to its
674 runtime suspend state. Userspace must take care to order the suspensions
675 if it wants to guarantee that a superspeed port will power-off.
677 2. Port resume is sequenced to force a superspeed port to power-on prior to its
681 power session is lost the device may have been removed, or need reset.
684 child device can suspend (autosuspend-delay) and resume (reset-resume
689 ``<hubdev-portX>/power/pm_qos_no_power_off``:
692 port may suspend/poweroff provided that
697 ``<hubdev-portX>/power/runtime_status``:
699 or 'suspended' (logically off). There is no indication to
702 ``<hubdev-portX>/connect_type``:
703 An advisory read-only flag to userspace indicating the
718 expected to be safe to allow these ports to suspend
729 powered-off at all times.
738 - since we are relying on the BIOS to get this ACPI
742 - Take care in clearing ``pm_qos_no_power_off``. Once
758 power session loss (suspend / port-power event). When
764 this time the only mechanism to clear the usb-internal
765 wakeup-capability for an interface device is to unbind
768 Summary of poweroff pre-requisite settings relative to a port device::
777 -------------------------------------
793 all ports (set ``<hubdev-portX>/power/pm_qos_no_power_off`` to ``0``) when
796 ports when the screen blanks, and re-power them when the screen becomes