On Mon, 13 Feb 2012, Rafael J. Wysocki wrote: > > I'm not sure if this is really the right approach. What you're trying > > to do is implement two different low-power states, basically D3hot and > > D3cold. Currently the runtime PM core doesn't support such things; all > > it knows about is low power and full power. > > I'd rather say all it knows about is "suspended" and "active", which mean > "the device is not processing I/O" and "the device may be processing I/O", > respectively. A "suspended" device may or may not be in a low-power state, > but the runtime PM core doesn't care about that. Yes, okay. We can say that this patch tries to implement two different "suspended" states, basically "low power" and "power off" (or D3hot and D3cold). > > Before doing an ad-hoc implementation, it would be best to step back > > and think about other subsystems. Other sorts of devices may well have > > multiple low-power states. What's the best way for this to be > > supported by the PM core? > > Well, I honestly don't think there's any way they all can be covered at the > same time and that's why we chose to support only "suspended" and "active" > as defined above. The handling of multiple low-power states must be > implemented outside of the runtime PM core (like in the PCI core, for example). That's the point. If this is to be implemented outside of the runtime PM core, should the patch be allowed to add new fields to struct dev_pm_info (which has to be shared among all subsystems)? Or to put it another way, if we do add new fields to struct dev_pm_info (like can_power_off) in order to help support multiple "suspended" states, shouldn't these new fields be such that they can be used by many different subsystems rather than being special for the full-power/no-power situation? Likewise, should new routines like pm_runtime_allow_power_off() be added to the runtime PM core if they are going to be used just by PCI? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
