Lines Matching +full:autosuspend +full:- +full:period
1 .. _usb-power-management:
7 :Date: Last-updated: February 2014
11 ---------
17 * Changing the default idle-delay time
20 * The driver interface for autosuspend and autoresume
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 -------------------
104 device. This is called ``autosuspend`` for short. In general, a device
105 won't be autosuspended unless it has been idle for some minimum period
106 of time, the so-called idle-delay time.
116 autosuspend. In fact, at the time of this writing (Linux 2.6.23) the
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
128 triggered within the USB stack: autosuspend and autoresume. Note that
134 ---------------------------------
142 ``control`` file. In 2.6.38 the ``autosuspend`` file will be deprecated
146 but only ``autosuspend`` works.)
165 - ``on`` means that the device should be resumed and
166 autosuspend is not allowed. (Of course, system
169 - ``auto`` is the normal state in which the kernel is
170 allowed to autosuspend and autoresume the device.
181 before the kernel will autosuspend it (the idle-delay
182 time). The default is 2000. 0 means to autosuspend
184 values mean never to autosuspend. You can write a
185 number to the file to change the autosuspend
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
193 (In 2.6.21 writing ``0`` to ``power/autosuspend`` would prevent the device
195 ``power/autosuspend`` attribute did not exist prior to 2.6.21, and the
201 Changing the default idle-delay time
202 ------------------------------------
204 The default autosuspend idle-delay time (in seconds) is controlled by
209 modprobe usbcore autosuspend=5
214 options usbcore autosuspend=5
224 usbcore.autosuspend=5
231 echo 5 >/sys/module/usbcore/parameters/autosuspend
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
239 then to enable autosuspend for selected devices.
243 --------
253 For this reason, by default the kernel disables autosuspend (the
255 than hubs. Hubs, at least, appear to be reasonably well-behaved in
258 (In 2.6.21 and 2.6.22 this wasn't the case. Autosuspend was enabled
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
272 it can enable autosuspend all by itself. For example, the video
278 autosuspend there are still problems. For example, the usbhid driver,
279 which manages keyboards and mice, has autosuspend support. Tests with
283 of them will issue a remote-wakeup request in response to button
286 The kernel will not prevent you from enabling autosuspend on devices
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
349 The driver interface for autosuspend and autoresume
350 ---------------------------------------------------
352 To support autosuspend and autoresume, a driver should implement all
354 that it supports autosuspend by setting the ``.supports_autosuspend`` flag
369 autosuspend the interface's device. When the usage counter is = 0
371 autosuspend the device.
379 has returned -- say from within a work-queue routine -- provided they
391 attempts an autosuspend if the new value is = 0.
395 their non-async counterparts. The big difference is that they
404 an autoresume or an autosuspend. Hence they can be called in
412 The autosuspend attempts mentioned above will often fail for one
417 carry out the operation automatically when the autosuspend idle-delay
422 autosuspend, there's no idle-delay for an autoresume.
426 -----------------------------------
428 Drivers can enable autosuspend for their devices by calling::
435 drivers can disable autosuspend by calling::
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.
470 cause autosuspends to fail with -EBUSY if the driver needs to use the
474 only autosuspend calls. The driver can tell them apart by applying
476 method; it will return True for internal PM events (autosuspend) and
481 ----------------
483 For external events -- but not necessarily for autosuspend or
484 autoresume -- the device semaphore (udev->dev.sem) will be held when a
488 this is true of autosuspend/autoresume events as well.
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 -------------------------------------
624 Note, some interface devices/drivers do not support autosuspend. Userspace may
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
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