Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit ffffa4b5 authored by David Brownell's avatar David Brownell Committed by Len Brown
Browse files

PM: Remove obsolete /sys/devices/.../power/state docs 



The /sys/devices/.../power/state files have been gone for a while
now, but I just noticed some documentation that still refers to
them.  (Fortunately described as DEPRECATED and WILL REMOVE).

Time to remove that obsolete documentation too ...

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: default avatarPavel Machek <pavel@ucw.cz>
Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: default avatarLen Brown <len.brown@intel.com>
parent 5a0a2f30

Documentation/power/devices.txt

+0 −49
Original line number Diff line number Diff line
@@ -502,52 +502,3 @@ If the CPU can have a "cpufreq" driver, there also may be opportunities 
to shift to lower voltage settings and reduce the power cost of executing

a given number of instructions.  (Without voltage adjustment, it's rare

for cpufreq to save much power; the cost-per-instruction must go down.)
 




/sys/devices/.../power/state files

==================================

For now you can also test some of this functionality using sysfs.



	DEPRECATED:  USE "power/state" ONLY FOR DRIVER TESTING, AND

	AVOID USING dev->power.power_state IN DRIVERS.



	THESE WILL BE REMOVED.  IF THE "power/state" FILE GETS REPLACED,

	IT WILL BECOME SOMETHING COUPLED TO THE BUS OR DRIVER.



In each device's directory, there is a 'power' directory, which contains

at least a 'state' file.  The value of this field is effectively boolean,

PM_EVENT_ON or PM_EVENT_SUSPEND.



   *	Reading from this file displays a value corresponding to

	the power.power_state.event field.  All nonzero values are

	displayed as "2", corresponding to a low power state; zero

	is displayed as "0", corresponding to normal operation.



   *	Writing to this file initiates a transition using the

   	specified event code number; only '0', '2', and '3' are

	accepted (without a newline); '2' and '3' are both

	mapped to PM_EVENT_SUSPEND.



On writes, the PM core relies on that recorded event code and the device/bus

capabilities to determine whether it uses a partial suspend() or resume()

sequence to change things so that the recorded event corresponds to the

numeric parameter.



   -	If the bus requires the irqs-disabled suspend_late()/resume_early()

	phases, writes fail because those operations are not supported here.



   -	If the recorded value is the expected value, nothing is done.



   -	If the recorded value is nonzero, the device is partially resumed,

	using the bus.resume() and/or class.resume() methods.



   -	If the target value is nonzero, the device is partially suspended,

	using the class.suspend() and/or bus.suspend() methods and the

	PM_EVENT_SUSPEND message.



Drivers have no way to tell whether their suspend() and resume() calls

have come through the sysfs power/state file or as part of entering a

system sleep state, except that when accessed through sysfs the normal

parent/child sequencing rules are ignored.  Drivers (such as bus, bridge,

or hub drivers) which expose child devices may need to enforce those rules

on their own.