Hi,

On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson [off-list ref] wrote:

On 8 September 2015 at 22:56, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Tue, Sep 8, 2015 at 9:35 AM, Oliver Neukum [off-list ref] wrote:

quoted

On Tue, 2015-09-08 at 01:10 +0000, Tirdea, Irina wrote:

[cut]

quoted

quoted

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()...

Well, from the initial comment in drivers/base/power/sysfs.c:

 *
 *    NOTE: The autosuspend_delay_ms attribute and the autosuspend_delay
 *    value are used only if the driver calls pm_runtime_use_autosuspend().
 *

Some drivers don't do that and they would be the primary target
audience for the new interface (if we agreed that it was useful after
all).

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.

That certainly is correct and not limited to 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!?

My understanding is that the idea would be to trigger an attempt to
suspend via a specific event (eg. lid closes) rather then via an
inactivity timer.

Thanks,
Rafael