On Fri, 10 Jun 2011, Rafael J. Wysocki wrote: > 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. Right. For example, consider the USB subsystem. It has separate entry points for system suspend and runtime suspend. These routines decide whether or not wakeup should be enabled, check the device's current power state, and do a few other things; then they call the driver-level routines. Each driver has a single suspend routine; all it does is quiesce the device and make sure I/O queues are stopped. The subsystem code then takes care of setting the proper power state. Alan Stern -- 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
