driver-api/usb/power-management.rst

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
67 ----------------------
85 --------------------------
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 ---------------------------------
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
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
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
311       - The ``resume`` method is called to tell the driver that the
315       - The ``reset_resume`` method is called to tell the driver that
327 possible to work around the hibernation-forces-disconnect problem by
331 :ref:`usb-persist`) and it can also be used under certain
350 ---------------------------------------------------
379 has returned -- say from within a work-queue routine -- provided they
383 Drivers using the async routines are responsible for their own
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 --------------------------------------------
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 -------------------------------------
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
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
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
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