On Friday, June 10, 2011, Mark Brown wrote: > On Fri, Jun 10, 2011 at 08:49:03PM +0200, Rafael J. Wysocki wrote: > > On Friday, June 10, 2011, Mark Brown wrote: > > > > It seems like everyone's agreeing with each other here - from the user > > > side the request seems to be largely for core infastructure like > > > UNIVERSAL_DEV_PM_OPS() (which I'm not sure is a good idea any more given > > > that it doesn't do anything to handle the runtime/system interaction?). > > > I'm not sure what you mean here. First, UNIVERSAL_DEV_PM_OPS() actually > > does what it says, defines a set of operations to use for system suspend, > > hibernation and runtime PM all the same. > > Right, but in the light of what you guys are saying about the > interactions between runtime suspend and resume I'm no longer clear that > that is actually sane for something which does use runtime PM, and of > course if a driver wants to support the wake configuration interface > then this might also fall out of the window. It is not generally safe and there are multiple factors deciding of it (see the message I've just sent for details). > > The Kevin's point originally was that it might be desirable to do things > > like calling pm_runtime_suspend() from a driver's (system) .suspend() > > callback, if I understood it correctly, and the answer was that it wasn't > > the right thing to do (for reasons given elsewhere in the thread). > > Yeah, I think it is too. > > > Your point seems to be that simple drivers should not be required to > > define separate callback routines, for example, for system suspend and > > runtime PM. However, they aren't required to do so, they can point > > all of their "suspend" callback pointers to the same routine, which is > > what the UNIVERSAL_DEV_PM_OPS() macro does. > > So that's definitely safe? I guess this partly comes back to the thing > I'm saying about how I'm finding all this stuff difficult to reason > about, every time I see such discussion I get confused about needing to > worry about it or not. Well, it's just that multiple things go into play here: the subsystem, the overall complexity of the driver and so on. I can probably say what's good for a PCI driver, but that may not be suitable for a USB driver, for one example. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
