Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > 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. We handle that too. The way we handle it, that the pm_domain code "knows" that the device *should* be runtime suspended by the time the pm_domain suspend_noirq callback is called. So it checks pm_runtime_status_suspended() and if the device is not runtime suspended, the pm_domain will "forcibly" runtime suspend the device (which just means, calling the driver's ->runtime_suspend(), doing the bus-level magic, and setting the runtime PM state accordingly.) This is arguably the same approach as the using the late callbacks that you've already described, but it's just done in a hidden way at the bus level. Also, this solution predates the addtion of the late callbacks and I believe may have even been initially proposed by you (or maybe Rafael, I forgot.) Kevin -- 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
