Lines Matching refs:it

10 II. How does it work?
23 sets this variable.  After this, it executes try_to_freeze_tasks() that sends a
28 it loop until PF_FROZEN is cleared for it. Then, we say that the task is
39 signal-handling code, but the freezable kernel threads need to call it
92 directly is not allowed).  From this point it is regarded as freezable
145 a kernel thread that belongs to a device driver accesses the device directly, it
146 in principle needs to know when the device is suspended, so that it doesn't try
147 to access it at that time.  However, if the kernel thread is freezable, it will
148 be frozen before the driver's .suspend() callback is executed and it will be
149 thawed after the driver's .resume() callback has run, so it won't be accessing
150 the device while it's suspended.
158 that depends on all CPUs being online while it's running.  Since we need to
159 disable nonboot CPUs during the hibernation, if this process is not frozen, it
177 userspace, it gets even more complicated because some userspace processes are
181 The problem 1. seems to be fixable, although it hasn't been fixed so far.  The
182 other one is more serious, but it seems that we can work around it by using
188 they are not directly related to it.  For example, if request_firmware() is
189 called from a device driver's .resume() routine, it will timeout and eventually
196 tasks, since it generally exists anyway.
198 A driver must have all firmwares it may need in RAM before suspend() is called.
213 it is strongly discouraged to directly call mutex_[un]lock(&pm_mutex) since
221 since they ask the freezer to skip freezing this task, since it is anyway
222 "frozen enough" as it is blocked on 'pm_mutex', which will be released
228 /sys/power/pm_freeze_timeout controls how long it will cost at most to freeze