Lines Matching refs:device
12 * The power management workqueue pm_wq in which bus types and device drivers can
19 * A number of runtime PM fields in the 'power' member of 'struct device' (which
23 * Three device runtime PM callbacks in 'struct dev_pm_ops' (defined in
29 device drivers are encouraged to use these functions.
31 The runtime PM callbacks present in 'struct dev_pm_ops', the device runtime PM
37 There are three device runtime PM callbacks defined in 'struct dev_pm_ops':
41 int (*runtime_suspend)(struct device *dev);
42 int (*runtime_resume)(struct device *dev);
43 int (*runtime_idle)(struct device *dev);
48 are executed by the PM core for the device's subsystem that may be either of
51 1. PM domain of the device, if the device's PM domain object, dev->pm_domain,
54 2. Device type of the device, if both dev->type and dev->type->pm are present.
56 3. Device class of the device, if both dev->class and dev->class->pm are
59 4. Bus type of the device, if both dev->bus and dev->bus->pm are present.
66 priority order of callbacks from high to low is: PM domain, device type, class
68 a low-priority one. The PM domain, bus type, device type and class callbacks
74 and ->runtime_idle() callbacks for the given device in atomic context with
77 listed at the end of Section 4 may be used for that device within an interrupt
81 for handling the suspend of the device as appropriate, which may, but need not
82 include executing the device driver's own ->runtime_suspend() callback (from the
84 callback in a device driver as long as the subsystem-level suspend callback
85 knows what to do to handle the device).
88 if invoked directly) has completed successfully for the given device, the PM
89 core regards the device as suspended, which need not mean that it has been
91 device will not process data and will not communicate with the CPU(s) and
93 PM status of a device after successful execution of the suspend callback is
96 * If the suspend callback returns -EBUSY or -EAGAIN, the device's runtime PM
97 status remains 'active', which means that the device _must_ be fully
102 the helper functions described in Section 4 for the device until its status
107 mechanism allowing the device to request a change of its power state, such as
109 device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
110 device_run_wake() returns 'true' for the device and the device is put into a
112 that remote wakeup will be enabled for the device. Generally, remote wakeup
116 handling the resume of the device as appropriate, which may, but need not
117 include executing the device driver's own ->runtime_resume() callback (from the
119 callback in a device driver as long as the subsystem-level resume callback knows
120 what to do to handle the device).
123 invoked directly) has completed successfully, the PM core regards the device
124 as fully operational, which means that the device _must_ be able to complete
125 I/O operations as needed. The runtime PM status of the device is then
130 4 for the device, until its status is directly set to either 'active', or
135 executed by the PM core whenever the device appears to be idle, which is
136 indicated to the PM core by two counters, the device's usage counter and the
137 counter of 'active' children of the device.
142 idle callback with the device as its argument.
146 if the device can be suspended (i.e. if all of the conditions necessary for
147 suspending the device are satisfied) and to queue up a suspend request for the
148 device in that case. If there is no idle callback, or if the callback returns
149 0, then the PM core will attempt to carry out a runtime suspend of the device,
152 device last busy mark, pm_runtime_mark_last_busy(), to control the delay under
159 one device:
163 instance of ->runtime_suspend() for the same device) with the exception that
166 of the other callbacks is being executed for the same device).
173 (3) ->runtime_idle() and ->runtime_suspend() can only be executed for a device
186 to execute it, ->runtime_idle() will not be executed for the same device.
190 device.
193 to execute it, the other callbacks will not be executed for the same device.
196 scheduled requests to execute the other callbacks for the same device,
201 The following device runtime PM fields are present in 'struct dev_pm_info', as
223 - the usage counter of the device
226 - the count of 'active' children of the device
253 being executed for that device and it is not practical to wait for the
257 - set if the device is capable of generating runtime wake-up events
260 - the runtime PM status of the device; this field's initial value is
261 RPM_SUSPENDED, which means that each device is initially regarded by the
265 - if set, indicates that the user space has allowed the device driver to
266 power manage the device at run time via the /sys/devices/.../power/control
271 - indicates that the device does not use the runtime PM callbacks (see
280 - indicates that the device's driver supports delayed autosuspend (see
293 function was last called for this device; used in calculating inactivity
296 All of the above fields are members of the 'power' member of 'struct device'.
303 void pm_runtime_init(struct device *dev);
304 - initialize the device runtime PM fields in 'struct dev_pm_info'
306 void pm_runtime_remove(struct device *dev);
307 - make sure that the runtime PM of the device will be disabled after
308 removing the device from device hierarchy
310 int pm_runtime_idle(struct device *dev);
311 - execute the subsystem-level idle callback for the device; returns an
316 int pm_runtime_suspend(struct device *dev);
317 - execute the subsystem-level suspend callback for the device; returns 0 on
318 success, 1 if the device's runtime PM status was already 'suspended', or
320 to suspend the device again in future and -EACCES means that
323 int pm_runtime_autosuspend(struct device *dev);
329 int pm_runtime_resume(struct device *dev);
330 - execute the subsystem-level resume callback for the device; returns 0 on
331 success, 1 if the device's runtime PM status was already 'active' or
333 resume the device again in future, but 'power.runtime_error' should be
337 int pm_request_idle(struct device *dev);
339 device (the request is represented by a work item in pm_wq); returns 0 on
342 int pm_request_autosuspend(struct device *dev);
344 device when the autosuspend delay has expired; if the delay has already
347 int pm_schedule_suspend(struct device *dev, unsigned int delay);
349 device in future, where 'delay' is the time to wait before queuing up a
351 item is queued up immediately); returns 0 on success, 1 if the device's PM
357 int pm_request_resume(struct device *dev);
359 device (the request is represented by a work item in pm_wq); returns 0 on
360 success, 1 if the device's runtime PM status was already 'active', or
363 void pm_runtime_get_noresume(struct device *dev);
364 - increment the device's usage counter
366 int pm_runtime_get(struct device *dev);
367 - increment the device's usage counter, run pm_request_resume(dev) and
370 int pm_runtime_get_sync(struct device *dev);
371 - increment the device's usage counter, run pm_runtime_resume(dev) and
374 void pm_runtime_put_noidle(struct device *dev);
375 - decrement the device's usage counter
377 int pm_runtime_put(struct device *dev);
378 - decrement the device's usage counter; if the result is 0 then run
381 int pm_runtime_put_autosuspend(struct device *dev);
382 - decrement the device's usage counter; if the result is 0 then run
385 int pm_runtime_put_sync(struct device *dev);
386 - decrement the device's usage counter; if the result is 0 then run
389 int pm_runtime_put_sync_suspend(struct device *dev);
390 - decrement the device's usage counter; if the result is 0 then run
393 int pm_runtime_put_sync_autosuspend(struct device *dev);
394 - decrement the device's usage counter; if the result is 0 then run
397 void pm_runtime_enable(struct device *dev);
398 - decrement the device's 'power.disable_depth' field; if that field is equal
400 callbacks described in Section 2 for the device
402 int pm_runtime_disable(struct device *dev);
403 - increment the device's 'power.disable_depth' field (if the value of that
405 callbacks from being run for the device), make sure that all of the
406 pending runtime PM operations on the device are either completed or
408 necessary to execute the subsystem-level resume callback for the device
411 int pm_runtime_barrier(struct device *dev);
412 - check if there's a resume request pending for the device and resume it
416 necessary to execute the subsystem-level resume callback for the device to
419 void pm_suspend_ignore_children(struct device *dev, bool enable);
420 - set/unset the power.ignore_children flag of the device
422 int pm_runtime_set_active(struct device *dev);
423 - clear the device's 'power.runtime_error' flag, set the device's runtime
427 zero); it will fail and return error code if the device has a parent
430 void pm_runtime_set_suspended(struct device *dev);
431 - clear the device's 'power.runtime_error' flag, set the device's runtime
437 bool pm_runtime_active(struct device *dev);
438 - return true if the device's runtime PM status is 'active' or its
441 bool pm_runtime_suspended(struct device *dev);
442 - return true if the device's runtime PM status is 'suspended' and its
445 bool pm_runtime_status_suspended(struct device *dev);
446 - return true if the device's runtime PM status is 'suspended'
448 bool pm_runtime_suspended_if_enabled(struct device *dev);
449 - return true if the device's runtime PM status is 'suspended' and its
452 void pm_runtime_allow(struct device *dev);
453 - set the power.runtime_auto flag for the device and decrease its usage
455 effectively allow the device to be power managed at run time)
457 void pm_runtime_forbid(struct device *dev);
458 - unset the power.runtime_auto flag for the device and increase its usage
460 effectively prevent the device from being power managed at run time)
462 void pm_runtime_no_callbacks(struct device *dev);
463 - set the power.no_callbacks flag for the device and remove the runtime
465 added when the device is registered)
467 void pm_runtime_irq_safe(struct device *dev);
468 - set the power.irq_safe flag for the device, causing the runtime-PM
471 bool pm_runtime_is_irq_safe(struct device *dev);
472 - return true if power.irq_safe flag was set for the device, causing
475 void pm_runtime_mark_last_busy(struct device *dev);
478 void pm_runtime_use_autosuspend(struct device *dev);
481 void pm_runtime_dont_use_autosuspend(struct device *dev);
484 void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
489 unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
516 If pm_runtime_irq_safe() has been called for a device then the following helper
532 -EAGAIN until pm_runtime_enable() is called for the device.
535 'suspended', but it need not reflect the actual physical state of the device.
536 Thus, if the device is initially active (i.e. it is able to process I/O), its
538 pm_runtime_set_active(), before pm_runtime_enable() is called for the device.
540 However, if the device has a parent and the parent's runtime PM is enabled,
541 calling pm_runtime_set_active() for the device will affect the parent, unless
547 once pm_runtime_set_active() has been called for the device, pm_runtime_enable()
552 If the default initial runtime PM status of the device (i.e. 'suspended')
553 reflects the actual state of the device, its bus type's or its driver's
556 should be used. Of course, for this purpose the device's runtime PM has to be
559 It may be desirable to suspend the device once ->probe() has finished.
561 request to execute the subsystem-level idle callback for the device at that
570 resumes the device if it's in the suspended state and prevents it from
581 The user space can effectively disallow the driver of the device to power manage
585 runtime power management of the device until the user space turns it on.
587 status of the device is 'active' and call pm_runtime_forbid(). It should be
590 manage the device at run time, the driver may confuse it by using
597 ways. If a device is active when a system sleep starts, everything is
598 straightforward. But what should happen if the device is already suspended?
600 The device may have different wake-up settings for runtime PM and system sleep.
604 device's wake-up setting (it may leave that to the device driver's system
605 suspend routine). It may be necessary to resume the device and suspend it again
613 * The device might need to switch power levels, wake-up settings, etc.
617 * The device's children may need the device to be at full power in order
620 * The driver's idea of the device state may not agree with the device's
623 * The device might need to be reset.
625 * Even though the device was suspended, if its usage counter was > 0 then most
628 If the device had been suspended before the system suspend began and it's
657 different levels of device hierarchy. Namely, if a system suspend .prepare()
658 callback returns a positive number for a device, that indicates to the PM core
659 that the device appears to be runtime-suspended and its state is fine, so it
663 complete callback, which is then entirely responsible for handling the device
672 * During system suspend pm_runtime_get_noresume() is called for every device
674 pm_runtime_barrier() is called for every device right before executing the
677 device right before executing the subsystem-level .suspend_late() callback
681 every device right after executing the subsystem-level .resume_early()
691 int pm_generic_runtime_suspend(struct device *dev);
693 device and return its result, or return 0 if not defined
695 int pm_generic_runtime_resume(struct device *dev);
697 device and return its result, or return 0 if not defined
699 int pm_generic_suspend(struct device *dev);
700 - if the device has not been suspended at run time, invoke the ->suspend()
704 int pm_generic_suspend_noirq(struct device *dev);
706 callback provided by the device's driver and return its result, or return
709 int pm_generic_resume(struct device *dev);
710 - invoke the ->resume() callback provided by the driver of this device and,
711 if successful, change the device's runtime PM status to 'active'
713 int pm_generic_resume_noirq(struct device *dev);
714 - invoke the ->resume_noirq() callback provided by the driver of this device
716 int pm_generic_freeze(struct device *dev);
717 - if the device has not been suspended at run time, invoke the ->freeze()
721 int pm_generic_freeze_noirq(struct device *dev);
723 callback provided by the device's driver and return its result, or return
726 int pm_generic_thaw(struct device *dev);
727 - if the device has not been suspended at run time, invoke the ->thaw()
731 int pm_generic_thaw_noirq(struct device *dev);
733 callback provided by the device's driver and return its result, or return
736 int pm_generic_poweroff(struct device *dev);
737 - if the device has not been suspended at run time, invoke the ->poweroff()
741 int pm_generic_poweroff_noirq(struct device *dev);
743 callback provided by the device's driver and return its result, or return
746 int pm_generic_restore(struct device *dev);
747 - invoke the ->restore() callback provided by the driver of this device and,
748 if successful, change the device's runtime PM status to 'active'
750 int pm_generic_restore_noirq(struct device *dev);
751 - invoke the ->restore_noirq() callback provided by the device's driver
777 pm_runtime_no_callbacks(). This should be done after the device structure is
778 initialized and before it is registered (although after device registration is
779 also okay). The routine will set the device's power.no_callbacks flag and
787 As a consequence, the PM core will never directly inform the device's subsystem
788 or driver about runtime power changes. Instead, the driver for the device's
789 parent must take responsibility for telling the device's driver when the
794 Changing a device's power state isn't free; it requires both time and energy.
795 A device should be put in a low-power state only when there's some reason to
797 says that a device which hasn't been used for a while is liable to remain
804 device is automatically suspended (the subsystem or driver still has to call
812 initially by calling pm_runtime_set_autosuspend_delay(), but after device
817 pm_runtime_use_autosuspend() (preferably before registering the device), and
831 Under some circumstances a driver or subsystem may want to prevent a device
838 itself because no suspend requests of any kind are accepted while the device is
871 int foo_runtime_suspend(struct device *dev)
880 /* ... suspend the device ... */
887 int foo_runtime_resume(struct device *dev)
892 /* ... resume the device ... */