diff options
-rw-r--r-- | Documentation/power/devices.txt | 49 |
1 files changed, 0 insertions, 49 deletions
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index d0e79d5820a5..c53d26361919 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt | |||
@@ -502,52 +502,3 @@ If the CPU can have a "cpufreq" driver, there also may be opportunities | |||
502 | to shift to lower voltage settings and reduce the power cost of executing | 502 | to shift to lower voltage settings and reduce the power cost of executing |
503 | a given number of instructions. (Without voltage adjustment, it's rare | 503 | a given number of instructions. (Without voltage adjustment, it's rare |
504 | for cpufreq to save much power; the cost-per-instruction must go down.) | 504 | for cpufreq to save much power; the cost-per-instruction must go down.) |
505 | |||
506 | |||
507 | /sys/devices/.../power/state files | ||
508 | ================================== | ||
509 | For now you can also test some of this functionality using sysfs. | ||
510 | |||
511 | DEPRECATED: USE "power/state" ONLY FOR DRIVER TESTING, AND | ||
512 | AVOID USING dev->power.power_state IN DRIVERS. | ||
513 | |||
514 | THESE WILL BE REMOVED. IF THE "power/state" FILE GETS REPLACED, | ||
515 | IT WILL BECOME SOMETHING COUPLED TO THE BUS OR DRIVER. | ||
516 | |||
517 | In each device's directory, there is a 'power' directory, which contains | ||
518 | at least a 'state' file. The value of this field is effectively boolean, | ||
519 | PM_EVENT_ON or PM_EVENT_SUSPEND. | ||
520 | |||
521 | * Reading from this file displays a value corresponding to | ||
522 | the power.power_state.event field. All nonzero values are | ||
523 | displayed as "2", corresponding to a low power state; zero | ||
524 | is displayed as "0", corresponding to normal operation. | ||
525 | |||
526 | * Writing to this file initiates a transition using the | ||
527 | specified event code number; only '0', '2', and '3' are | ||
528 | accepted (without a newline); '2' and '3' are both | ||
529 | mapped to PM_EVENT_SUSPEND. | ||
530 | |||
531 | On writes, the PM core relies on that recorded event code and the device/bus | ||
532 | capabilities to determine whether it uses a partial suspend() or resume() | ||
533 | sequence to change things so that the recorded event corresponds to the | ||
534 | numeric parameter. | ||
535 | |||
536 | - If the bus requires the irqs-disabled suspend_late()/resume_early() | ||
537 | phases, writes fail because those operations are not supported here. | ||
538 | |||
539 | - If the recorded value is the expected value, nothing is done. | ||
540 | |||
541 | - If the recorded value is nonzero, the device is partially resumed, | ||
542 | using the bus.resume() and/or class.resume() methods. | ||
543 | |||
544 | - If the target value is nonzero, the device is partially suspended, | ||
545 | using the class.suspend() and/or bus.suspend() methods and the | ||
546 | PM_EVENT_SUSPEND message. | ||
547 | |||
548 | Drivers have no way to tell whether their suspend() and resume() calls | ||
549 | have come through the sysfs power/state file or as part of entering a | ||
550 | system sleep state, except that when accessed through sysfs the normal | ||
551 | parent/child sequencing rules are ignored. Drivers (such as bus, bridge, | ||
552 | or hub drivers) which expose child devices may need to enforce those rules | ||
553 | on their own. | ||