Lines Matching +full:usb +full:- +full:hub
1 .. _usb-power-management:
3 Power Management for USB
7 :Date: Last-updated: February 2014
11 ---------
14 * When is a USB device idle?
17 * Changing the default idle-delay time
25 * USB Port Power Control
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
48 dynamic PM is implemented in the USB subsystem, although system PM is
55 for USB is present whenever
58 [Historically, dynamic PM support for USB was present only if the
61 support for USB was present whenever the kernel was built with
67 ----------------------
81 pressed, or a suspended USB hub resuming when a device is plugged in.
84 When is a USB device idle?
85 --------------------------
91 communication taking place. (For example, a hub isn't considered idle
92 unless all the devices plugged into that hub are already suspended.)
96 If a USB device has no driver, its usbfs file isn't open, and it isn't
101 -------------------
106 of time, the so-called idle-delay time.
115 It is worth mentioning that many USB drivers don't support
117 only drivers which do support it are the hub driver, kaweth, asix,
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
128 triggered within the USB stack: autosuspend and autoresume. Note that
134 ---------------------------------
137 subdirectory of each USB device's sysfs directory, that is, in
138 ``/sys/bus/usb/devices/.../power/`` where "..." is the device's ID. The
165 - ``on`` means that the device should be resumed and
169 - ``auto`` is the normal state in which the kernel is
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
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
238 autosuspend of any USB device. This has the benefit of allowing you
243 --------
245 The USB specification states that all USB devices must support power
248 try to resume them they disconnect themselves from the USB bus or
255 than hubs. Hubs, at least, appear to be reasonably well-behaved in
259 by default for almost all USB devices. A number of people experienced
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
283 of them will issue a remote-wakeup request in response to button
293 -----------------------------------------
295 The requirements for a USB driver to support external power management
305 - The ``suspend`` method is called to warn the driver that the
311 - The ``resume`` method is called to tell the driver that the
315 - The ``reset_resume`` method is called to tell the driver that
326 current to the USB host controllers during hibernation. (It's
327 possible to work around the hibernation-forces-disconnect problem by
328 using the USB Persist facility.)
330 The ``reset_resume`` method is used by the USB Persist facility (see
331 :ref:`usb-persist`) and it can also be used under certain
338 USB drivers are bound to interfaces, so their ``suspend`` and ``resume``
342 suspending the other interfaces. The USB core doesn't allow this; all
350 ---------------------------------------------------
356 USB core whenever one of its interfaces becomes busy or idle. The
379 has returned -- say from within a work-queue routine -- provided they
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
487 ``disconnect``, ``pre_reset``, and ``post_reset``; the USB core guarantees that
499 --------------------------------------------
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 ---------------------
534 ``power/`` subdirectory of each USB device's sysfs directory, that is, in
535 ``/sys/bus/usb/devices/.../power/`` where "..." is the device's ID. The
541 xHCI host root hub which support software LPM, the
552 When a USB 3.0 lpm-capable device is plugged in to a
562 USB Port Power Control
563 ----------------------
566 controlled link power management, the USB subsystem also has the
568 controlled through ``Set/ClearPortFeature(PORT_POWER)`` requests to a hub.
569 In the case of a root or platform-internal hub the host controller
574 Upon receiving a ``ClearPortFeature(PORT_POWER)`` request a USB port is
576 VBUS may be maintained in the case where a hub gangs multiple ports into
578 are turned off. VBUS may also be maintained by hub ports configured for
590 USB device or driver that misbehaves with system suspend will be
593 quirks) as the system resume path for the hub.
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/
605 USB 3.1 Section 10.12
613 -------------------------------------
620 suspended. This mechanism is dependent on the hub advertising port power
621 switching in its hub descriptor (wHubCharacteristics logical power switching
627 be careful to unbind interface drivers, not the driver of the parent usb
628 device. Also, leave hub interface drivers bound. If the driver for the usb
630 device. If a hub interface driver is unbound, control of its child ports is
631 lost and all attached child-devices will disconnect. A good rule of thumb is
637 these files are relative to a usb hub device (prefix)::
639 prefix=/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1
642 hub port device + |
643 hub interface device + | |
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
655 another hub. The expectation is that all superspeed ports have a
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
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``:
697 ``<hubdev-portX>/power/runtime_status``:
702 ``<hubdev-portX>/connect_type``:
703 An advisory read-only flag to userspace indicating the
715 connectable. Examples are internal ports for USB
717 switch or a port with a hardwired USB camera. It is
729 powered-off at all times.
733 external hub ports which should be considered 'hotplug'
738 - since we are relying on the BIOS to get this ACPI
739 information correct, the USB port descriptions may
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 -------------------------------------
792 A more aggressive userspace policy is to enable USB port power off for
793 all ports (set ``<hubdev-portX>/power/pm_qos_no_power_off`` to ``0``) when
795 system. For example, a distro may want to enable power off all USB
796 ports when the screen blanks, and re-power them when the screen becomes
797 active. Smart phones and tablets may want to power off USB ports when