PM / Runtime: Add sysfs switch for disabling device run-time PM

Quoted 8 lines · Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).

Ouch. This does nearly the same thing as the power/level attribute in the USB subsystem, but in an incompatible and more complicated way.

Is there any reason this same mechanism shouldn't be used for all devices?

Alan Stern

Rafael J. Wysocki

author

2010-01-18 22:25 UTC #3 lore raw

RFC PATCH 1/1 PM / Runtime: Add sysfs switch for disabling device run-time PM

Quoted 11 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).

Quoted 6 lines

Ouch. This does nearly the same thing as the power/level attribute in the USB subsystem, but in an incompatible and more complicated way.
The power/level attribute can contain either "on" or "auto", meaning that the device is always on or that it is subject to automatic runtime power management (autosuspend).

It looks like my "disable" is similar to "on", while my "enable" is similar to "auto". I can use "auto" and "on" just fine.

Quoted 3 lines

Changing the setting from "auto" to "on" merely does sets a flag and does pm_runtime_get_sync(); changing it from "on" to "auto" clears the flag and does pm_runtime_put_sync().

We can do it almost this way in general, although I think the flag should be changed under the power.lock.

Updated patch is appended.

Rafael

---
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM

Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules).

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/power.h   |    4 +++
 drivers/base/power/runtime.c |   43 ++++++++++++++++++++++++++++++++++++
 drivers/base/power/sysfs.c   |   50 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm.h           |    1 
 4 files changed, 98 insertions(+)

drivers/base/power/power.h +4 -0

Index: linux-2.6/drivers/base/power/power.h
===================================================================
@@ -2,11 +2,15 @@
 
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
 
 #else /* !CONFIG_PM_RUNTIME */
 
 static inline void pm_runtime_init(struct device *dev) {}
 static inline void pm_runtime_remove(struct device *dev) {}
+static inline void pm_runtime_allow(struct device *dev) {}
+static inline void pm_runtime_forbid(struct device *dev) {}
 
 #endif /* !CONFIG_PM_RUNTIME */

drivers/base/power/sysfs.c +50 -0

68 lines not on this page · raw message

include/linux/pm.h +1 -0

Index: linux-2.6/include/linux/pm.h
===================================================================
@@ -433,6 +433,7 @@ struct dev_pm_info {
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
 	unsigned int		run_wake:1;
+	unsigned int		runtime_auto:1;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;

drivers/base/power/runtime.c +43 -0

55 lines not on this page · raw message

Alan Stern

2010-01-19 15:40 UTC #4 lore raw

Quoted 9 lines · Rafael J. Wysocki

Quoted 6 lines
Ouch. This does nearly the same thing as the power/level attribute in the USB subsystem, but in an incompatible and more complicated way.
The power/level attribute can contain either "on" or "auto", meaning that the device is always on or that it is subject to automatic runtime power management (autosuspend).
It looks like my "disable" is similar to "on", while my "enable" is similar to "auto". I can use "auto" and "on" just fine.

Good.

Quoted 6 lines

Quoted 3 lines
Changing the setting from "auto" to "on" merely does sets a flag and does pm_runtime_get_sync(); changing it from "on" to "auto" clears the flag and does pm_runtime_put_sync().
We can do it almost this way in general, although I think the flag should be changed under the power.lock.

Yes. I was using the device semaphore, but the power.lock is more appropriate here.

Quoted 1 line

Updated patch is appended.

Why change the name from "level" to "runtime"?

Quoted 9 lines

/*
+ * runtime - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/runtime file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managemed at run time;

---------------------------------------------------------------^^ typo

Don't forget to add an entry to Documentation/ABI/testing/.

Alan Stern

2010-01-19 15:40 UTC #5 lore raw

Quoted 9 lines · Rafael J. Wysocki

Quoted 6 lines
Ouch. This does nearly the same thing as the power/level attribute in the USB subsystem, but in an incompatible and more complicated way.
The power/level attribute can contain either "on" or "auto", meaning that the device is always on or that it is subject to automatic runtime power management (autosuspend).
It looks like my "disable" is similar to "on", while my "enable" is similar to "auto". I can use "auto" and "on" just fine.

Good.

Quoted 6 lines

Quoted 3 lines
Changing the setting from "auto" to "on" merely does sets a flag and does pm_runtime_get_sync(); changing it from "on" to "auto" clears the flag and does pm_runtime_put_sync().
We can do it almost this way in general, although I think the flag should be changed under the power.lock.

Yes. I was using the device semaphore, but the power.lock is more appropriate here.

Quoted 1 line

Updated patch is appended.

Why change the name from "level" to "runtime"?

Quoted 9 lines

/*
+ * runtime - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/runtime file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managemed at run time;

---------------------------------------------------------------^^ typo

Don't forget to add an entry to Documentation/ABI/testing/.

Alan Stern

Rafael J. Wysocki

author

2010-01-19 20:32 UTC #6 lore raw

Quoted 21 lines · Alan Stern

Quoted 9 lines · Rafael J. Wysocki
Quoted 6 lines
Ouch. This does nearly the same thing as the power/level attribute in the USB subsystem, but in an incompatible and more complicated way.
The power/level attribute can contain either "on" or "auto", meaning that the device is always on or that it is subject to automatic runtime power management (autosuspend).
It looks like my "disable" is similar to "on", while my "enable" is similar to "auto". I can use "auto" and "on" just fine.
Good.
Quoted 6 lines
Quoted 3 lines
Changing the setting from "auto" to "on" merely does sets a flag and does pm_runtime_get_sync(); changing it from "on" to "auto" clears the flag and does pm_runtime_put_sync().
We can do it almost this way in general, although I think the flag should be changed under the power.lock.

Quoted 6 lines

Yes. I was using the device semaphore, but the power.lock is more appropriate here.
Quoted 1 line
Updated patch is appended.
Why change the name from "level" to "runtime"?

Because it wouldn't be really obvious what "level" applied to. For example, some people might expect the values of "level" to correspond to PCI power states for PCI devices and so on, so it might turn out to be confusing.

Quoted 11 lines

Quoted 9 lines
/*
+ * runtime - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/runtime file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managemed at run time;
---------------------------------------------------------------^^ typo

Ah, thanks

Quoted 1 line

Don't forget to add an entry to Documentation/ABI/testing/.

Rafael

Rafael J. Wysocki

author

2010-01-19 23:26 UTC #7 lore raw

Quoted 2 lines · Rafael J. Wysocki

Quoted 1 line · Alan Stern
On Mon, 18 Jan 2010, Rafael J. Wysocki wrote:

...

Quoted 3 lines

Quoted 1 line
Don't forget to add an entry to Documentation/ABI/testing/.
OK

Actually, not in this patch.

There doesn't seem to be room for the /sys/devices/.../power/* attributes at all right now and I don't think this particular patch is the right one for adding them all.

Rafael

Rafael J. Wysocki

author

2010-01-19 23:27 UTC #8 lore raw

Quoted 2 lines · Rafael J. Wysocki

Quoted 1 line · Alan Stern
On Mon, 18 Jan 2010, Rafael J. Wysocki wrote:

...

Quoted 3 lines

Quoted 1 line
Don't forget to add an entry to Documentation/ABI/testing/.
OK

Actually, not in this patch.

There doesn't seem to be room for the /sys/devices/.../power/* attributes at all right now and I don't think this particular patch is the right one for adding them all.

Rafael

Alan Stern

2010-01-20 15:09 UTC #9 lore raw

Quoted 5 lines · Rafael J. Wysocki

Quoted 1 line
Why change the name from "level" to "runtime"?
Because it wouldn't be really obvious what "level" applied to. For example, some people might expect the values of "level" to correspond to PCI power states for PCI devices and so on, so it might turn out to be confusing.

But is the name "runtime" any clearer? Especially to people who have never come across the phrase "runtime power management"?

Does anybody have a suggestion for a better attribute name?

Alan Stern

2010-01-20 15:09 UTC #10 lore raw

Quoted 5 lines · Rafael J. Wysocki

Quoted 1 line
Why change the name from "level" to "runtime"?
Because it wouldn't be really obvious what "level" applied to. For example, some people might expect the values of "level" to correspond to PCI power states for PCI devices and so on, so it might turn out to be confusing.

But is the name "runtime" any clearer? Especially to people who have never come across the phrase "runtime power management"?

Does anybody have a suggestion for a better attribute name?

Alan Stern

Rafael J. Wysocki

author

2010-01-20 21:09 UTC #11 lore raw

Quoted 4 lines · Alan Stern

Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line
Why change the name from "level" to "runtime"?

Quoted 8 lines

Quoted 3 lines
Because it wouldn't be really obvious what "level" applied to. For example, some people might expect the values of "level" to correspond to PCI power states for PCI devices and so on, so it might turn out to be confusing.
But is the name "runtime" any clearer? Especially to people who have never come across the phrase "runtime power management"?
Does anybody have a suggestion for a better attribute name?

Apparently not, but I can try. ;-)

* status

* power (power/power looks weird, but the values would make sense)

* control

No more ideas for now.

Rafael

Alan Stern

2010-01-20 21:37 UTC #12 lore raw

Quoted 11 lines · Rafael J. Wysocki

Quoted 1 line
Does anybody have a suggestion for a better attribute name?
Apparently not, but I can try. ;-)
* status
* power (power/power looks weird, but the values would make sense)
* control
No more ideas for now.

I vote for "control".

Alan Stern

2010-01-20 21:37 UTC #13 lore raw

Quoted 11 lines · Rafael J. Wysocki

Quoted 1 line
Does anybody have a suggestion for a better attribute name?
Apparently not, but I can try. ;-)
* status
* power (power/power looks weird, but the values would make sense)
* control
No more ideas for now.

I vote for "control".

Alan Stern

Rafael J. Wysocki

author

2010-01-20 22:17 UTC #14 lore raw

Quoted 8 lines · Alan Stern

Quoted 6 lines · Rafael J. Wysocki
Quoted 1 line
Does anybody have a suggestion for a better attribute name?
Apparently not, but I can try. ;-)
* status

Quoted 7 lines

Quoted 5 lines
* power (power/power looks weird, but the values would make sense)
* control
No more ideas for now.
I vote for "control".

OK, if no one objects, I'll use that in the next "release" of the patch.

Rafael

Rafael J. Wysocki

author

2010-01-20 22:17 UTC #15 lore raw

Quoted 8 lines · Alan Stern

Quoted 6 lines · Rafael J. Wysocki
Quoted 1 line
Does anybody have a suggestion for a better attribute name?
Apparently not, but I can try. ;-)
* status

Quoted 7 lines

Quoted 5 lines
* power (power/power looks weird, but the values would make sense)
* control
No more ideas for now.
I vote for "control".

OK, if no one objects, I'll use that in the next "release" of the patch.

Rafael

Rafael J. Wysocki

author

2010-01-20 21:09 UTC #16 lore raw

Quoted 4 lines · Alan Stern

Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line
Why change the name from "level" to "runtime"?

Quoted 8 lines

Quoted 3 lines
Because it wouldn't be really obvious what "level" applied to. For example, some people might expect the values of "level" to correspond to PCI power states for PCI devices and so on, so it might turn out to be confusing.
But is the name "runtime" any clearer? Especially to people who have never come across the phrase "runtime power management"?
Does anybody have a suggestion for a better attribute name?

Apparently not, but I can try. ;-)

* status

* power (power/power looks weird, but the values would make sense)

* control

No more ideas for now.

Rafael

Rafael J. Wysocki

author

2010-01-19 20:32 UTC #17 lore raw

Quoted 21 lines · Alan Stern

Quoted 9 lines · Rafael J. Wysocki
Quoted 6 lines
Ouch. This does nearly the same thing as the power/level attribute in the USB subsystem, but in an incompatible and more complicated way.
The power/level attribute can contain either "on" or "auto", meaning that the device is always on or that it is subject to automatic runtime power management (autosuspend).
It looks like my "disable" is similar to "on", while my "enable" is similar to "auto". I can use "auto" and "on" just fine.
Good.
Quoted 6 lines
Quoted 3 lines
Changing the setting from "auto" to "on" merely does sets a flag and does pm_runtime_get_sync(); changing it from "on" to "auto" clears the flag and does pm_runtime_put_sync().
We can do it almost this way in general, although I think the flag should be changed under the power.lock.

Quoted 6 lines

Yes. I was using the device semaphore, but the power.lock is more appropriate here.
Quoted 1 line
Updated patch is appended.
Why change the name from "level" to "runtime"?

Quoted 11 lines

Quoted 9 lines
/*
+ * runtime - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/runtime file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managemed at run time;
---------------------------------------------------------------^^ typo

Ah, thanks

Quoted 1 line

Don't forget to add an entry to Documentation/ABI/testing/.

Rafael

Rafael J. Wysocki

author

2010-01-18 22:25 UTC #18 lore raw

RFC PATCH 1/1 PM / Runtime: Add sysfs switch for disabling device run-time PM

Quoted 11 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).

Quoted 6 lines

Ouch. This does nearly the same thing as the power/level attribute in the USB subsystem, but in an incompatible and more complicated way.
The power/level attribute can contain either "on" or "auto", meaning that the device is always on or that it is subject to automatic runtime power management (autosuspend).

It looks like my "disable" is similar to "on", while my "enable" is similar to "auto". I can use "auto" and "on" just fine.

Quoted 3 lines

Changing the setting from "auto" to "on" merely does sets a flag and does pm_runtime_get_sync(); changing it from "on" to "auto" clears the flag and does pm_runtime_put_sync().

We can do it almost this way in general, although I think the flag should be changed under the power.lock.

Updated patch is appended.

Rafael

---
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/power.h   |    4 +++
 drivers/base/power/runtime.c |   43 ++++++++++++++++++++++++++++++++++++
 drivers/base/power/sysfs.c   |   50 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm.h           |    1 
 4 files changed, 98 insertions(+)

drivers/base/power/power.h +4 -0

Index: linux-2.6/drivers/base/power/power.h
===================================================================
@@ -2,11 +2,15 @@
 
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
 
 #else /* !CONFIG_PM_RUNTIME */
 
 static inline void pm_runtime_init(struct device *dev) {}
 static inline void pm_runtime_remove(struct device *dev) {}
+static inline void pm_runtime_allow(struct device *dev) {}
+static inline void pm_runtime_forbid(struct device *dev) {}
 
 #endif /* !CONFIG_PM_RUNTIME */

drivers/base/power/sysfs.c +50 -0

68 lines not on this page · raw message

include/linux/pm.h +1 -0

Index: linux-2.6/include/linux/pm.h
===================================================================
@@ -433,6 +433,7 @@ struct dev_pm_info {
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
 	unsigned int		run_wake:1;
+	unsigned int		runtime_auto:1;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;

drivers/base/power/runtime.c +43 -0

55 lines not on this page · raw message

Greg KH

2010-01-20 02:51 UTC #19 lore raw

Quoted 9 lines · Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).

Quoted 8 lines

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/power.h   |    4 +
 drivers/base/power/runtime.c |  107 +++++++++++++++++++++++++++++++++----------
 drivers/base/power/sysfs.c   |   46 ++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |   11 +---
 5 files changed, 139 insertions(+), 30 deletions(-)

You forgot to also add an entry into Documentation/ABI/ for when you add/change a sysfs file :)

thanks,

greg k-h

Greg KH

2010-01-20 03:18 UTC #20 lore raw

Quoted 9 lines · Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).

Quoted 8 lines

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/power.h   |    4 +
 drivers/base/power/runtime.c |  107 +++++++++++++++++++++++++++++++++----------
 drivers/base/power/sysfs.c   |   46 ++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |   11 +---
 5 files changed, 139 insertions(+), 30 deletions(-)

You forgot to also add an entry into Documentation/ABI/ for when you add/change a sysfs file :)

thanks,

greg k-h

Rafael J. Wysocki

author

2010-01-20 20:55 UTC #21 lore raw

Quoted 19 lines · Greg KH

Quoted 9 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).
Quoted 8 lines
Signed-off-by Rafael J. Wysocki <[email protected]>
---
 drivers/base/power/power.h   |    4 +
 drivers/base/power/runtime.c |  107 +++++++++++++++++++++++++++++++++----------
 drivers/base/power/sysfs.c   |   46 ++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |   11 +---
 5 files changed, 139 insertions(+), 30 deletions(-)

Quoted 2 lines

You forgot to also add an entry into Documentation/ABI/ for when you add/change a sysfs file :)

There's no description for /sys/devices/.../power/wakeup in there too and that one has been present for quite some time already.

I'd prefer adding them both in a separate patch if you don't mind.

Rafael

Greg KH

2010-01-20 22:50 UTC #22 lore raw

Quoted 20 lines · Rafael J. Wysocki

Quoted 19 lines · Greg KH
Quoted 17 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).
Signed-off-by Rafael J. Wysocki <[email protected]>
---
 drivers/base/power/power.h   |    4 +
 drivers/base/power/runtime.c |  107 +++++++++++++++++++++++++++++++++----------
 drivers/base/power/sysfs.c   |   46 ++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |   11 +---
 5 files changed, 139 insertions(+), 30 deletions(-)

Quoted 7 lines

Quoted 2 lines
You forgot to also add an entry into Documentation/ABI/ for when you add/change a sysfs file :)
There's no description for /sys/devices/.../power/wakeup in there too and that one has been present for quite some time already.
I'd prefer adding them both in a separate patch if you don't mind.

That's fine with me, as long as you add them :)

thanks,

greg k-h

Greg KH

2010-01-20 22:56 UTC #23 lore raw

Quoted 20 lines · Rafael J. Wysocki

Quoted 19 lines · Greg KH
Quoted 17 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).
Signed-off-by Rafael J. Wysocki <[email protected]>
---
 drivers/base/power/power.h   |    4 +
 drivers/base/power/runtime.c |  107 +++++++++++++++++++++++++++++++++----------
 drivers/base/power/sysfs.c   |   46 ++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |   11 +---
 5 files changed, 139 insertions(+), 30 deletions(-)

Quoted 7 lines

Quoted 2 lines
You forgot to also add an entry into Documentation/ABI/ for when you add/change a sysfs file :)
There's no description for /sys/devices/.../power/wakeup in there too and that one has been present for quite some time already.
I'd prefer adding them both in a separate patch if you don't mind.

That's fine with me, as long as you add them :)

thanks,

greg k-h

Rafael J. Wysocki

author

2010-01-20 20:55 UTC #24 lore raw

In reply to Greg KH

Quoted 19 lines · Greg KH

Quoted 9 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM
Add new device sysfs attribute, power/runtime, allowing the user space to block the run-time power management of the device. If this attribute is set to "disabled", the driver of the device won't be able to enable run-time power management for it (without breaking the rules).
Quoted 8 lines
Signed-off-by Rafael J. Wysocki <[email protected]>
---
 drivers/base/power/power.h   |    4 +
 drivers/base/power/runtime.c |  107 +++++++++++++++++++++++++++++++++----------
 drivers/base/power/sysfs.c   |   46 ++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |   11 +---
 5 files changed, 139 insertions(+), 30 deletions(-)

Quoted 2 lines

You forgot to also add an entry into Documentation/ABI/ for when you add/change a sysfs file :)

There's no description for /sys/devices/.../power/wakeup in there too and that one has been present for quite some time already.

I'd prefer adding them both in a separate patch if you don't mind.

Rafael

Rafael J. Wysocki

author

2010-01-21 22:57 UTC #25 lore raw

cover sysfs switch for disabling device run-time PM

Hi,

The first of the following two patches adds a sysfs switch for controlling the run-time power management of devices and the second one documents the sysfs attributes in /sys/devices/.../power/ (including the new one).

Thanks,
Rafael

Rafael J. Wysocki

author

2010-01-21 23:01 UTC #26 lore raw

cover sysfs switch for disabling device run-time PM

Hi,

Thanks,
Rafael

Rafael J. Wysocki

author

2010-01-21 22:59 UTC #27 lore raw

PATCH 1/2 PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

From: Rafael J. Wysocki <[email protected]>

Add new device sysfs attribute, power/control, allowing the user space to block the run-time power management of devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules) and the device will always be in the full power state (except when the entire system goes into a sleep state).

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/power.h   |    4 +++
 drivers/base/power/runtime.c |   43 ++++++++++++++++++++++++++++++++++++
 drivers/base/power/sysfs.c   |   50 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm.h           |    1 
 4 files changed, 98 insertions(+)

drivers/base/power/power.h +4 -0

Index: linux-2.6/drivers/base/power/power.h
===================================================================
@@ -2,11 +2,15 @@
 
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
 
 #else /* !CONFIG_PM_RUNTIME */
 
 static inline void pm_runtime_init(struct device *dev) {}
 static inline void pm_runtime_remove(struct device *dev) {}
+static inline void pm_runtime_allow(struct device *dev) {}
+static inline void pm_runtime_forbid(struct device *dev) {}
 
 #endif /* !CONFIG_PM_RUNTIME */

drivers/base/power/sysfs.c +50 -0

68 lines not on this page · raw message

include/linux/pm.h +1 -0

Index: linux-2.6/include/linux/pm.h
===================================================================
@@ -433,6 +433,7 @@ struct dev_pm_info {
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
 	unsigned int		run_wake:1;
+	unsigned int		runtime_auto:1;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;

drivers/base/power/runtime.c +43 -0

55 lines not on this page · raw message

Rafael J. Wysocki

author

2010-01-21 23:01 UTC #28 lore raw

PATCH 1/2 PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

From: Rafael J. Wysocki <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/power.h   |    4 +++
 drivers/base/power/runtime.c |   43 ++++++++++++++++++++++++++++++++++++
 drivers/base/power/sysfs.c   |   50 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm.h           |    1 
 4 files changed, 98 insertions(+)

drivers/base/power/power.h +4 -0

Index: linux-2.6/drivers/base/power/power.h
===================================================================
@@ -2,11 +2,15 @@
 
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
 
 #else /* !CONFIG_PM_RUNTIME */
 
 static inline void pm_runtime_init(struct device *dev) {}
 static inline void pm_runtime_remove(struct device *dev) {}
+static inline void pm_runtime_allow(struct device *dev) {}
+static inline void pm_runtime_forbid(struct device *dev) {}
 
 #endif /* !CONFIG_PM_RUNTIME */

drivers/base/power/sysfs.c +50 -0

68 lines not on this page · raw message

include/linux/pm.h +1 -0

Index: linux-2.6/include/linux/pm.h
===================================================================
@@ -433,6 +433,7 @@ struct dev_pm_info {
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
 	unsigned int		run_wake:1;
+	unsigned int		runtime_auto:1;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;

drivers/base/power/runtime.c +43 -0

55 lines not on this page · raw message

Alan Stern

2010-01-22 03:02 UTC #29 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 8 lines · Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>
Add new device sysfs attribute, power/control, allowing the user space to block the run-time power management of devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules) and the device will always be in the full power state (except when the entire system goes into a sleep state).

...

drivers/base/power/power.h line 6

Quoted 8 lines

drivers/base/power/power.h +2 -0

@@ -2,11 +2,15 @@
 
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);

Can you write a follow-up patch that moves these declarations to a public header file like include/linux/pm_runtime.h and EXPORTs the two new routines? It is sometimes useful for drivers to be able to call the routines directly.

For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.

Alan Stern

2010-01-22 03:02 UTC #30 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 8 lines · Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>
Add new device sysfs attribute, power/control, allowing the user space to block the run-time power management of devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules) and the device will always be in the full power state (except when the entire system goes into a sleep state).

...

drivers/base/power/power.h line 6

Quoted 8 lines

drivers/base/power/power.h +2 -0

@@ -2,11 +2,15 @@
 
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);

Alan Stern

Rafael J. Wysocki

author

2010-01-22 20:55 UTC #31 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 17 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Add new device sysfs attribute, power/control, allowing the user space to block the run-time power management of devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules) and the device will always be in the full power state (except when the entire system goes into a sleep state).
...
Quoted 4 lines
drivers/base/power/power.h +0 -0
@@ -2,11 +2,15 @@
 

Quoted 9 lines

drivers/base/power/power.h line 6
Quoted 4 lines
drivers/base/power/power.h +2 -0
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
Can you write a follow-up patch that moves these declarations to a public header file like include/linux/pm_runtime.h and EXPORTs the two new routines? It is sometimes useful for drivers to be able to call the routines directly.

I can put them in there in this patch just as well, but I'm not sure it's the right thing to do.

Quoted 3 lines

For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.

Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.

IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.

Rafael

Alan Stern

2010-01-22 22:45 UTC #32 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Rafael J. Wysocki

Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.

Okay, I understand your point of view. It means I'll have to make some changes to the USB code. No problem.

Alan Stern

2010-01-22 22:45 UTC #33 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Rafael J. Wysocki

Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.

Okay, I understand your point of view. It means I'll have to make some changes to the USB code. No problem.

Alan Stern

Rafael J. Wysocki

author

2010-01-22 22:55 UTC #34 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.

Quoted 5 lines

Quoted 2 lines
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.
Okay, I understand your point of view. It means I'll have to make some changes to the USB code. No problem.

Great, thanks a lot.

Rafael

Rafael J. Wysocki

author

2010-01-22 22:55 UTC #35 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.

Quoted 5 lines

Quoted 2 lines
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.
Okay, I understand your point of view. It means I'll have to make some changes to the USB code. No problem.

Great, thanks a lot.

Rafael

Alan Stern

2010-01-23 03:22 UTC #36 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Rafael J. Wysocki

Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.

After more thought, I changed my mind about this. The ability to override the driver's choice means that the user should be able to enable runtime PM even if the driver tries to disable it, as well as the other way 'round.

In other words, it's not productive to say the user is the owner of the runtime_auto flag. What we _really_ want is to put the user in charge of whether or not a device is subject to runtime PM.

First of all, note that if the driver doesn't support runtime PM then it makes no difference what value runtime_auto has. The issue is moot.

So suppose the driver does support runtime PM. In this case, it's irrelevant that runtime PM starts out disabled by default when the device structure is initialized. The bus subsystem and driver will reinitialize the settings in the way they think best.

But if the driver decides to disable runtime PM and pm_runtime_forbid() isn't EXPORTed, then the driver will be forced to implement its decision by leaving disable_depth > 0 -- which means there's nothing the user can do. The power/control attribute won't help. On the other hand, if the driver decides to disable runtime PM and it can do so by calling pm_runtime_forbid(), then the user can override the decision.

Alan Stern

2010-01-23 03:22 UTC #37 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Rafael J. Wysocki

Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.

In other words, it's not productive to say the user is the owner of the runtime_auto flag. What we _really_ want is to put the user in charge of whether or not a device is subject to runtime PM.

First of all, note that if the driver doesn't support runtime PM then it makes no difference what value runtime_auto has. The issue is moot.

Alan Stern

Rafael J. Wysocki

author

2010-01-23 12:14 UTC #38 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 30 lines · Alan Stern

Quoted 10 lines · Rafael J. Wysocki
Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.
After more thought, I changed my mind about this. The ability to override the driver's choice means that the user should be able to enable runtime PM even if the driver tries to disable it, as well as the other way 'round.
In other words, it's not productive to say the user is the owner of the runtime_auto flag. What we _really_ want is to put the user in charge of whether or not a device is subject to runtime PM.
First of all, note that if the driver doesn't support runtime PM then it makes no difference what value runtime_auto has. The issue is moot.
So suppose the driver does support runtime PM. In this case, it's irrelevant that runtime PM starts out disabled by default when the device structure is initialized. The bus subsystem and driver will reinitialize the settings in the way they think best.

Quoted 6 lines

But if the driver decides to disable runtime PM and pm_runtime_forbid() isn't EXPORTed, then the driver will be forced to implement its decision by leaving disable_depth > 0 -- which means there's nothing the user can do. The power/control attribute won't help. On the other hand, if the driver decides to disable runtime PM and it can do so by calling pm_runtime_forbid(), then the user can override the decision.

Hmm, OK.

Of course, if the driver decides to leave disable_depth > 0, the user still won't be able to do anything about that, but if I understand correctly, you want drivers to have the option to use pm_runtime_forbid() initially, right after pm_runtime_enable(), so that the user space can turn the runtime PM on if desired via sysfs.

That makes sense. I have a usage case for that myself. :-)

Updated patch is appended.

Rafael

---
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM

Add new device sysfs attribute, power/control, allowing the user space to block the run-time power management of the devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules) and the device will always be in the full power state (except when the entire system goes into a sleep state).

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/runtime.c |   45 +++++++++++++++++++++++++++++++++++++
 drivers/base/power/sysfs.c   |   51 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |    4 +++
 4 files changed, 101 insertions(+)

drivers/base/power/sysfs.c +51 -0

Index: linux-2.6/drivers/base/power/sysfs.c
===================================================================
@@ -4,9 +4,25 @@
 
 #include <linux/device.h>
 #include <linux/string.h>
+#include <linux/pm_runtime.h>
 #include "power.h"
 
 /*
+ *	control - Report/change current runtime PM setting of the device
+ *
+ *	Runtime power management of a device can be blocked with the help of
+ *	this attribute.  All devices have one of the following two values for
+ *	the power/control file:
+ *
+ *	 + "auto\n" to allow the device to be power managed at run time;
+ *	 + "on\n" to prevent the device from being power managed at run time;
+ *
+ *	The default for all devices is "auto", which means that devices may be
+ *	subject to automatic power management, depending on their drivers.
+ *	Changing this attribute to "on" prevents the driver from power managing
+ *	the device at run time.  Doing that while the device is suspended causes
+ *	it to be woken up.
+ *
  *	wakeup - Report/change current wakeup option for device
  *
  *	Some devices support "wakeup" events, which are hardware signals

@@ -43,6 +59,38 @@
 static const char enabled[] = "enabled";
 static const char disabled[] = "disabled";
 
+#ifdef CONFIG_PM_RUNTIME
+static const char ctrl_auto[] = "auto";
+static const char ctrl_on[] = "on";
+
+static ssize_t control_show(struct device *dev, struct device_attribute *attr,
+			    char *buf)
+{
+	return sprintf(buf, "%s\n",
+				dev->power.runtime_auto ? ctrl_auto : ctrl_on);
+}
+
+static ssize_t control_store(struct device * dev, struct device_attribute *attr,
+			     const char * buf, size_t n)
+{
+	char *cp;
+	int len = n;
+
+	cp = memchr(buf, '\n', n);
+	if (cp)
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);
+	else if (len == sizeof ctrl_on - 1 && strncmp(buf, ctrl_on, len) == 0)
+		pm_runtime_forbid(dev);
+	else
+		return -EINVAL;
+	return n;
+}
+
+static DEVICE_ATTR(control, 0644, control_show, control_store);
+#endif
+
 static ssize_t
 wake_show(struct device * dev, struct device_attribute *attr, char * buf)
 {

@@ -79,6 +127,9 @@ static DEVICE_ATTR(wakeup, 0644, wake_sh
 
 
 static struct attribute * power_attrs[] = {
+#ifdef CONFIG_PM_RUNTIME
+	&dev_attr_control.attr,
+#endif
 	&dev_attr_wakeup.attr,
 	NULL,
 };

include/linux/pm.h +1 -0

Index: linux-2.6/include/linux/pm.h
===================================================================
@@ -430,6 +430,7 @@ struct dev_pm_info {
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
 	unsigned int		run_wake:1;
+	unsigned int		runtime_auto:1;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;

drivers/base/power/runtime.c +45 -0

57 lines not on this page · raw message

include/linux/pm_runtime.h +4 -0

Index: linux-2.6/include/linux/pm_runtime.h
===================================================================
@@ -28,6 +28,8 @@ extern int __pm_runtime_set_status(struc
 extern int pm_runtime_barrier(struct device *dev);
 extern void pm_runtime_enable(struct device *dev);
 extern void __pm_runtime_disable(struct device *dev, bool check_resume);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
 
 static inline bool pm_children_suspended(struct device *dev)
 {

@@ -78,6 +80,8 @@ static inline int __pm_runtime_set_statu
 static inline int pm_runtime_barrier(struct device *dev) { return 0; }
 static inline void pm_runtime_enable(struct device *dev) {}
 static inline void __pm_runtime_disable(struct device *dev, bool c) {}
+static inline void pm_runtime_allow(struct device *dev) {}
+static inline void pm_runtime_forbid(struct device *dev) {}
 
 static inline bool pm_children_suspended(struct device *dev) { return false; }
 static inline void pm_suspend_ignore_children(struct device *dev, bool en) {}

Alan Stern

Acked-by

2010-01-23 15:20 UTC #39 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 11 lines · Rafael J. Wysocki

Hmm, OK.
Of course, if the driver decides to leave disable_depth > 0, the user still won't be able to do anything about that, but if I understand correctly, you want drivers to have the option to use pm_runtime_forbid() initially, right after pm_runtime_enable(), so that the user space can turn the runtime PM on if desired via sysfs.
That makes sense. I have a usage case for that myself. :-)
Updated patch is appended.

It looks good.

Acked-by Alan Stern <[email protected]>

Alan Stern

Acked-by

2010-01-23 15:20 UTC #40 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 11 lines · Rafael J. Wysocki

Hmm, OK.
Of course, if the driver decides to leave disable_depth > 0, the user still won't be able to do anything about that, but if I understand correctly, you want drivers to have the option to use pm_runtime_forbid() initially, right after pm_runtime_enable(), so that the user space can turn the runtime PM on if desired via sysfs.
That makes sense. I have a usage case for that myself. :-)
Updated patch is appended.

It looks good.

Acked-by Alan Stern <[email protected]>

Alan Stern

Rafael J. Wysocki

author

2010-01-23 20:07 UTC #41 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
Hmm, OK.
Of course, if the driver decides to leave disable_depth > 0, the user still won't be able to do anything about that, but if I understand correctly, you want drivers to have the option to use pm_runtime_forbid() initially, right after pm_runtime_enable(), so that the user space can turn the runtime PM on if desired via sysfs.

Quoted 7 lines

Quoted 3 lines
That makes sense. I have a usage case for that myself. :-)
Updated patch is appended.
It looks good.
Acked-by Alan Stern <[email protected]>

Thanks!

Rafael

Rafael J. Wysocki

author

2010-01-23 20:08 UTC #42 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 10 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
Hmm, OK.
Of course, if the driver decides to leave disable_depth > 0, the user still won't be able to do anything about that, but if I understand correctly, you want drivers to have the option to use pm_runtime_forbid() initially, right after pm_runtime_enable(), so that the user space can turn the runtime PM on if desired via sysfs.

Quoted 7 lines

Quoted 3 lines
That makes sense. I have a usage case for that myself. :-)
Updated patch is appended.
It looks good.
Acked-by Alan Stern <[email protected]>

Thanks!

Rafael

Rafael J. Wysocki

author

2010-01-23 12:14 UTC #43 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 30 lines · Alan Stern

Quoted 10 lines · Rafael J. Wysocki
Quoted 3 lines
For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.
Runtime PM is disabled for all devices by default unless the driver enables it. The setting in power/control is to override the driver's choice, so that it can be disabled even if the driver tries to enable it.
IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.
After more thought, I changed my mind about this. The ability to override the driver's choice means that the user should be able to enable runtime PM even if the driver tries to disable it, as well as the other way 'round.
In other words, it's not productive to say the user is the owner of the runtime_auto flag. What we _really_ want is to put the user in charge of whether or not a device is subject to runtime PM.
First of all, note that if the driver doesn't support runtime PM then it makes no difference what value runtime_auto has. The issue is moot.
So suppose the driver does support runtime PM. In this case, it's irrelevant that runtime PM starts out disabled by default when the device structure is initialized. The bus subsystem and driver will reinitialize the settings in the way they think best.

Quoted 6 lines

But if the driver decides to disable runtime PM and pm_runtime_forbid() isn't EXPORTed, then the driver will be forced to implement its decision by leaving disable_depth > 0 -- which means there's nothing the user can do. The power/control attribute won't help. On the other hand, if the driver decides to disable runtime PM and it can do so by calling pm_runtime_forbid(), then the user can override the decision.

Hmm, OK.

That makes sense. I have a usage case for that myself. :-)

Updated patch is appended.

Rafael

---
From: Rafael J. Wysocki <[email protected]>
Subject: PM / Runtime: Add sysfs switch for disabling device run-time PM

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 drivers/base/power/runtime.c |   45 +++++++++++++++++++++++++++++++++++++
 drivers/base/power/sysfs.c   |   51 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm.h           |    1 
 include/linux/pm_runtime.h   |    4 +++
 4 files changed, 101 insertions(+)

drivers/base/power/sysfs.c +51 -0

Index: linux-2.6/drivers/base/power/sysfs.c
===================================================================
@@ -4,9 +4,25 @@
 
 #include <linux/device.h>
 #include <linux/string.h>
+#include <linux/pm_runtime.h>
 #include "power.h"
 
 /*
+ *	control - Report/change current runtime PM setting of the device
+ *
+ *	Runtime power management of a device can be blocked with the help of
+ *	this attribute.  All devices have one of the following two values for
+ *	the power/control file:
+ *
+ *	 + "auto\n" to allow the device to be power managed at run time;
+ *	 + "on\n" to prevent the device from being power managed at run time;
+ *
+ *	The default for all devices is "auto", which means that devices may be
+ *	subject to automatic power management, depending on their drivers.
+ *	Changing this attribute to "on" prevents the driver from power managing
+ *	the device at run time.  Doing that while the device is suspended causes
+ *	it to be woken up.
+ *
  *	wakeup - Report/change current wakeup option for device
  *
  *	Some devices support "wakeup" events, which are hardware signals

@@ -43,6 +59,38 @@
 static const char enabled[] = "enabled";
 static const char disabled[] = "disabled";
 
+#ifdef CONFIG_PM_RUNTIME
+static const char ctrl_auto[] = "auto";
+static const char ctrl_on[] = "on";
+
+static ssize_t control_show(struct device *dev, struct device_attribute *attr,
+			    char *buf)
+{
+	return sprintf(buf, "%s\n",
+				dev->power.runtime_auto ? ctrl_auto : ctrl_on);
+}
+
+static ssize_t control_store(struct device * dev, struct device_attribute *attr,
+			     const char * buf, size_t n)
+{
+	char *cp;
+	int len = n;
+
+	cp = memchr(buf, '\n', n);
+	if (cp)
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);
+	else if (len == sizeof ctrl_on - 1 && strncmp(buf, ctrl_on, len) == 0)
+		pm_runtime_forbid(dev);
+	else
+		return -EINVAL;
+	return n;
+}
+
+static DEVICE_ATTR(control, 0644, control_show, control_store);
+#endif
+
 static ssize_t
 wake_show(struct device * dev, struct device_attribute *attr, char * buf)
 {

@@ -79,6 +127,9 @@ static DEVICE_ATTR(wakeup, 0644, wake_sh
 
 
 static struct attribute * power_attrs[] = {
+#ifdef CONFIG_PM_RUNTIME
+	&dev_attr_control.attr,
+#endif
 	&dev_attr_wakeup.attr,
 	NULL,
 };

include/linux/pm.h +1 -0

Index: linux-2.6/include/linux/pm.h
===================================================================
@@ -430,6 +430,7 @@ struct dev_pm_info {
 	unsigned int		request_pending:1;
 	unsigned int		deferred_resume:1;
 	unsigned int		run_wake:1;
+	unsigned int		runtime_auto:1;
 	enum rpm_request	request;
 	enum rpm_status		runtime_status;
 	int			runtime_error;

drivers/base/power/runtime.c +45 -0

57 lines not on this page · raw message

include/linux/pm_runtime.h +4 -0

Index: linux-2.6/include/linux/pm_runtime.h
===================================================================
@@ -28,6 +28,8 @@ extern int __pm_runtime_set_status(struc
 extern int pm_runtime_barrier(struct device *dev);
 extern void pm_runtime_enable(struct device *dev);
 extern void __pm_runtime_disable(struct device *dev, bool check_resume);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
 
 static inline bool pm_children_suspended(struct device *dev)
 {

@@ -78,6 +80,8 @@ static inline int __pm_runtime_set_statu
 static inline int pm_runtime_barrier(struct device *dev) { return 0; }
 static inline void pm_runtime_enable(struct device *dev) {}
 static inline void __pm_runtime_disable(struct device *dev, bool c) {}
+static inline void pm_runtime_allow(struct device *dev) {}
+static inline void pm_runtime_forbid(struct device *dev) {}
 
 static inline bool pm_children_suspended(struct device *dev) { return false; }
 static inline void pm_suspend_ignore_children(struct device *dev, bool en) {}

Rafael J. Wysocki

author

2010-01-22 20:56 UTC #44 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 17 lines · Alan Stern

Quoted 8 lines · Rafael J. Wysocki
From: Rafael J. Wysocki <[email protected]>
Add new device sysfs attribute, power/control, allowing the user space to block the run-time power management of devices. If this attribute is set to "on", the driver of the device won't be able to power manage it at run time (without breaking the rules) and the device will always be in the full power state (except when the entire system goes into a sleep state).
...
Quoted 4 lines
drivers/base/power/power.h +0 -0
@@ -2,11 +2,15 @@
 

Quoted 9 lines

drivers/base/power/power.h line 6
Quoted 4 lines
drivers/base/power/power.h +2 -0
 extern void pm_runtime_init(struct device *dev);
 extern void pm_runtime_remove(struct device *dev);
+extern void pm_runtime_allow(struct device *dev);
+extern void pm_runtime_forbid(struct device *dev);
Can you write a follow-up patch that moves these declarations to a public header file like include/linux/pm_runtime.h and EXPORTs the two new routines? It is sometimes useful for drivers to be able to call the routines directly.

I can put them in there in this patch just as well, but I'm not sure it's the right thing to do.

Quoted 3 lines

For example, we disable runtime PM for most USB devices by default. But a few drivers may know that their devices are able to handle it, so they want to change the default setting when they are bound.

IOW, the user space is the owner of the power.runtime_auto flag and I don't think we should allow drivers to modify it.

Rafael

Pavel Machek

2010-02-04 22:46 UTC #45 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Hi!

Quoted 9 lines

/*
+ * control - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/control file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managed at run time;

I find interface with mandatory \n quite 'interesting'.

Plus english is strange here. All devices have ... "auto" to allow...? Strange formulation. List the values first, then add "write ... to allow"?

Quoted 2 lines

+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.

Is it wise to specify 'auto' default value for devices without runtime pm?

drivers/base/power/sysfs.c line 98

Quoted 11 lines

drivers/base/power/sysfs.c +11 -0

+static ssize_t control_store(struct device * dev, struct device_attribute *attr,
+			     const char * buf, size_t n)
+{
+	char *cp;
+	int len = n;
+
+	cp = memchr(buf, '\n', n);
+	if (cp)
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);

parenthesis after sizeof?

Do I read it correctly that all of

"auto"
"auto\n"
"auto\non\nIm confused"

will switch to auto?

(and sorry for late reply...)
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2010-02-04 22:46 UTC #46 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Hi!

Quoted 9 lines

/*
+ * control - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/control file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managed at run time;

I find interface with mandatory \n quite 'interesting'.

Plus english is strange here. All devices have ... "auto" to allow...? Strange formulation. List the values first, then add "write ... to allow"?

Quoted 2 lines

+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.

Is it wise to specify 'auto' default value for devices without runtime pm?

drivers/base/power/sysfs.c line 98

Quoted 11 lines

drivers/base/power/sysfs.c +11 -0

+static ssize_t control_store(struct device * dev, struct device_attribute *attr,
+			     const char * buf, size_t n)
+{
+	char *cp;
+	int len = n;
+
+	cp = memchr(buf, '\n', n);
+	if (cp)
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);

parenthesis after sizeof?

Do I read it correctly that all of

"auto"
"auto\n"
"auto\non\nIm confused"

will switch to auto?

(and sorry for late reply...)
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Rafael J. Wysocki

author

2010-02-04 23:07 UTC #47 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 12 lines · Pavel Machek

Hi!
Quoted 9 lines
/*
+ * control - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/control file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managed at run time;

Quoted 1 line

I find interface with mandatory \n quite 'interesting'.

This simply follows the other descriptions in this file.

Quoted 2 lines

Plus english is strange here. All devices have ... "auto" to allow...? Strange formulation. List the values first, then add "write ... to allow"?

Ditto.

Quoted 5 lines

Quoted 2 lines
+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.
Is it wise to specify 'auto' default value for devices without runtime pm?

Yes, it is. It means the user space doesn't care whether or not the device is power managed at run-time.

Quoted 5 lines

drivers/base/power/sysfs.c +5 -0

+static ssize_t control_store(struct device * dev, struct device_attribute *attr,
+			     const char * buf, size_t n)
+{
+	char *cp;
+	int len = n;

Quoted 8 lines

drivers/base/power/sysfs.c line 98
Quoted 6 lines
drivers/base/power/sysfs.c +6 -0
+
+	cp = memchr(buf, '\n', n);
+	if (cp)
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);
parenthesis after sizeof?

This notation is used throughout this file too.

Quoted 7 lines

Do I read it correctly that all of
"auto"
"auto\n"
"auto\non\nIm confused"
will switch to auto?

Perhaps it would, but what exactly is the problem with that?

Rafael

Pavel Machek

2010-02-05 06:27 UTC #48 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 9 lines

Quoted 6 lines
Quoted 3 lines
+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.
Is it wise to specify 'auto' default value for devices without runtime pm?
Yes, it is. It means the user space doesn't care whether or not the device is power managed at run-time.

Well, defaulting to 'on' for drivers when runtime pm is experimental seems logical. and there will be such drivers...

Quoted 7 lines

Quoted 5 lines
drivers/base/power/sysfs.c line 98
Quoted 3 lines
drivers/base/power/sysfs.c +3 -0
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);
parenthesis after sizeof?
This notation is used throughout this file too.

...but is inconsistent with rest of kernel.

Quoted 9 lines

Quoted 7 lines
Do I read it correctly that all of
"auto"
"auto\n"
"auto\non\nIm confused"
will switch to auto?
Perhaps it would, but what exactly is the problem with that?

That apps will start depending on such broken behaviour?
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2010-02-05 06:28 UTC #49 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 9 lines

Quoted 6 lines
Quoted 3 lines
+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.
Is it wise to specify 'auto' default value for devices without runtime pm?
Yes, it is. It means the user space doesn't care whether or not the device is power managed at run-time.

Well, defaulting to 'on' for drivers when runtime pm is experimental seems logical. and there will be such drivers...

Quoted 7 lines

Quoted 5 lines
drivers/base/power/sysfs.c line 98
Quoted 3 lines
drivers/base/power/sysfs.c +3 -0
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);
parenthesis after sizeof?
This notation is used throughout this file too.

...but is inconsistent with rest of kernel.

Quoted 9 lines

Quoted 7 lines
Do I read it correctly that all of
"auto"
"auto\n"
"auto\non\nIm confused"
will switch to auto?
Perhaps it would, but what exactly is the problem with that?

That apps will start depending on such broken behaviour?
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Alan Stern

2010-02-05 15:19 UTC #50 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 4 lines · Pavel Machek

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Is it wise to specify 'auto' default value for devices without runtime pm?
Yes, it is. It means the user space doesn't care whether or not the device is power managed at run-time.
Well, defaulting to 'on' for drivers when runtime pm is experimental seems logical. and there will be such drivers...

It's really not very important what the default setting is. Runtime PM is always initially disabled, regardless of the "auto"/"on" setting, until the driver explicitly enables it. At that time the driver also has the option of changing the setting from "auto" to "on".

So if a driver writer wants to support runtime PM but thinks that his implementation (or the device!) may be buggy, he can easily arrange things so the user has to change the sysfs setting to make anything happen.

Alan Stern

2010-02-05 15:19 UTC #51 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 4 lines · Pavel Machek

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
Is it wise to specify 'auto' default value for devices without runtime pm?
Yes, it is. It means the user space doesn't care whether or not the device is power managed at run-time.
Well, defaulting to 'on' for drivers when runtime pm is experimental seems logical. and there will be such drivers...

Alan Stern

Rafael J. Wysocki

author

2010-02-04 23:08 UTC #52 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Quoted 12 lines · Pavel Machek

Hi!
Quoted 9 lines
/*
+ * control - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/control file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managed at run time;

Quoted 1 line

I find interface with mandatory \n quite 'interesting'.

This simply follows the other descriptions in this file.

Quoted 2 lines

Plus english is strange here. All devices have ... "auto" to allow...? Strange formulation. List the values first, then add "write ... to allow"?

Ditto.

Quoted 5 lines

Quoted 2 lines
+ * The default for all devices is "auto", which means that devices may be
+ * subject to automatic power management, depending on their drivers.
Is it wise to specify 'auto' default value for devices without runtime pm?

Yes, it is. It means the user space doesn't care whether or not the device is power managed at run-time.

Quoted 5 lines

drivers/base/power/sysfs.c +5 -0

+static ssize_t control_store(struct device * dev, struct device_attribute *attr,
+			     const char * buf, size_t n)
+{
+	char *cp;
+	int len = n;

Quoted 8 lines

drivers/base/power/sysfs.c line 98
Quoted 6 lines
drivers/base/power/sysfs.c +6 -0
+
+	cp = memchr(buf, '\n', n);
+	if (cp)
+		len = cp - buf;
+	if (len == sizeof ctrl_auto - 1 && strncmp(buf, ctrl_auto, len) == 0)
+		pm_runtime_allow(dev);
parenthesis after sizeof?

This notation is used throughout this file too.

Quoted 7 lines

Do I read it correctly that all of
"auto"
"auto\n"
"auto\non\nIm confused"
will switch to auto?

Perhaps it would, but what exactly is the problem with that?

Rafael

Nigel Cunningham

2010-02-05 08:01 UTC #53 lore raw

Re: [linux-pm] [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Hi Pavel et al.

Quoted 12 lines · Pavel Machek

Hi!
Quoted 9 lines
/*
+ * control - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/control file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managed at run time;

Quoted 1 line

I find interface with mandatory \n quite 'interesting'.

Agreed.

Quoted 2 lines

Plus english is strange here. All devices have ... "auto" to allow...? Strange formulation. List the values first, then add "write ... to allow"?

It seems okay to me because of the preceding sentence ending in a colon.

Regards,

Nigel

Nigel Cunningham

2010-02-05 08:03 UTC #54 lore raw

Re: [PATCH 1/2] PM / Runtime: Add sysfs switch for disabling device run-time PM (rev. 2)

Hi Pavel et al.

Quoted 12 lines · Pavel Machek

Hi!
Quoted 9 lines
/*
+ * control - Report/change current runtime PM setting of the device
+ *
+ * Runtime power management of a device can be blocked with the help of
+ * this attribute. All devices have one of the following two values for
+ * the power/control file:
+ *
+ * + "auto\n" to allow the device to be power managed at run time;
+ * + "on\n" to prevent the device from being power managed at run time;

Quoted 1 line

I find interface with mandatory \n quite 'interesting'.

Agreed.

Quoted 2 lines

Plus english is strange here. All devices have ... "auto" to allow...? Strange formulation. List the values first, then add "write ... to allow"?

It seems okay to me because of the preceding sentence ending in a colon.

Regards,

Nigel

Rafael J. Wysocki

author

2010-01-21 23:00 UTC #55 lore raw

PATCH 2/2 PM: Document device power attributes in sysfs

From: Rafael J. Wysocki <[email protected]>

There are sysfs attributes in /sys/devices/.../power/ that haven't been documented yet in Documentation/ABI/. Document them as appropriate.

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 Documentation/ABI/testing/sysfs-devices-power |   53 ++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

Documentation/ABI/testing/sysfs-devices-power new file +53 -0

Index: linux-2.6/Documentation/ABI/testing/sysfs-devices-power
===================================================================
@@ -0,0 +1,53 @@
+What:		/sys/devices/.../power/
+Date:		January 2009
+Contact:	Rafael J. Wysocki <[email protected]>
+Description:
+		The /sys/devices/.../power directory contains attributes
+		allowing the user space to check and modify some power
+		management related properties of given device.
+
+What:		/sys/devices/.../power/wakeup
+Date:		January 2009
+Contact:	Rafael J. Wysocki <[email protected]>
+Description:
+		The /sys/devices/.../power/wakeup attribute allows the user
+		space to check if the device is enabled to wake up the system
+		from sleep states, such as the memory sleep state (suspend to
+		RAM) and hibernation (suspend to disk), and to enable or disable
+		it to do that as desired.
+
+		Some devices support "wakeup" events, which are hardware signals
+		used to activate the system from a sleep state.  Such devices
+		have one of the following two values for the sysfs power/wakeup
+		file:
+
+		+ "enabled\n" to issue the events;
+		+ "disabled\n" not to do so;
+
+		In that cases the user space can change the setting represented
+		by the contents of this file by writing either "enabled", or
+		"disabled" to it.
+
+		For the devices that are not capable of generating system wakeup
+		events this file contains "\n".  In that cases the user space
+		cannot modify the contents of this file and the device cannot be
+		enabled to wake up the system.
+
+What:		/sys/devices/.../power/control
+Date:		January 2009
+Contact:	Rafael J. Wysocki <[email protected]>
+Description:
+		The /sys/devices/.../power/control attribute allows the user
+		space to control the run-time power management of the device.
+
+		All devices have one of the following two values for the
+		power/control file:
+
+		+ "auto\n" to allow the device to be power managed at run time;
+		+ "on\n" to prevent the device from being power managed;
+
+		The default for all devices is "auto", which means that they may
+		be subject to automatic power management, depending on their
+		drivers.  Changing this attribute to "on" prevents the driver
+		from power managing the device at run time.  Doing that while
+		the device is suspended causes it to be woken up.

Rafael J. Wysocki

author

2010-01-21 23:01 UTC #56 lore raw

PATCH 2/2 PM: Document device power attributes in sysfs