[PATCH] Hotplug for device power state changes

[PATCH] Hotplug for device power state changes

[Todd Poynor]

A patch to call a hotplug device-power agent when the power state of a
device is modified at runtime (that is, individually via sysfs or by a
driver call, not as part of a system suspend/resume).  Allows a power
management application to be informed of changes in device power needs.
This can be useful on platforms with dependencies between system
clock/voltage settings and operation of certain devices (such as
PXA27x), or, for example, on a cell phone where voiceband or network
devices going inactive signals an opportunity to lower platform power
levels to conserve battery life.

Implemented via new class device-power, with which all devices register.
I'm interested in comments on this approach and in alternate
suggestions.  Perhaps device-power should be an "opt-in" class, since
power state changes won't be a concern for most devices/platforms/applications.


--- linux-2.6.5-orig/drivers/base/power/runtime.c	2004-03-11 15:02:22.000000000 -0800
+++ linux-2.6.5-pm/drivers/base/power/runtime.c	2004-04-28 16:51:37.000000000 -0700
@@ -33,6 +33,7 @@
 	down(&dpm_sem);
 	runtime_resume(dev);
 	up(&dpm_sem);
+	dpm_notify(dev);
 }
 
 
@@ -53,8 +54,10 @@
 	if (dev->power.power_state)
 		runtime_resume(dev);
 
-	if (!(error = suspend_device(dev,state)))
+	if (!(error = suspend_device(dev,state))) {
 		dev->power.power_state = state;
+		dpm_notify(dev);
+	}
  Done:
 	up(&dpm_sem);
 	return error;

--- linux-2.6.5-orig/drivers/base/power/sysfs.c	2004-03-11 14:57:55.000000000 -0800
+++ linux-2.6.5-pm/drivers/base/power/sysfs.c	2004-04-29 12:41:32.962625032 -0700
@@ -3,6 +3,7 @@
  */
 
 #include <linux/device.h>
+#include <linux/init.h>
 #include "power.h"
 
 
@@ -57,12 +58,81 @@
 	.attrs	= power_attrs,
 };
 
+#ifdef CONFIG_HOTPLUG
+static int
+device_power_hotplug(struct class_device *class_dev, char **envp,
+		     int num_envp, char *buffer, int buffer_size)
+{
+	struct device * dev = (struct device *) class_dev->class_data;
+	int i = 0;
+	int length = 0;
+
+	envp[i++] = buffer;
+	length += scnprintf (buffer, buffer_size - length, "STATE=%d",
+			     dev->power.power_state);
+	if ((buffer_size - length <= 0) || (i >= num_envp))
+		return -ENOMEM;
+	++length;
+
+	envp[i] = 0;
+
+	return 0;
+}
+#endif
+
+static void
+device_power_dev_release(struct class_device *class_dev)
+{
+	if (class_dev)
+		kfree(class_dev);
+}
+
+void dpm_notify(struct device * dev)
+{
+#ifdef CONFIG_HOTPLUG
+	kobject_hotplug("state-change", &dev->power.class_dev->kobj);
+#endif
+}
+
+static struct class device_power_class = {
+	.name		= "device-power",
+#ifdef CONFIG_HOTPLUG
+	.hotplug	= device_power_hotplug,
+#endif
+	.release	= device_power_dev_release,
+};
+
+
 int dpm_sysfs_add(struct device * dev)
 {
+	struct class_device *class_dev = kmalloc(sizeof(struct class_device), GFP_KERNEL);
+
+	if (class_dev) {
+		memset(class_dev, 0, sizeof (*class_dev));
+		dev->power.class_dev = class_dev;
+		class_dev->class = &device_power_class;
+		class_dev->class_data = dev;
+		strlcpy(class_dev->class_id, dev->bus_id, BUS_ID_SIZE);
+		class_device_register(class_dev);
+	}
+
 	return sysfs_create_group(&dev->kobj,&pm_attr_group);
 }
 
 void dpm_sysfs_remove(struct device * dev)
 {
+	struct class_device *class_dev = dev->power.class_dev;
+
+	if (class_dev) {
+		class_device_unregister(class_dev);
+		dev->power.class_dev = NULL;
+	}
+
 	sysfs_remove_group(&dev->kobj,&pm_attr_group);
 }
+
+int __init dpm_init(void)
+{
+	return class_register(&device_power_class);
+}
+

--- linux-2.6.5-orig/drivers/base/power/power.h	2004-03-11 14:57:55.000000000 -0800
+++ linux-2.6.5-pm/drivers/base/power/power.h	2004-04-28 16:53:52.000000000 -0700
@@ -54,6 +54,7 @@
 
 extern int dpm_sysfs_add(struct device *);
 extern void dpm_sysfs_remove(struct device *);
+extern void dpm_notify(struct device *);
 
 /*
  * resume.c 

--- linux-2.6.5-orig/drivers/base/init.c	2004-03-11 15:02:22.000000000 -0800
+++ linux-2.6.5-pm/drivers/base/init.c	2004-04-28 16:56:25.000000000 -0700
@@ -14,6 +14,7 @@
 extern int buses_init(void);
 extern int classes_init(void);
 extern int firmware_init(void);
+extern int dpm_init(void);
 extern int platform_bus_init(void);
 extern int system_bus_init(void);
 extern int cpu_dev_init(void);
@@ -31,6 +32,7 @@
 	devices_init();
 	buses_init();
 	classes_init();
+	dpm_init();
 	firmware_init();
 
 	/* These are also core pieces, but must come after the 

--- linux-2.6.5-orig/include/linux/pm.h	2004-03-11 14:58:50.000000000 -0800
+++ linux-2.6.5-pm/include/linux/pm.h	2004-04-28 16:55:31.000000000 -0700
@@ -227,6 +227,7 @@
  */
 
 struct device;
+struct class_device;
 
 struct dev_pm_info {
 #ifdef	CONFIG_PM
@@ -234,6 +235,7 @@
 	u8			* saved_state;
 	atomic_t		pm_users;
 	struct device		* pm_parent;
+	struct class_device	* class_dev;
 	struct list_head	entry;
 #endif
 };


-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Russell King]

On Thu, Apr 29, 2004 at 01:26:54PM -0700, Todd Poynor wrote:
> A patch to call a hotplug device-power agent when the power state of a
> device is modified at runtime (that is, individually via sysfs or by a
> driver call, not as part of a system suspend/resume).  Allows a power
> management application to be informed of changes in device power needs.
> This can be useful on platforms with dependencies between system
> clock/voltage settings and operation of certain devices (such as
> PXA27x), or, for example, on a cell phone where voiceband or network
> devices going inactive signals an opportunity to lower platform power
> levels to conserve battery life.

Note that we should run this synchronously with userspace - ie, wait
for the userspace hotplug script to finish executing before moving
on to the next device.  Why?

Think of the case where we're suspending the complete system.  If you
go round and asynchonously try to run userspace scripts, chances are
you'll have the CPU asleep before _any_ of the scripts have run, which
means (eg) your DHCP client couldn't tell the server that its released
its allocation.

Also, should we be telling userspace about suspend before we actually
suspend the device?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Russell King wrote:

> Note that we should run this synchronously with userspace - ie, wait
> for the userspace hotplug script to finish executing before moving
> on to the next device.  Why?
> 
> Think of the case where we're suspending the complete system.  If you
> go round and asynchonously try to run userspace scripts, chances are
> you'll have the CPU asleep before _any_ of the scripts have run, which
> means (eg) your DHCP client couldn't tell the server that its released
> its allocation.

I figured system suspend/resume would need to be a separate event and 
isn't covered by this patch, which is for "runtime" individual device 
suspend/resume only.  Also, the flood of notifications of all devices 
suspending/resuming might not be useful -- the single system 
suspend/resume event could imply these device events, although perhaps 
in some cases something would want to know exactly which devices were 
operable at system suspend time.  I can also send a patch for system 
suspend/resume hotplug if there's interest.

Now that you mention it, device power hotplug should be synchronous, to 
make sure the power management application has reacted to the changed 
state prior to the device going into actual service (in the case of a 
resume).

> Also, should we be telling userspace about suspend before we actually
> suspend the device?

I suppose that, depending on the reason notification is needed, "just 
before" or "just after" might be the right answer.  Now that you bring 
this up, it was originally my intention to notify of suspend "just 
after" (so power mgr can change power state, knowing that the associated 
device no longer has any requirements), and notify of resume "just 
before" (so power mgr can adjust power state to match requirements about 
to be put into service).  I'd be interested in hearing about other usage 
scenarios that might need a different notification order.  Thanks,

-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Benjamin Herrenschmidt]

> I figured system suspend/resume would need to be a separate event and 
> isn't covered by this patch, which is for "runtime" individual device 
> suspend/resume only.  Also, the flood of notifications of all devices 
> suspending/resuming might not be useful -- the single system 
> suspend/resume event could imply these device events, although perhaps 
> in some cases something would want to know exactly which devices were 
> operable at system suspend time.  I can also send a patch for system 
> suspend/resume hotplug if there's interest.
> 
> Now that you mention it, device power hotplug should be synchronous, to 
> make sure the power management application has reacted to the changed 
> state prior to the device going into actual service (in the case of a 
> resume).

This is dangerous.

If the device you are suspending is on the VM path in any way,
beeing synchronous with a userland call can deadlock you solid.

This is even more true for system suspend where we are suspending
all devices including the main swap/storage.

There are various cases where I would have loved to get userland
more involved in the suspend/resume process for various reasons,
but in the end, I always got bitten by that problem. Userland cannot
be relied upon unless the process is made completely resident as soon
as we start the suspend dance.

More to this: If you use the "common" code in kernel/power, which I
don't (yet) use on pmac for suspend-to-ram, you'll also stop all
userland processes before notifying drivers (and suspend-to-disk
expects that).

Ben.

Re: [PATCH] Hotplug for device power state changes

[Russell King]

On Fri, Apr 30, 2004 at 10:50:26AM +1000, Benjamin Herrenschmidt wrote:
> This is dangerous.
> 
> If the device you are suspending is on the VM path in any way,
> beeing synchronous with a userland call can deadlock you solid.

And not being synchronous means that there's no point in calling
userland, because userland won't run before the machine has
suspended, so there's no point in calling it in the first place.
Also consider the case where you suspend, and asynchronously queue
up all these suspend scripts to run.  Then you resume and queue up
the resume scripts to run.  What order do the suspend and resume
scripts ultimately end up being run?

What if the scripts have side effects like releasing and re-acquiring
your DHCP allocation - what would be the effect of the suspend script
completing after the resume script?

What about the case where suspend/resume scripts bring up/tear down
any communication protocol?

Maybe we should have a two-pass approach, where the first pass
synchronously tells userspace about the suspend, and the second
pass does the actual suspend.  Then for resume the opposite.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Russell King wrote:

> And not being synchronous means that there's no point in calling
> userland, because userland won't run before the machine has
> suspended, so there's no point in calling it in the first place.
> Also consider the case where you suspend, and asynchronously queue
> up all these suspend scripts to run.  Then you resume and queue up
> the resume scripts to run.  What order do the suspend and resume
> scripts ultimately end up being run?
...
> Maybe we should have a two-pass approach, where the first pass
> synchronously tells userspace about the suspend, and the second
> pass does the actual suspend.  Then for resume the opposite.

I would argue that a system suspend/resume event does not need to also 
inform of the individual device suspend/resume events, since these can 
be implied.  But if we were to include individual device suspend/resume 
hotplug events as part of system suspend/resume then I would agree with 
a two-phase model, since notification at the time of actual hardware 
suspend does not work once something critical to userspace notification 
is shutdown.

So I'm planning to resubmit patches with the following:

* Individual device resume events signalled before, not after, the 
resume, so that userspace can react to any new requirements before the 
device is placed into service.

* Individual device suspend and resume events converted to synchronous 
events (that wait for hotplug processing to complete before continuing).

* Changes to kobject to allow kobject hotplug to optionally be 
synchronous if desired.  I'd assume this is a new hotplug_ops field.

* Synchronous hotplug events for system suspend and resume (without 
individual device notifications).  These events can probably be 
generated by the kobject hotplug methods by the existing power subsys 
(once the above enhancement is in place).

Any comments on this course of action welcomed.


-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Greg KH]

On Fri, Apr 30, 2004 at 12:59:40PM -0700, Todd Poynor wrote:
> 
> * Changes to kobject to allow kobject hotplug to optionally be 
> synchronous if desired.  I'd assume this is a new hotplug_ops field.

Ick.

> * Synchronous hotplug events for system suspend and resume (without 
> individual device notifications).  These events can probably be 
> generated by the kobject hotplug methods by the existing power subsys 
> (once the above enhancement is in place).

But why?  Do you really need this?  Have you actually tested a system to
see if it is needed?

thanks,

greg k-h

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Greg KH wrote:
> On Fri, Apr 30, 2004 at 12:59:40PM -0700, Todd Poynor wrote:
> 
>>* Changes to kobject to allow kobject hotplug to optionally be 
>>synchronous if desired.  I'd assume this is a new hotplug_ops field.
> 
> 
> Ick.

Is the objection to using kobject for synchronous hotplug events, or to 
using a hotplug_ops flag to indicate which kind is needed?  Would the 
addition of a kobject_hotplug_sync function be better?  Or a 
handshake-like interface as with firmware downloads?

>>* Synchronous hotplug events for system suspend and resume (without 
>>individual device notifications).  These events can probably be 
>>generated by the kobject hotplug methods by the existing power subsys 
>>(once the above enhancement is in place).
> 
> 
> But why?  Do you really need this?  Have you actually tested a system to
> see if it is needed?

This is something that was requested of me by others who build Linux 
into consumer electronics devices.  Perhaps some of the interested 
parties may speak up here to add more insight.  Among the intended uses 
that I'm aware of are: saving application state to stable storage (for 
example, to be prepared in case the battery dies during an extended 
"suspended" period, and such gadgets often do not have a device suitable 
for a complete system suspend-to-disk), terminating applications that 
reside in memory banks to be powered off during the suspend (this also 
relies on other enhancements to allocate memory accordingly), and 
dropping network connections in order to conserve resources on servers 
that support mobile devices.  It sounds like the folks that deal with 
ACPI power management have found use for such a mechanism in the 
server/desktop world as well.

Thanks,

-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Greg KH]

On Fri, Apr 30, 2004 at 06:16:22PM -0700, Todd Poynor wrote:
> Greg KH wrote:
> >On Fri, Apr 30, 2004 at 12:59:40PM -0700, Todd Poynor wrote:
> >
> >>* Changes to kobject to allow kobject hotplug to optionally be 
> >>synchronous if desired.  I'd assume this is a new hotplug_ops field.
> >
> >
> >Ick.
> 
> Is the objection to using kobject for synchronous hotplug events, or to 
> using a hotplug_ops flag to indicate which kind is needed?  Would the 
> addition of a kobject_hotplug_sync function be better?  Or a 
> handshake-like interface as with firmware downloads?

To add an option to the kobject_hotplug() function for a sync call is
one thing.  To make the option for the main kobject add and remove call
to be sync is a horribly misguided thought (the reason why is left as an
exercise for the reader...like go read the udev code for many reasons
why...)

I don't have an objection to add such a new paramater (or even a new
function call like you suggested), just don't go messing with the main
kobject hotplug call without thinking everything through :)

> >>* Synchronous hotplug events for system suspend and resume (without 
> >>individual device notifications).  These events can probably be 
> >>generated by the kobject hotplug methods by the existing power subsys 
> >>(once the above enhancement is in place).
> >
> >
> >But why?  Do you really need this?  Have you actually tested a system to
> >see if it is needed?
> 
> This is something that was requested of me by others who build Linux 
> into consumer electronics devices.  Perhaps some of the interested 
> parties may speak up here to add more insight.

Please encourage them to speak up.  I hear _nothing_ from any embedded
developers, and I am really interested in how the driver model and
hotplug works (or doesn't) for them.  Without that feedback, we are in
the dark as to what their needs/hates are.

thanks,

greg k-h

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Greg KH wrote:

> I don't have an objection to add such a new paramater (or even a new
> function call like you suggested), just don't go messing with the main
> kobject hotplug call without thinking everything through :)

OK, will do.

>>This is something that was requested of me by others who build Linux 
>>into consumer electronics devices.  Perhaps some of the interested 
>>parties may speak up here to add more insight.
> 
> 
> Please encourage them to speak up.  I hear _nothing_ from any embedded
> developers, and I am really interested in how the driver model and
> hotplug works (or doesn't) for them.  Without that feedback, we are in
> the dark as to what their needs/hates are.

Thanks, I have passed the call to get involved on to a group of Linux 
consumer electronics developers (the Consumer Electronics Linux Forum; 
Tim Bird will hold a BoF at OLS introducing this group).  I am involved 
at an infrastructure level and have helped steer various general 
requirements toward use of LDM (which we've been using even in 2.4 for 
some time) and hotplug (which is new to us for these purposes and they 
might not yet have much experience with this), and can also serve as a 
conduit for feedback.  I appreciate your interest in the needs of 
embedded developers and hope that we can contribute some useful 
suggestions and features.


-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Nigel Cunningham]

Hi.

Sorry for getting in on this conversion a little late; I've only just  
noticed it.

The usual way in which userspace notification of suspending/resuming is  
handled at the moment is via scripts which are run prior to suspending and  
after resuming. As has been noted, the first thing the kernel side  
implementations does is freeze userspace, keeping things static until post  
resume. This seems to me to be a good, simple model. DHCP releases can be  
handled from user space, prior to echo 4 > /proc/acpi/sleep (or  
alternatives) and the whole difficulty regarding interactions between  
userspace and kernelspace just goes away.

Note too that the actual invocation of a suspend can still be in response  
to kernel events. An ACPI event can be sent to the userspace ACPI daemon,  
which does userspace preparations and then invokes the kernel suspend  
mechanism. After resume, it can also do userspace reinitialisation.

Given this model, I would suggest that hotplug should silently drop any  
events that happen while suspending, and queue events that occur while  
resuming until the kernelspace part of resuming is complete and userspace  
can run as normal. It shouldn't rely upon device suspend/resume  
notifications because they can and do happen while we're still in the  
process of suspending and resuming. The means to detect whether we're  
suspending or resuming or running normally could be implemented as a  
simple function that could test the status of the different suspend  
implementations.

Is that at all helpful?

Regards,

Nigel

-- 
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614, Australia.
+61 (2) 6251 7727 (wk)

At just the right time, while we were still powerless, Christ
died for the ungodly. (Romans 5:6)

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Nigel Cunningham wrote:

> Given this model, I would suggest that hotplug should silently drop any  
> events that happen while suspending, and queue events that occur while  
> resuming until the kernelspace part of resuming is complete and 
> userspace  can run as normal. It shouldn't rely upon device 
> suspend/resume  notifications because they can and do happen while we're 
> still in the  process of suspending and resuming. The means to detect 
> whether we're  suspending or resuming or running normally could be 
> implemented as a  simple function that could test the status of the 
> different suspend  implementations.

If needed, there's already a "system_running" flag used to ignore the 
underlying usermode helper execution if requested prior to the system 
being ready for such an event at boot time, and perhaps this could be 
co-opted or extended for use at suspend/resume time.  Sounds like the 
correct behavior is to leave the exec requests queued until userspace is 
resumed (and I'd assume that device power state notifications are not 
needed, but perhaps hotplug events and/or modprobes of drivers for 
hotpluggable devices and associated features may be generated at resume 
time).  Thanks,

-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Benjamin Herrenschmidt wrote:

>>Now that you mention it, device power hotplug should be synchronous, to 
>>make sure the power management application has reacted to the changed 
>>state prior to the device going into actual service (in the case of a 
>>resume).
> 
> 
> This is dangerous.
> 
> If the device you are suspending is on the VM path in any way,
> beeing synchronous with a userland call can deadlock you solid.
> 
> This is even more true for system suspend where we are suspending
> all devices including the main swap/storage.

Well, this feature is intended to allow power management of appropriate 
devices; using sysfs or a driver call to individually suspend a device 
required for proper system operation would be a danger, hotplug 
notification or no.  And the individual device notifications provided by 
the patch under discussion are not for use during a system-wide 
suspend/resume sequence.  I would imagine system suspend/resume would be 
separate events that probably would not notify of the individual device 
suspends/resumes performed as a consequence.  At any rate, yes, this 
would occur outside of the code path that freezes processes and such.

-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Patrick Mochel]

> A patch to call a hotplug device-power agent when the power state of a
> device is modified at runtime (that is, individually via sysfs or by a
> driver call, not as part of a system suspend/resume).  Allows a power
> management application to be informed of changes in device power needs.
> This can be useful on platforms with dependencies between system
> clock/voltage settings and operation of certain devices (such as
> PXA27x), or, for example, on a cell phone where voiceband or network
> devices going inactive signals an opportunity to lower platform power
> levels to conserve battery life.

Why? If the device is powered down at runtime via sysfs, then the app that
did that already exists in userspace, like the ones you're trying to
notify via /sbin/hotplug. It would be much simpler for the first app to
generate e.g. a d-bus message to notify other apps, rather than creating
this conduit through the kernel.

Besides, if one process has a device open, then the driver should refuse
any requests to power it down.

And, for the case where a communication device loses signal, you should
treat it similarly to a network device, which notifies userspace of a lost
link, which then has the option of powering down the device and notifying
other processes.


	Pat

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Patrick Mochel wrote:
>>A patch to call a hotplug device-power agent when the power state of a
>>device is modified at runtime (that is, individually via sysfs or by a
>>driver call, not as part of a system suspend/resume).  Allows a power
>>management application to be informed of changes in device power needs.
>>This can be useful on platforms with dependencies between system
>>clock/voltage settings and operation of certain devices (such as
>>PXA27x), or, for example, on a cell phone where voiceband or network
>>devices going inactive signals an opportunity to lower platform power
>>levels to conserve battery life.
> 
> 
> Why? If the device is powered down at runtime via sysfs, then the app that
> did that already exists in userspace, like the ones you're trying to
> notify via /sbin/hotplug. It would be much simpler for the first app to
> generate e.g. a d-bus message to notify other apps, rather than creating
> this conduit through the kernel.

The ability to do this was originally requested in the context of a 
driver managing the power state of its devices (according to some 
unspecified logic); agreed that state changes requested via sysfs are a 
less compelling usage scenario.  Small battery-powered gadgets often 
implement drivers that are more actively involved in managing power 
state than the desktop/notebook/server norm, invoking LDM suspend 
routines when an opportunity to power down arises.  But it is also 
common in wall-plug-wired systems to have a few power state transitions 
that result from things under kernel control, such as blanking a display 
device after a timer expires.

In many cases, the opportunity to move to a lower-power state may be 
triggered by userspace activity and would make a good candidate for a 
purely userspace notification method.  However, a kernel-to-userspace 
notification method is suggested for this to cover potential cases where 
a device power state change might not be directly caused by, or may be a 
non-obvious side effect of, an application action.  Display blanking is 
an example; other devices that can enter a low-power state due to 
inactivity or due to changes in power state of other upstream or 
downstream devices could also use this.  If anyone reading this has 
concrete examples that they would like to have considered then please do 
speak up.

It may be the case that most useful scenarios for userspace actions in 
response to device power state changes could be handled through a 
suitable implementation of D-BUS messages between applications, and I'd 
certainly support use of that model wherever possible.  Returning errors 
through the system call interface for an operation on a device file 
descriptor, as I believe you've suggested, may also help cover most 
useful cases.  I will continue to encourage the developers who have 
asked me for driver power state notifiers to chime in here with more 
details on their needs.

> Besides, if one process has a device open, then the driver should refuse
> any requests to power it down.

I'd suggest some latitude in driver handling of low-power device states 
wrt open file descriptors, such as for display blanking.  But yes, this 
is usually true (at least in the non-system-suspend case).


-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Patrick Mochel]

> The ability to do this was originally requested in the context of a
> driver managing the power state of its devices (according to some
> unspecified logic); agreed that state changes requested via sysfs are a
> less compelling usage scenario.  Small battery-powered gadgets often
> implement drivers that are more actively involved in managing power
> state than the desktop/notebook/server norm, invoking LDM suspend
> routines when an opportunity to power down arises.  But it is also
> common in wall-plug-wired systems to have a few power state transitions
> that result from things under kernel control, such as blanking a display
> device after a timer expires.

It seems like it would best be done at the class level, rather than the
core driver level, if you wanted to do it all. For things like
communication devices going out of range, you would probably want to
easily support multiple drivers of the same type, so you might as well
abstract it to the class. And, I don't see a reason for it to be
synchronous, since any apps trying to communicate over it will soon
realize it's not available; and any policy in userspace shouldn't by
definition be that critical to the health of the system.

Display blanking is based on user input inactivity, and already works on
most systems.


	Pat

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Patrick Mochel wrote:
>>The ability to do this was originally requested in the context of a
>>driver managing the power state of its devices (according to some
>>unspecified logic); agreed that state changes requested via sysfs are a
>>less compelling usage scenario.  Small battery-powered gadgets often
>>implement drivers that are more actively involved in managing power
>>state than the desktop/notebook/server norm, invoking LDM suspend
>>routines when an opportunity to power down arises.  But it is also
>>common in wall-plug-wired systems to have a few power state transitions
>>that result from things under kernel control, such as blanking a display
>>device after a timer expires.
> 
> 
> It seems like it would best be done at the class level, rather than the
> core driver level, if you wanted to do it all. For things like
> communication devices going out of range, you would probably want to
> easily support multiple drivers of the same type, so you might as well
> abstract it to the class. And, I don't see a reason for it to be
> synchronous, since any apps trying to communicate over it will soon
> realize it's not available; and any policy in userspace shouldn't by
> definition be that critical to the health of the system.
> 
> Display blanking is based on user input inactivity, and already works on
> most systems.

Although there are a number of ways this information could be used, the
specific use I intended is for system power management purposes.  I wouldn't
suggest implementing features such as screen blanking (which was brought up
as an example of a device power state transition that occurs according to kernel
logic and not at the request of an app) or notifying network applications of
downed links using this mechanism.  

Let me throw out an example to help discuss the model best suits that situation.
An XScale PXA27x "Bulverde", a smartphone platform, has a low-power mode that
helps conserve battery power during periods of reduced activity while leaving
the CPU running at a low clock rate (and often idling) to handle any events
that occur during that time.  In that mode, certain devices must be powered off
(apparently critical input clocks are turned off and the device may get wedged
and cease to function).  Among these devices are the LCD controller and serial
devices such as IrDA and Bluetooth.  If a system power management mechanism such
as cpufreq is employed to place the system into low-power mode during idle
periods, some coordination between device state and entering/exiting low-power
state is needed.

Various interactions to accomplish this coordination are possible.  For the
patch under discussion it is suggested that an appropriate mechanism by which
the power management control app may be informed of changes in device state
would be for the LCD and serial drivers to notify the app about changes in the
state of their devices at exactly the time the state transition is to occur (and
that hotplug is an appropriate method to use for this).  The notification
might be used by the power management app to take the system out of low-power
mode prior to powering up the device, or to note that low-power mode may be
entered now that all conflicting devices are off.  So in this case an app not
using the device for I/O purposes could still benefit from information about
its state.

A similar request was made by another smartphone development team to handle a
dual-core CPU + DSP ARM OMAP system, where changes in DSP or network activity
(i.e., a call or other communication is starting or stopping) are to trigger
changes in system power state.  In this case, the affected devices might not be
all-the-way powered off, but in an intermediate lower-power state.

Now it may be the case that application-level state could be used to manage
these interactions; I have very limited knowledge of what happens above the
kernel (and the device usage models) in the example systems I'm discussing.
Placing the ability to notify of power state changes into the drivers would
seem to be the model that offers the most flexibility, which is probably why
it was originally requested and why I thought it might be appropriate.  If
there continue to be strong reservations regarding the suitability of
kernel-to-userspace device power state notifiers then I'll encourage the
developers to either add their voices directly to the debate or to explore
solutions using existing kernel interfaces and/or pure userspace methods.


-- 
Todd Poynor
MontaVista Software

Re: [PATCH] Hotplug for device power state changes

[Pavel Machek]

Hi!

> Let me throw out an example to help discuss the model best suits that 
> situation.
> An XScale PXA27x "Bulverde", a smartphone platform, has a low-power mode 
> that
> helps conserve battery power during periods of reduced activity while 
> leaving
> the CPU running at a low clock rate (and often idling) to handle any events
> that occur during that time.  In that mode, certain devices must be powered 
> off

...

> A similar request was made by another smartphone development team to handle 
> a
> dual-core CPU + DSP ARM OMAP system, where changes in DSP or network 
> activity
> (i.e., a call or other communication is starting or stopping) are to trigger
> changes in system power state.  In this case, the affected devices might 
> not be
> all-the-way powered off, but in an intermediate lower-power state.

Hey, I want linux smartphone ;-).

In case of that dual-core CPU, does linux really run on both CPUs? Do
we get sources for GSM network stack, too?

Is there some preliminary docs about such beasts available somewhere?
Dual CPU design for phone certainly looks interesting...

								Pavel
-- 
When do you have heart between your knees?

Re: [PATCH] Hotplug for device power state changes

[Nicolas Pitre]

On Fri, 14 May 2004, Pavel Machek wrote:

> In case of that dual-core CPU, does linux really run on both CPUs?

No, only one of them.  One is usually an ARM core which runs Linux while the
other is a DSP.

> Do we get sources for GSM network stack, too?

Since they run on the DSP then probably not.

> Is there some preliminary docs about such beasts available somewhere?
> Dual CPU design for phone certainly looks interesting...

Try Google with "site:www.ti.com OMAP".


Nicolas

Re: [PATCH] Hotplug for device power state changes

[Pavel Machek]

Hi!

> > In case of that dual-core CPU, does linux really run on both CPUs?
> 
> No, only one of them.  One is usually an ARM core which runs Linux while the
> other is a DSP.

Ahha, I originaly thought that it is 2 arms, each of them with DSP
capabilities (MMX-like). Thanks.

> > Do we get sources for GSM network stack, too?
> 
> Since they run on the DSP then probably not.

Ok, even without DSP sources it should be possible to create usefull
NetMonitor, but we'll probably not be able to turn phones into two-way
radios... Good.
									Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: [PATCH] Hotplug for device power state changes

[Todd Poynor]

Pavel Machek wrote:

> Hey, I want linux smartphone ;-).

Me too ;)

> In case of that dual-core CPU, does linux really run on both CPUs? Do
> we get sources for GSM network stack, too?

As Nicolas mentioned, the voiceband/RF stuff is probably on the DSP in 
such systems and typically runs in a custom environment, perhaps with 
libraries supplied by the silicon vendor.  I am not myself familiar with 
a Linux-based phone software offering that includes open source GSM 
modem drivers or GSM/GPRS network stacks and such.

> Is there some preliminary docs about such beasts available somewhere?

Nicolas mentioned sites for the popular TI OMAP platform (ARM925/6T), 
another is Renesas SH-Mobile.  I'm not aware of writeups regarding Linux 
support for CPU+DSP designs, if that's of interest; in my capacity I 
mostly treat the DSP as an unmanaged black box device.  But in the 
context of power management there are a few unavoidable interactions, 
for example, phone software developers get cranky when Linux decides to 
power down some or all of the system while the DSP was busy doing 
something important and there's a common clock or power domain.


Todd