As I understood it, the "parents" are simply things the device has dependencies on. Since the dependencies are different, there is at least potentially a benefit in being able to dismiss those dependencies serially (that is, as the dependency on each device goes away, tell that parental device that its parental role has been satisfied and that the child is no longer depending on it as a parent). scott -----Original Message----- From: linux-pm-bounces@xxxxxxxxxxxxxx [mailto:linux-pm-bounces@xxxxxxxxxxxxxx] On Behalf Of Pavel Machek Sent: Thursday, August 11, 2005 9:10 AM To: Alan Stern Cc: Linux-pm mailing list Subject: Re: [linux-pm] Re: Runtime PM and device locking Hi! > > This solution is very similar to the power object tree patch I'm > > currently working on. The main difference is that I'm using > > pre-state-change and post-state-change notification methods. The > > advantage is that we should be able to use an iterative algorithm, > > allowing for deep power trees. I'll post code soon. > > I'm looking forward to seeing it. However, I think an iterative > algorithm may be impractical, to a greater or lesser extent. (Not to > mention the fact that in any particular case we never need both pre- > and post- > notifications.) > > Consider a device that has many power parents (P1 - Pn). A typical > power-state change for this device might have to go like this: > > Do something to the device. > > Notify P1. > > Do some more to the device. > > Notify P2. > > Do some more to the device. > > ... > > Notify Pn. > > Do the last thing to the device. Ouch, thats really ugly. Is it really neccessary to do something to the device just after notifying parent? I thought it would be more like mouse "oh, I'm idle". power myself down. tell all my parents that they can power down my cord. If something is neccessary to be done after changing parent state, I'd do it during call from parent. Pavel -- if you have sharp zaurus hardware you don't need... you know my address
