-----Original Message-----
From: linux-input-owner@vger.kernel.org [mailto:linux-input-owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki
Sent: 08 September, 2015 0:20
To: Tirdea, Irina
Cc: Alan Stern; linux-pm@vger.kernel.org; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org; 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:

quoted

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.

quoted

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".

quoted

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 <redacted>
---

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html