diff options
author | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2012-02-01 10:08:15 +0000 |
---|---|---|
committer | Mark Brown <broonie@opensource.wolfsonmicro.com> | 2012-02-01 10:08:15 +0000 |
commit | 177f72fd101d512d938558b53cd4faa6a5434090 (patch) | |
tree | 1cfe58343c705f02c53886d7aa781b97b671b704 /Documentation/power/freezing-of-tasks.txt | |
parent | 761bfdd91184c6662a9233976e855b4ccb883c96 (diff) | |
parent | 62aa2b537c6f5957afd98e29f96897419ed5ebab (diff) | |
download | op-kernel-dev-177f72fd101d512d938558b53cd4faa6a5434090.zip op-kernel-dev-177f72fd101d512d938558b53cd4faa6a5434090.tar.gz |
Merge tag 'v3.3-rc2' into for-3.4
A reasonable amount of new development is causing fiddly merge conflicts
between different resource management changes (mostly fixing bugs in
resource management due to noticing things while doing enhancements in
the same area).
Linux 3.3-rc2
.. several days delayed. No reason, I just didn't think of it.
Diffstat (limited to 'Documentation/power/freezing-of-tasks.txt')
-rw-r--r-- | Documentation/power/freezing-of-tasks.txt | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt index 6ccb68f..ebd7490 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.txt @@ -120,10 +120,10 @@ So in practice, the 'at all' may become a 'why freeze kernel threads?' and freezing user threads I don't find really objectionable." Still, there are kernel threads that may want to be freezable. For example, if -a kernel that belongs to a device driver accesses the device directly, it in -principle needs to know when the device is suspended, so that it doesn't try to -access it at that time. However, if the kernel thread is freezable, it will be -frozen before the driver's .suspend() callback is executed and it will be +a kernel thread that belongs to a device driver accesses the device directly, it +in principle needs to know when the device is suspended, so that it doesn't try +to access it at that time. However, if the kernel thread is freezable, it will +be frozen before the driver's .suspend() callback is executed and it will be thawed after the driver's .resume() callback has run, so it won't be accessing the device while it's suspended. |