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

[Octavian Purdila]

On Wed, Sep 9, 2015 at 4:55 PM, Oliver Neukum <oneukum@xxxxxxxx> wrote:
> On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
>> > Note that when the screen is turned-on again, we want to resume the
>> > touchscreen so that it can send events again.
>
> Why is it impractical to close the fd for the touchscreen?
>

I am not sure, but I think it is this way due to historical reasons.
On Android devices early-suspend was used originally to save power
when the screen was turned-off but the device was not suspend. Later
Android moved to power HAL [1] and run-time PM for some devices,
however that is not sufficient for touchscreen.

i2c touchscreen devices usually have two low-power states: a deep
power state where event collection is disabled and the device needs to
be poked via i2c to restart collecting events and a shallow power
state where the device reduces the internal polling rate after it is
idle for some time. The latter it is usually implemented directly in
hardware. That means that you can't really implemented auto-suspend
with the deep power state, since the device can not resume itself.

To address this limitation, Android used early suspend (and then the
power HAL mechanism) where the upper layers signals when you can turn
on or off certain devices.

I have added Colin and Arve to this thread who maybe can answer this better.

>> 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.
>
> I'd doubt that. Suppose you put the phone into your pocket while
> the device isn't suspended. The continuous stream of spurious events
> will keep it awake.

I agree.

> The ability to disable remote wakeup is necessary but not sufficient.
>

I don't know enough about remote wake-up, but do we even need to use
it for this kind of devices?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/