Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

[Ulf Hansson]

On 8 September 2015 at 22:56, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum <oneukum@xxxxxxxx> wrote:
>> On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:
>
> [cut]
>
>>> this would work except for adding a sysfs attribute that would trigger
>>> a runtime suspend while ignoring usage count. Would that be a
>>> better direction?
>>
>> No. If we want this at all, we need a new callback to notify drivers
>> that user space is temporarily uninterested in a device. And the reverse
>> of course.
>> The power model is good. We must not assume that devices can be
>> suspended at will. If we do this at all, we ought to see it as giving
>> strong hints to drivers when a device can be considered idle.
>
> This is a good summary in my view.
>
> The only thing we can add, realistically, is an interface for user
> space to "kick" drivers to check if the devices they handle may be
> suspended at this point (or to run their ->runtime_idle callbacks
> IOW).
>
> That would be quite similar to autosuspend except that the "kick" will
> come from user space rather than from a timer function in the kernel.

Apologize for interrupting the discussion!

Unless I miss the point, I assumes the above is somewhat already
achievable via sysfs when changing the value of the auto-suspend
timeout, since it triggers a call to
pm_runtime_set_autosuspend_delay()...

Also, according to the discussion so far, it seems like we are on
agreement that we should really think twice when considering to extend
the sysfs interface for runtime PM.

>From the change-log/description to $subject patch, I fail to
understand *why* the regular runtime PM *autosuspend* feature isn't
sufficient. Perhaps Irina can elaborate more on the use case, to help
me get a better understanding of the issue!?

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/