Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux