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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
