On Tue, 19 Nov 2013, Kevin Hilman wrote: > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > > On Tue, 19 Nov 2013, Ulf Hansson wrote: > > > >> At the moment, system PM is already affecting behaviour of runtime PM > >> since it is preventing runtime suspend during system suspend. > > > > Sure. And that behavior is documented. In any case, it's a bug for > > drivers to depend on runtime suspend for carrying out a system suspend. > > As Rafael mentioned, there is bus/pm_domain code that comes into play > here, so I'm not sure it's always a bug. > > IMO, it's not a bug for the driver to depend on runtime PM if the > bus/pm_domain is handling the details. > > On OMAP, we handle all the SoC on-chip devices with a pm_domain since > the low-level PM operations that need to happen are bus-level things not > device-level things. Therefore, drivers for these devices can rely > entirely on runtime PM, even for system suspend. The late/early > callbacks in the pm_domain can see if the device is runtime suspended > already or not and behave accordingly. > > So, this all *can* work by handling it at the bus/pm_domain level, but > as Ulf has mentioned (and I agree) it seems like a clunky workaround > because the PM core is preventing it from happening as one might expect. The problem is that userspace can disable runtime PM at any time by writing "on" to /sys/.../power/control. Once that's done, you can't depend on runtime PM to put the device into a low-power state during system suspend. Now, if the bus-level code always takes care of putting the device into low power during system suspend, then the driver doesn't have to worry about it at all. That's perfectly fine -- but I would hardly describe the situation by saying the driver relies on runtime PM for system suspend. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
