Hi, On Wed, Sep 9, 2015 at 12:25 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > 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()... 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 -- 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
