Hi, On Wed, Sep 9, 2015 at 1:13 PM, Octavian Purdila <octavian.purdila@xxxxxxxxx> wrote: > On Wed, Sep 9, 2015 at 2:50 AM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: >> >> 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. >> > > The best example and actually the very specific problem we want to > solve is handling touchscreens on a phone / tablet. When the screen is > turned off, it is ideal to suspend the touchscreen for two reasons: to > lower the power consumption as much as possible and to prevent > interrupts to wake-up the CPU when the user touches the device, and > thus save even more power as we allow the CPU to stay in deep idle > states for longer periods. > > Note that when the screen is turned-on again, we want to resume the > touchscreen so that it can send events again. In fact, then, what you need seems to be the feature discussed by Alan and me some time ago allowing remote wakeup do be disabled for runtime PM from user space as that in combination with autosuspend should address your use case. > This is different then the lid closes examples, as in that case the > user can not generate new events and thus the usual autosuspend > feature is probably good enough (if the suspend power and autosuspend > power consumption is similar). Autosuspend just means checking the device state periodically and suspending it if idle (not in use). It doesn't affect the energy consumption in the suspended state. 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
