On 21 November 2013 16:54, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 21 Nov 2013, Ulf Hansson wrote: > >> >> 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. >> >> But they are, since that is exactly what these driver depends on >> during system suspend. > > Not at all. These drivers rely on the bus-level code's suspend > routine to handle system suspend. They don't rely on runtime PM. > >> And since the power domain invokes the runtime >> callbacks, normally CONFIG_PM_RUNTIME is needed for the callbacks to >> be set up from in the bus/driver. > > No, it isn't. You can always write callbacks that get compiled even > when CONFIG_PM_RUNTIME isn't enabled. It's very easy -- all you have > to do is change > > #ifdef CONFIG_PM_RUNTIME > > to > > #ifdef CONFIG_PM You nailed it here! Since you consider this to be allowed from dependency point of view, all my problems described would be "solvable". :-) Regarding the SET_RUNTIME_PM_OPS macro, which today relies on CONFIG_PM_RUNTIME should then be moved to CONFIG_PM instead. As prerequisites, drivers using this macro, obviously need to implement the runtime PM callbacks within CONFIG_PM as well. If that makes sense to you as well, I will start working on converting them that needs. > >> I suppose that the OMAP SoC maintainers were accepting that this >> dependency were allowed to exist, since that was the only solution to >> their problem at that point. >> >> Today, several years later, we are still indirectly pushing those SoC >> maintainers that faces similar issues, to accept this dependency >> between system suspend and runtime suspend. I see a conflict here. :-) > > It's only a misunderstanding. There is no dependency. > > >> I started drafting a new RFC according to your suggestion. Soon I >> realized that using such a callback for .suspend_late will make >> drivers/buses system suspend to depend on runtime suspend, (which my >> RFC also has problem with). So I guess this is not a recommended set >> up from the PM maintainers. Wandering in circles... :-) > > Same misunderstanding as before. The drivers merely need to be written > so that the callbacks are compiled whenever CONFIG_PM is enabled rather > than CONFIG_PM_RUNTIME. I will submit a patch for a "generic suspend late" asap. I noticed the pm_generic_suspend_late already existed in similar form as the other generic functions, so I suggest we leave that as is. We name this new one as, "pm_generic_suspend_late_runtime", to indicate some relationship with runtime PM. If you have other suggestions, please advise me. Kind regards Ulf Hansson > > 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
