On Friday 03 December 2004 2:19 pm, Benjamin Herrenschmidt wrote: > I don't know how the system reacts to PME. On mac, we have no way that I > know for software to detect that it happened. It's purely some logic > that works independently of the CPU that triggers the wakeup when the > machine is sleepnig. > > Maybe on x86, you have a way to be informed of PME things ? It's visible in the PM capabilities, just as on Macintoshes. Both systems could inform at least by polling, and I'd hope by better mechanisms too. > > Non-ACPI systems with PCI can still detect and process PME, > > but I'd expect they would just resume() the devices that were > > issuing the PME signal. > > But that's off band from the normal PM calls. That is, I would expect > the controller to simply forward the resume event to some higher levels > in the system, that will trigger the system resume which will then > trigger the resum() callbacks dance. But I see your point about having > potentially havign a local resume. That is, you put your bus into > suspend mode (local/dynamic PM), and in the middle of a subsequence > suspend process, That is, a "sleep transition"? The word "suspend" is way too ambiguous. I think we could probably agree to use "sleep" for the system-wide states, but there are too many contradictory uses of "suspend" for me to want to use it for much more than describing a particular driver call. > get a resume from a device... I'd rather ignore it at > this point. That'd certainly be a simplification, and my main issue with that option is wondering what to do when that _over_simplifies. > > I'm curious how you think composite hardware modules should > > handle suspend. I hope there's a better name for those; > > the case is several pieces of hardware (say, four different > > controllers) that collaborate, and rely on invariants like > > "if this controller is active, so is this other one"(*). > > 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". > > The point being, sometimes drivers need to suspend and resume > > each other ... and for PM, the goal is to keep everything > > suspended except when it's in active use. I've not seen any > > reason to redefine suspend() and resume() to apply only to > > system sleep state transitions. > > I agree, but we need to properly pass to the driver the semantic > information of either doing a functional freezing (rejecting or > blockingany subsequent request from upstream) or letting it do some kind > of auto-resume. Annything more complicated will require explicit > collaboration between the drivers (hooks etc...). Don't all the suspend() methods imply FREEZE? > But anyway, this is why I think we need to go on now with the suspend > calls we defined (plus adding a parameter to resume), with the explicit > precision that drivers must be ready to deal gracefully with additional > calls we may define. For example, one sent when the sysfs thing is > written to would make sense. What are all those "calls we defined", and what would that extra parameter be used for? There's no meaningful way to require that "drivers must be ready ..." for arbitrary future stuff. > > (*) One particular example: a USB OTG device consists of > > at least three controllers + drivers, counting just the > > lowest level "real hardware". ... > > I'm not sure I understand what OTG is, but from what you describe, there > should be no problem putting them in some kind of hierarchy... 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 ... ;) - Dave
