| /linux/Documentation/power/ |
| H A D | swsusp.rst | 11 If you touch anything on disk between suspend and resume...
14 If you do resume from initrd after your filesystems are mounted...
22 between suspend and resume, it may do something wrong. If you change
26 ( ) suspend/resume support is needed to make it safe.
29 they won't be accessible after resume and you may lose data, as though
35 You need to append resume=/dev/your_swap_partition to kernel command
36 line or specify it using /sys/power/resume.
39 If using a swapfile you can also specify a resume offset using
57 support. For suspend and resume to work, make sure your disk drivers
59 suspend/resume with modular disk drivers, see FAQ, but you probably
[all …]
|
| H A D | swsusp-dmcrypt.rst | 25 or an usb stick prior to resume. So you need an initrd, that sets
26 up dm-crypt and then asks swsusp to resume from the encrypted
30 a way that the swap device you suspend to/resume from has
39 resume partition, so your kernel .config contains::
67 initrd that allows you to resume from encrypted swap and that
68 continues boot with your mini system on /dev/hda1 if resume
106 echo 254:0 > /sys/power/resume
121 First we have to decide if we want to try to resume, or not.
122 We will not resume if booting with "noresume" or any parameters
127 device if we don't want to resume. The line "echo 254:0 > /sys/power/resume"
[all …]
|
| H A D | s2ram.rst | 21 always it's a driver that is buggy. Thank God for the suspend/resume
25 driver that doesn't resume and recompile and reboot).
46 hash matches drivers/base/power/resume.c:28
49 which means that the last trace event was just before trying to resume
52 fix it, disable it, or trace into its resume function.
63 that "radeonfb" simply cannot resume that device - it tries to set the
65 resume it instead works fine.
71 hardware during resume operations where a value can be set that will
78 Consequence is that after a resume (even if it is successful) your system
85 quickly after the resume failure. The trace option does not use the seconds
|
| H A D | drivers-testing.rst | 2 Testing suspend and resume support in device drivers
11 resume transitions in a driver, it is necessary to suspend and resume a fully
19 resume without the driver being tested. Thus, if possible, you should first
20 resolve all suspend/resume-related problems in the test system before you start
22 for more information about the debugging of suspend/resume functionality.
27 Once you have resolved the suspend/resume-related problems with your test system
52 regarded as suspend/resume-safe.
|
| H A D | basic-pm-debugging.rst | 15 and the system should create a hibernation image, reboot, resume and get back to
23 fails to hibernate or resume in the "reboot" mode, you should try the
39 button to make the system resume).
88 parameter), resume devices and thaw processes. If "platform" is written to
116 or resume its device (in the latter case the system may hang or become unstable
168 - if there are n modules loaded and the attempt to suspend and resume fails,
171 - if there are n modules loaded and the attempt to suspend and resume succeeds,
188 a hibernation image will be created and a resume from it will be triggered
191 That test can be used to check if failures to resume from hibernation are
193 works every time, but resume from actual hibernation does not work or is
[all …]
|
| H A D | runtime_pm.rst | 21 hibernation and resume from system sleep states). pm_wq is declared in
98 RAM until the appropriate resume callback is executed for it. The runtime
121 The subsystem-level resume callback, if present, is **entirely responsible** for
122 handling the resume of the device as appropriate, which may, but need not
125 callback in a device driver as long as the subsystem-level resume callback knows
128 * Once the subsystem-level resume callback (or the driver resume callback, if
134 * If the resume callback returns an error code, the PM core regards this as a
261 suspend to complete; means "start a resume as soon as you've suspended"
339 - execute the subsystem-level resume callback for the device; returns 0 on
343 be safe to attempt to resume the device again in future, but
[all …]
|
| H A D | userland-swsusp.rst | 16 are going to develop your own suspend/resume utilities.
26 assumed to be in the resume mode. The device cannot be open for simultaneous
49 from it (0) (after resume the system finds itself finishing the
81 allocate a swap page from the resume partition
90 set the resume partition and the offset (in <PAGE_SIZE>
94 containing the resume device specification and the offset); for swap
115 to resume the system from RAM if there's enough battery power or restore
137 snapshot image from/to the kernel will use a swap partition, called the resume
138 partition, or a swap file as storage space (if a swap file is used, the resume
|
| /linux/Documentation/admin-guide/pm/ |
| H A D | suspend-flows.rst | 23 working state is referred to as *system resume*.
25 The kernel code flows associated with the suspend and resume transitions for
34 resume hooks that need to be provided by the platform driver to make them
35 available. Apart from that, the suspend and resume code flows for these sleep
51 transition is about to occur and when the resume transition has finished.
65 put into uninterruptible sleep until the end of the subsequent system resume
74 resume, which can be much more precise than the freezing, so the latter is
93 deferred till the subsequent system resume transition as described
96 IRQs associated with system wakeup devices are "armed" so that the resume
115 system wakeup, in which case the system resume transition is started.
[all …]
|
| /linux/include/linux/ |
| H A D | pm.h | 81 * transition and during the subsequent resume if all of its descendants
84 * functioning of the device after the system resume.
87 * devices may be assumed to be functional or to respond to runtime resume
97 * all kinds of resume transitions, following one of the resume callbacks:
98 * @resume(), @thaw(), @restore(). Also called if the state transition
104 * the appropriate resume callbacks for all devices. If the corresponding
107 * executing any suspend and resume callbacks for it), @complete() will be
108 * the only callback executed for the device during resume. In that case,
110 * proper functioning of the device after the system resume. To this end,
112 * learn whether (unset) or not (set) the previous suspend and resume
[all …]
|
| /linux/sound/soc/sof/ |
| H A D | pm.c | 81 /* do nothing if dsp resume callbacks are not set */ in sof_resume()
82 if (!runtime_resume && !sof_ops(sdev)->resume) in sof_resume()
88 /* DSP was never successfully started, nothing to resume */ in sof_resume()
94 * or else call the system resume routine in sof_resume()
102 "error: failed to power up DSP after resume\n"); in sof_resume()
113 * D0 substate. Resume trace and return when resuming from in sof_resume()
122 "failed to enable trace after resume %d\n", ret); in sof_resume()
132 "error: failed to load DSP firmware after resume %d\n", in sof_resume()
147 "error: failed to boot DSP firmware after resume %d\n", in sof_resume()
153 /* resume DMA trace */ in sof_resume()
[all …]
|
| /linux/drivers/base/ |
| H A D | syscore.c | 79 if (ops->resume) in syscore_suspend()
80 ops->resume(); in syscore_suspend()
87 * syscore_resume - Execute all the registered system core resume callbacks.
97 "Interrupts enabled before system core resume.\n"); in syscore_resume()
100 if (ops->resume) { in syscore_resume()
101 pm_pr_dbg("Calling %pS\n", ops->resume); in syscore_resume()
102 ops->resume(); in syscore_resume()
104 "Interrupts enabled after %pS\n", ops->resume); in syscore_resume()
|
| /linux/Documentation/devicetree/bindings/arm/marvell/ |
| H A D | 98dx3236-resume-ctrl.txt | 1 Resume Control
7 - compatible: must be "marvell,98dx3336-resume-ctrl"
9 - reg: Should contain resume control registers location and length
13 resume@20980 {
14 compatible = "marvell,98dx3336-resume-ctrl";
|
| /linux/Documentation/driver-api/usb/ |
| H A D | power-management.rst | 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
75 asking the kernel to resume them, or even telling the entire computer
76 to resume. This capability goes by several names such as "Wake On
78 device is enabled for remote wakeup and it is suspended, it may resume
111 kernel will automatically resume the device (autoresume). For the
125 agent outside the USB stack: system suspend/resume (triggered by
126 userspace), manual dynamic resume (also triggered by userspace), and
248 try to resume them they disconnect themselves from the USB bus or
271 If a driver knows that its device has proper suspend/resume support,
[all …]
|
| /linux/Documentation/devicetree/bindings/arm/cpu-enable-method/ |
| H A D | al,alpine-smp | 17 "al,alpine-cpu-resume" and "al,alpine-nb-service".
20 * Alpine CPU resume registers
22 The CPU resume register are used to define required resume address after
26 - compatible : Should contain "al,alpine-cpu-resume".
63 compatible = "al,alpine-cpu-resume";
|
| /linux/Documentation/driver-api/pm/ |
| H A D | devices.rst | 42 by implementing various role-specific suspend and resume methods to
69 various role-specific suspend and resume methods, so that the hardware
119 The core methods to suspend and resume devices reside in
233 resume it by returning it to full power. The suspend and resume operations
238 matching resume calls would then completely reinitialize the hardware
251 used to resume those devices.
331 method must not update its state in case it is necessary to resume it
343 the subsequent device resume for all of these devices. In that case,
378 Namely, they may resume the devices from runtime suspend by
381 time (in case the drivers need to resume the devices from runtime
[all …]
|
| H A D | notifiers.rst | 14 before hibernation/suspend or after restore/resume, but they require the system
16 ``->resume()`` or even ``->prepare()`` and ``->complete()`` callbacks are not
20 resume/restore, but they cannot do it by calling :c:func:`request_firmware()`
21 from their ``->resume()`` or ``->complete()`` callback routines (user land
24 ``->resume()`` routine. A suspend/hibernation notifier may be used for that.
54 resume callbacks have been executed and tasks have been thawed.
|
| /linux/drivers/accel/ivpu/ |
| H A D | ivpu_pm.c | 92 ivpu_err(vdev, "Failed to resume MMU: %d\n", ret); in ivpu_resume()
112 ivpu_err(vdev, "Failed to resume the FW: %d\n", ret); in ivpu_resume()
137 ivpu_err(vdev, "Failed to resume NPU: %d\n", ret); in ivpu_pm_reset_complete()
249 trace_pm("resume"); in ivpu_pm_resume_cb()
250 ivpu_dbg(vdev, PM, "Resume..\n"); in ivpu_pm_resume_cb()
254 ivpu_err(vdev, "Failed to resume: %d\n", ret); in ivpu_pm_resume_cb()
256 ivpu_dbg(vdev, PM, "Resume done.\n"); in ivpu_pm_resume_cb()
257 trace_pm("resume done"); in ivpu_pm_resume_cb()
310 trace_pm("runtime resume"); in ivpu_pm_runtime_resume_cb()
311 ivpu_dbg(vdev, PM, "Runtime resume..\n"); in ivpu_pm_runtime_resume_cb()
[all …]
|
| /linux/Documentation/driver-api/ |
| H A D | device_link.rst | 23 suspend/resume and shutdown ordering.
28 types: It guarantees correct suspend/resume and shutdown ordering between a
35 suspend/resume and shutdown ordering is needed, the device link may
41 is instructed to runtime resume the supplier and keep it active
53 the midst of a suspend/resume transition, so either commencement of
56 not to run in parallel to a suspend/resume transition, such as from a
76 addition (e.g. exclusion of a parallel suspend/resume transition) apply equally
82 driver presence dependency is needed (but only correct suspend/resume and
88 can be specified to runtime resume the supplier and prevent it from suspending
172 and an NHI device to manage the PCIe switch. On resume from system sleep,
[all …]
|
| /linux/Documentation/ABI/testing/ |
| H A D | sysfs-devices-power | 59 enable or diasble the device's suspend and resume callbacks to
61 with the main suspend/resume thread) during system-wide power
67 + "enabled\n" to permit the asynchronous suspend/resume;
73 It generally is unsafe to permit the asynchronous suspend/resume
209 contains the PM QoS resume latency limit for the given device,
210 which is the maximum allowed time it can take to resume the
211 device, after it has been suspended at run time, from a resume
214 the PM QoS resume latency may be arbitrary and the special value
215 "n/a" means that user space cannot accept any resume latency at
221 This attribute has no effect on system-wide suspend/resume and
[all …]
|
| /linux/drivers/hid/intel-ish-hid/ipc/ |
| H A D | pci-ish.c | 103 * This function initialize wait queues for suspend/resume and call
261 /* 50ms to get resume response */
265 * ish_resume_handler() - Work function to complete resume
268 * The resume work function to complete resume function asynchronously.
269 * There are two resume paths, one where ISH is not powered off,
270 * in that case a simple resume message is enough, others we need
288 /* Waiting to get resume response */ in ish_resume_handler()
296 * So on resume, need to go through init sequence again. in ish_resume_handler()
302 * Resume from the D3, full reboot of ISH processor will happen, in ish_resume_handler()
343 * ISH into D3, and FW would reset on resume. in ish_suspend()
[all …]
|
| /linux/drivers/pinctrl/samsung/ |
| H A D | pinctrl-exynos-arm64.c | 222 .resume = exynos_pinctrl_resume,
231 .resume = exynos_pinctrl_resume,
239 .resume = exynos_pinctrl_resume,
247 .resume = exynos_pinctrl_resume,
255 .resume = exynos_pinctrl_resume,
263 .resume = exynos_pinctrl_resume,
271 .resume = exynos_pinctrl_resume,
279 .resume = exynos_pinctrl_resume,
287 .resume = exynos_pinctrl_resume,
295 .resume = exynos_pinctrl_resume,
[all …]
|
| /linux/drivers/usb/host/ |
| H A D | xhci-port.h | 87 * - U3 to Resume Wakeup signaling from a device
88 * - Resume to Recovery to U0 USB 3.0 device resume
89 * - Resume to U0 USB 2.0 device resume
90 * - U3 to Recovery to U0 Software resume of USB 3.0 device complete
91 * - U3 to U0 Software resume of USB 2.0 device complete
92 * - U2 to U0 L1 resume of USB 2.1 device complete
158 /* Set default HIRD/BESL value to 4 (350/400us) for USB2 L1 LPM resume latency.
164 * device's resume latency requirements,
|
| /linux/drivers/gpu/drm/xe/ |
| H A D | xe_bo_doc.h | 127 * Suspend / resume eviction of VRAM
130 * During device suspend / resume VRAM may lose power which means the contents
141 * TTM memcpy (CPU) to move any kernel (pinned) BO on either suspend or resume.
148 * Pinned external BOs in VRAM are restored on resume via the GPU.
150 * Rebinds after suspend / resume
153 * Most kernel BOs have GGTT mappings which must be restored during the resume
160 * resume. All we really need to save / restore via TTM memcpy is the memory
165 * the same physical address on resume. In all likelihood the only memory that
175 * Some kernel BOs do not need to be restored on resume (e.g. GuC ADS as that is
176 * repopulated on resume), add flag to mark such objects as no save / restore.
|
| /linux/include/uapi/linux/ |
| H A D | apm_bios.h | 123 #define APM_CAP_RESUME_STANDBY_TIMER 0x0004 /* Timer resume from standby */
124 #define APM_CAP_RESUME_SUSPEND_TIMER 0x0008 /* Timer resume from suspend */
125 #define APM_CAP_RESUME_STANDBY_RING 0x0010 /* Resume on Ring fr standby */
126 #define APM_CAP_RESUME_SUSPEND_RING 0x0020 /* Resume on Ring fr suspend */
127 #define APM_CAP_RESUME_STANDBY_PCMCIA 0x0040 /* Resume on PCMCIA Ring */
128 #define APM_CAP_RESUME_SUSPEND_PCMCIA 0x0080 /* Resume on PCMCIA Ring */
|
| /linux/kernel/power/ |
| H A D | console.c | 34 * @required: if true, caller needs VT switch at suspend/resume time
37 * suspend/resume, depending on how they handle restoring video state and
40 * Drivers can indicate support for switchless suspend/resume, which can
95 * There are three cases when a VT switch on suspend/resume are required:
99 * suspend/resume
104 * resume look a little prettier (and suspend too, but that's usually hidden,
|