Lines Matching +full:powered +full:- +full:while +full:- +full:suspended
1 .. _usb-power-management:
7 :Date: Last-updated: February 2014
11 ---------
17 * Changing the default idle-delay time
31 -------------------------
34 parts of a computer system when they aren't being used. While a
35 component is ``suspended`` it is in a nonfunctional low-power state; it
36 might even be turned off completely. A suspended component can be
37 ``resumed`` (returned to a functional full-power state) when the kernel
40 suspended; an example would be reducing the CPU's clock rate. This
43 When the parts being suspended include the CPU and most of the rest of
45 device is turned off while the system as a whole remains running, we
67 ----------------------
69 When a device has been suspended, it generally doesn't resume until
71 suspended, it generally doesn't resume until the user tells it to, say
78 device is enabled for remote wakeup and it is suspended, it may resume
80 event. Examples include a suspended keyboard resuming when a key is
81 pressed, or a suspended USB hub resuming when a device is plugged in.
85 --------------------------
88 anything important and thus is a candidate for being suspended. The
92 unless all the devices plugged into that hub are already suspended.)
101 -------------------
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
134 ---------------------------------
155 device is next suspended. (If the setting is changed
156 while the device is suspended, the change won't take
165 - ``on`` means that the device should be resumed and
169 - ``auto`` is the normal state in which the kernel is
174 suspended and autoresume was not allowed. This
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
228 Finally, the parameter value can be changed while the system is
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 --------
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
280 a number of keyboards show that typing on a suspended keyboard, while
283 of them will issue a remote-wakeup request in response to button
293 -----------------------------------------
305 - The ``suspend`` method is called to warn the driver that the
306 device is going to be suspended. If the driver returns a
311 - The ``resume`` method is called to tell the driver that the
315 - The ``reset_resume`` method is called to tell the driver that
322 If the device is disconnected or powered down while it is suspended,
327 possible to work around the hibernation-forces-disconnect problem by
331 :ref:`usb-persist`) and it can also be used under certain
339 methods get called when the interfaces are suspended or resumed. In
343 interfaces are suspended when the device itself is suspended and all
350 ---------------------------------------------------
379 has returned -- say from within a work-queue routine -- provided they
387 does an autoresume if the device is suspended. If the
395 their non-async counterparts. The big difference is that they
417 carry out the operation automatically when the autosuspend idle-delay
422 autosuspend, there's no idle-delay for an autoresume.
426 -----------------------------------
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.
470 cause autosuspends to fail with -EBUSY if the driver needs to use the
481 ----------------
483 For external events -- but not necessarily for autosuspend or
484 autoresume -- the device semaphore (udev->dev.sem) will be held when a
499 --------------------------------------------
506 possible, the device should remain suspended following the system
512 Secondly, a dynamic power-management event may occur as a system
515 For example, a suspended device may send a remote-wakeup signal while
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
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 -------------------------------------
620 suspended. This mechanism is dependent on the hub advertising port power
626 suspend. An unbound interface device is suspended by default. When unbinding,
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
666 While a superspeed port is powered off a device may downgrade its
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
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
684 child device can suspend (autosuspend-delay) and resume (reset-resume
689 ``<hubdev-portX>/power/pm_qos_no_power_off``:
691 Once all children and descendants have suspended the
694 '1' the port will remain active/powered regardless of
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
711 to keep such a port powered to handle new device
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
752 reflects the 'suspended' state. Default
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