On Friday, June 10, 2011, Mark Brown wrote: > On Fri, Jun 10, 2011 at 08:38:22PM +0200, Rafael J. Wysocki wrote: > > On Friday, June 10, 2011, Mark Brown wrote: > > > > I think from an interface point of view it's something like > > > UNIVERSAL_DEV_PM_OPS() and friends, probably with some additional ops > > > that can do the glue bits like enabling wakeup and quiescing activity. > > > I'd need to think harder about what exactly that'd look like - for my > > > cases the fundamental thing I want to say is that there's one suspend > > > routine and one resume routine and I'd like some framework code to work > > > out when they're called. > > > Can your device generate wakeup signals? > > I am interested in a fairly large selection of devices but broadly > speaking any off-SoC device can generate wakeups if it can generate > interrupts. So, there are a few things to consider: * Can the device do things like DMA? * Does the driver use a workqueue? * Does it use timers? In all of the above cases your system suspend handling will require extra care to make sure those things won't get in the way of the suspend process. Next, what subsystem (e.g. bus type) is the driver going to work with? If the subsystem is "smart" enough, it can take care of many things, like "powering off", wakeup preparations and so on. Now, there are a few combinations possible. First, if the subsystem is "smart" and the driver need not take care of the things listed above, then very likely .runtime_suspend() and .suspend() can do the same and UNIVERSAL_DEV_PM_OPS() can be used. Next, if the subsystem is "smart", but the driver needs to take care of those things, then .suspend() has more to do, but very likely .runtime_suspend() and .suspend_noirq() can do the same, while .suspend() may simply prepare the device for the next stage. And so on. It's probably fair to say that everithing depends on the subsystem, what it does and what it expects from the driver. In the extreme case, when the subsystem is like the platform bus type, the driver unfortunately is on its own and has to deal with the whole complexity. 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
