On Sun, 2005-03-06 at 11:27 -0500, Alan Stern wrote: > On Sun, 6 Mar 2005, Benjamin Herrenschmidt wrote: > > > Ok, I'll need to take more time re-reading this and giving you a more > > complete answer, but a quick note for now: I have been thinking about a > > model that would help deal with both "local" suspend and deal with > > dependencies. > > > > For example, a device may idle suspend, and the parent may want to be > > notified so that when all the childs are idle-suspended, it may suspend > > the bus. That sort of things. > > > > I have some idea based on a definition of power states as an array in > > the driver, where the driver exposes the parent/child state dependencies > > and exposes a state name to sysfs. I posted some blurb about this a > > while ago on this list btw. > > I saw that when it appeared. It struck me as more complicated than we > need. But I agree that there ought to be a way for userspace and drivers > to communicate mutually meaningful state names. Well, my idea was flexibility, with simple defaults. That is, it doesn't need to be complicated. A simple driver can use a "default" state table provided by the core and not bother for example. A richer driver can define more states. > Notifying parents when children are auto suspended... This can probably > be done without involving the PM core. I was thinking about using the abstract state definition I described in my previous email such that a parent (bus) defines the bus states. For example USB defines running, suspended, off for example, PCI defines D states, etc... So that devices can properly define their state dependency (as explained in that previous email) based on the parent bus states. I don't think it's that complex if you think about it. And I think the problem _is_ complex to solve anyway. I've been struggling with those ideas for a while, trying to find simple solutions to a complex problem :) I suppose we'll have to bit the bullet at one point, but if we can make it so that we have a reasonable "default" that makes it easy for most drivers that don't need subtlety (like pci based network drivers), and some easy conversion for USB, we have covered a good deal of the needs. Ben.
