On Fri, 2004-12-03 at 15:34 -0800, David Brownell wrote: > That'd certainly be a simplification, and my main issue with > that option is wondering what to do when that _over_simplifies. The problem is that we can do that for ages, and never come up with anything, or worse, come up with an over-engineered mamoth... I'd rather go toward the simple way, making sure we define the callback interface to drivers in a way that is flexible enough to move forward later. For example, while we don't have partial tree suspend, and our whole list management in the PM core makes it difficult to mix system sleep with local PM, the core may be changes/rewritten, without impact on the actual callback semantics, or by simply adding new calls, existing drivers thus not breaking for sleep. > > They either can be organized in some hierarchy, or if they can't then > > the drivers will have to find local ways of collaborating (hooks, > > whatever). For those cases, it would make sense to add virtual nodes to > > the PM tree that don't directly match a struct device tho, I agree. > > Thing is, I think in those cases a "web" is maybe a better model > than a "tree". Good luck designing a dependency model that will work out ... I think we can pretty much make things work as a tree, the really nasty cases can be dealt with special casing or explicit knowledge of the relationship. Overdesign is our main ennemy. > Don't all the suspend() methods imply FREEZE? Only when issued from system sleep. Local operations or dynamic PM or whatever userland-triggered mecanism may be auto-wakeup, which in my book doesn't include freeze... > What are all those "calls we defined", and what would that extra > parameter be used for? Hrm... should I really rewrite all of the discussions we had here for a couple of monthes now ? Isn't it fairly clear that we defined the need for sleep related "freeze/suspend/standby" and the need for some more precision on the resume() side for knowing what we are resuming from ? I have this horrible feeling is that as soon as we stop talking for a week, it's like nothing was said, everything is forgtten, and we have to re-explain everything from scratch. We are making 0% progress there ! > There's no meaningful way to require that "drivers must be ready ..." > for arbitrary future stuff. No but there are ways to deal more gracefully than others. Honestly, you give me impression that you won't let any line of code be written before you have designed the ultimate uber PM mecanism that can cure world hunger. I think that is the wrong way to go and has proven wrong each time we have tried going that way in linux. > There's some info at http://www.linux-usb.org/gadget/h2-otg.html > but it's got a big gap where "Linux PM" should fit. The OTG > controller can be sort of the root of the tree (true on both > OMAP and PXA27x processors) in configurations where it's used, > but the platform bus sort of expects an excessively flat sort > of hierarchy ... ;) It's easy to add hiearchy to the platform bus. Or do an OTG bus type, or whatever for that purpose. Ben.
