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

[Tirdea, Irina]

> -----Original Message-----
> From: linux-input-owner@xxxxxxxxxxxxxxx [mailto:linux-input-owner@xxxxxxxxxxxxxxx] On Behalf Of Rafael J. Wysocki
> Sent: 08 September, 2015 0:20
> To: Tirdea, Irina
> Cc: Alan Stern; linux-pm@xxxxxxxxxxxxxxx; linux-input@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Brown, Len; Pavel Machek;
> Purdila, Octavian; Dmitry Torokhov
> Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
> 
> On Monday, September 07, 2015 11:42:41 PM Irina Tirdea wrote:
> > Add new option to sysfs control interface, allowing the user to force
> > suspend the device.
> 
> Had we thought this had been a good idea, we'd have added that thing to
> the interface from the start.
> 
> The problem with it is that user space generally doesn't know when it is
> safe to suspend a device, so it cannot force anything into runtime suspend.
> 

Yes, this is generally true. 

However, in the scenario I mentioned this is exactly what is happening.
When turning off the screen of a mobile device, the user space
is the one that suspends the devices that are not needed in order to save power
(like touchscreens). Each such driver export an enable/disable attribute
that calls the same code as resume/suspend (e.g. touchscreen drivers ads7846,
ad7877 and most Android drivers not merged upstream). This adds more
complexity to every driver by adding one more logical power state.
It would be good to have a common interface instead of doing this in
every driver.

I might have not used "forced" in the proper way here. What I mean by it is that
the device can be runtime suspended while ignoring the runtime usage count.

> > This is useful for devices that need to be
> > suspended when closing the lid of a laptop or the screen of a mobile
> > device, while user space still holds open handles to it and the
> > system does not enter system suspend.
> >
> > Add the "off" option to the sysfs control power interface, along with
> > the already present "on" and "auto". When this attribute is set to
> > "off", the device will be force suspended by calling its runtime
> > suspend callback and disabling runtime power management so that
> > further accesses to the device will not change the actual state.
> 
> And how is user space supposed to know that it doesn't break things
> this way?
> 

In this implementation, user space is only allowed to change the states
bottom-up in the sysfs hierarchy (it cannot force suspend a device if it
has children that have not been suspended by user space).

Another way to do this is to keep runtime power management enabled
but to force the usage count to 0 while the device is set to runtime mode
"off".

> > The device can be resumed by setting the attribute to "on" or "auto".
> > The behavior of the interface when switching only between "on"
> > and "auto" states remains unchanged.
> >
> > Signed-off-by: Irina Tirdea <irina.tirdea@xxxxxxxxx>
> > ---
> >
> > Hi,
> >
> > This is a proposal for suspending devices when the closing the lid of
> > a laptop or the screen of a mobile device.
> >
> > I am testing this with a Goodix touchscreen [1] for an Android mobile
> > device. Android has an user space layer (power HAL) that would normally
> > close the touchscreen when the screen is closed. Android touchscreen
> > drivers usually provide a custom sysfs interface to allow this.
> > This would be better implemented in a common place, to avoid code
> > duplication and to simplify the driver code (as previously discussed
> > in [1]).
> >
> > I know there are more ways to implement this, so I would appreciate
> > your feedback.
> 
> So the feedback is that this is not going to work in general.  Please
> use a different approach.
> 

Would it work if this would be a capability that individual drivers need
to declare?

In the previous discussion thread , there were a couple of options
mentioned, but none seemed to reach a consensus. You mentioned
adding a "more aggressive runtime PM mode" [1]. I'm not sure how
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?

Thank you,
Irina

[1] http://marc.info/?l=linux-input&m=140564626306396&w=2

> 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